Living, text-preserving Agreements
Keep the complete human agreement in the document and add reusable processes only where selected meaning can be operationalized safely.
The false choice#
Many “smart contract” approaches force a choice between the full human agreement and a smaller executable model. The first remains passive. The second becomes incomplete and can imply that anything not represented in code has disappeared.
A Blue Agreement should keep both.
The Blue pattern#
The Agreement Root preserves complete ordered authored content: recitals, definitions, sections, paragraphs, schedules, and source references. Parties and process parameters link back to exact clauses.
Ordered lists of reusable process occurrences operationalize selected meaning, such as:
- all required parties accept exact content;
- activation follows acceptance, payment, a date, delivery, or approval;
- payment is requested on invoice, milestone, usage, or condition;
- a stage advances after a PayNote confirms settlement;
- a party terminates on notice;
- the Agreement terminates after an uncured breach or attributable condition;
- renewal occurs unless timely notice is recorded;
- the Agreement creates Orders under an accepted framework;
- amendment, dispute, suspension, and closeout follow explicit processes.
The rule is:
Terms preserve meaning. Processes operationalize selected meaning. Root events connect process outcomes to authoritative Agreement state.
Acceptance is not activation#
Acceptance asks whether required participants assented to exact content. Activation asks whether operational rights and obligations are live. A contract may be accepted now and activate after a deposit, a future date, onboarding, a permit, or another attributable condition.
Why process groups are lists#
The design-stage Agreement package uses ordered lists because each direct item becomes one distinct owned process occurrence. Lists preserve authored order, stable occurrence slots, append identity, and a natural reader order. Retired process occurrences remain as history rather than being compacted away.
What must remain text#
Standards such as reasonableness, materiality, good faith, compliance with law, liability, indemnity, governing law, and contested facts usually cannot be converted safely into deterministic Booleans. They remain present unless a separately governed evidence or decision process is introduced.
Product view#
A good Agreement reader shows the complete text and highlights mapped parties and processes. Known processes receive purpose-built cards. Unknown types remain inspectable. Unmapped clauses remain visible as “not automated,” which prevents false completeness.
Status#
This is a coherent design-stage architecture and implementation seed, not yet a released Agreement interoperability profile. Exact package identities, runtime support, fixtures, and conformance are publication gates.