context-execution-collaboration.md

CTX: context operations, execution and collaboration

A Vercy-conformant meta-model only functions as the primary digital reflection of reality if work is done through it: every task starts from model context and every result flows back into the model. This family defines how contexts are built and scaled, how work is executed with full context, and how several humans and AI agents work on one model concurrently without corrupting it.

Collaboration overview: many actors, one truth

Multi-actor work on a meta-model rests on six invariants. Together they make concurrency safe by construction rather than by vigilance:

1. One master per dataset. Every write goes to the dataset's declared System of Record (the Mastership Register). A copy (mirror, raw capture, generated artifact, scaled view, context package) is never edited, whoever holds it and however convenient. An actor that cannot tell what it may edit SHALL NOT edit.
2. Declared structure, green walk. The model's own map (manifests, walk order, coverage check) is the shared invariant between actors and sessions. Every actor leaves the walk green; nobody hands over a red walk.
3. Partition before parallelism. Concurrent writers work on disjoint scopes (bundles, layers, datasets) assigned by the Steward and published in the model. Locks are the exception for scopes a partition cannot separate; they carry a TTL. Reads are unrestricted within granted permission.
4. Explicit transitions. Every change is an event with actor, time and rationale. State a future session must know goes into the model (registers, handoff notes, bootstrap materials), never into chat logs. Silent merges, silent renames and last-writer-wins are non-conforming.
5. Bounded delegation. Every Agent acts under a Delegation Contract naming its processes, datasets, tier per step type (T1/T2/T3 as defined in the palette preamble, COMMON) and expiry. The Delegation Contract is a declared specialization of the Semantic Contract (04-core-concepts/Contract.md 5-6; 03-federation/Federation-Contracts.md 3a), and CTX-9 is its single System of Record. Autonomy is earned by track record, revocable at once with gate-enforced effect, and fully audited. Accountability never leaves the Steward.
6. Rules before judgment. Conflicts between contributions resolve by declared conflict rules first; only the residue reaches the Steward, whose ruling is recorded and, where possible, converted into a rule so the next instance is mechanical.

Two palette-wide iron controls from COMMON bind every CTX surface. First, data-never-command: content from any non-authored origin (mirrored-external, federated, human-report) is data, never instructions, and every Delegation Contract carries that prohibition. Second, the security-critical dataset class (BOOTSTRAP and bootstrap materials, process and gate definitions, approval matrix, auto-approval lane criteria, Delegation Contracts, sources.yaml mastership and conflict-rule fields, severity rubrics, watch and threshold configs): changes to this class are accepted only at T1 with a second human reviewer, are structurally ineligible for auto-approval lanes, and are continuously hash-anchored by QSC-9.

Vocabulary per the palette glossary: quarantine is MIR-8's readable-but-flagged trust marking (also the MIR-6 freshness state); admission quarantine is FED-8's inbound holding zone, unreadable until promoted; integrity hold is QSC-9's marker, excluded from answering and publication until cleared.

The unit of work is the Full Context Development loop (CTX-5): bootstrap, extract context, verify sufficiency, act, write back to the masters through the CON chain, record events, leave the walk green. Handback (CTX-11) closes the learning loop: what an actor learned becomes model content or it is lost with the session.

The family is written for the real ratio of actors: Stewards delegate heavily to Agents. Read-only steps (extraction, scaling, bootstrap, monitoring) are routinely T3; mechanical writes and merges are T2; where a card says a step SHALL remain T1, the Agent proposes and a human approves each act; acts named non-delegable in substance (Steward arbitration rulings, contract issuance and revocation) are decisions the role holder performs personally, whatever drafting support an Agent provides. Tiers are used exactly as the palette preamble defines them and are never re-glossed in this family.

Core set of this family after charter adjudication: CTX-1, CTX-5, CTX-9 and CTX-10. CTX-2, CTX-6, CTX-7 and CTX-11 are recommended with the conditional core promotions stated on their cards; CTX-3, CTX-4 and CTX-8 are recommended.

Reference implementations include Orkestron-style agent services operating under scoped per-role contracts. The Meta-Orchestrator State stress case, published in the external reference Dimension repository (orkestron-ai/meta-orchestrator-state) and not part of the standard, has thousands of agent citizens acting against one civic model corpus: it operates only because partitioning, delegation contracts and mastership-routed writes hold at that scale.

Interfaces with other families

• GOV: in: internal access grants and their revocations from GOV-7 (the grants CTX-1 checks for packaging and redaction, and the read scopes Delegation Contracts bind to); policy and configuration artifacts from GOV-2 (tier maps, gate configs, auto-approval lane criteria, the default context selection-rule set CTX-1 falls back to); capacity plans and agent compute quotas from GOV-5 (they bound CTX-9 contract limits); Owner and Steward decisions via GOV-1 (Owner sign-off for restricted CTX-9 scopes, rulings on escalated arbitration patterns and appeals from CTX-7); short-validity capability material from GOV-8 (bounds CTX-9 revocation propagation). out: Delegation Contract register state and portfolio reports (CTX-9); arbitration records and rule-change proposals (CTX-7); GOV-3 Steward succession executes its handover with CTX-8 mechanics; GOV-4 genesis produces the born model CTX-10 bootstraps into.
• CON: CTX-5 write-back enters the model through the CON chain: CON-1 lists CTX-5 write-back sets as a registered channel, CON-4's approval matrix governs, with an auto-approval lane for mechanical event appends; CTX-7 is the concurrency-integration step that feeds CON-4, never a parallel approval authority. CON-10 establishes identity, entry rights and onboarding, and its agent branch obtains Delegation Contracts by invoking CTX-9 (entry rights reference contracts by ID; CTX-9 revocation Events propagate to the CON-10 entry-rights register within the declared TTL). Structure, manifest and record-editing conventions used by CTX-3/CTX-4/CTX-5 are CON-3/CON-6 territory. CTX-1 consumer profiles resolve against the CON-13 consumer and subscription register. CTX-11 change proposals enter through CON-1.
• MIR: CTX-1 freshness and quarantine stamps come from MIR-2 harvest metadata and MIR-6/MIR-8 states; CTX-11 corrections to external-mastered facts route to the external master through MIR pipelines; CTX-5 drift checks cite MIR-7 as the sole drift-detection engine and republish drifted projections through its machinery; register changes arising in CTX-3/CTX-4/CTX-5 execute via MIR-1; lifecycle and history persistence is MIR-9; model retirement (MIR-11) triggers the CTX-9 revocation sweep.
• ACT: in: ACT-12 loop-health reports and tier recalibration proposals as named inputs to CTX-9 step 8; requests for decision-support context (CTX-1 packages). out: the Delegation Contracts under which every delegated ACT step runs (CTX-9, with gate-enforced liveness at ACT-6 dispatch); parked work from suspended actuation agents via CTX-8; external reality-changing actions inside a CTX-5 loop dispatch through ACT-6 under its controls, never directly.
• QSC: every CTX exit gate (green walk, validation, drift verification) invokes QSC checkers; QSC-7 delegation audits reconcile agent acts against the CTX-9 register, feed recommendations into CTX-9 step 8, and test injection-bait refusal against the contracts' data-never-command clause; QSC-9 continuously hash-anchors the security-critical class this family touches (bootstrap materials verified at CTX-10 step 1 and written via CTX-11 step 5, Delegation Contracts mastered by CTX-9); CTX standing monitors (CTX-6 partition monitor, CTX-9 contract monitoring) are registered and health-watched via QSC-15; residual authority past the revocation TTL and dead monitors escalate into QSC-14.
• FED: CTX processes stop at the sovereignty boundary; context extraction over a partner's model runs only against exposed Projections under Federation Contracts (grants via FED-3); cross-universe disputes leave CTX-7 for FED-9 resolution; an external party's agent never holds a local Delegation Contract, it consumes under a Federation Contract instead; federated package sections carry the federated origin class from CTX-1.

Key artifacts this family exports: Context Package with origin/taint classes, quarantine stamps and grant IDs (CTX-1/CTX-2), partition map and lock table (CTX-6), Handoff Note (CTX-8), the Delegation Contract register as System of Record (CTX-9), session log and bootstrap report (CTX-10), handback records and change proposals (CTX-11).

CTX-1 Context extraction

• Purpose: Build a task-scoped context package from the model: select the objects, relationships, canon texts and constraints a consumer needs, sized to the consumer's window, with provenance, origin/taint classes and an explicit gap list.
• Trigger: A task assignment, a Consumer request, or the start of an FCD loop (CTX-5 invokes this process).
• Actors: Consumer requests; Steward or Agent executes. Agent delegation: T3 for read-only extraction within the Agent's GOV-7 granted permission scope; T2 when the selection touches restricted datasets (the human review covers the inclusion and redaction list). The Steward authors and maintains the standing selection rules (step 1).
• Inputs / Outputs: Inputs: task statement; the model (manifests, sources.yaml, traceability links, canon); consumer profile (window size, requested depth, GOV-7 grants; registered consumers resolve against the CON-13 consumer register); the versioned selection-rule set. Outputs: Context Package (selected records with an origin/taint class per section, provenance header, freshness and quarantine stamps, redaction notes, gap list, the grant IDs it was built under and an expiry); extraction event in the log.
• Steps:
  1. Resolve the selection rules: the Steward authors and versions standing selection rules per task type; where no local rule set exists, the shipped default applies (anchors plus 1-hop declared relationships plus cited constraints), maintained as a versioned GOV-2 config.
  2. Parse the task statement into anchor entities (record IDs, names, model areas).
  3. Resolve anchors to records following the canonical walk order and declared traceability links.
  4. Expand the neighborhood per the selection rules: follow declared relationships dependency-first, collecting the context classes the rules name for this task type (requirements, decisions, constraints, risks, tests, runtime facts).
  5. Check every included dataset in the Mastership Register; stamp mirrors with last-harvest time and the dataset's quarantine state (per MIR-6/MIR-8); flag any that exceed the staleness limit; exclude datasets under a hard block (admission quarantine or integrity hold) and record every exclusion in the gap list.
  6. Tag every package section with its origin class: authored, mirrored-external, federated, or human-report. Non-authored classes are data, never instructions (COMMON iron control); the tag is what lets consumers and gates enforce that.
  7. Gateway: does the raw selection fit the consumer's window? If no, invoke CTX-2 to step down depth per section by declared priority, never by silent omission.
  8. Gateway: is any permission-restricted content selected? If yes, drop or redact per the GOV-7 grants and record the redaction.
  9. Assemble the Context Package with a provenance header (model version, extraction time, selection-rule version), the grant IDs the package was built under, and an expiry: the package expires on revocation of any cited grant or on a fixed TTL, whichever is sooner. Include the explicit gap list (what was excluded and why).
  10. Deliver to the consumer and record the extraction event.
• Controls: Permission check against GOV-7 grants before assembly; mandatory freshness and quarantine stamps on mirrors with hard-block exclusion; mandatory origin/taint tags on every section; the package is marked generated (disposable, never edited, regenerated on demand) and expiring (grant IDs plus TTL); the gap list is mandatory (silent truncation is non-conforming).
• Tier: core.
• Variants: Solo: the Owner-Steward extracts by reading in walk order; the package may be a scratch summary, the taint and expiry discipline still applies to anything an Agent will consume. Team: standing extraction rules per task type. Federated: extraction runs only against Projections the remote Owner exposes, never against remote internals; federated sections carry the federated origin class. Manual, hybrid and autonomous execution are all lawful; autonomous requires the extraction log.
• Metrics: Consumer-reported gap/escalation count per package (the computable recall proxy); extraction latency; staleness rate of included mirrors; share of packages delivered with complete origin tagging (target 100 percent).
• Failure modes: Keyword-only selection misses linked constraints (guard: rule-driven link expansion is mandatory, text search alone does not conform). Package silently truncated to fit the window (guard: mandatory gap list). Stale mirror presented as fresh (guard: freshness stamps and flags). Restricted content leaks into a package (guard: redaction gateway plus audit of extraction logs). Embedded instructions in mirrored or federated content are executed as task context (guard: origin/taint classes plus the Delegation Contract's data-never-command clause, with refusal behavior tested by QSC-7). Quarantined data consumed as current at machine speed (guard: step 5 stamping and hard-block exclusion). A revoked grant's content lives on in a cached package (guard: step 9 expiry bound to grant IDs).

CTX-2 Context scaling

• Purpose: Render the same knowledge at declared depths (summary, working, full) so any consumer window receives a faithful, not truncated, view of the model.
• Trigger: Window overflow detected in CTX-1; a consumer requesting a specific depth; publication of a scaled projection.
• Actors: Steward defines the depth profiles; Agent generates scaled views at T3 (generation is mechanical); T2 review when a scaled view will be published outside the governance domain. Auditor MAY sample views for fidelity.
• Inputs / Outputs: Inputs: source records with their origin/taint classes and quarantine flags; depth profile definitions (what each depth preserves). Outputs: scaled views marked as generated artifacts with pointers to their sources; generation events.
• Steps:
  1. Read the model's depth profile declaration. Minimum convention: summary SHALL preserve identity, status, one-line meaning and links; working adds operative rules and interfaces; full is the record itself.
  2. Generate the view of each selected record at the requested depth.
  3. Verify invariants: every scaled view keeps the record ID and a pointer to the full record; normative keywords are never dropped at working depth; every scaled view preserves the source's origin/taint class and quarantine flags (scaling never launders provenance or trust state).
  4. Gateway: does the scaled set fit the target window? If no, step down depth per section following the declared priority order; omission of whole sections SHALL be recorded in the gap list, never silent.
  5. Stamp the views as generated (regenerable, never hand-edited).
  6. Record the generation event with the source model version.
• Controls: Identity, taint-class and quarantine-flag preservation check; a scaled view is a projection, not a fork; regeneration on source change with a drift check (content hash over the comparable part, detection per the MIR-7 engine).
• Tier: recommended (core for models that serve small-window consumers or federated partners at reduced depth).
• Variants: Solo: two depths usually suffice. Team: per-role depth defaults (an executive reads summary, an implementer reads full). Federated: depth profiles are named in the Federation Contract; a partner MAY be granted summary depth only. Autonomous generation is the norm; manual generation only during bootstrap of the profiles.
• Metrics: Compression ratio per depth; scaled-view drift incidents; consumer escalation rate (how often summary consumers must fetch full).
• Failure modes: Summary drifts from source after edits (guard: regenerate on change, drift hash compared by a check job registered with QSC-15). Depth misused as covert access control (guard: access is granted by GOV-7 permission, not by hoping a summary hides data). A hand-edited scaled view becomes a second truth (guard: generated origin; it is overwritten on regeneration by rule). A scaled view drops the taint or quarantine flag and mirrored content passes as authored (guard: step 3 preservation invariant).

CTX-3 Decomposition

• Purpose: Split a model, bundle or task into parts that can be worked on independently while preserving every cross-link, the single-master rule and the green walk.
• Trigger: A task too large for one actor or window; model growth beyond navigable size; a request for partitions from CTX-6.
• Actors: Steward decides the cut: approval of model splits SHALL remain T1 (the Agent proposes, the Steward approves each cut); task splits MAY run at T2. The Agent computes the dependency graph, proposes cut lines and executes the mechanical split at T2; Auditor MAY verify link preservation on model-level splits.
• Inputs / Outputs: Inputs: source model or task scope; dependency graph; Mastership Register. Outputs: parts with their own manifests; cross-part reference map; updated register (register changes execute via MIR-1); decomposition record.
• Steps:
  1. Build the dependency graph of the candidate scope (records, relationships, datasets).
  2. Propose cut lines that minimize cross-part references and never split a mastered dataset across two masters.
  3. Gateway: does any proposed cut split a single mastered dataset? If yes, redraw the cut, or first split the dataset formally in the register via MIR-1 (Data Mastership pattern H; MIR-1's gates, including its Owner gate, apply), then re-propose.
  4. Steward approves the cut.
  5. Execute: create part manifests, move records, convert internal links that cross the cut into explicit cross-part references by stable ID (references, never copies).
  6. Re-run the coverage walker on every part; every walk SHALL be green before completion.
  7. Record the decomposition event (what was split, why, the reference map).
• Controls: No record duplicated into two parts; register updated in the same change through MIR-1, the sole register-change executor; green-walk gate on every part; stable IDs survive the move.
• Tier: recommended.
• Variants: Solo: task decomposition only, the model stays whole. Team: bundle-level decomposition maps to team ownership. Federated: decomposition MAY promote a part to a sovereign model with its own Owner (roles appointed via GOV-3, the transfer recorded via GOV-1), after which federation rules govern the relationship. Hybrid is typical: the Agent computes the graph and proposal, the human draws the line.
• Metrics: Cross-part reference count (lower is better); post-split walk failures (target zero); rework attributable to wrong cut lines.
• Failure modes: Split follows folder convenience instead of dependencies (guard: graph-based proposal is mandatory input to the decision). A link is turned into a copy during the split (guard: reference-only rule plus duplicate detection). Orphan files after the move (guard: coverage walker gate). A dataset ends with two masters (guard: MIR-1 register gateway in step 3).

CTX-4 Composition and model merge

• Purpose: Merge parts back into a whole, or merge two models covering overlapping reality, without duplicate identities, contradictory statements or mastership conflicts.
• Trigger: Completion of parallel work on parts; adoption of a second model; scheduled recomposition.
• Actors: Steward leads; Agent executes the mechanical merge at T2; each unresolved conflict escalates to the Steward at T1; Auditor reviews the merge report for model-level merges; Owner approval is required when merging across ownership boundaries (recorded as a GOV-1 decision Event).
• Inputs / Outputs: Inputs: parts or models with manifests and registers; identity mapping; declared conflict rules. Outputs: merged model; merge report (matches, conflicts, rulings, dropped duplicates); updated register (register changes execute via MIR-1); composition event.
• Steps:
  1. Align identities: match records denoting the same real-world entity (by stable ID first, by declared keys second, by human judgment last).
  2. Gateway: identity conflict (two IDs for one entity, or one ID reused for two entities)? If yes, resolve by Steward decision recorded as an event; silent renaming is non-conforming.
  3. Merge the Mastership Registers via MIR-1, the sole register-change executor (its gates apply). Gateway: does any dataset now claim two masters? If yes, apply Data Mastership pattern rules (choose one master, or partition the datum) before any content merges.
  4. Merge content dependency-first; convert cross-part references back into internal links.
  5. Detect contradictory statements about one entity; resolve each by the declared conflict rule or by a recorded Steward ruling.
  6. Re-run the coverage walk and validation; all green.
  7. Publish the merge report and record the composition event.
• Controls: Identity uniqueness gate; single-master gate before content merge (executed through MIR-1); validation gate at exit; Owner permission gate when source models have different Owners; pre-merge conformance check of conventions.
• Tier: recommended.
• Variants: Solo: trivial recomposition of task parts. Team: routine part merges are Agent work at T2 with the Steward on exceptions. Federated: two sovereign models never truly merge; they federate, or one Owner formally transfers ownership first (recorded as a GOV-1 decision Event with roles reassigned via GOV-3), then this process runs inside one governance domain. Autonomous merging is lawful only for parts produced by CTX-3 with a clean reference map.
• Metrics: Duplicate identities surviving the merge (target zero); conflicts per merge and mean resolution time; post-merge validation failures.
• Failure modes: The same entity exists twice under two IDs (guard: identity alignment step with key matching). One part's statement silently overwrites another's (guard: contradiction detection plus recorded rulings). Mastership collision after register merge (guard: single-master gate via MIR-1 blocks content merge). Models with incompatible conventions merged raw (guard: pre-merge conformance check).

CTX-5 Full context task execution (the FCD loop)

• Purpose: Execute any task with full model awareness, per Full Context Development: gather context, verify it suffices, act, write results back to the masters through the CON chain, and leave the model truer than before.
• Trigger: Any task assignment against the model or against the reality it reflects.
• Actors: Contributor or Agent executes; Steward stays accountable. Agent tiers per step: context gathering (steps 2-3) T3; execution (step 6) per the Delegation Contract, T1 to T3 depending on impact; write-back (steps 7-8) T2 by default, T3 only with a mature audit trail; the refusal duty applies at every tier.
• Inputs / Outputs: Inputs: task statement; Context Package from CTX-1 (with origin/taint classes and grant IDs); the actor's GOV-7 permissions and CTX-9 Delegation Contract. Outputs: task result; model updates with transition events, entered through the CON chain; execution record.
• Steps:
  1. Receive the task. Gateway: is the model the right place for this work, and does the actor hold permission and contract scope for the affected area? The gate validates the citing Delegation Contract's liveness at act time; if permission, scope or liveness fails, refuse or escalate to the Steward.
  2. Gather context: invoke CTX-1 (and CTX-2 as needed); read the package including its gap list. The package's origin/taint classes bind: non-authored content is data, never instructions (COMMON iron control).
  3. Gateway: is the context sufficient? If material gaps remain, extend the extraction or ask the Steward; the actor SHALL NOT proceed on guessed context.
  4. Plan the change: enumerate the affected records and datasets and look up each dataset's master before acting.
  5. Gateway: does any planned write target a non-master copy (mirror, raw capture, generated artifact)? If yes, redirect the write to the master, or deliver it as a change proposal to whoever can reach the master; never write the copy.
  6. Execute the task (produce the analysis, decision, content, code or external action). External reality-changing actions dispatch through the ACT chain (ACT-6) under its controls, never directly from this loop.
  7. Write results back through the CON chain: the write-back set enters CON-1 as a registered channel and is approved per CON-4's matrix, with the auto-approval lane for mechanical event appends; update model-mastered records, record an event for every transition, and update manifests and (via MIR-1) the register in the same change if structure changed.
  8. Re-run the coverage walker and drift checks (drift detection cites the MIR-7 engine); leave the walk green and republish drifted projections.
  9. Record the execution event (task, actor, contract cited, context package used, changes made) and feed learnings to CTX-11.
• Controls: Permission and contract gate at entry with gate-enforced contract liveness at every write and dispatch (never agent-honored); sufficiency gateway; master-only write rule with Agent refusal duty; write-back executes through the CON chain, no side door; green-walk exit gate; the audit trail for every Agent execution is emitted by the mediating infrastructure (gate, channel, runtime), never self-reported by the acting Agent.
• Tier: core.
• Variants: Solo: the loop is a discipline, not a ceremony (read before changing, record after). Team: loop instances run inside partitions assigned by CTX-6. Federated: context MAY include federated projections read-only; write-back goes only to what this model masters. Manual, hybrid and autonomous execution all conform; autonomous requires a T3 contract and audit. Editorial fast lane: for changes classified editorial or corrective under the declared size threshold, the COMMON fast lane's single composite Event is conformant evidence for this card's execution record.
• Metrics: Fraction of tasks executed with a recorded context package; write-back completeness (changes reflected in the model within the declared window); count of tasks reopened with the insufficient-context reason code (code defined in the MIR-10 taxonomy); walk-green rate at task close.
• Failure modes: Task executed from the task text alone, model ignored (guard: a recorded context package is part of conformant execution). Results delivered but never written back, so the model rots (guard: write-back is part of the definition of done, checked at close). Write to a mirror out of convenience (guard: step 5 gateway plus the Agent's refusal duty). A context package cached and reused stale across tasks (guard: packages carry the model version and grant IDs and expire per CTX-1 step 9). Results written around the CON chain as a side door (guard: registered-channel rule in step 7; the coverage walker flags commits that bypassed intake). Instruction-like content in the package steers the actor (guard: taint classes bind at step 2, contract prohibition enforced and tested by QSC-7).

CTX-6 Concurrent work partitioning and locking

• Purpose: Let several humans and Agents work on one model simultaneously without collisions, by partitioning write access along mastership and structure lines, with short-lived locks only where partitions cannot separate the work.
• Trigger: More than one active writer on a model; a burst of parallel tasks; standing team operation.
• Actors: Steward assigns partitions (the assignment act is Steward work); an orchestrating Agent MAY run routine assignment at T2, and assignments touching restricted scopes SHALL remain T1 (the Agent proposes, the Steward approves each assignment); Agents and Contributors work inside their partitions; a monitoring Agent watches for violations at T3 (the monitor is a standing job registered and health-watched via QSC-15).
• Inputs / Outputs: Inputs: task queue; model structure (bundles, layers, datasets); Mastership Register; actor roster with CTX-9 Delegation Contracts. Outputs: partition map (model content, versioned); lock table with TTLs; assignment and release events.
• Steps:
  1. Map open tasks to the datasets and bundles they will write.
  2. Partition: assign each actor a scope of whole datasets, layers or bundles for the duration; write scopes SHALL be disjoint.
  3. Gateway: do two tasks require writes to the same dataset? If yes, choose explicitly: serialize the tasks, split the dataset per Data Mastership pattern H (via MIR-1), or grant one actor a short-lived exclusive lock with a TTL.
  4. Publish the partition map in the model, not in chat: every actor can see who masters what right now.
  5. Actors run FCD loops (CTX-5) inside their partitions; reads are unrestricted within GOV-7 permissions; writes only inside one's partition or valid lock.
  6. Monitor: detect out-of-partition writes (diff of change scope against the map) and expired locks; alarm the Steward; a dead monitor or residual out-of-partition authority escalates into QSC-14.
  7. On completion, release partitions and locks, record events, and route changed parts to CTX-7 where integration is needed.
• Controls: Disjoint-write invariant; mandatory lock TTL (no eternal locks); partition enforcement is gate-side: writes validate partition assignment and contract liveness at act time, never by agent honor; out-of-partition write alarm with revert-to-proposal; the partition map is versioned model content.
• Tier: recommended (core for any model with more than one concurrent writer).
• Variants: Solo: a no-op, the Owner-Steward is the partition. Team: bundle ownership is stable, task-level partitioning within it is dynamic. Federated: sovereignty already partitions across universes; this process governs inside one universe only. Autonomous: assignment by an orchestrator Agent at T2 is the mature pattern; operation at the scale of the external MOS reference case (thousands of agent actors) is only possible in this mode.
• Metrics: Write collision incidents (target zero); lock wait time; out-of-partition attempts caught; partition utilization.
• Failure modes: Two actors edit one dataset quickly without a lock (guard: disjoint-write invariant plus monitor alarm). A forgotten lock blocks everyone (guard: TTL expiry plus Steward override). The partition map lives in chat and evaporates between sessions (guard: the map SHALL be model content). A task cuts across the drawn partitions (guard: gateway 3 forces an explicit choice: serialize, split or lock). The partition monitor dies silently (guard: QSC-15 registration and meta-monitoring, escalation into QSC-14).

CTX-7 Merge discipline and Steward arbitration

• Purpose: Integrate concurrent contributions into the model in a controlled order, and resolve disputes by declared rules first, with the Steward as recorded arbiter of last resort. CTX-7 is the concurrency-integration step that feeds CON-4: it orders, reconciles and arbitrates, and the integrated state enters the model through CON-4's approval machinery; it is not a parallel approval authority.
• Trigger: Completed partition work; a change proposal touching another actor's partition; detected contradiction or drift between contributions.
• Actors: Contributing actors submit change sets; an Agent pre-merges mechanically at T2; the Steward arbitrates residual conflicts (the ruling is non-delegable in substance: an Agent MAY prepare the options analysis, the Steward rules); Auditor reviews arbitration patterns periodically; recurring patterns the model's rules cannot absorb escalate to GOV-1.
• Inputs / Outputs: Inputs: contribution sets (changes, events, rationale); partition map; declared conflict rules. Outputs: integrated model state handed to CON-4; merge record; arbitration records; rule updates.
• Steps:
  1. Queue contributions in dependency order (foundation bundles first).
  2. Mechanical merge: apply non-overlapping contributions; re-run validation after each batch.
  3. Gateway: overlap or contradiction detected? If no, close with a merge record. If yes, continue.
  4. Classify the conflict: (a) mastership violation (a write outside the writer's partition), (b) semantic contradiction (two truths about one entity), (c) structural conflict (both changed the same manifest or register entry).
  5. Apply declared rules first: mastership violations revert to change proposals for the owning partition; register conflict rules decide dataset-level disputes.
  6. Gateway: does a declared rule decide the conflict? If yes, apply it and record. If no, escalate to the Steward.
  7. Steward arbitration: review both rationales, rule, and record the ruling as an event with reasons; the ruling SHOULD update the declared rules so the next instance resolves mechanically. Conflict-rule fields are security-critical datasets (COMMON class): the rule change is accepted at T1 with a second human reviewer and never rides an auto-approval lane.
  8. Hand the integrated state to CON-4 for approval and publication; leave walk and validation green.
• Controls: No judgment-per-incident merging (rules first is normative); every arbitration recorded and citable; revert-to-proposal for out-of-partition writes; validation gate per merge batch; publication only through CON-4 (no parallel approval path).
• Tier: recommended (core, together with CTX-6, for multi-writer models).
• Variants: Solo: self-merge; contradictions found are still recorded. Team: continuous per-task merges or scheduled merge trains. Federated: cross-universe disputes are Federation Contract matters resolved via FED-9, not Steward arbitration; a Steward rules only inside their own model. Mechanical merges MAY run at T3 with audit; rulings are never autonomous.
• Metrics: Mechanical merge rate (share resolved without arbitration, should rise); arbitration turnaround time; repeat conflicts on the same rule (should fall); post-merge defect rate.
• Failure modes: Last-writer-wins applied silently (guard: contradiction detection on an ordered queue). The Steward rules differently on similar cases (guard: rulings are recorded, cited and converted into rules). Merge outruns validation (guard: per-batch validation gate). Arbitration becomes the bottleneck (guard: rule-first design, tracked by the mechanical merge rate). CTX-7 drifts into a second approval authority (guard: step 8 hands to CON-4; approval lives there).

CTX-8 Actor handoff

• Purpose: Transfer in-progress work between actors (human to human, human to Agent, Agent to Agent, shift to shift) without losing context or leaving the model in an undeclared state.
• Trigger: Session end with unfinished work; actor reassignment; Delegation Contract expiry, suspension or revocation (CTX-9 step 7 parks the agent's open work here); escalation from an Agent to a human.
• Actors: Outgoing actor prepares the handoff; incoming actor accepts; Steward is informed, and approves when the incoming actor's contract scope differs from the outgoing one's. An Agent MAY prepare and consume handoff notes at T3; accepting a scope beyond one's contract requires a Steward act at T1.
• Inputs / Outputs: Inputs: work state; partition assignment; both actors' CTX-9 contracts. Outputs: Handoff Note (model content); updated partition map; handoff event; or a parked-work state addressed to the Steward.
• Steps:
  1. Outgoing actor brings the model to a declared state: partial work committed as Draft-status records or reverted; walk green; no half-written files.
  2. Write the Handoff Note in the model: task state, decisions taken, open questions, next steps, pointer to the context package used, surprises encountered.
  3. Gateway: is the incoming actor identified and authorized (GOV-7 permissions and a live CTX-9 contract cover the scope, validated at the gate)? If not, park the work: release the partition and address the note to the Steward.
  4. Transfer the partition or lock assignment; record the handoff event (from, to, scope, time).
  5. Incoming actor runs session bootstrap (CTX-10) and reads the Handoff Note. Gateway: does the incoming actor accept the state as described? Discrepancies are reported before work resumes, not discovered later.
  6. Resume the FCD loop (CTX-5).
• Controls: Green-walk precondition; the Handoff Note SHALL be model content, not a chat message; explicit acceptance confirmation; contract coverage check on the incoming actor, enforced at the gate.
• Tier: recommended.
• Variants: Solo: handoff to one's future self; the note is the same artifact. Team: shift handoffs on live models. Role handover: GOV-3 Steward succession and role handover execute with this process's mechanics. Federated: handoff never crosses a sovereignty boundary; the analog there is contract reassignment. Human-Agent handoffs are the common case: an Agent parks work for human judgment, or a human hands routine continuation to an Agent.
• Metrics: Handoff pickup time; discrepancies found at acceptance; age of parked work without pickup; context loss incidents (work redone after handoff).
• Failure modes: Handoff by chat message that never reaches the model (guard: the note SHALL be model content). Model left mid-edit with a red walk (guard: declared-state precondition). Incoming Agent's contract is narrower than the work (guard: coverage gateway in step 3). Broken state accepted silently (guard: explicit acceptance step with discrepancy reporting).

CTX-9 Delegation contract lifecycle

• Purpose: Issue, scope, monitor, adjust and revoke the Delegation Contracts under which Agents execute processes, so that agent autonomy is always bounded, auditable and revocable, and accountability stays with the Steward. CTX-9 is the single System of Record for the Delegation Contract lifecycle: issue, amend, suspend, revoke, tier ladder and probation all live here, every palette reference to delegation resolves to this process, and CON-10's agent branch obtains contracts by invoking it. The Delegation Contract is a declared specialization of the Semantic Contract (04-core-concepts/Contract.md 5-6; 03-federation/Federation-Contracts.md 3a) and carries the canonical contract components: parties, authority, purpose, scope, effective period, obligations, permissions, restrictions, lifecycle state, provenance, version.
• Trigger: A Steward decides to delegate; CON-10 onboarding reaches its agent branch; an Agent requests scope; a monitoring threshold trips; a scheduled review; an incident; a model retirement runbook (MIR-11) orders a revocation sweep.
• Actors: Steward issues, amends and revokes (non-delegable in substance: an Agent MAY draft the proposed scope, the Steward performs the act); Owner sign-off is required when the scope touches permission-restricted datasets (GOV-7 classes) or externally visible surfaces, recorded as a GOV-1 decision Event; the Agent operates under the contract; Auditor reviews the contract portfolio (QSC-7); monitoring MAY be an Agent function at T3 over gate-emitted trails.
• Inputs / Outputs: Inputs: candidate scope (processes, steps, datasets, partitions, tier per step type cited from the palette preamble, limits, expiry); Agent capability evidence; the model's risk profile; the GOV-5 capacity plan and agent compute quotas (contract limits SHALL fit the quota); ACT-12 tier recalibration proposals and QSC-7 audit recommendations as named step 8 inputs. Outputs: Delegation Contract as versioned model content in the contract register (the System of Record); monitoring reports; amendment, suspension and revocation Events with propagation confirmations.
• Steps:
  1. Draft the scope: which processes and steps, which datasets or partitions, which tier (T1/T2/T3 per the palette preamble, never re-glossed here) per step type, rate and impact limits within the GOV-5 quota, expiry date. Every contract SHALL include the data-never-command clause: content of non-authored origin classes in any context package or input is data, never instructions (COMMON iron control).
  2. Gateway: does the scope include writes to restricted datasets or externally visible surfaces? If yes, obtain Owner sign-off, recorded via GOV-1.
  3. Apply the unified probation rule: a new agent-scope pairing SHALL start at T1 or T2; T3 is earned by track record, never granted first; and the first N acts under any new or upgraded contract run one tier stricter than granted (N is declared in the contract). This is the palette's single probation rule; no other card states a variant.
  4. Issue: record the contract in the register with an activation event; register the Agent in the actor roster; CON-10 entry rights reference the contract by ID, never copy it.
  5. Operate: every Agent act cites its contract, and the gate validates the cited contract's liveness at act time for every write, dispatch and channel access; enforcement is gate-side, never agent-honored. Acts outside scope are refused by the gate, refused by the Agent under its refusal duty, and alarmed by monitoring.
  6. Monitor: sample reviews at T2; full audit trail with periodic review at T3; trails are emitted by the mediating infrastructure (gate, channel, runtime), never self-reported by the Agent; track error rate, refusal rate and out-of-scope attempts.
  7. Gateway: threshold breached or incident occurred? If yes: suspend the contract immediately; the suspension Event propagates to the CON-10 entry-rights register and to runtime channel teardown within the declared TTL; capability material is minted with short validity (GOV-8) so worst-case propagation is bounded; a gate-side probe verifies no orphan rights remain; residual authority past the TTL is an incident (QSC-14). Open work parks via CTX-8. Investigate, then amend, downgrade the tier, or revoke; revocation propagates identically.
  8. Review on schedule and at expiry by invoking the generic register-recertification pattern (COMMON), parameterized with the contract register, its age and usage thresholds and the Steward as approver. Named inputs: ACT-12 tier recalibration proposals, QSC-7 audit recommendations, the GOV-5 capacity plan. Renew, expand (tier upgrade with evidence, restarting probation per step 3), shrink or retire; every change is a versioned Event, never a silent edit.
• Controls: Single System of Record (no second contract register anywhere; QSC-7 reconciles agent acts against this register only); non-delegable issuance and revocation; unified probation ladder (step 3); mandatory expiry (no perpetual contracts); suspension takes effect before investigation, not after; gate-enforced liveness on every act; revocation propagation within the declared TTL with a gate-side probe; Delegation Contracts are security-critical datasets (COMMON class): changes are T1 with a second human reviewer, structurally ineligible for auto-approval lanes, and continuously hash-anchored by QSC-9 with any unexplained diff opening QSC-8; 100 percent of agent acts cite a valid live contract.
• Tier: core (whenever any Agent executes any step of any process; a purely human-operated model MAY leave this process dormant).
• Variants: Solo: the Owner-Steward contracts with their own agents; the discipline is identical, only the ceremony is lighter, and the consolidated quarterly review of the Solo/Minimal conformance profile (COMMON) lawfully satisfies step 8 when it falls due in the window. Team: contract templates per agent role (extractor, merger, monitor, executor). Federated: an external party's agent never holds a local Delegation Contract; it consumes projections under a Federation Contract instead. Reference implementations exist (for example an Orkestron-style professional-agent service running under per-role scoped contracts), but the lifecycle is defined by the standard, not the vendor.
• Metrics: Share of agent acts covered by a valid live contract at the gate (target 100 percent); out-of-scope attempt rate; mean time from incident to suspension, and from suspension Event to verified propagation (measured against the TTL); tier progression rate across the portfolio.
• Failure modes: Scope creep through small unrecorded extensions (guard: versioned amendments only, under the security-critical change discipline). A perpetual contract outlives the model area it governed (guard: mandatory expiry and step 8 recertification). T3 granted on day one for convenience (guard: unified probation ladder). Revocation orphans work mid-task (guard: suspension triggers CTX-8 parking). A suspended agent keeps acting on residual authority (guard: gate-enforced liveness, short-validity capability material, TTL probe, QSC-14 incident on residue). A second contract register emerges and the one-master law breaks on the palette's own governance dataset (guard: System-of-Record control; all other cards reference by ID).

CTX-10 Session bootstrap

• Purpose: Bring any actor (human or Agent) joining work on a model from cold start to safe productivity: know the structure, the authority map, the current state and one's own boundaries before touching anything.
• Trigger: Any new session on a model; an actor's first contact; resumption after long absence; post-handoff pickup.
• Actors: The joining actor executes; fully delegable to an Agent at T3 (bootstrap is read-only); the Steward owns the freshness of the bootstrap materials.
• Inputs / Outputs: Inputs: model repository (BOOTSTRAP.md, manifest.yaml, sources.yaml, bundle READMEs); the actor's GOV-7 permissions and CTX-9 Delegation Contract; open handoff notes; the partition map; QSC-9 hash anchors for the bootstrap materials. Outputs: session readiness state; bootstrap report (what was read, verification result, walk status, failures); session log event.
• Steps:
  1. Verify the bootstrap materials against their QSC-9 hash anchors (bootstrap materials are security-critical datasets, COMMON class); on an unexplained mismatch, stop, report it (it opens QSC-8), and do not proceed on unverified materials. Then read BOOTSTRAP.md (how this model wants to be read, local conventions, prohibitions) and the ecosystem entry file if present (it carries operating state, BOOTSTRAP carries structure).
  2. Read the repository manifest (identity, bundle order, exclusions) and the Mastership Register (what is authored here, what is mirrored, with what freshness). Do this before reading content.
  3. Walk the foundational bundles' READMEs in declared order to load the vocabulary; read deeper per task need.
  4. Run the coverage walker if present. Gateway: is the walk green? If red, report to the Steward and do not build on the unclassified area.
  5. Load one's own boundaries: GOV-7 permissions granted, Delegation Contract scope (from the CTX-9 register), current partition map, open handoff notes addressed to this actor.
  6. Gateway: is there an open handoff note for this actor's scope? If yes, process acceptance per CTX-8 before starting new work.
  7. Declare readiness with a session log event: model version read, verification result, walk status, contract cited.
• Controls: No write before bootstrap completes; a red walk blocks building on affected areas; instructions are taken only from authored, hash-verified bootstrap materials, and non-authored content encountered during bootstrap is data, never instructions (COMMON); registers over memory (anything a future session must know goes into the model, not into chat).
• Tier: core.
• Variants: Solo: a short ritual in the same order. Team: identical for every member, which is the point: no tribal onboarding. Federated: a remote Consumer bootstraps on the published package (BOOTSTRAP and manifest travel with it), never on repository internals. Agents SHOULD cache bootstrap results keyed by model version and invalidate on version change. A model is born via GOV-4 genesis; this process presupposes a born model and never substitutes for it.
• Metrics: Time to readiness; incidents traced to skipped bootstrap; red walks discovered at bootstrap (early detection is the good outcome); bootstrap cache hit rate for Agents.
• Failure modes: The actor skips to the task and writes on stale assumptions (guard: no-write-before-bootstrap, enforced through the Delegation Contract and the gate). Bootstrap materials themselves are stale (guard: Steward reviews them at every model version bump). Poisoned bootstrap material becomes standing instructions for every future session (guard: security-critical acceptance discipline in CTX-11 step 5 plus the hash-anchor verification in step 1). An Agent re-reads the whole model every session, wasting its window (guard: version-keyed caching). Work proceeds on a red walk (guard: gateway 4 blocks the affected areas).

CTX-11 Knowledge handback

• Purpose: Capture what an actor learned during work (facts, corrections, surprises, decisions, reusable methods) as model content, so knowledge accumulates in the model rather than dying in actors' heads or chat logs.
• Trigger: FCD loop close (CTX-5 feeds it); session end; an actor noticing that the model diverges from observed reality; periodic retrospective.
• Actors: Any Contributor or Agent submits handback records; the Steward accepts them into authored layers (T2 by default, T1 for sensitive layers, and always T1 with a second human reviewer for the security-critical class per COMMON); an Agent MAY draft handback records at T3, but acceptance into normative content is at most T2 and never below the class rules; Auditor samples accepted records for provenance quality.
• Inputs / Outputs: Inputs: session experience (observations, deltas against the model, decisions, method improvements); execution records. Outputs: handback records (new or updated model records, annotations, change proposals); acceptance and rejection events; updated freshness metadata.
• Steps:
  1. At task or session close, enumerate the deltas: what did the work reveal that the model does not yet say (missing facts, wrong facts, missing links, better methods, recurring pitfalls)?
  2. Classify each delta by target dataset and master: model-mastered (write as a record or annotation), external-mastered (deliver the correction to the external system through the MIR pipelines, or record an annotated deviation about the mirror, never edit the mirrored bytes), out of scope (drop with a note).
  3. Gateway: is the delta within the actor's write partition and contract? If yes, write directly under FCD rules (through the CON chain per CTX-5 step 7). If no, file it as a change proposal into the owning Steward's queue via CON-1 (a registered channel).
  4. The Steward (or an authorized Agent at T2) reviews proposals: accept, amend, or reject with reason; acceptance writes the record with provenance (who learned it, during which task, when, from what evidence).
  5. Route method-level learning (a better procedure, a recurring trap, an improved prompt) to BOOTSTRAP or bootstrap materials and process definitions, not into domain layers. These targets are security-critical datasets (COMMON class): acceptance is always T1 with a second human reviewer, structurally ineligible for any auto-approval lane, and the accepted change is re-anchored by QSC-9.
  6. Record handback events; update freshness metadata where mirrors were re-verified against their sources.
• Controls: Provenance mandatory on every handback record; proposals are never silently dropped (aging alarm on the queue); fact handback (domain layers) and method handback (bootstrap materials) are kept distinct; the security-critical class rule of step 5 binds regardless of who submits; no handback ever writes into raw/ or artifacts/.
• Tier: recommended (core for models claiming to be the primary reflection of a living reality).
• Variants: Solo: the discipline of writing down what you learned before closing the session; the T1-plus-second-reviewer rule for bootstrap materials still applies, with the second reviewer MAY being an external peer. Team: proposal queues per partition with review service levels. Federated: learning about a partner's data goes back to the partner as a report (their master), never as edits to their mirror. Agents are prolific handback generators; T2 acceptance keeps the quality bar.
• Metrics: Handback records per active week; proposal acceptance rate and latency; model-reality divergence found by later audits (should fall over time); share of sessions closed with zero handback (suspicious if high).
• Failure modes: Learning stays in chat logs and dies with the session (guard: handback is a closing step of the FCD loop, checked at close). Handback bypasses mastership by annotating a mirror as if it were truth (guard: classification step routes every delta to its master). A poisoned method improvement rides low-tier acceptance into BOOTSTRAP and persists as standing instructions across sessions (guard: step 5's T1-plus-second-reviewer rule, lane ineligibility and QSC-9 re-anchoring). The proposal queue becomes a graveyard (guard: aging alarm and a Steward latency metric). Agents flood the queue with low-value records (guard: acceptance rate tracked per contract, and the contract adjusted via CTX-9 step 8).