Implementation

The Foundations define the semantic contract. The Implementation section provides schemas, envelopes, lifecycle rules, and worked examples. Published schemas and canonical TypeScript interfaces are normative at their declared version; examples and deployment guidance are not additional wire contracts.

Start here

Implementation flow

Begin with accepted outcomes, forbidden effects, and runtime ownership. Keep existing execution machinery where it can enforce the contract. The sequence below is the worked contract path; it is not a prerequisite to build every reference component before the first workflow.

A workable adoption path:

1. Admit — declare the workflow’s actual features and exact required profile revisions; negotiate supported controls before work starts. Conditional requirements remain active even if a caller omits a convenient label. Assign runtime enforcement and evidence owners. (Execution Contract, Control Profiles)
2. Model — define ontology and identity-layer CEIDs for the entity types your workflow touches. (Ontology, Identity Layer)
3. Declare — author a Context Pack with intelligence_refs, policy_layer, tooling_layer, decision_layer, memory_layer. (Context Pack)
4. Compile — feed an invokeAgent envelope and a RunContext into the ContextPackCompiler to produce a CompiledContext. Stop on an applicable policy-expression error.
5. Invoke — run the bounded Planner / Executor / Critic loop; route every side effect through the Tool Gateway. Recheck current authority, exact approval, actual boundary/data destinations, and budget at dispatch. Store operation identity and uncertainty across retries, cancellation and resume.
6. Record — emit a typed DecisionRecord with evidence_refs, approvals, controls_active, and linked effect/postcondition evidence. A decision receipt alone cannot prove completion.
7. Evaluate — score accepted outcomes and denied cases, replay against pinned artifacts, and collect current runtime evidence for the exact profile and release before claiming conformance. Feed reviewed changes through the continuous improvement loop.

Authoritative artifacts

The schemas linked from each doc and the canonical interfaces in src/lib/contextos/types.ts are the authoritative versioned contracts. Foundation prose defines required semantics. Examples are illustrative; adapter and deployment pages are profiles. The compiler and tests under src/lib/contextos/ are the deterministic conformance reference, not a hosted runtime.

See it running

For an open-source system that exercises many of these patterns—Context Pack compilation, governed tools, decision records, improvement workflows, memory, and reviewer profiles—see SecondBrain (Reference Implementation). Its source map is implementation evidence, not proof that every deployment obligation in this spec is universally satisfied.

Common pitfalls

• Hand-assembled prompts. Bypassing the Compiler loses budget control, manifests, and runtime controls; use the pipeline.
• Untyped decisions. Free-form text alone omits the governed outcome and acceptance contract needed to compare and audit decisions; retain the DecisionRecord.
• Unsupported conformance claims. Passing compiler/schema tests or declaring a sandbox does not demonstrate current runtime enforcement. Report missing evidence explicitly.
• Direct adapter calls. Bypassing the Tool Gateway loses native-risk evaluation, authority checks, idempotency, evidence validation, and trace lineage.
• Scalar risk policy. Use native ActionRisk; v1 approval modes are conservative compatibility projections, and gate names remain separate workflow artifacts.
• Memory writes without promotion. All writes flow through the promotion pipeline; direct durable writes are not allowed.