# ── Blueprint metadata (machine-readable; the panel generator and the back-office builder read this block) ──
blueprint:
  aioc: "[ORG]AIOC-TOM"
  parent: "[ORG]AIOC-CH"                  # example code of the Charter; each organisation writes its own Charter's code (Standard §1.7, item 13)
  full_name: "Target Operating Model"
  organisation: "<organisation>"          # filled in each organisation's own copy
  type: "specialised"
  org_aion: "[ORG]AION"
  blueprint_version: "v0.6.3"
  status: "draft"
  template:
    name: "49GAION AIOC Blueprint Template"
    version: "v1.5.0"
    source: "github.com/49g-holding/49GAION-aioc, template/AIOC-BLUEPRINT-TEMPLATE.md @ 06b00d9"
  mother:
    name: "49GAION Target Operating Model"
    version: "part card v1 (DRAFT)"
    source: "github.com/49g-holding/49GAION-protocol, library/cards/target-operating-model.part-card.json and the Protocol section Target Operating Model (§19); Standard §3.1, item 4 (49GAION DR-0016). This text is its mother blueprint"
  writing_repository: "<org>aioc-tom"
  code_project: "<org>aioc-tom, on the organisation's code platform"
  panel_register_id: "none yet"
  capabilities:
    standard: ["Chief of Staff", "Office", "Input socket", "Panel"]
    functional: ["Request Reconstruction", "Needs Requests", "Structuring", "Entity Packaging", "Entity Model Design", "Hand-offs", "Operational Walkthrough", "Independent Review", "Decision Package and Release"]

Blueprint · [ORG]AIOC-TOM · Target Operating Model · v0.6.3

Draft, closed at v0.4.0, 15 October 2026; v0.4.1 the same day changes wording only (decisions/DR-0004): every human position is a HOAC position, and no natural person exists in the system. v0.5.0, 16 October 2026, links this AIOC directly to the stages after it (decisions/DR-0005): a release notice to Process and Position Design on every filing, and the returns of Process and Position Design and of Delivery and Implementation received directly, each carried to an end under the Library's design return contract (§5.10). v0.6.0, 16 October 2026, adds what the model also states and reads (decisions/DR-0006; Annex H): the strategy on one page, how each capability is delivered and how mature it is, the critical value streams, each outside party's journey, the value case, the priority of each element, and records of the work as it runs today, never about a person. v0.6.1, 19 October 2026: the Chief of Staff takes its COS code [ORG]CELL-COSTOM (decisions/DR-0007). Written by [ORG]AIOC-OCO on the directions recorded in decisions/DR-0001, decisions/DR-0002, decisions/DR-0003, decisions/DR-0005 and decisions/DR-0006. Version 0.4.0 adds four features to the closed v0.3.0, and removes or weakens nothing of it: a register of the roles across the release (§5.6; Annex E.17), a run depth (Annex F), two independent authors at Frame and Design (Annex G), and reference models from the 49GAION Library (§5.5; Annex B.5). Every rule here either rests on a 49GAION text, is carried from the case study (docs/DESIGN-BASIS.md; full rule texts in docs/CARRIED-RULES.md), or is new in this AIOC and marked New. Nothing here has run. Every fixed test reads NOT_RUN.

TOM in one page

TOM (Target Operating Model) turns an organisation's own documents into a written model of how it should work. For each part of the organisation, the model sets out what the part must be able to do, how its main work flows, who decides what, and where it hands work to other parts and to outside parties. It names roles and what each decides. It does not say what fills a role.

It serves one person's work, a unit, a company, a group of companies, or a group with independent institutions inside it. Where there are several companies, it designs only the hand-offs between them and with outside parties.

What goes in

1. An approved design request, recorded in Source Lifecycle, the organisation's library of sources: who asks, what the design is for, what should be different, and how fine the model should be (light, standard or deep).
2. The organisation's own documents, read only by reference. The input socket checks them, cuts them into numbered passages, labels each passage with how far it can be trusted, and hands the engine one sealed Input Pack.
3. Answers to what the documents do not say. TOM never asks a person. It asks the Chief of Staff of Source Lifecycle, who gets the answer from the position that can give it, has it approved and recorded, and returns it. Each answer arrives as a new version of the Input Pack.
4. Where the organisation has them, records of how the work runs today, exported by role and by process and never about a person. Where there are none, the model says so and goes on.

Today Source Lifecycle is the only source. Other kinds of source plug into the same socket, each through its own adapter file, and only to be read.

What the engine does, in nine stages

1. Admit: check the request and the connection, and make the Input Pack.
2. Frame: work out what is asked, who may decide it, what exists today, what should change, and what is unknown or in conflict.
3. Structure: split the work into parts, and propose which to design first.
4. Child briefs: for each part, what it must achieve and how anyone would know.
5. Package: gather each part's own evidence, and nothing about the other parts.
6. Design: design each part's model, and write down why. A general pattern may suggest a structure, but it never counts as evidence.
7. Hand-offs: pair every hand-off between parts and with outside parties, list every role once with what it decides, and flag legal questions for a lawyer.
8. Walk: test the model against realistic situations, and record where it holds and where it stops.
9. Decide and release: the organisation decides each element; the decided model is frozen and filed back in Source Lifecycle, and Process and Position Design is told at once.

Each stage has one input, one output and one test that says when it is done. The frame and each part's design are written twice, separately, by two AI engines of different families; their differences are settled on the sources or put to the organisation. Inside every stage, three or more other independent AI engines check the output: each alone first, then in a short debate held to quotes. They do not vote. A human position, the TOM Design Lead, rules on what they still dispute.

What comes out: the TOM Release

1. The Decision Package: a plain summary, what is still unknown, and the choices to make.
2. For each part: what it must be able to do, how each capability is delivered and how mature it is, its main flows and which are critical, who decides what, and where it hands work over, each with its reasons and sources.
3. The hand-offs between parts and with outside parties, each outside party's journey through the organisation, and the legal questions for a lawyer. 3a. The strategy on one page, the value the change is meant to bring, the priority of each element, and how the work runs today where records exist.
4. The role register: every role in the model, what it decides, what it answers for, and what it hands to whom.
5. The test against situations, and the quality checks made at each stage.
6. What is still open: unknowns, assumptions, deferred items, and any defect the organisation chose to accept.
7. The record: the sources used, and the trace from each statement back to its source.

Who uses it

• The decision-maker who asked for the design decides each element: accept, correct or reject. Silence decides nothing.
• The positions that lead each part check its model against how the work runs.
• Process and Position Design, the next stage, is told of each decided release directly and reads it, starting with the role register. It sends back what it cannot use, and so may Delivery and Implementation, the stage after it.
• Every return goes back and forth until it ends: answered by a new release, answered by a decision, or set aside by decision and carried forward as a known defect or a decided assumption. None is left open.
• Auditors and lawyers use the sources, the trace and the record.

Closure. This blueprint is closed at v0.4.0; v0.5.0 adds its links to the stages after it, and v0.6.0 what the model also states and reads (Annex H); neither removes anything. Every stage is fixed by its input, its output and its done-test (§5.0), and every object a stage makes has its field list (Annex E; docs/CARRIED-RULES.md). It holds no open design question. What remains is to build and test it, and the decisions that only a human seat can take, listed once in §13.

0. Identity and lineage

Lineage. This AIOC joins six capabilities of an earlier organisation-design chain into one unit: request reconstruction, commission decomposition, entity work packaging, single-entity operating-model design, cross-entity assembly (mandated there but never designed; here narrowed to Hand-offs), and the operational walkthrough. A seventh, requester stewardship, is kept, split: its person-facing half is done by the Chief of Staff of [ORG]AIOC-SL; its other half (capturing the request, tracking what is missing, carrying decision rows) is done here (§5.1, §5.2, §5.9). docs/DESIGN-BASIS.md says, for every rule, why it is here and which test case checks it. docs/CARRIED-RULES.md holds the full text of the carried rules that this blueprint states only in short. The organisation's private register of the earlier texts is kept in its code project.

The earlier work is a case study. This AIOC was designed by studying an earlier organisation-design chain. That chain is a case study. Its rules are reused here, in full text in docs/CARRIED-RULES.md. Its tests and its run results count for nothing here. Its code is not wired in: every code step of this AIOC is written new against this blueprint, with its own tests, and the earlier code is kept unchanged in the code project only to be read. No earlier result is the reason for a rule, and nothing is left out or narrowed because of one. Every fixed test of this AIOC reads NOT_RUN until it runs.

1. Card (49GAION Operating Protocol §3)

card:
  unit_kind: "AIOC"
  code: "[ORG]AIOC-TOM"
  parent: "[ORG]AIOC-CH"                  # example code of the Charter, the root AIOC; only it has parent none (Standard §1.7, item 13)
  inner_units: ["[ORG]CELL-TDL", "[ORG]CELL-COSTOM", "[ORG]POD-TRR", "[ORG]POD-TS", "[ORG]POD-TEP", "[ORG]POD-TEM", "[ORG]POD-TH", "[ORG]POD-TW", "[ORG]POD-TR"]
  type: "specialised"
  org_aion: "[ORG]AION"
  card_version: "v0.6.3"
  input_door: "Chief of Staff"
  wake: { method: "queue", verified: false }
  receives:
    - kind: "run request"                 # a Work Item from the Requesting Authority's Cell, through the HU input port; it carries only the reference of an approved Design Request source in [ORG]AIOC-SL
      format: "Work Item (Protocol §4.1) whose sources field holds one Design Request reference"
      acceptance_test: "TEST-TOM v5, cases 3, 29, 44, 81, 89"
      decision_needed: false
    - kind: "source reference"            # served through an adapter of the Input socket; in this version, the output socket of [ORG]AIOC-SL
      format: "source reference (contracts/source-reference.schema.json)"
      acceptance_test: "TEST-TOM v5, cases 1-6, 31-34, 44-52, 119"
      decision_needed: false
    - kind: "needs answer"                # the output of a needs request sub-item
      format: "needs answer (contracts/needs-answer.schema.json)"
      acceptance_test: "TEST-TOM v5, cases 10-12, 35, 36, 49, 118"
      decision_needed: false
    - kind: "needs status"                # accepted, returned or asked, from [ORG]AIOC-SL
      format: "needs status (contracts/needs-status.schema.json)"
      acceptance_test: "TEST-TOM v5, case 10"
      decision_needed: false
    - kind: "return"                      # a design return from [ORG]AIOC-PPD or [ORG]AIOC-DI on a release of this AIOC (Protocol §19, items 5 and 6); carried to an end by §5.10
      format: "design return (49GAION-protocol library/contracts/design-return.schema.json, at the version pinned in contracts/PINS.json)"
      acceptance_test: "TEST-TOM v5, cases 101-107"
      decision_needed: true
  delivers:
    - kind: "needs request"
      format: "needs request (contracts/needs-request.schema.json), as a sub-item of the run Work Item"
      usual_receivers: ["[ORG]AIOC-SL"]
    - kind: "missing report"
      format: "Missing Report (contracts/missing-report.schema.json), one per pass"
      usual_receivers: ["[ORG]AIOC-SL"]
    - kind: "needs status"                # withdrawn or superseded, from this AIOC
      format: "needs status (contracts/needs-status.schema.json)"
      usual_receivers: ["[ORG]AIOC-SL"]
    - kind: "TOM Release filing"          # the release itself lives only in [ORG]AIOC-SL; every later stage reads it there, by reference
      format: "TOM Release manifest (contracts/tom-release.schema.json) and its parts, filed as a source of origin kind operating model; filing receipt (contracts/tom-filing-receipt.schema.json)"
      usual_receivers: ["[ORG]AIOC-SL"]
    - kind: "release notice"              # on every filing of a decided release (Protocol §19, item 5; §5.9 step 8a)
      format: "release notice (contracts/release-notice.schema.json): the release ID, version and manifest hash, its filed reference, and the returns it answers; never release text"
      usual_receivers: ["[ORG]AIOC-PPD"]
    - kind: "return answer"               # the end of a return, or its next round, recorded on the return itself (§5.10)
      format: "the return at its next version (49GAION-protocol library/contracts/design-return.schema.json): its status, the answering release or decision reference, and for a return set aside, its carried_forward_on"
      usual_receivers: ["[ORG]AIOC-PPD", "[ORG]AIOC-DI"]
  anatomy:
    panel: { health: { tests: true, metrics: ["stuck", "returned", "late", "needs open", "needs past deadline", "run state", "pack version", "reviews held", "review budget used", "run depth", "authoring", "role findings open", "returns open", "returns past deadline", "return age", "return round", "strategy elements not given", "activity profile"] } }
    back_office: { converses_with_humans: false, hosts: ["Chief of Staff", "Office"], protocol_traffic: true }
    definition: { location: "<org>aioc-tom, blueprint/TOM-BLUEPRINT.md", version: "v0.6.3" }
    delivery: { rollback: "one-click" }
    connectors:
      - { role: "source of record", connector: "[ORG]AIOC-SL output socket", access_managed_in: "panel" }   # the Panel shows and requests it; the grant itself is signed at the tool gateway as connect-external-port by the [ORG]HOAC-ACS seat over [ORG]AIOC-SL (Protocol §13, item 5; upstream/PROPOSALS.md, item 4)
      - { role: "next design stage", connector: "[ORG]AIOC-PPD input port: release notices out, returns in", access_managed_in: "panel" }   # signed at the tool gateway as connect-external-port by the [ORG]HOAC-ACS position over this AIOC (Protocol §19, item 7; H-35)
      - { role: "returns from the last stage", connector: "[ORG]AIOC-DI output port: returns in", access_managed_in: "panel" }   # signed as above (Protocol §20, item 3; H-35)
    gateway: { metering_id: "<per-AIOC metering id>" }
  full_name: "Target Operating Model"
  version: "0.6.3"
  lineage: { id: "[ORG]AIOC-TOM", version: "0.6.2", relation: "original" }
  lifecycle_state: "designed"
  blueprint_version: "v0.6.3"
  template_version: "v1.5.0"
  accountable_to: "[ORG]CELL-TMS"         # example code of the Cell carrying [ORG]HOAC-TM (Naming Standard R15); never a Cell inside this AIOC
  top_cell: "[ORG]CELL-TDL"
  hoac: "[ORG]HOAC-ACS"
  label_holder: "[ORG]CELL-TDL"
  fixed_test: { id: "TEST-TOM", version: "v5", owner: "[ORG]CELL-TMS" }
  skills:
    - { id: "tom-request-reconstruction", name: "Request reconstruction from sources", tags: ["design", "intake"] }
    - { id: "tom-entity-model", name: "Entity operating model design", tags: ["design"] }
    - { id: "tom-hand-offs", name: "Hand-offs between parts and with outside parties", tags: ["design"] }
    - { id: "tom-walkthrough", name: "Operational walkthrough", tags: ["assurance"] }
    - { id: "tom-role-register", name: "Role register across the release", tags: ["design"] }
    - { id: "tom-returns", name: "Returns from later stages, each carried to an end", tags: ["coordination"] }
  ports:
    - { unit: "[ORG]AIOC-TOM", port: "ai-in", direction: "input", type: "AI", identification: "technical-key", accepted_content: ["source reference", "needs answer", "needs status", "return"], authority_limit: "read only, within the organisation-design scope signed for this connection; returns only on the connections signed with [ORG]AIOC-PPD and [ORG]AIOC-DI", audit_trail: "unit register and the serve log of [ORG]AIOC-SL", required_tests: ["TEST-TOM v5"], enforcement: "shared-gateway-outside-unit" }
    - { unit: "[ORG]AIOC-TOM", port: "ai-out", direction: "output", type: "AI", identification: "technical-key", accepted_content: ["needs request", "missing report", "needs status", "TOM Release filing", "release notice", "return answer"], authority_limit: "requests, reports and filings only; files only sources of origin kind operating model or design report, within the write scope signed for this connection; release notices and return answers by reference only, on the connections signed with [ORG]AIOC-PPD and [ORG]AIOC-DI; never an instruction to a person", audit_trail: "Work Item record and the unit register", required_tests: ["TEST-TOM v5"], enforcement: "shared-gateway-outside-unit" }
    - { unit: "[ORG]AIOC-TOM", port: "hu-in", direction: "input", type: "HU", identification: "live-human-sign-in-at-gateway", accepted_content: ["run request from the Requesting Authority's Cell (a Design Request reference only)", "run control and configuration from the TOM Design Lead (never a source)"], authority_limit: "the signer's authority_scope; nothing received here is a source", audit_trail: "Office record", required_tests: ["TEST-TOM v5"], enforcement: "shared-gateway-outside-unit" }
    - { unit: "[ORG]AIOC-TOM", port: "hu-out", direction: "output", type: "HU", identification: "live-human-sign-in-at-gateway", accepted_content: ["run brief to the TOM Design Lead", "run preview to the TOM Design Lead", "ruling sheets to the TOM Design Lead", "release notice to the Requesting Authority's Cell"], authority_limit: "information only; never a question about the organisation", audit_trail: "Office record", required_tests: ["TEST-TOM v5"], enforcement: "shared-gateway-outside-unit" }
    - { unit: "[ORG]AIOC-TOM", port: "stop", direction: "input", type: "HU", identification: "live-human-sign-in-at-gateway", accepted_content: ["stop"], authority_limit: "stop only", audit_trail: "unit register", required_tests: ["TEST-TOM v5"], enforcement: "shared-gateway-outside-unit", stop_door: true }
  configuration:                          # every slot is set by the organisation (§15); an empty slot fails the joining test
    office_accountable_human: { value: "<set by the organisation>", set_by: "<seat>", date: "<date>", version: "<vN>" }
    central_head: { value: "<the OCO of this [ORG]AION>", set_by: "<seat>", date: "<date>", version: "<vN>" }
    discussion_limits: { value: "<set by the organisation>", set_by: "<seat>", date: "<date>", version: "<vN>" }
    waiting_deadlines: { value: "<per status>", set_by: "<Cell carrying [ORG]HOAC-TM>", date: "<date>", version: "<vN>" }
    bounce_limit: { value: "<number>", set_by: "<seat>", date: "<date>", version: "<vN>" }
    chain_depth: { value: "<number, at least 1>", set_by: "<seat>", date: "<date>", version: "<vN>" }
    halt_request_priority: { value: "immediate", set_by: "<seat>", date: "<date>", version: "<vN>" }
    budget_cap: { value: "<amount per period>", set_by: "<Cell carrying [ORG]HOAC-TM>", date: "<date>", version: "<vN>" }
    unattended_action: "read-record-triage"
    requesting_authority_cell: { value: "<set by the organisation>", set_by: "<Cell carrying [ORG]HOAC-GOV>", date: "<date>", version: "<vN>" }
    rows_per_pass: { value: 12, set_by: "<seat>", date: "<date>", version: "<vN>" }
    non_response_passes: { value: "<set by the organisation>", set_by: "<Cell carrying [ORG]HOAC-TM>", date: "<date>", version: "<vN>" }
    decision_passes_max: { value: 3, set_by: "<seat>", date: "<date>", version: "<vN>" }
    explainers_per_pass: { value: 2, set_by: "<seat>", date: "<date>", version: "<vN>" }
    round_caps: { value: "Request Reconstruction 12; Structuring 8; Entity Model Design 8", set_by: "<seat>", date: "<date>", version: "<vN>" }
    repair_cycles: { value: 2, set_by: "<seat>", date: "<date>", version: "<vN>" }
    situation_mix: { value: "standard library ≥ 60%, blind pack ≥ 30%", set_by: "<seat>", date: "<date>", version: "<vN>" }
    parallel_runs: { value: 1, set_by: "<seat>", date: "<date>", version: "<vN>" }
    review_engines: { value: 3, set_by: "<seat>", date: "<date>", version: "<vN>" }
    review_families_min: { value: 2, set_by: "<seat>", date: "<date>", version: "<vN>" }
    reduced_review_permitted: { value: "no", set_by: "<Cell carrying [ORG]HOAC-TM>", date: "<date>", version: "<vN>" }
    review_budget_per_run: { value: "<set by the organisation>", set_by: "<Cell carrying [ORG]HOAC-TM>", date: "<date>", version: "<vN>" }
    lazy_atomising_threshold: { value: 1000, set_by: "<seat>", date: "<date>", version: "<vN>" }
    lenses_max: { value: 6, set_by: "<seat>", date: "<date>", version: "<vN>" }
    run_depth_permitted: { value: "standard", set_by: "<Cell carrying [ORG]HOAC-TM>", date: "<date>", version: "<vN>" }
    single_author_permitted: { value: "no", set_by: "<Cell carrying [ORG]HOAC-TM>", date: "<date>", version: "<vN>" }
    return_round_deadline: { value: "<set by the organisation>", set_by: "<Cell carrying [ORG]HOAC-TM>", date: "<date>", version: "<vN>" }
    return_rounds_max: { value: "<set by the organisation>", set_by: "<Cell carrying [ORG]HOAC-TM>", date: "<date>", version: "<vN>" }

Joining the protocol. This AIOC joins only after every input and output on this card passes fixed samples (the joining test, Protocol §11, item 1; Standard §3.2, item 4). It also needs Source Lifecycle to declare, on its card, support for the contracts of docs/INTAKE-WITH-SOURCE-LIFECYCLE.md §9 (gate T0). It also needs the engine register at the tool gateway to hold eligible engines for the organisation's highest confidentiality level (T0, condition (g)), and two author families (condition (j)). Until then its lifecycle_state stays designed and no Work Item is routed to it. The cards of its Pods and Cells are set in §17 and generated into cards/.

2. Organisation table and placement

2.1 Organisation table

2.2 Placement

• Where it sits. A top-level AIOC under the Charter, beside [ORG]AIOC-SL. It is the second stage of an organisation's design: the "next stage" of Protocol §13, item 6, set out in the Protocol section Target Operating Model (§19).
• Its role. It turns an organisation's own sources into a target operating model, decided by the organisation's own authority. It names roles and what each decides. It does not say what fills a role.
• Scope.
  • It does: reconstruct the request and write the Design Brief from sources; ask, through Source Lifecycle, for what the sources lack, and report what is missing; structure the work into children; brief each child; package each child in isolation; design each child's operating model with its rationale; record the hand-offs between children and with outside parties; list every accountable role-type once, in the role register; state the strategy frame from the sources and the organisation's decisions; record each capability's delivery model and maturity, each value stream's criticality and each outside party's journey; compile the value case, each element's proposed priority and the activity profile (Annex H); walk the model through realistic situations; have every stage's output checked under the Review Panel rule; prepare the decision; release the model.
  • It does not: ask any person anything about the organisation; write job descriptions; set workloads; assign work to anything other than an accountable role; choose tools or vendors; write processes, procedures or policies; write a success criterion; write a goal, a target, a level or a figure of its own; watch work, or read a record that says who did a piece of work; make a legal determination; decide anything for the organisation.
• Shapes it serves. Any shape: a single person, a single entity, a group of entities, or a group with independent institutions inside it (the same four shapes as Source Lifecycle). A unit of an organisation may be the subject of a design (scope.subject, docs/OUTPUT.md §3).
• Boundaries with other AIOCs.
  • [ORG]AIOC-SL holds every source and every contact with a person. This AIOC holds only references and its own design records. It asks; the Chief of Staff of [ORG]AIOC-SL gets the answer and records it. Source Lifecycle never designs; this AIOC never records a source, except its own filed release and design reports.
  • [ORG]AIOC-PPD, the next stage, is told of each decided release directly (§5.9 step 8a), reads it from Source Lifecycle starting with its role register, and returns what it cannot use (§5.10). [ORG]AIOC-DI, the last stage, may also return what it cannot use. This AIOC writes no position or job description, and assigns work only to accountable roles.
  • [ORG]AIOC-OCO installs, fixes and upgrades this AIOC; it never grades it (Standard §2.3, item 9).
  • Installation. The core designs and proposes [ORG]AIOC-TOM, the governing seat approves it, and the Top Management Group installs it in the operation and uses its filed TOM Release (the complete definition, Part E). The AIOC itself belongs to the [ORG]AION. It is also a product on its own (docs/OUTPUT.md §14).
• Overlap. None known. Where an organisation already holds earlier design capabilities of the same kind, their content is carried here (docs/DESIGN-BASIS.md) and they are retired through OCO.

3. Positions

• The Requesting Authority is not a position of this AIOC (§2.1). It decides the design; this AIOC only prepares the decision.
• The Process Auditor of v0.2.0 is not a position. The process audit is kept as review point RP1b (§5.8).
• No AI Cell signs anything (Protocol §10, item 3). Each AI Cell's bot has its own identity card (Annex A.5 of the template; §17).
• No natural person (Standard §1.1, item 9, proposed by 49GAION/DR-0013). Every human position this AIOC deals with, its own and the organisation's, is a HOAC position, a legal persona. This AIOC addresses positions only, through their HU ports; who holds them, and how, is the organisation's own mechanism, outside the system, and no part of this AIOC holds, reads or infers it.
• Each position's role pack is carried in the role cards of the capabilities it performs (§4, §5).

4. Standard capabilities

Defaults are in docs/STANDARD-CAPABILITIES.md of 49GAION-aioc v1.5.0. The differences are listed in §11.

4.1 Office

Definition

Default · form: single Chief of Staff. An Office forms only if the Design Lead needs more than one Chief of Staff.

Process (SOP)

Default.

Role card

None while the form is a single Chief of Staff.

Fixed test

TEST-TOM-COSTOM v5 (TEST-TOM v5, case 25: an Office is proposed, never self-created) · result NOT_RUN

4.2 Chief of Staff

Definition

Default, managing kind, with these additions:

• The only door to Source Lifecycle. It is the only Cell of this AIOC that sends anything outside it. It opens every needs request, Missing Report and filing as a Work Item to [ORG]AIOC-SL, and receives every answer through the Input socket. The connection's two external ports sit on its card (§17).
• The door to the stages after it. It sends each release notice to [ORG]AIOC-PPD (§5.9 step 8a), receives the returns of [ORG]AIOC-PPD and [ORG]AIOC-DI, and carries each to its end (§5.10). It never answers a return itself: the Requesting Authority does. Those ports sit on its card too (§17).
• No question to a person. It never asks any person anything about the organisation. Every question for the organisation goes to the Chief of Staff of [ORG]AIOC-SL as a needs request (§5.2). Its only human contact is its own HOAC seat, the TOM Design Lead, and its briefs to the Design Lead are about the run. Nothing the Design Lead sends is a source (§4.3).
• An orchestrator that never judges itself. It runs the gates of each run (Annex C): it dispatches the Cells, locks outputs, runs the code steps, draws the Review Panel and writes the run record. It records verification labels and review findings; it never writes a label on a check it ran, and never dismisses or downgrades a finding (§5.8; Annex B.4). It runs the Input socket's code steps (§4.3) and the review code steps (§5.8). It runs the compare code step (Annex G.4) and the role-register code step (§5.6 step 6a). It never rules on a finding, never dismisses or downgrades one, and never lowers a review.

Process (SOP)

Default, plus:

1. Admission (stage S0). On a run request: open the run record; have the Input socket build Input Pack P0 at the snapshot each adapter pins (§4.3); check T0 conditions (a) to (f) and (i) (Annex C.2) and read the engine register → P0 and the T0 record so far (evidence: the T0 record, with P0's pack_id).
2. Run preview. Send the TOM Design Lead the run preview (Annex E.13). Record the acknowledgement and, where only a reduced level is possible, the acceptance within the TM Cell's permission (§5.8 rule 18), and, where two authors at S5 would lower its review, the acceptance of single authoring there within the TM Cell's permission (Annex G.7); then check conditions (g) and (j) → acknowledged preview (evidence: the signed record).
3. Pack review. Run review point RP0 (§5.8). On its settlement, record T0 → T0 passed (evidence: the RP0 record).
4. One run at a time. One run per organisation (work in progress = 1). The slot is released only by the Requesting Authority's decision on the release, or by the run's closure (Annex C.1); never by a review verdict. A second run in parallel needs the TOM Design Lead's approval, recorded in the run record → run slot (evidence: run record).
5. Passes. Collect the needs requests the Pods raise; batch them into passes of at most the configured rows (§15, default 12), one decision per row; send each pass with its Missing Report (§5.2). Each pass is reviewed at RPa (§5.8) before it is sent → pass sent (evidence: Work Item IDs in the needs log).
6. Waiting. Overdue requests follow the [ORG]AION's waiting deadlines and escalation (Protocol §4.6, item 1): reminded, then raised to the TOM Design Lead and shown on the Panels of both AIOCs. A run is never left silent: past the configured passes it stops as non-response and emits a Readiness Report or the narrowest honest brief (§5.1, failure; Annex C.1) → ageing record (evidence: the needs log).
7. Answers. Hand each answer to the Input socket, which admits it, through the acceptance test of §4.3, into a new pack version. Re-open only the work that cites an affected atom → re-opened items (evidence: the pack's increment.reopens).
8. Stops. A stop takes effect at the tool gateway on every Pod and Cell of this AIOC; the Chief of Staff takes no action of its own and is itself stopped. After a signed restart-stopped-unit, it resumes from the records → nothing (evidence: the unit register).
9. Revocation. If the Source Lifecycle connection is revoked or narrowed, every later read is refused at the gateway. The run is held as held: connection revoked (Annex C.1). This is not a stop, and no restart is needed when a new connection is signed → held run (evidence: run record; unit register).
10. Re-base. Only on the TOM Design Lead's run-control decision: have the socket make a re-base pack version, with its diff; re-open only the work resting on changed atoms → re-base record (evidence: the diff and the decision).
11. Returns. Run §5.10 for every return received, whether or not a run is open → each return carried to its end (evidence: the returns log, Annex E.21).

Role card

Fixed test

TEST-TOM-COSTOM v5 · result NOT_RUN

4.3 Input socket

Definition

Default, with this AIOC's standard format, the source reference (contracts/source-reference.schema.json), and these parts.

1. What the socket hands to the engine: the Input Pack. The engine reads nothing but the Input Pack of its run, at the version each step names. The Input Pack is one versioned, content-addressed object (contracts/input-pack.schema.json; Annex E.1). Its ID is TOMI- + the SHA-256 of its body. It holds references, hashes and labels only. The text it points to is resolved into the run workspace and never written into a record. It holds: the run; the Design Request, with the run depth it states; the adapters read, each with its grant, snapshot and test; the source catalogue; the atoms; what was refused, and why; the unknowns; the increment of this version; any carried release; the pack report. It never carries this AIOC's design content, anything received through a human port, a source's text, or a reference model (Annex B.5).

2. Pack versions: the rules.

1. P0 is made at gate T0, from the snapshot each adapter pins.
2. A new version is made only when:
   • a needs answer or a decision is admitted; it is read at the snapshot the answer names;
   • a notice changes the status, scope or classification of a reference already read;
   • the read plan opens a source not yet atomised (lazy atomising, slot lazy_atomising_threshold);
   • the TOM Design Lead decides a re-base.
3. A version keeps every earlier atom unchanged. It only adds atoms or flags them. Nothing is removed.
4. Each step names the pack version it reads, for the whole step. A newer version never changes a running step or review. Afterwards it re-opens only the work that cites an affected atom (increment.reopens).
5. No silent re-pin. Re-pinning the whole snapshot is never automatic. A re-base is a run-control decision of the TOM Design Lead. It is recorded with the diff between the old and new snapshots, makes a new version (made_because: re-base), and re-opens only the work resting on changed atoms.
6. Supersession after the pin does not stop the run. The affected atoms are flagged superseded since pin in the next version, and the Decision Package lists them in plain words. A revocation or a reclassification holds the run (held: connection revoked, or the hold of §7).
7. The trace (T9). Every element of a release traces to an atom of a pack version of this run, or of a pack version named in the manifest of a release this run carries forward. Each such atom still resolves, by hash, at its snapshot. The manifest lists every pack version with its snapshots (input_packs).

3. Labels, once. The socket cuts each held source into atoms and assigns each atom its Annex B label once, at admission, by Annex B.1 and B.1a and the adapter's mapping. Every stage cites atoms of the pack. No stage creates an atom.

4. Adapters. Every source type plugs in through its own adapter file, adapters/<source-type>.adapter.md, with its fixtures and its own fixed test (Annex E.2). An adapter is the Standard's converter for one source type (STANDARD-CAPABILITIES §4.3). It only reads. This version has one adapter, ADP-SL, for Source Lifecycle. The adapter register is adapters/README.md. Three rules:

1. Adding an adapter is a tested change: one new file, its fixtures and its test, and a row in the adapter register (adapters/README.md). No stage changes.
2. An adapter is never a precedence rule. Two sources that disagree are a contradiction (Annex B.2), whichever adapters served them.
3. The same bytes served by two adapters are one source, with two references.

5. What Source Lifecycle serves, and what it is asked to add.

• What Source Lifecycle serves today (Protocol §13, item 4): the source ID, version and SHA-256 hash, and held or not held, within the approved scope.
• What Source Lifecycle is asked to add (docs/INTAKE-WITH-SOURCE-LIFECYCLE.md §9): the snapshot ID; the origin kind (document, explainer, confirmation, status, export, decision, operating model, design report); the status from Source Lifecycle's own list (draft, in review, approved, in force, superseded); the confidentiality level; for an export, the date it is as of; and, for an item derived from conversation, each statement's own Source Lifecycle label with its anchor (SL-A7). It is also asked to pin snapshots, read a needs answer at the snapshot that answer names, and keep every snapshot named by a filed release readable (SL-A8, as amended), and to send notices of revocation, narrowing, reclassification and supersession (SL-A11). New in v0.6.0. It is asked to admit an export of records of the work only as the organisation's projection by role-type and process, after its impact assessment and its HF-17 decision (SL-A13; Annex H.8), and to show and record the priority of an element row (the v0.6 sockets contract). Until Source Lifecycle serves these fields, gate T0 fails (Annex C). How the adapter reads each field, with the defaults where a value is not served, is fixed in adapters/source-lifecycle.adapter.md.

6. not held. A not held answer is recorded in the pack's unknowns, as an unknown with its cost. It is never taken to mean that the fact is absent.

7. What is refused.

• New. Nothing that arrives through a human port is a source. A run request is admitted only if it carries the reference of an approved Design Request in Source Lifecycle; the reference is admitted, never the words around it. Direction from the TOM Design Lead covers only method, configuration and run control (start, pause, stop, a second run, the budget, a re-base). A statement about the organisation in it is refused under case 2, and, if the design needs it, is asked through Source Lifecycle like any other need.
• New. A source that is not served by reference, or that comes from any channel other than an adapter's connection, is refused with its reason. Words typed or spoken to this AIOC are not a source.
• New in v0.6.0. An export of records of the work whose records still carry a field that says who did the work is refused person-level records, and nothing of it is kept (Annex H.8).
• The refusal reasons are those of Annex E.1 (refused[].reason).

8. The acceptance test of a needs answer (it makes case 11 concrete). An answer is admitted into a pack version only when all eight hold:

1. It validates against contracts/needs-answer.schema.json.
2. Its request_id and version match an open request.
3. Its outcome is allowed for the request's type.
4. Each source reference resolves, at the snapshot it names, to exactly one valid version with a matching hash.
5. For a non-delegable row, deciding_cell equals answering_cell.
6. For a listed type, signature_ref is valid for the exact row payload.
7. For a decision row, weak_approval_signal and delegated are both false.
8. It carries no secret.

9. A carried release enters P0 under carried (§5.9, Slices and carry-forward).

Process (SOP)

Default, plus the socket's five steps (STANDARD-CAPABILITIES §4.3), run by the Chief of Staff through the socket's code steps:

1. Receive. Three kinds of item: the run Work Item, through the HU port, carrying one Design Request reference only; references served by an adapter; needs answers and needs status messages.
2. Identify. For each item: the adapter, the grant, the time read, and the ID, version and hash.
3. Normalise, through the adapter. Make the canonical reference; map origin kind, status and confidentiality by the adapter's tables (defaults where unserved); cut each held source into atoms by the adapter's anchor scheme; assign each atom its Annex B label once, here, by Annex B.1 and the adapter's mapping.
4. Check. Each check passes, or refuses the item with its reason (refused[].reason):
   • the item resolves to exactly one valid version, and the hash matches (Protocol §8, item 2);
   • it is inside its scope, the scope is not expired, and the connection is not revoked;
   • it carries no secret;
   • an export of records of the work carries no field that says who did the work (Annex H.8);
   • instruction-like text is flagged, and kept as data;
   • for a Work Item: it is within the card;
   • for a needs answer: it passes the acceptance test of part 8 of the Definition, above.
5. Deliver. Write the next pack version and its pack report. Hand the list of re-opened work to the Chief of Staff.

Role card

Default; performed by the Chief of Staff ([ORG]CELL-COSTOM) through the socket's code steps and its adapters (Definition, part 4).

Fixed test

TEST-TOM-COSTOM v5 (TEST-TOM v5, cases 1-6, 29, 31-34, 44, 46, 49-52, 61, 81, 89, 96, 119 and 120); each adapter's own test (TEST-TOM-ADP-SL v2); plus the default Input socket test · result NOT_RUN

4.4 Panel

Definition

Default. The Panel of this AIOC also shows, for each run:

• the run state (Annex C.1), with its flags and their ages;
• the current pack version, its totals, and its difference from the previous version;
• per adapter: its last read, its scope expiry and the notices received;
• every needs request, with its state and its age against the waiting deadline;
• the latest Missing Report;
• each gate, with its result and evidence;
• per review: its point, level, verdict, findings by state, holds and budget used; any MATERIAL finding withdrawn by its raiser (§5.8 rule 14);
• the findings of the walkthrough, and each ruling;
• the run preview;
• the run depth and its source;
• per stage S1 and S5: two authors or one, and each job's differences by disposition;
• the role findings, by kind and state;
• the reference-model catalogue version, or unavailable;
• the strategy frame, with each element not given; the activity profile, or no observation (Annex H);
• the decision state of the release.

Across runs, it also shows every return received (§5.10): its sender, kind and elements, its round and the deadline of that round, its status and its age, and the decision rows open on it. A return past its deadline is shown in red, here and on its sender's Panel.

This is the Panel. It is not a Review Panel (§5.8).

Process (SOP)

Default.

Role card

Default.

Fixed test

Default Panel test · result NOT_RUN

5. Functional capabilities

Nine stages (§5.0) are performed by the Input socket (§4.3: S0) and seven of these capabilities: Request Reconstruction (S1, S3); Structuring (S2); Entity Packaging (S4); Entity Model Design (S5); Hand-offs (S6); Operational Walkthrough (S7); Decision Package and Release (S8). Needs Requests (§5.2) is a service every stage uses. Independent Review (§5.8) is the rule that closes every stage. Each capability is written in the four-part form (Annex A of the template). Its Definition has one added row, Done when, which names its gate. Each step reads: position: action → output (evidence). Where a capability has more than three steps, its Steps cell points to a numbered list below the table. A step run by code is written as the Chief of Staff running a named code step: code is a tool, never a seat. Rules that apply to every capability are in Annex B (labels and the honesty ceiling), Annex C (run states, gates, Gate A and admissible criteria), Annex D (what this AIOC never does) and Annex E (the field lists of the new objects). Where a rule is carried from the case study, docs/DESIGN-BASIS.md gives the reason and docs/CARRIED-RULES.md the full text. Where it is new, it is marked New.

Child, not entity. A child is the unit of packaging and design: a whole entity, or a bounded part of one, decided in Structuring (§5.3). Every step after Structuring speaks of children. Where a request covers one entity split into several children, their crossings are paired in Hand-offs like those between entities.

5.0 The stages: input, output, done-test

Each stage is one run state and closes on its gate. The last stage closes on T8, then T9. "Settled" and "clear" are defined in §5.8 (Done when). "Unresolved" has the meaning of Annex D item 12.

Not stages: services and rules used by every stage.

Run states (Annex C.1).

• States, in order: admitting (S0) → framing (S1) → structuring (S2) → child briefing (S3) → packaging (S4) → designing (S5) → hand-offs (S6) → walking (S7) → deciding (S8) → end states released → filed.
• Endings other than a release: closed: not admitted (T0 failed; the run Work Item is returned with each failed condition by name); closed: readiness report; closed: held report; closed: non-response; closed: rejected; closed: withdrawn by the Requesting Authority.
• Flags on any state, each shown with its age: waiting; waiting: ruling; held: material finding; held: connection revoked; held: no reviewers; held: review budget; held: engine ceiling.
• No flag releases the run slot. Every ending releases it.
• Per-child stages (S3, S4, S5) run per child. The run state is the earliest stage any child of the slice is still in.

One word per meaning.

• Review Panel: the rule of §5.8, and the set of engines drawn for one review. It is never the Panel.
• Panel: the AIOC's screen (§4.4).
• Engine: an AI model as served through the tool gateway. Family: its lineage.
• Operating model: only what TOM designs. In engine text "the model" means the operating model; "model" never names an engine.
• Crossing: one child's declared boundary entry (seven fields, docs/CARRIED-RULES.md §7.1). Hand-off: a clean pair of crossings between two children, recorded in the hand-offs register. A child's crossing with an outside party is recorded in the counterparty register.
• Job: the per-child run of a per-child stage ("one child per job"). Run: the whole design run (one Work Item).
• Release file in reader text; part in the manifest and in engine text.
• Author: an AI Cell whose engine produced an output (§5.8 rule 3). Two authors: two such Cells, bound to engines of two families, writing one output blind to each other (Annex G).
• Draft: one author's locked version of the frame (S1) or of a child's design ledger (S5). Difference: one item on which the two drafts differ (Annex E.18). Reconciler: the Cell that makes one version from two drafts (Annex G.1).
• Run depth: how fine the model is, light, standard or deep (Annex F).
• Pattern: an entry of the reference-model catalogue of the 49GAION Library; a method, never evidence (Annex B.5). In reader text: "general pattern".
• Role register: the release part that lists every role-type once (Annex E.17). It lists roles, never positions: the Position Register belongs to the next stage (Naming Standard §3).
• Strategy frame: the organisation's strategy on one page, as its sources state it or as it decides it (Annex H.1). Value case: per outcome, its measures, baselines and targets, compiled by code (Annex H.6). Activity profile: how the work runs today, by role-type and process, from approved exports only (Annex H.8). Journey: the moments where one outside party meets the organisation, in order (Annex H.5).

5.1 Request Reconstruction

Definition

Process (SOP)

The frame (S1).

Steps 1–9 are run twice, blind (Annex G.2): by the Request Analyst, and by the Second Request Analyst on an engine of the other author family, each with its own Source Proxy rounds. Each output of steps 1–9 is that author's own.

0. Chief of Staff (runs the activity-profile code step): before the authors start, and again on each pack version that admits an export of records of the work, compiles the current-state activity profile, or no observation (Annex H.8) → activity profile (evidence: hash; mechanically-verified). Both authors read it as present state.
1. Request Analyst: declares the read plan before reading: what is read in full, sampled or not opened, and why the unopened material is unlikely to change a decision; the selection basis carries its own label; the organisation dictionary is opened wherever Source Lifecycle serves one (Annex H.9). The socket atomises each source the plan opens, as a new pack version, where the corpus is above lazy_atomising_threshold → read plan (evidence: run record entry and hash).
2. Source Proxy: screens each source's Source Lifecycle status. Recency is never authority; presence in the sources is never adoption; a precedence between two sources is admitted only when a held source states it, cited. The pack's live_version_conflicts enter as candidate contradictions → currency screen (evidence: run record).
3. Request Analyst ↔ Source Proxy: internal rounds. The Proxy answers only from the sources, with a citation, or refuses. The Analyst may ask about situation, history, constraints and intent found in the sources. It may never ask about solutions, design preferences, tools or success criteria → round log (evidence: run record).
4. Request Analyst: the lens pass (docs/CARRIED-RULES.md §2.7), with at most the lens cap of the run depth (Annex F) → lens record (evidence: run record).
5. Request Analyst: builds the Working Context: what exists today; who does what; the contradiction register; what was expected and not found; unclear authority; the currency screen; every row labelled (Annex B). Retained lens findings enter only with their citations → Working Context (evidence: run record).
6. Request Analyst: states the request kind with its reason (CARRIED-RULES.md §2.8), and writes the party register (Annex E.3) → party register (evidence: run record).
7. Request Analyst: reconstructs the frame. It covers: the requesting authority per entity, each entity committed or context, with its veto-holders; the request as interpreted; scope in; named exclusions; present state; outcomes, each stated as a difference from today that two independent readers would judge the same; criteria only as the sources state them, each checked for admissibility (Annex C.3); constraints; assumptions, each with what breaks if false; unknowns, carried or blocking; contradictions; obligations; open items; the request kind; the honesty ceiling; and the strategy frame, each element cited or not given (Annex H.1) → frame draft (evidence: run record and hash).
8. Request Analyst: records Gate A for the whole request: the eight questions of Annex C.3, each answered yes or no with a reason → Gate A record (evidence: run record).
9. Request Analyst: applies the decision-leverage test to each item the sources cannot answer: does any scope boundary, constraint, criterion or design decision change with its value? If not, the item is carried as an assumption and not asked. If so, it becomes a needs candidate (§5.2), ranked by breadth, irreversibility and cost of being wrong. An element of the strategy frame that no held source states is always a candidate, asked once through EX-10 (Annex H.1, item 3) → needs candidates with leverage proofs (evidence: needs log). 9a. Chief of Staff (runs the compare code step): once both authors' drafts of steps 1–9 are locked by hash, aligns them and writes the difference register (Annex G.4; Annex E.18) → difference register (evidence: hashes; mechanically-verified). 9b. Frame Reconciler: in a fresh context, with only the two locked drafts, the difference register, the atoms they cite and the rules, reconciles them into one frame, party register, do-not-ask and do-not-use-as-fact lists and set of needs candidates, under Annex G.5, recording each disposition; a reading of the request that only the organisation can settle becomes a row of the frame decision pass (step 12) → reconciled frame (evidence: run record).
10. Review Pod: the process audit, review point RP1b (§5.8), over both authors' round logs and lens records. A MATERIAL verdict stops the step, and the author whose rounds hold the defect re-forms its draft from its last clean round; steps 9a and 9b then run again → RP1b record (evidence: the review record).
11. Review Pod: the frame review, review point RP1 (§5.8), with the question set of CARRIED-RULES.md §11.1. It sees only the pack atoms the frame cites, the reconciled frame with its Gate A record, the party register, the two locked drafts and the difference register, never the rounds. It re-assesses every Gate A answer and the floor on its own → RP1 record (evidence: the review record).
12. Request Analyst: runs only after RP1b and RP1 have settled clear. It sends the frame decision pass (CARRIED-RULES.md §4.5), through the Chief of Staff (§5.2): non-delegable rows for scope, exclusions, the roster and contradictions; delegable confirmation rows for the understanding check, findings not said, load-bearing assumptions and obligations; a non-delegable row for each reading of the request that step 9b could not settle (reading A, reading B, both readings); one non-delegable row for the strategy frame, and the purpose-and-values rows where no source in force states them (Annex H.1) → frame decision pass (evidence: needs log).

The child briefs (S3), after the structure is decided (§5.3).

13. Request Analyst: for each decided child, records Gate A and the floor on that child (Annex C.3), and checks each criterion the sources state for admissibility (Annex C.3) → child brief draft and Gate A record (evidence: run record).
14. Review Pod: the child brief review, review point RP3 (§5.8) → RP3 record (evidence: the review record).
15. Request Analyst: after RP3 has settled clear, sends the child's non-delegable rows, through the Chief of Staff (§5.2): its criteria (at least one startable, admissible criterion), and each contradiction touching the child that no held source settles. A child whose floor cannot hold gets a Readiness Report section; the request resolves as a paired set of child briefs and child Readiness Report sections → child decision rows, or Readiness Report section (evidence: needs log; run record).

Role card

Fixed test

TEST-TOM-TRR v5: TEST-TOM v5, cases 4, 5, 8, 14, 15, 28, 73-76, 83, 91-93, 109-111, 121 and 123 · result NOT_RUN

5.2 Needs Requests

Definition

Process (SOP)

1. Raising Cell: drafts the candidate: type; the question in its own wording; why it matters; which element, decision or gate it blocks; what changes depending on the answer; what will be carried if no answer comes, and what that costs; the rows it depends on; the references searched → candidate (evidence: needs log).
2. Chief of Staff: checks the candidate against the do-not-ask list and the needs log, and drops a duplicate or an answered question → checked candidate (evidence: needs log).
3. Chief of Staff: writes the plain-language question for the organisation, keeping the original wording verbatim beside it, and picks the asking form (docs/ASKING-CATALOGUE.md); a confirmation row states its row_purpose → needs request (evidence: the request validates against its contract).
4. Chief of Staff: batches the pass: at most the configured rows, one decision per row, ranked by leverage. Non-delegable rows name their answering Cell (the Requesting Authority's, or for a listed type its signer's) and come first. An explainer counts as three rows toward the pass limit → pass (evidence: needs log).
5. Chief of Staff: writes the pass's Missing Report (docs/INTAKE-WITH-SOURCE-LIFECYCLE.md §8.1) → Missing Report (evidence: it validates, and its open needs equal the open entries of the needs log).
6. Review Pod: review point RPa on the pass (§5.8) → RPa record (evidence: the review record).
7. Chief of Staff: sends each request as a sub-item of the run Work Item, and the Missing Report with the pass, through the output port to [ORG]AIOC-SL → Work Item IDs (evidence: needs log).
8. Chief of Staff of [ORG]AIOC-SL (outside this AIOC): accepts or returns each request with a reason, and reports asked; obtains the answer; has it approved; records it as a source; answers by reference, or with declared absent, not applicable, declined, dont know or returned → needs status messages and needs answer (evidence: Source Lifecycle's serve log).
9. Input socket: admits the answer only by reference, through the acceptance test of §4.3, into a new pack version; a typed or pasted answer is refused → pack version (evidence: the pack's increment).
10. Chief of Staff: sets the sub-item done only when this AIOC's acceptance test passes on the answer (Protocol §4.5); updates the needs log; re-opens only the work that cites an affected atom; returns to undecided every row declared as depending on a row answered correct or dont know → dependent work re-opened (evidence: run record).
11. Chief of Staff: withdraws a request the run no longer needs, or supersedes it with a new version, and tells Source Lifecycle, which stops asking → needs status (evidence: needs log).

Role card

Fixed test

TEST-TOM-COSTOM v5 (cases 7-13, 28, 30, 75, 76 and 109 for this capability) · result NOT_RUN

5.3 Structuring

Definition

Process (SOP)

1. Work Structurer: derives the axes of division from the decided frame and the sources, each cited → axes (evidence: run record).
2. Work Structurer: proposes children and applies the four-leg test to each, answering yes or no with a reason. Ownable: one accountable owner role could hold it. Boundable: its in and out fit in three sentences without "everything" or "various". Startable: work could begin from the brief and this proposal alone. Interfaces nameable: what crosses to and from each sibling is listed. A child failing a leg merges upward. Of the sets where every child passes, the smallest wins → children with leg answers (evidence: run record).
3. Work Structurer: a single child equal to the whole request is admitted only with an attempted-split table: every axis tried, and why each fails the four legs. A vague "inseparable" note fails the run → split table where needed (evidence: run record).
4. Work Structurer: runs the orphan check: every in-scope item maps to at least one child, and the mapping table is part of the output. It also runs the exclusion check: no child crosses a named exclusion, and the matrix is shown → checks (evidence: run record).
5. Work Structurer: records at least one rejected alternative, with why → alternatives (evidence: run record).
6. Work Structurer: writes the dependency order (an ordering note, never a dispatch) and the proposed first slice, and extends the party register with the sibling children → ordering note; party register extension (evidence: run record).
7. Review Pod: review point RP2 (§5.8) → RP2 record (evidence: the review record).
8. Chief of Staff: after RP2 has settled clear, sends one non-delegable decision row per child, and one for the first slice (§5.2) → decision rows (evidence: needs log).

Role card

Fixed test

TEST-TOM-TS v5: TEST-TOM v5, cases 16, 42 and 83 · result NOT_RUN

5.4 Entity Packaging

Definition

The seven fields of each crossing in the declared boundary register:

• a stable marker (BX-n; provisional BXP-n for an evidenced party missing from the party register);
• direction (inbound, outbound, two-way);
• what crosses, in the child's own words;
• the child-side obligation or trigger;
• counterparty class (regulatory, commercial-counterparty, group-internal, financial-infrastructure, technology-platform, public, unresolved-class);
• provenance (stated, inferred, unresolved), with a confidence;
• optional criticality, only as citations to the child's own evidence.

Each field carries its own basis, or unknown.

Atoms come from the Input Pack. The Input socket cuts every source into atoms and labels each once (§4.3). Packaging selects atoms for a child and creates none. Atom text is resolved from Source Lifecycle into the run workspace only, and never edited. Records and releases keep atom IDs and hashes (§7).

Process (SOP)

1. Chief of Staff (runs the prepackaging code step): over the pack atoms in the child's scope, builds one stable marker per party of the party register, with its aliases, abbreviations and role descriptors; replaces identities in every atom, longest match first; then sweeps for crossing candidates: hand-off, receipt, notification, approval and reporting patterns, and every marker mention → marker store, class-only registry, candidate list, marker-to-identity map (evidence: code-step log and hashes).
2. Packager: sees only the markerised atoms, the class-only registry, the candidates, the child row and the constraints. It decides each atom's membership (in, out, withheld). It adjudicates every candidate as crossing, not-crossing or unresolved, with reasons and references. It selects and declares; it never retypes evidence → packaging ledger (evidence: run record).
3. Chief of Staff (runs the package-assembly code step): assembles the package and the three records from the ledger and the store, pulling atom text by ID → package (evidence: hashes).
4. Chief of Staff (runs the gate code step): runs gates G1-G5 (docs/CARRIED-RULES.md §7.3): G1, no identity, alias or descriptor appears except under a declared disclosure; G2, markers and register match; G3, closed vocabularies and complete fields; G4, every atom is byte-identical to its source after marker substitution; G5, every candidate is adjudicated, with reason and references. Any finding blocks release → gate report (evidence: mechanically-verified).
5. Review Pod: review point RP4 (§5.8). The engines see the markerised atoms, the child row, the package, the packaging ledger, the gate report and the rules. They look for far-side content left after substitution, semantic identity leakage, evidenced crossings not declared, and atoms of the child's own withheld → RP4 record (evidence: externally-audited).

Role card

Fixed test

TEST-TOM-TEP v5: TEST-TOM v5, cases 17, 41 and 45 · result NOT_RUN

5.5 Entity Model Design

Definition

New: organisation-stated evidence and reference models.

• An approved statement of the organisation held in Source Lifecycle (an explainer, a confirmation's correction, or a decision's correction) is admitted as evidence with the label organisation-stated (Annex B), statement by statement, keeping each statement's Source Lifecycle label. It carries its label into the ceiling and never becomes source-backed. In the case study, the organisation's statements entered through conversation; here they enter only as approved, versioned sources.
• Reference models (New in v0.4.0). The Designer and the Second Designer may read the reference-model catalogue of the 49GAION Library, at the version and hash pinned for the run (contracts/PINS.json; the run preview). A pattern is a method, never evidence (Annex B.5):
  1. It may suggest a structure: capabilities, decision rights by role-type, hand-offs. It never supplies a fact about the organisation, never enters the Input Pack, and never raises a label.
  2. Each ledger element a pattern informed records it in pattern_refs: the pattern, the catalogue version, and what it suggested. B3 states each pattern considered, why it fits and what would flip it (CARRIED-RULES.md §8.1 rule 7).
  3. Each element still rests on the child's own atoms. An element whose basis holds no atom is assumed, with what breaks if it is false and when to re-check it; it is listed in B6 and walked as an assumption. A major or core capability on a pattern alone is never authoritative: it stays at the coarser grain, with the pattern's structure as a non-authoritative candidate.
  4. Only patterns of the pinned catalogue are cited. While the Library holds no catalogue, or none is pinned, the catalogue is declared unavailable and no pattern is cited; none is invented.
  5. The release names each pattern used, in plain words, with the elements that rest on it alone (the Decision Package; the honesty ceiling; the quality checks).
  6. Done when: the design check finds every pattern reference in the pinned catalogue and every element on no atom assumed (CARRIED-RULES.md §8.3 item 9); RP5 finds no pattern used as evidence; T9 re-checks every reference by version and hash.

Process (SOP)

1. Chief of Staff (runs the receipt code step): validates the package against its schema; a mismatch goes back to packaging → receipt (evidence: mechanically-verified).
2. Designer and Second Designer: each writes a design ledger for the child, blind to the other (Annex G.2). Each element has its type, claim, provenance (stated, inferred, unresolved, or assumed where its basis holds no atom), confidence, basis references and class (authoritative, candidate, narrative), and, where a reference model informed it, its pattern references. A decision-domain element names its decision and its accountable role-type. A capability carries its delivery model, the crossings that deliver it where it is not in-house, and its maturity now and target; a value stream carries critical, with its reasons (Annex H.2–H.4). The ledger also holds the narrative cells, bound to the entries they draw on; the alternatives; the candidates; and the demand signals → two ledger drafts (evidence: run record).
3. Chief of Staff (runs the render code step): validates each ledger against its schema, renders Outputs A and B from each, and locks both drafts by hash → two rendered drafts, locked (evidence: hashes). 3a. Chief of Staff (runs the compare code step): aligns the two locked ledgers and writes the difference register (Annex G.4; Annex E.18) → difference register (evidence: hashes; mechanically-verified).
4. Ledger Reviser: works in a fresh context, with only the package, the two locked drafts, the difference register and the rules. It first reconciles the two drafts into one ledger under Annex G.5, recording each disposition; then it revises that ledger as before. Its record states only what changed, and each disposition with its reason and quotes, with no verdict → reconciled and revised ledger (evidence: run record). With one author (Annex G.7), steps 3a and the reconciliation are skipped, and it revises the one locked draft.
5. Chief of Staff (runs the design-check code step): renders Outputs A and B from the revised ledger and runs the code checks of docs/CARRIED-RULES.md §8.3. Register to interface: one-to-one. Externals: referenced only by marker. Provenance, confidence and direction: none upgraded from the register. Candidate names: none in Output A outside A5's non-authoritative part, swept on every narrative cell and again on the rendered Output A. Narrative cells: no negative enumeration; no confidence or provenance vocabulary; no name absent from the cell's linked entries. Every element: has a brief entry. Schema: no undeclared section. Patterns: every pattern reference resolves in the pinned catalogue; an element on no atom is assumed. Role fields: every decision domain names its decision and its role-type, or unknown. Delivery and maturity: every capability's delivery model is in the closed list, with the make-or-buy that follows from it and its crossings where it is not in-house; every critical stream has a cited reason; every level cites its basis (Annex H.11 checks 2 and 3; CARRIED-RULES.md §8.3 items 11 and 12) → gate report (evidence: mechanically-verified).
6. Review Pod: review point RP5 (§5.8). It checks fidelity, not presence: every Blueprint element, and every evidence entry supporting one, says exactly what its cited atoms say. Coverage is full; a declared sample is allowed only for entries that support no element. It also looks for semantic paraphrase of candidates. It also checks each difference's disposition (Annex G.6), and that no pattern is used as evidence (Annex B.5) → RP5 record (evidence: externally-audited).
7. Chief of Staff: on an upheld or ruled MATERIAL finding, starts bounded repair (§5.8 rule 19); otherwise records the step complete → step state (evidence: run record).

Role card

Fixed test

TEST-TOM-TEM v5: TEST-TOM v5, cases 18, 19, 38, 39, 91-93, 96, 97 and 112-115 · result NOT_RUN

5.6 Hand-offs

Definition

Process (SOP)

1. Chief of Staff (runs the pairing code step): restores identities inside the hand-offs workspace only, and pairs each outbound marker with its inbound counterpart, carried children included → pairing table (evidence: hashes).
2. Chief of Staff (runs the seam-check code step): every unmatched or contradictory crossing between children becomes a seam finding (Annex E.6) → seam findings (evidence: mechanically-verified).
3. Hand-off Analyst: records each clean pair in the hand-offs register (Annex E.4), from both sides' registers and ledgers, citing sources or decided items only; the decision on the crossing is one field → hand-offs register (evidence: run record).
4. Hand-off Analyst: maps every counterparty by class (Annex E.5); raises a need where the sources are silent on a class the organisation's shape normally has → counterparty register (evidence: run record). 4a. Hand-off Analyst: records the journey of each counterparty entry: its moments in order, each a crossing of that entry, with the stream and phase it meets; a moment no crossing carries becomes a seam finding (Annex H.5) → outside-party journeys (evidence: run record). 4b. Chief of Staff (runs the journey and delivery code step): checks every journey moment against its entry and every phase against the decided ledgers, and every crossing that delivers a shared service, outsourced or partner capability against the hand-offs register, the counterparty register and the deferred-boundary register; each miss is a seam finding (Annex H.11 checks 2 and 4) → check report (evidence: mechanically-verified).
5. Hand-off Analyst: lists the legal and regulatory perimeter, each item flagged for human legal review → perimeter list.
6. Hand-off Analyst: places or registers every deferred boundary class (Annex E.7) → deferred-boundary register. 6a. Chief of Staff (runs the role-register code step): compiles the role register from the decided ledgers of the slice and of carried children, the hand-offs and counterparty registers and the obligations of the decided Design Brief, by the rules of Annex E.17; raises the role findings; sends each decision row finding as a non-delegable row (§5.2) and routes the others → role register and role findings (evidence: hashes; mechanically-verified).
7. Review Pod: review point RP6 (§5.8) → RP6 record (evidence: externally-audited).

Role card

Fixed test

TEST-TOM-TH v5: cases 20, 37, 42, 65, 66, 70, 85-88, 113 and 116 · result NOT_RUN

5.7 Operational Walkthrough

Definition

Situation types.

• W1: the happy path of each value stream.
• W2: an in-scope exception, or a demand to discharge a held obligation.
• W3: authority ambiguity, a gap, or a decision that cannot be taken locally.
• W4: an outside dependency that fails, or whose condition is not met.
• W5: an assumption flipped false, a critical-path unknown made unavailable, or an excluded class probed.
• W6: two live tokens competing for one decision domain (narrowed, below).
• Mandatory negatives: for every excluded class, deferred class and withdrawn candidate, a situation that must not need it.

Situation sources.

• At least 60% from the standard situation library, written against finding classes before any particular model exists; the request kind's situation pack selects from it.
• At least 30% from a blind adversarial pack, written from the blind brief only (Annex E.9): the entity's type, accountability set and boundary list, never its capability map, streams or domains.
• The rest named by the organisation: additive only, and never able to rescue a core failure.
• New. Until the library holds at least one situation per finding class for the entity's type, the walk runs with the shortfall declared in the report. The mix rule is then reported as not met, never silently waived. The library is a build item of the code project (§8).
• New in v0.4.0. The budget follows the run depth (Annex F.2). The floors above hold at every depth; the situations deep adds are additive.

Finding classes.

• CLEAR: closed in a licensed terminal state, on facts and design only.
• LIMITATION: closed or halted honestly. The cause is a flagged assumption, an unmet condition with a declared holding obligation, an excluded or deferred halt, or an unknown on a path the model never claimed.
• MINOR: a wording or traceability defect that does not change navigability.
• MATERIAL: a defect on a path the model claims to handle. It is one of:
  • unowned work;
  • an unarbitrated collision;
  • an authority violation with no escalation home;
  • an undeclared boundary escape;
  • a scope leak;
  • a withdrawn candidate brought back;
  • a loop with no exit;
  • a critical-path unknown;
  • responsibility that evaporates with no holding obligation;
  • a claimed obligation with no way to discharge it.
• NOT-WALKABLE: the model cannot compile, or the situation needs evidence the input marks absent.

Each finding states what was injected, where the path stopped, which element and which class, and what information or decision would close it. It names the gap, never the fix. The licensed terminal states and the per-hop and per-walk fields are in docs/CARRIED-RULES.md §10.

New: the five known defects of the earlier standard are fixed (docs/CARRIED-RULES.md §10.4):

• I-1: a halt at excluded scope has a licensed terminal state, halts-excluded-scope.
• I-2: a standing evidence ceiling is declared once, as the frame of the walk, not as a flag on every path.
• I-3: the class follows the claimed-path test, and the terminal follows the licensed-terminal list.
• I-4: W6 detects a defect only where the two decisions are mutually exclusive and held by different authorities.
• I-5: a finding's class must cite the cell text that licenses it; a class resting on an unbindable binding is void.

The reduced-catalogue rule is adopted: a model complete in obligations and authority but thin in value streams is walked on its capability, domain and boundary graph. It is never refused as not walkable for being thin, and its grade is "PASS WITH LIMITATIONS" or "SIMULATION-INCOMPLETE", never a plain pass.

Process (SOP)

0. Chief of Staff (runs the walk-input code step): compiles the walk input and extracts the blind brief → walk input, blind brief (evidence: hashes).
1. Chief of Staff (runs the compile code step): compiles the model and the hand-offs to the obligation, authority and boundary graph. A cell that cannot be bound is a compile finding (unbindable-prose), never a guessed edge → graph and compile findings (evidence: hashes).
2. Situation Author (a seat that did not design the model): writes the blind pack from the blind brief only. The code generates the standard and negative situations from the situation pack of the request kind, and the budget is declared before the walk → situation set (evidence: run record).
3. Chief of Staff (runs the seal code step): hash-seals the model, the situation set and the rules version → seal record (evidence: hashes).
4. Situation Walker: walks each situation hop by hop under the binding rules. For each hop it records: the input; the actor; the element; the decision; the authority relied on; the licensing rule; the crossing; the assumption flags; the outcome; the terminal state → trace (evidence: run record).
5. Situation Walker: classifies each finding, citing the cell text that licenses the class → finding register (evidence: run record).
6. Review Pod: review point RP7 (§5.8). It reviews the findings only, never re-walks and never redesigns. It confirms by hash that the walked model is the reviewed model, and replays one or two traces → RP7 record (evidence: externally-audited).
7. Chief of Staff (runs the render code step): renders the report → walkthrough report (evidence: hashes).

Role card

Fixed test

TEST-TOM-TW v5: TEST-TOM v5, cases 21, 71, 84 and 91, and the walkthrough battery · result NOT_RUN. The battery is a build item. It sets the card's claim and the wording of a clean walk; no walk or release waits for it (tests/TEST-TOM.md).

5.8 Independent Review

In plain words. At the end of every stage, three or more AI engines check the stage's output. They come from at least two families. In normal mode none is from the family of the engines that made the output. Each engine first reviews alone. Then each sees the findings of the others, never who raised them or how many did, and confirms, challenges with a quote, or says it cannot check. They do not vote. Code checks every quote and settles every finding. A human, the TOM Design Lead, rules on what stays contested. This is the Review Panel rule; a Review Panel is the set of engines drawn for one review. It is not the Panel of §4.4.

Definition

Rules

1. Where it applies. At every review point of the table below, once per locked output, and per child at RP3, RP4 and RP5. A stage's gate passes only on its settled review.
2. Engines. An engine is one AI model as served through the tool gateway. Its family is the lineage the engine register records for it (Annex E.12). A Review Panel has as many engines as the slot review_engines sets: at least 3, at most 5 (§15). Two engines of one family count once wherever families are counted. At the run depth deep, every Review Panel of the run has five engines, and the draw takes three families where the register allows (Annex F).
3. Families and the author. A Review Panel holds engines of at least as many families as the slot review_families_min sets (at least 2), and three where the register allows. The author of an output is every AI Cell whose engine produced it, as the gateway log shows. For RP0 and RP9, whose outputs are made by code steps, the author is the Chief of Staff, which runs them. An output with two authors (Annex G) has both as authors, and its reconciler, whose engine is of one of their two families; so it has exactly two author families. In normal mode no engine of an author's family sits on the review.
4. Level. full: at least three engines, at least two families, none of an author's family. reduced: an author's family sits on the review, or all engines are of one family. With fewer than three eligible engines no review takes place: the step stays produced, not reviewed, and the run shows held: no reviewers (Annex C.1).
5. Blind pass. Every engine receives the same packet in its own fresh context, with no tool and no memory, and sees nothing of any other engine. The order of the questions, and of packet sections that have no order, is shuffled for each engine. Each engine returns one card: a verdict; its findings; the items it examined; the items it could not check, with the reason. The calls run in parallel. No round-1 call starts until every blind call has returned or failed. Each seat calls under its own credential (§17).
6. A finding holds: a class (MATERIAL or MINOR, as the review point defines them); a target (the ID of an item of the output); quotes of the output and of the input or rule; the mechanism, in at most 40 words; and what would close it (the gap, never the fix). An engine never proposes wording, design or repair.
7. Quotes. Engines see the source text in their packet. Every quote in a card, a position or a record is held as atom ID (or packet item ID), span and span hash, never as text (docs/CARRIED-RULES.md §11.2). Code checks every quote against the packet. A quote that fails goes back to its engine once; if it fails again, its finding is void. Free text (a mechanism or a position) holding eight or more consecutive words of a packet source is sent back once; if it fails again, the position counts as CANNOT-CHECK.
8. Coverage. Every checkable item of the output (an element, a crossing, a numbered statement, a row) is examined by at least two engines. Code sends items examined by fewer to the engines that examined fewest, for one targeted pass. An item still short is recorded not covered, and code raises a MINOR finding on it, so the verdict cannot be CLEAR.
9. No debate when clear. When every blind card is CLEAR, no finding was raised and every item is covered, the review settles CLEAR without debate.
10. Round 1: cross-examination. Code merges findings with the same target and class, removes every sign of who raised them and how many did, sets each in a fixed form, and shuffles their order for each engine. Every engine takes one position on every finding:
    • CONFIRM: it checked, agrees, and gives its own quotes;
    • RECLASS: a defect exists, the class differs; it quotes the rule that fixes the class;
    • CHALLENGE: there is no defect; it quotes the text that shows it;
    • CANNOT-CHECK: with the reason.
    A position is at most 120 words. An engine may add at most three new findings, marked late, with the same quotes. Silence is not a position: a missing position is recorded CANNOT-CHECK.
11. Round 2: rebuttal. Only for findings challenged or reclassified in round 1, and for late findings. The raiser sees each quoted challenge; each challenger sees the raiser's mechanism. Each states a final position, HOLD, WITHDRAW or CONCEDE, with a packet quote. "The others disagree" is not a reason.
12. Stop. The debate stops at the first of: every finding settled; a round in which no position moved and no finding was added; two rounds (the cap, fixed by this rule); the review's budget (rule 16). No round is added to reach agreement.
13. Settlement, by code, without a vote. Each finding ends as one of:
    • upheld: after the last round no CHALLENGE or RECLASS stands on it, and at least one engine of a family other than the raiser's has confirmed it with its own quotes;
    • withdrawn: its raiser withdrew it, with a quote;
    • void: its quote failed twice (rule 7);
    • contested: anything else, including a finding no other family could check.
    A finding's class is the highest class any engine still holds. The verdict is the worst class among the findings that end upheld or contested: MATERIAL-findings-present; else MINOR-findings-only; else CLEAR.
14. Nobody votes a finding away. A finding with a verified quote leaves the register only when its raiser withdraws it, or when the TOM Design Lead rules it out. Not by the number of engines or families, not by the Chief of Staff, not by code. A MATERIAL finding withdrawn by its raiser is shown on the Panel, and the Design Lead may reinstate it.
15. Who rules.
    • An upheld MATERIAL finding goes straight to bounded repair (rule 19), or, past the repair cap, to the material finding notice. The Chief of Staff confirms it and rules nothing.
    • A contested MATERIAL finding goes to the TOM Design Lead on a one-page ruling sheet: the finding; the quotes on each side; each family's last position; the rule text; and three choices, UPHOLD, UPHOLD AS MINOR and DISMISS. The last two need a written reason. The ruling rests on the rule text and the evidence, never on a count, and is signed with a live sign-in. Before ruling, the Design Lead may ask for one further engine of a family not yet on this review; its position is evidence, not a vote.
    • A contested MINOR finding holds nothing. It is recorded with its dissent.
    • While a ruling is awaited, the step shows waiting: ruling. Silence rules nothing.
    • At the reduced level no other family can confirm a finding, so every MATERIAL finding is contested and goes to a ruling.
16. Cost. Calls per review are at most the number of engines × (1 blind pass + 1 targeted pass + 2 rounds), plus one re-send per returned quote (rule 7) and the one further engine of rule 15. Each run has a review budget (slot review_budget_per_run, set by the Cell carrying [ORG]HOAC-TM, within budget_cap), metered at the gateway. The Chief of Staff tells the Design Lead at 80% of it. At 100% the step stops with held: review budget. Nothing lowers the engines, families, rounds or level to save cost.
17. Eligibility, ceilings and the served engine.
    • An engine is eligible for a review only if the engine register lists it as active for reviewing at that review point, its confidentiality ceiling is at or above the highest level of any atom in the packet, and it has passed the reviewer seat test (§9) at its current version.
    • No atom reaches an engine above its ceiling (Annex D item 18).
    • The identity of the engine actually served is checked on every call. A mismatch voids the call, which is re-run once. After a second mismatch the engine is dropped from that review.
    • A packet larger than an engine's context is split by code into groups. The same engines review every group, and coverage (rule 8) proves each item was examined. A packet is never truncated.
18. Reduced mode. A reduced review takes place only where the slot reduced_review_permitted (set by the Cell carrying [ORG]HOAC-TM; default no) is yes, and the TOM Design Lead has accepted the reduced level for this run at the run preview (§4.2 step 2). At that level the family minimum of rule 3 does not apply; the minimum of three engines always does. Any review that falls below the accepted level holds. The verification label reads externally-audited (reduced), and the quality checks of the release carry the fixed sentence of Annex E.11. The Requesting Authority is not asked.
19. Repair and re-review. On an upheld or ruled MATERIAL finding:
    • a fresh-context reviser (for a child design, the Ledger Reviser) makes the smallest change;
    • it sweeps for unrepaired findings of the same class;
    • every version is kept, and all code checks re-run;
    • a full re-review follows: a new blind pass on the repaired output, with no earlier finding in the packet; then each earlier finding is put to every engine as a closure question, CLOSED or NOT CLOSED, with a quote.
    At most two cycles. Then the step is held, and the Chief of Staff sends the material finding notice (Failure and recovery, below).
20. The record. The review record (Annex E.10) is a run record, referenced from the release manifest by hash. It keeps:
    • each seat's engine as served, its family, and the level;
    • the cards and the checks;
    • every position, by round and seat, and every change of position with its quote;
    • the minority's wording;
    • the settlement, and the rulings with their reasons;
    • the calls and the cost.
    Dissent survives repair. Nothing of the record enters a release part, except, through code, the quality checks of Annex E.11.

Review points. "Packet" lists what the engines receive, all by hash. "MATERIAL" says what makes a finding of that class at that point; every other true defect is MINOR.

Process (SOP)

1. Chief of Staff (runs the packet code step): builds the packet of the review point; nothing of the dialogue, except at RP1b; on a re-review, no earlier finding → packet (evidence: hashes).
2. Chief of Staff (runs the draw code step): draws seats and engines under rules 2–4, 17 and 18 → seats, engines and level (evidence: the gateway log; the engine register version).
3. Blind Reviewers: each reviews alone → blind cards (evidence: the gateway log shows every blind call ended before round 1).
4. Chief of Staff (runs the check code step): quote and coverage checks; targeted pass → checked cards (evidence: the check log).
5. Chief of Staff (runs the collation code step): merges findings, removes authorship and counts, fixes the form, shuffles → round-1 set (evidence: hashes).
6. Blind Reviewers: cross-examination → positions.
7. Chief of Staff (runs the collation code step): builds the round-2 set → round-2 set.
8. Blind Reviewers: rebuttal → final positions.
9. Chief of Staff (runs the settlement code step): settles every finding, computes the verdict, writes the review record → review record and verdict (evidence: a second run gives the same verdict; the label externally-audited, at its level, is written from this record only).
10. Chief of Staff: confirms upheld MATERIAL findings; sends contested ones to the Design Lead on ruling sheets → finding register.
11. TOM Design Lead: rules → ruling (evidence: signed with a live sign-in).
12. Bounded repair (rule 19) → repair record.
13. Chief of Staff: on a held step, sends one material finding notice as a decision needs request through Source Lifecycle → notice (evidence: needs log).

Role card

Fixed test

TEST-TOM-TR v5: TEST-TOM v5, cases 22, 23, 41, 53–64, 72, 88, 90, 91, 93, 94 and 97, and the reviewer battery · result NOT_RUN

5.9 Decision Package and Release

Definition

Process (SOP)

• 1. Chief of Staff: writes the Decision Package (docs/OUTPUT.md §10). It contains: an executive summary; for each element, its purpose, what it owns and does not own, why it exists and its main evidence; value streams in plain language; the decision model; the boundary as inside, outside and deferred, visibly separated; the rationale; the open items in five blocks (A evidence gaps, B instrument gaps, C deferred cross-child scope, D remaining design uncertainty, E items needing a decision now, and only E asks anything); the missing-evidence signal in plain words; risks and limitations; the walkthrough summary; findings of the quality checks only where they help the decision, never wording hygiene; the elements carried from an earlier release, listed apart as decided in release <ID>; the sources superseded since the pin, in plain words; the run depth, in plain words; the general patterns relied on, and each element resting on one alone; the role register in plain words, with each role finding and how it was settled; the strategy frame, with each element not given; each capability's delivery model and maturity, and each critical stream with its reasons; each outside party's journey; the value case; how the work runs today, or that no record of it was given; each element's proposed priority, with the rule that gave it; the number of rows and passes → package (evidence: hash).
• 1b. Chief of Staff (runs the value-case and priority code step): compiles the value case from the decided parts and the decision references (Annex H.6), and proposes each element's priority by the fixed rule of Annex H.7 → value case; proposed priorities (evidence: hashes; mechanically-verified).
• 1a. Chief of Staff (runs the quality-checks code step): generates the quality checks (Annex E.11) from the settled review records and rulings → quality checks (evidence: hash).
• 2. Review Pod: review point RP8 (§5.8). Every statement traces to a reviewed part and claims no more; the plain-words restatement → RP8 record (evidence: externally-audited). Once RP8 has settled, the quality-checks code step adds the section of this stage from the settled RP8 record.
• 3. TOM Design Lead: attests that gates T0-T7 passed, each with its evidence → attestation (evidence: run record, live sign-in).
• 4. Chief of Staff: sends the decision sheet as decision needs requests: one row per element (ACCEPT, CORRECT with a comment, REJECT), each showing its proposed priority (must, should, could), which ACCEPT keeps and CORRECT may change (Annex H.7); one row for the value case; then one final-status row (ACCEPT; ACCEPT WITH CORRECTIONS, before or after the next stage; RETURN FOR REDESIGN; REJECT). Carried elements are not asked again. Purpose-and-values rows are marked with their listed type → decision rows (evidence: needs log).
• 5. Requesting Authority (in Source Lifecycle, outside this AIOC): decides each row. The Cell carrying [ORG]HOAC-GOV signs the purpose-and-values rows at the gateway. Source Lifecycle records each decision → decision references (evidence: Source Lifecycle's decision records).
• 6. Chief of Staff: applies corrections at the smallest affected step and re-runs only what they re-open, with the failing situations as regression. On ACCEPT or ACCEPT WITH CORRECTIONS, it freezes the release: the manifest names every part and every run record by hash, every pack version with its snapshots, the decision references and every version → TOM Release (evidence: the release_id, computed over the manifest without any filing data).
• 6a. Chief of Staff (runs the release-lint code step): lints every part (Annex D item 19). A hit fails T9 → lint report (evidence: the report's hash in the manifest).
• 6b. Review Pod: review point RP9 (§5.8) → RP9 record. A MATERIAL finding stops filing; the release is re-frozen after repair.
• 7. Chief of Staff: files the TOM Release into [ORG]AIOC-SL as a source of origin kind operating model. It files through the write scope of the connection, on behalf of the TOM Design Lead's Cell, whose position has accepted the contributor agreement. The filing carries the final-status decision reference as its approval; Source Lifecycle sets the release's status from that decision, and nothing more is asked of the Requesting Authority → filing receipt (evidence: the receipt validates; the filed source reads back byte-identical by hash).
• 8. Chief of Staff: sends the release notice to the Requesting Authority's Cell through the HU output port. The run Work Item is done only when the Requesting Authority's acceptance test passes on the filed reference (Protocol §4.5) → notice (evidence: Office record).
• 8a. Chief of Staff: sends the release notice to the next stage, [ORG]AIOC-PPD, through the gateway on the connection of §6 (Protocol §19, item 5). It validates against contracts/release-notice.schema.json (Annex E.20): the release ID, version and manifest hash; the filed reference; the final-status decision reference; the release it supersedes; and the returns it answers (§5.10). It carries no release text: the next stage reads the release from Source Lifecycle by that reference. It is sent once per release, only after the filing receipt reads back. Where the connection is not signed, the notice waits, shown on the Panel; nothing of the run waits for it → release notice (evidence: the Work Item, and the notice's hash in the run record). New in v0.5.0.

Slices and carry-forward. A release covers one slice. The next slice is designed in a continuation run, by these rules:

1. Entry. A continuation run's Design Request (DRQ-01 field 8) names the release it continues and any children to change. P0 lists that release under carried, with the pack IDs named in its manifest.
2. Carried as decided. Each carried child enters decided, by hash. Its child brief, package and design ledger are admitted at T3, T4 and T5 without re-design, with their decision references, unless rule 3 applies.
3. Re-entry. A carried child re-enters at its smallest affected stage when the new Design Request names it for change. It re-enters at the first stage whose input changed (S4 at the earliest) when a source under its load-bearing elements changed: an atom superseded, revoked or reclassified, or no longer resolving by hash at its snapshot. Otherwise it stays decided.
4. Party register. The carried children's marker maps are reconciled with the new party register. A marker that now names a new sibling child is re-paired in Hand-offs (the carry-forward record, Annex E.16).
5. Seams. Hand-offs pairs every crossing of a carried child with the new children. A seam that does not pair is routed to the new child's Structure, Package or evidence, never to the carried child, unless the carried child is named for change (rule 3). A seam that cannot be closed on the new side becomes a decision row.
6. Walk. The walk covers the whole set of children, carried and new. Every earlier failing situation, and every earlier regression set, re-runs as regression. A fresh situation set never erases a recorded failure.
7. Decision. Carried elements are not asked again. The Decision Package lists them apart, as "decided in release <ID>", and asks for the new and changed elements and one final status for the whole release.
8. Release. The new release names every carried part by its original hash (parts[].carried_from), lists the carried release under carries and its pack versions under input_packs (with from_release), contains every slice designed so far, and supersedes the earlier release (supersedes).
9. Trace. T9 accepts an atom of a carried release's pack version only if it still resolves by hash at its snapshot (SL-A8, as amended).
10. A return from a later stage arrives directly and ends by §5.10 (CARRIED-RULES.md §4.4). Where the Requesting Authority answers it by a release, it opens a continuation run whose revised Design Request cites the return's filed copy in Source Lifecycle, and the new release's notice names the returns it answers.

Role card

Fixed test

TEST-TOM-COSTOM v5 (cases 23, 24, 27, 36, 51, 52, 64, 67-69, 80, 82, 85, 98, 100, 117, 118 and 122 for this capability) · result NOT_RUN

5.10 Returns from later stages

New in v0.5.0 (decisions/DR-0005).

Definition

Process (SOP)

• 1. Chief of Staff: admits the return by limit 1, or refuses it with the reason → admitted return or refusal (evidence: the returns log, with the return's hash).
• 2. Chief of Staff: records it in the returns log and shows it on the Panel with its age; ends an accepted return at once (limit 3) → recorded return (evidence: the returns log).
• 3. Chief of Staff (runs the return-brief code step): generates the return brief and its rows from the return and the release elements it names (limit 4) → return brief (evidence: hash).
• 4. Chief of Staff: sends the rows as decision needs requests through [ORG]AIOC-SL (§5.2), one decision per row, with the brief as their explainer → decision rows (evidence: the needs log).
• 5. Requesting Authority (in Source Lifecycle, outside this AIOC): decides one row. Source Lifecycle records the decision → decision reference (evidence: Source Lifecycle's decision record).
• 6. Chief of Staff: records the decision on the return as its next version. answered by decision, or set aside by decision with its carried_forward_on, ends it. A decision to open a continuation run keeps it open until the new release is filed; that release's notice names the return, and the return becomes answered by release, with answered_by the new release ID → return answer (evidence: the return's next version, valid against the pinned contract).
• 7. Chief of Staff: sends the return answer back to its sender, on the same connection → sent answer (evidence: the Work Item).
• 8. Chief of Staff: on the sender's next round of the same return, repeats steps 2 to 7; at a deadline passed, or at return_rounds_max, escalates by limit 6 → escalated return (evidence: the returns log).
• 9. TOM Design Lead: classifies each ended return by limit 8 → classification record (evidence: run record, live sign-in).

Role card

Fixed test

TEST-TOM-COSTOM v5 (cases 101–108 for this capability) and TEST-TOM-TDL v5 (TDL-8) · result NOT_RUN

6. Coordination and routes

• [ORG]AIOC-SL. It is the only source this AIOC asks and files into, and the only route to any person in the organisation.
  • Routes. Sources, answers and status messages arrive by reference through the Input socket. Needs requests, Missing Reports, status messages and filings leave as Work Items through the output port.
  • The organisation-design connection. It is signed by the [ORG]HOAC-ACS seat that [ORG]AIOC-SL is accountable to, as connect-external-port (Protocol §13, item 5); a wider scope is grant-or-widen-access. It has three parts:
    • unrestricted read across every collection and confidentiality level, as Source Lifecycle requires for an organisation-design connection;
    • least-privilege write, only for sources of origin kind operating model or design report;
    • needs requests.
  • Expiry and revocation. Scope expiry is checked on every read. A revocation cuts the connection at the tool gateway at once: every later read is refused, and the run is held as held: connection revoked (Annex C.1). A revocation is not a stop, and no restart is needed.
• Other source types are read only, each through its own adapter (§4.3), each connection signed by the seat over that source as connect-external-port.
• Work Items.
  • The run. A run is one Work Item, opened by the Requesting Authority's Cell through this AIOC's HU input port. Its fields:
    • requested output: a TOM Release under contracts/tom-release.schema.json;
    • acceptance test: the Requesting Authority's (gate T8 decided; the manifest valid; the filed reference reads back);
    • sources: the Design Request reference.
  • Needs requests. Each is a sub-item of the run, with chain depth 1. It goes to [ORG]AIOC-SL, and its requested output is a needs answer (Protocol §4.6, item 2). Source Lifecycle answers the sub-item; it never opens a new item back to this AIOC, so the chain never loops.
• [ORG]AIOC-PPD, the next stage, linked directly (Protocol §19, items 5 and 7). New in v0.5.0.
  • Routes. On every filing of a decided release, a release notice leaves through the output port (§5.9 step 8a). PPD reads the release itself from Source Lifecycle, by the reference in the notice. Its returns arrive at the Chief of Staff's port, and end by §5.10.
  • The connection. One connection with two scopes: release notices to PPD; returns from PPD and their answers. It is signed by the [ORG]HOAC-ACS position over this AIOC, the TOM Design Lead's, as connect-external-port (H-35). A wider scope is grant-or-widen-access. A revocation cuts it at the gateway at once; notices and answers wait, shown on the Panel. This AIOC stands alone without it (Protocol §19, item 9).
  • Loops. A return is a Work Item from PPD. This AIOC answers it on that Work Item and never opens a new item back, so the chain never loops (Protocol §4.6, item 2).
• [ORG]AIOC-DI, the last stage (Protocol §20, item 3). New in v0.5.0. Its returns on elements of this AIOC's releases arrive and end in the same way, on a connection with one scope (returns from DI and their answers), signed as above (H-35). Nothing else is sent to it; it reads this AIOC's releases from Source Lifecycle, by reference.
• [ORG]AIOC-OCO. It installs, fixes and upgrades this AIOC through the front door. Every proposal, correction or critique of this AIOC's AIs is a design-proposal Work Item to OCO.
• Routing rows this AIOC contributes. needs request → [ORG]AIOC-SL; missing report → [ORG]AIOC-SL; needs status → [ORG]AIOC-SL; TOM Release filing → [ORG]AIOC-SL; release notice → [ORG]AIOC-PPD; return answer → the sender of the return.

7. Records and where things live

• References, not copies. Atom text is held only in the run workspace, resolved through its adapter by <adapter ID>:<source ID>@<version>#<anchor> and hash. Records store atom IDs and hashes, never atom text.
• Revocation or reclassification. On a notice from Source Lifecycle (docs/INTAKE-WITH-SOURCE-LIFECYCLE.md §9), the run is held and its workspace copies are sealed. A supersession after the pin flags the affected atoms in the next pack version (§4.3).
• Engine ceilings. No atom is sent to an engine whose confidentiality ceiling is below the atom's level (§5.8 rule 17; Annex E.12).
• Confidentiality of the release. The release quotes a source only where that source's confidentiality level allows it under the grant. It takes the highest confidentiality level of anything it quotes, and Source Lifecycle classifies it so.

8. Tools and the shared AI gateway

• Metering. Every engine call goes through the tool gateway of the [ORG]AION, metered for this AIOC (Standard §4.4, item 11).
• Engines and seats. Each AI Cell's filler is its bot, with its own identity card and credential. The gateway binds each call to an engine of the engine register and logs the engine served. For each review, the draw binds each drawn reviewer seat to one eligible engine (§5.8). Binding an engine is not a change of filler. An engine may serve a Cell only after passing that Cell's fixed test at its current version (Standard §3.2 item 2; §4.4 item 4). That binding an engine is not a change of filler is this AIOC's reading of the Standard, proposed to 49GAION as a reading note (upstream/PROPOSALS.md, item 6).
• New. Null default. Every AI Cell runs with no tools, no outside access, no memory and a fresh context for each dispatch. Any grant above that needs a rationale, a scope, a permission level and its effect on qualification.
• New. Instruction packs. They are generated from this blueprint and checked by diff; hand-paraphrase is forbidden.
• New. Tests stay hidden from the runners. No Cell under test sees TEST-TOM, its fixtures, the review protocol, §9 or the reviewer battery.

9. Fixed tests: index, triggers and scores

Each part has its own fixed test, made of the cases of TEST-TOM v5 (tests/TEST-TOM.md) that exercise it. The owner of every part's test is the TOM Design Lead ([ORG]CELL-TDL). The owner of the AIOC's whole test, and of the Design Lead's own seat test, is the Cell carrying [ORG]HOAC-TM.

• Re-run triggers. The template defaults, plus any change to a contract in contracts/, to the Source Lifecycle output socket, or to the situation library; and any change to an adapter file or its fixtures, to the engine register, or to the release lint deny-list; any change to the reference-model catalogue pin; any change to the pin of the Library's design return contract (contracts/PINS.json).
• Where results are kept. In this section; on the Panel's Health section; and, as evidence, in <org>aioc-tom-records.

10. Build: what is generated from this file

Template defaults. In addition:

• Validators. The code project builds, from contracts/, the validators for every contract.
• Cards. tools/make_cards.py generates the unit cards and the bot identity cards in cards/ from §17 of this file, and checks them. It writes 26 unit cards and 18 bot identity cards. The blueprint governs; the generated cards are copies. It also checks every code against Naming Standard R15 and R16 and the withdrawn codes (§17).
• Contract checks. tools/check_contracts.py validates every contract and example; checks the content addresses of the release and the Input Pack; checks that the listed-type enums are a subset of the pinned signature list (contracts/PINS.json); checks each adapter's fixtures against its mapping block; and runs the release lint over docs/OUTPUT.md, the release enum strings and the lint fixtures; validates the reference-model catalogue seed in upstream/ and checks its pin (check 10); checks the pin of the Library's design return contract and validates this AIOC's return examples against it (check 11).
• Release lint. tools/release_lint.py is the release-lint code step of S8, and the CI check (Annex D item 19; Annex E.15).

11. Exceptions

1. The Chief of Staff never asks the organisation's people anything. The default Chief of Staff carries requests to and from humans. This one talks only to its own HOAC seat, and only about the run. It reaches the organisation only through the Chief of Staff of [ORG]AIOC-SL. Reason: the direction recorded in decisions/DR-0001, that this AIOC works only from documents, because spoken words cannot be the basis of an operating model.
2. The Input socket has one adapter in this version, for Source Lifecycle (ADP-SL). Any other source type enters only through its own adapter file, read only (§4.3). Words typed or spoken to this AIOC are refused as input. Reason: as in item 1.
3. The Back office does not converse with humans (converses_with_humans: false on the card). Reason: as in item 1.
4. The HU input ports of the Pods and inner Cells accept only run control and configuration from the TOM Design Lead, never content about the organisation. Reason: as in item 1.

12. Lessons and proposals to the mother

Lessons from the case study are history, not evidence (§0).

13. For the [ORG]HOAC-ACS seat, and every decision only a human seat can take

Every decision that only a human seat can take is listed here once, with its seat and its default. Silence decides nothing; a general approval decides no row.

H-01 to H-27, H-30 to H-34, H-36, H-37 and H-39 are taken by GOV, the TM Cell or the Requesting Authority. H-40 is taken in the organisation's own mechanism, outside this AIOC. H-28, H-29, H-35, H-38 and H-40 are listed so that the list is complete; they are not design questions.

Money: the AI budget cap and the review budget (H-13); the deepest run depth permitted (H-31). People: none; this AIOC writes no position. Legal: none decided here; the perimeter list goes to a human legal reviewer.

14. Change log

15. Configuration

The template's slots, all none: must be set until the organisation sets them, plus these slots of this AIOC:

Waiting deadlines and escalation follow the template slot waiting_deadlines (Protocol §4.6); re-sending follows bounce_limit (Protocol §4.4).

16. Type

• Type: Specialised.
• Why this AIOC exists: an organisation needs a target operating model that is honest about its evidence and decided by its own authority; this AIOC makes one from the organisation's documents alone.
• Type-specific test: TEST-TOM v5, case 27 · result NOT_RUN.

17. Cells and Pods

The parts inside this AIOC (docs/CELLS-AND-PODS.md of 49GAION-aioc). The role and nature of this AIOC are read from the type of its top Cell, the TOM Design Lead.

The card data (the blueprint governs). The block below holds every value of every Pod and Cell card and of the bot identity card of every AI Cell. tools/make_cards.py expands it into the complete forms of the template (§17 of the template; spec/schemas/unit-card.schema.json and bot-identity-card.schema.json of 49GAION-protocol), writes them into cards/ as generated copies, and checks them: against the schemas; against the code rules of tests/cards/check_cards.py (a fixed test is never owned by the part itself; a bot never claims a right to sign; no credential is shared); and against this blueprint (the inner units of the AIOC card are exactly the parts whose parent is the AIOC, and the AIOC is accountable to no Cell inside it). Each port gets the standard fields (identification, enforcement at the shared gateway outside the unit, audit_trail, required_tests); the stop door accepts only stop.

parts:
  defaults:
    accountable_to: "[ORG]CELL-TDL"
    card_version: "v0.6.3"
    version: "0.6.3"
    lifecycle_state: "designed"
    test_version: "v5"
    test_owner: "[ORG]CELL-TDL"
    audit_trail: "the run record of [ORG]AIOC-TOM"
    hu_in: ["run control and configuration from the TOM Design Lead (never a source)"]
    hu_out: ["run report to the TOM Design Lead"]
  cells:
    - code: "[ORG]CELL-TDL"
      full_name: "TOM Design Lead"
      parent: "[ORG]AIOC-TOM"
      type: "Human Seat"
      filler_kind: "human"
      hoac: "[ORG]HOAC-ACS"
      accountable_to: "[ORG]CELL-TMS"       # example code of the Cell carrying [ORG]HOAC-TM
      entity: "<entity>"
      authority_scope:
        decision_types: ["change-fixed-test-or-threshold", "create-or-install-unit", "change-filler", "retire-unit", "restart-stopped-unit", "move-work-toward-ai"]
        entity: "<entity>"
        expires: "2027-10-14"                # placeholder; each organisation sets it
        authority: "delegated"
      test: { id: "TEST-TOM-TDL", cases: "TDL-1 to TDL-8", owner: "[ORG]CELL-TMS" }
      ai_in: ["run brief", "run preview", "ruling sheets for contested MATERIAL findings", "release notice", "ended returns to classify"]
      ai_out: ["run control and configuration"]
      hu_in: ["direction from the Cell carrying [ORG]HOAC-TM"]
      hu_out: ["rulings, attestations, reduced-level acceptances, re-base decisions and the classification of ended returns, under live sign-in", "report to the Cell carrying [ORG]HOAC-TM"]
    - code: "[ORG]CELL-COSTOM"
      code_rule: "R16"                     # 49GAION/DR-0028; replaces [ORG]CELL-TCS (retired, R5)
      lineage: { id: "[ORG]CELL-TCS", version: "0.6.0", relation: "derived" }
      full_name: "TOM Chief of Staff"
      role: "Chief of Staff"
      parent: "[ORG]AIOC-TOM"
      type: "AI Chief of Staff"
      filler_kind: "ai"
      cell_kind: "chief-of-staff-cell"
      test: { id: "TEST-TOM-COSTOM", cases: "1-13, 23-36, 40, 43, 44, 46, 49-52, 61, 64, 67-69, 75, 76, 78, 80-82, 85, 87, 89, 90, 92, 94-96, 98-108" }
      ai_in: ["source reference", "needs answer", "needs status", "needs candidate", "locked outputs of the Pods", "settled review records", "return"]
      ai_out: ["Input Pack version", "dispatch to a Pod", "review packet", "needs request", "missing report", "needs status", "TOM Release filing", "difference register", "role register", "release notice", "return brief", "return answer"]
      hu_out: ["run brief to the TOM Design Lead", "run preview to the TOM Design Lead", "ruling sheets to the TOM Design Lead", "release notice to the Requesting Authority's Cell"]
      external_ports:
        - { port: "sl-in", direction: "input", accepted_content: ["source reference", "needs answer", "needs status"], authority_limit: "the read scope signed under connect-external-port", audit_trail: "unit register connected and disconnected events; serve log of [ORG]AIOC-SL" }
        - { port: "sl-out", direction: "output", accepted_content: ["needs request", "missing report", "needs status", "TOM Release filing"], authority_limit: "the write and request scope signed under connect-external-port: sources of origin kind operating model or design report only", audit_trail: "unit register connected and disconnected events; serve log of [ORG]AIOC-SL" }
        - { port: "ppd-out", direction: "output", accepted_content: ["release notice", "return answer"], authority_limit: "notices and answers by reference only, under the scope signed under connect-external-port over this AIOC", audit_trail: "unit register; the Work Item record" }
        - { port: "ppd-in", direction: "input", accepted_content: ["return"], authority_limit: "returns only, under the scope signed under connect-external-port over this AIOC", audit_trail: "unit register; the Work Item record" }
        - { port: "di-out", direction: "output", accepted_content: ["return answer"], authority_limit: "answers by reference only, under the scope signed under connect-external-port over this AIOC", audit_trail: "unit register; the Work Item record" }
        - { port: "di-in", direction: "input", accepted_content: ["return"], authority_limit: "returns only, under the scope signed under connect-external-port over this AIOC", audit_trail: "unit register; the Work Item record" }
      bot:
        allowed_actions: ["dispatch Cells of this AIOC", "build Input Pack versions through the code steps", "lock outputs and run code steps", "draw review engines and run the review code steps", "write the run record", "send needs requests, Missing Reports and status messages to [ORG]AIOC-SL", "send run previews and ruling sheets to the TOM Design Lead", "file a release whose final status is decided", "compare two locked drafts and compile the role register through the code steps", "send the release notice of a filed release to [ORG]AIOC-PPD", "admit or refuse a return by the pinned contract and record it", "generate return briefs through the code step and send their rows to [ORG]AIOC-SL", "send return answers to the sender of each return"]
        ask_first_actions: ["a second run in parallel", "a budget above the cap", "a re-base of the Input Pack", "a reduced review level", "single authoring at S5", "any change to configuration", "anything outside its role card"]
    - { code: "[ORG]CELL-TSP", full_name: "TOM Source Proxy", role: "Source Proxy", parent: "[ORG]POD-TRR", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-TOM-TSP", cases: "4, 5, 14, 92" }, ai_in: ["Input Pack atoms", "question from the Request Analyst"], ai_out: ["cited answer or refusal"], bot: { allowed_actions: ["answer from the sources with a citation", "refuse"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-TRA", full_name: "TOM Request Analyst", role: "Request Analyst", parent: "[ORG]POD-TRR", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-TOM-TRA", cases: "8, 14, 15, 28, 73-75, 83, 91, 92" }, ai_in: ["Input Pack atoms", "cited answer or refusal", "decided structure"], ai_out: ["Design Brief draft", "Gate A record", "party register", "lens record", "needs candidate"], bot: { allowed_actions: ["draft and label the Design Brief", "derive lenses and read the sources through them, with citations", "write the party register", "raise needs candidates with leverage proofs"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-TSRA", full_name: "TOM Second Request Analyst", role: "Second Request Analyst", parent: "[ORG]POD-TRR", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-TOM-TSRA", cases: "8, 14, 15, 73-75, 83, 91, 92" }, ai_in: ["Input Pack atoms", "cited answer or refusal"], ai_out: ["frame draft, written blind to the other author", "Gate A record", "party register", "lens record", "needs candidate"], bot: { allowed_actions: ["draft and label the frame blind to the other author's draft", "derive lenses and read the sources through them, with citations", "write a party register", "raise needs candidates with leverage proofs"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-TFR", full_name: "TOM Frame Reconciler", role: "Frame Reconciler", parent: "[ORG]POD-TRR", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-TOM-TFR", cases: "93, 94" }, ai_in: ["two locked frame drafts", "difference register", "the Input Pack atoms the drafts cite"], ai_out: ["reconciled frame", "the dispositions of the difference register"], bot: { allowed_actions: ["reconcile two locked frame drafts under blueprint Annex G", "record each difference's disposition with its reason and quotes"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-TWS", full_name: "TOM Work Structurer", role: "Work Structurer", parent: "[ORG]POD-TS", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-TOM-TWS", cases: "16, 42, 83" }, ai_in: ["decided Design Brief frame", "party register"], ai_out: ["Structure Proposal", "party register extension"], bot: { allowed_actions: ["propose children and checks", "record alternatives", "extend the party register with sibling children"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-TP", full_name: "TOM Packager", role: "Packager", parent: "[ORG]POD-TEP", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-TOM-TP", cases: "17, 41, 45" }, ai_in: ["markerised pack atoms", "class-only registry", "crossing candidates", "child row"], ai_out: ["packaging ledger"], bot: { allowed_actions: ["decide atom membership", "adjudicate crossing candidates with reasons"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-TD", full_name: "TOM Designer", role: "Designer", parent: "[ORG]POD-TEM", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-TOM-TD", cases: "18, 19, 38, 39, 91, 92, 97" }, ai_in: ["child package", "reference-model catalogue at the run's pinned version"], ai_out: ["design ledger, written blind to the other author"], bot: { allowed_actions: ["write a design ledger blind to the other author's ledger"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-TLR", full_name: "TOM Ledger Reviser", role: "Ledger Reviser", parent: "[ORG]POD-TEM", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-TOM-TLR", cases: "18, 93" }, ai_in: ["child package", "two locked drafts", "difference register", "review findings to repair"], ai_out: ["reconciled and revised ledger", "revision record", "the dispositions of the difference register"], bot: { allowed_actions: ["reconcile two locked design ledgers under blueprint Annex G", "revise a locked ledger in a fresh context"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-TSD", full_name: "TOM Second Designer", role: "Second Designer", parent: "[ORG]POD-TEM", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-TOM-TSD", cases: "18, 19, 38, 39, 91, 92, 97" }, ai_in: ["child package", "reference-model catalogue at the run's pinned version"], ai_out: ["design ledger, written blind to the other author"], bot: { allowed_actions: ["write a design ledger blind to the other author's ledger"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-THA", full_name: "TOM Hand-off Analyst", role: "Hand-off Analyst", parent: "[ORG]POD-TH", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-TOM-THA", cases: "20, 37, 42, 65, 66, 70, 87" }, ai_in: ["design ledgers", "pairing table", "seam findings", "party register"], ai_out: ["hand-offs register", "counterparty register", "perimeter list", "deferred-boundary register"], bot: { allowed_actions: ["record each clean pair in the hand-offs register", "map counterparties by class", "list the legal and regulatory perimeter", "register deferred boundary classes"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-TSA", full_name: "TOM Situation Author", role: "Situation Author", parent: "[ORG]POD-TW", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-TOM-TSA", cases: "21, 84, 91" }, ai_in: ["blind brief: entity type, accountability set and boundary list"], ai_out: ["blind situation pack"], bot: { allowed_actions: ["write the blind situation pack"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-TSW", full_name: "TOM Situation Walker", role: "Situation Walker", parent: "[ORG]POD-TW", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-TOM-TSW", cases: "21, 71" }, ai_in: ["sealed situation set", "operating model graph from the walk input"], ai_out: ["trace", "finding register"], bot: { allowed_actions: ["walk sealed situations under the binding rules", "classify findings"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-TBRA", full_name: "TOM Blind Reviewer A", role: "Blind Reviewer A", parent: "[ORG]POD-TR", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-TOM-TBRA", cases: "22, 53, 55, 72 and the reviewer battery" }, ai_in: ["review packet", "collated findings of its review"], ai_out: ["review card", "positions on findings"], bot: { allowed_actions: ["write its own review card", "state its own positions on the findings of its review"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-TBRB", full_name: "TOM Blind Reviewer B", role: "Blind Reviewer B", parent: "[ORG]POD-TR", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-TOM-TBRB", cases: "22, 53, 55, 72 and the reviewer battery" }, ai_in: ["review packet", "collated findings of its review"], ai_out: ["review card", "positions on findings"], bot: { allowed_actions: ["write its own review card", "state its own positions on the findings of its review"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-TBRC", full_name: "TOM Blind Reviewer C", role: "Blind Reviewer C", parent: "[ORG]POD-TR", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-TOM-TBRC", cases: "22, 53, 55, 72 and the reviewer battery" }, ai_in: ["review packet", "collated findings of its review"], ai_out: ["review card", "positions on findings"], bot: { allowed_actions: ["write its own review card", "state its own positions on the findings of its review"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-TBRD", full_name: "TOM Blind Reviewer D", role: "Blind Reviewer D", parent: "[ORG]POD-TR", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-TOM-TBRD", cases: "22, 53, 55, 72 and the reviewer battery" }, ai_in: ["review packet", "collated findings of its review"], ai_out: ["review card", "positions on findings"], bot: { allowed_actions: ["write its own review card", "state its own positions on the findings of its review"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-TBRE", full_name: "TOM Blind Reviewer E", role: "Blind Reviewer E", parent: "[ORG]POD-TR", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-TOM-TBRE", cases: "22, 53, 55, 72 and the reviewer battery" }, ai_in: ["review packet", "collated findings of its review"], ai_out: ["review card", "positions on findings"], bot: { allowed_actions: ["write its own review card", "state its own positions on the findings of its review"], ask_first_actions: ["anything outside its role card"] } }
  pods:
    - { code: "[ORG]POD-TRR", full_name: "TOM Request Reconstruction", type: "AI Pod", inner_units: ["[ORG]CELL-TRA", "[ORG]CELL-TSP", "[ORG]CELL-TSRA", "[ORG]CELL-TFR"], top_cell: "[ORG]CELL-TRA", test: { id: "TEST-TOM-TRR", cases: "4, 5, 8, 14, 15, 28, 73-76, 83, 91-93" }, ai_in: ["Input Pack version", "needs answer", "decided structure"], ai_out: ["Design Brief", "party register", "needs candidate", "Readiness Report", "difference register"] }
    - { code: "[ORG]POD-TS", full_name: "TOM Structuring", type: "AI Pod", inner_units: ["[ORG]CELL-TWS"], top_cell: "[ORG]CELL-TWS", test: { id: "TEST-TOM-TS", cases: "16, 42, 83" }, ai_in: ["decided Design Brief frame", "party register"], ai_out: ["Structure Proposal"] }
    - { code: "[ORG]POD-TEP", full_name: "TOM Entity Packaging", type: "AI Pod", inner_units: ["[ORG]CELL-TP"], top_cell: "[ORG]CELL-TP", test: { id: "TEST-TOM-TEP", cases: "17, 41, 45" }, ai_in: ["decided child", "Input Pack atoms", "party register (code steps only)"], ai_out: ["child package"] }
    - { code: "[ORG]POD-TEM", full_name: "TOM Entity Model", type: "AI Pod", inner_units: ["[ORG]CELL-TD", "[ORG]CELL-TLR", "[ORG]CELL-TSD"], top_cell: "[ORG]CELL-TD", test: { id: "TEST-TOM-TEM", cases: "18, 19, 38, 39, 91-93, 96, 97" }, ai_in: ["child package", "reference-model catalogue at the run's pinned version"], ai_out: ["design ledger", "TOM Blueprint", "Rationale and Evidence Brief"] }
    - { code: "[ORG]POD-TH", full_name: "TOM Hand-offs", type: "AI Pod", inner_units: ["[ORG]CELL-THA"], top_cell: "[ORG]CELL-THA", test: { id: "TEST-TOM-TH", cases: "20, 37, 42, 65, 66, 70, 85-88" }, ai_in: ["design ledgers", "boundary registers", "party register"], ai_out: ["hand-offs register", "counterparty register", "perimeter list", "deferred-boundary register", "seam findings", "role register"] }
    - { code: "[ORG]POD-TW", full_name: "TOM Walkthrough", type: "AI Pod", inner_units: ["[ORG]CELL-TSW", "[ORG]CELL-TSA"], top_cell: "[ORG]CELL-TSW", test: { id: "TEST-TOM-TW", cases: "21, 71, 84, 91 and the walkthrough battery" }, ai_in: ["walk input", "blind brief"], ai_out: ["walkthrough report"] }
    - { code: "[ORG]POD-TR", full_name: "TOM Review", type: "AI Pod", inner_units: ["[ORG]CELL-TBRA", "[ORG]CELL-TBRB", "[ORG]CELL-TBRC", "[ORG]CELL-TBRD", "[ORG]CELL-TBRE"], top_cell: "[ORG]CELL-TBRA", test: { id: "TEST-TOM-TR", cases: "22, 23, 41, 53-64, 72, 88, 90, 91, 93, 94, 97 and the reviewer battery" }, ai_in: ["review packet"], ai_out: ["review cards and positions"] }

• Accountability. Every Pod and Cell of this AIOC is accountable_to [ORG]CELL-TDL. The AIOC itself and the Design Lead are accountable_to the Cell carrying [ORG]HOAC-TM, which signs the AIOC's install, its change-parent and its restart-stopped-unit (Standard §5.3, item 4; §4.4, item 3).
• The Design Lead's authority. The authority_scope of [ORG]CELL-TDL lists the listed types it signs on this AIOC's Cells (Protocol §4.10, item 12). Every other listed type on this AIOC's parts is signed by the Cell carrying [ORG]HOAC-TM. The expiry date is a placeholder that each organisation sets.
• Bots. Each AI Cell's bot (eighteen) has its own identity card, with its own credential, never_signs: true and its memory sealed on a change of filler (Protocol §10, item 3); the cards are generated into cards/bots/. The credential IDs there are placeholders; the credentials themselves live only in the organisation's vault.
• Engines. A bot's identity card names no engine. The gateway binds engines per call, and the draw binds them per review (§8; §5.8).
• Codes. The codes follow the initials of each part's own name (Naming Standard R15), except the Chief of Staff's, [ORG]CELL-COSTOM, which takes COS and the initials of [ORG]AIOC-TOM (R16, 49GAION/DR-0028). All pass the collision check of §5 (table below). [ORG]POD-TOR, [ORG]POD-TGA, [ORG]CELL-TOA, [ORG]CELL-TA and [ORG]CELL-TPA were never registered; they are withdrawn and never issued again for any meaning. [ORG]CELL-TCS, the Chief of Staff's code until v0.6.0, is retired at v0.6.1 (R5) and never issued again.
• The Requesting Authority and the Chief of Staff of [ORG]AIOC-SL are not Cells of this AIOC.

Code checks (Naming Standard R15, R16 and §5), recorded on 15 October 2026; the Chief of Staff's COS code on 19 October 2026. Each organisation repeats the check of §5.2 against its own register before first use (R9, R15.3).

The codes checked against: [ORG]CELL-TDL, -TCS, -TSP, -TRA, -TWS, -TP, -TD, -TLR, -THA, -TSA, -TSW, -TBRA to -TBRE; [ORG]POD-TRR, -TS, -TEP, -TEM, -TH, -TW, -TR; the example codes [ORG]AIOC-CH, [ORG]AIOC-SL, [ORG]AIOC-OCO, [ORG]CELL-TMS, [ORG]CELL-GOV, [ORG]CELL-SLCS, [ORG]POD-RV; the withdrawn codes; and the three new codes against each other. On 19 October 2026, [ORG]CELL-COSTOM against all of these and against the COS codes of the other mothers.

Annex B. Labels and the honesty ceiling

B.1 Labels. Every material statement in a run carries exactly one label, and a standing. This AIOC assigns the label on admission, in the Input socket (§4.3), once per atom. It never reads it from a source reference.

• Order: source-backed > inferred > organisation-stated > assumed > unknown. The label observed is not used: this AIOC never watches work. Records of the work as it runs today are read as exports, by role-type and process, never about a person (Annex H.8; §13, H-07).
• Source Lifecycle's own labels are kept statement by statement (adapters/source-lifecycle.adapter.md §5; B.1a). A statement Source Lifecycle labels stated is admitted as source-backed when it stands in a document, and as organisation-stated when it was recorded from conversation. inferred, assumed and unknown stay as they are. An approved explainer never lifts a statement Source Lifecycle holds as inferred or assumed.
• Confirmation never lowers a label, and never launders one. An organisation's confirmation of an inferred item keeps the label inferred and adds the standing note confirmed → <confirmation reference>. The item is then released from the sticky-inferred rule; it never becomes source-backed. A correction replaces the item with the corrected text, labelled organisation-stated. "Don't know" leaves the item as it was, unconfirmed, with the answer recorded. No answer ever lowers a label.
• No label laundering. A label changes only on evidence of the destination's own class. A change of what a claim covers ("the source says X" becoming "X is true") needs its own record row even when the label stays.
• Sticky inferred. An inferred item keeps raising its question until it is confirmed, corrected or carried with its cost.
• Standing: uncontested, or contested → C-n (the contradiction row). A statement cannot read uncontested while an open row names it.

B.1a Reading by origin kind. It applies to every adapter.

B.2 Contradictions. A contradiction row is closed only as:

• decided by the Requesting Authority for this brief, as a non-delegable row (the losing side stays in the register, and the decision does not spread beyond this brief);
• decided with a cited precedence rule from a held source;
• or carried, with what it blocks.

Where both sides rest on the same source, a decision does not close the row; it is carried. A decision that a draft governs never upgrades a claim to source-backed. A contradiction touching ownership, a scope boundary or a success criterion is never turned into an assumption. A status record in Source Lifecycle says whether one source is in force; it never says which of two sources governs. Two live versions of one document, found at admission, reach the frame as candidate contradictions; they are never resolved at S0. Two sources that disagree are a contradiction whichever adapters served them.

B.3 Honesty ceiling. The ceiling is the weakest label carried by any load-bearing claim, named together with that claim. It is stated per committed entity, and for the present state, the outcome and each criterion, with the label distribution. The brief's ceiling is the lowest of its committed entities; a context entity's ceiling is stated separately. A claim is load-bearing by default if it is used in scope, an exclusion, an outcome, a constraint, a criterion, a child boundary, a needs request, the do-not-ask or do-not-use-as-fact list, or an open item. Placing it in an open item does not exempt it. Calling it not load-bearing needs a recorded reason and is a reviewable defect. No committed entity sits in scope with ceiling unknown unless it is listed as a blocking unknown; a context entity's unknown creates no blocking unknown.

Pattern reliance. The ceiling also names, per child and for the release, each pattern that informed a load-bearing element (by its plain name and catalogue version), how many load-bearing elements it informed, and how many of those rest on no atom of the organisation. Such an element is assumed (B.5), so it sets the ceiling at assumed.

B.4 Verification labels. A check's result is labelled:

• mechanically-verified: a code step ran on the locked output. Only code writes this label;
• externally-audited: a settled review of this run confirmed it (§5.8), at the level full or reduced. The label states the level, for example externally-audited (reduced). Only the settlement step writes it, from a settled review record;
• self-reviewed: only the run's own judgement covers it;
• not-run.

The Chief of Staff records labels and never writes one on a check it ran. No Cell writes a label on its own work.

B.5 Reference models. New in v0.4.0. A reference model is a pattern of the 49GAION reference-model catalogue (Annex E.19), read at the version and hash pinned for the run. It is a method, never evidence.

• A statement taken from a pattern is never source-backed or organisation-stated, and never an atom. A pattern never raises a label, never closes an unknown and never settles a contradiction.
• Where the organisation's atoms state an element a pattern suggested, the element takes the label its atoms support, and the pattern is recorded as the method that suggested it.
• Where they do not, the element is assumed (B.1), with what breaks if it is false and when to re-check it. A major or core capability is never authoritative on a pattern alone (CARRIED-RULES.md §8.1 rule 11).
• Pattern reliance is part of the honesty ceiling (B.3).

Annex C. Run states, gates, Gate A, admissible criteria and decision rules

C.1 Run states

• States, in order: admitting (S0) → framing (S1) → structuring (S2) → child briefing (S3) → packaging (S4) → designing (S5) → hand-offs (S6) → walking (S7) → deciding (S8) → end states released → filed. Each stage is one run state and closes on its gate (§5.0). Per-child stages (S3, S4, S5) run per child. The run state is the earliest stage any child of the slice is still in.
• Endings other than a release.
  • closed: not admitted, when T0 fails; the run Work Item is returned with each failed condition by name;
  • closed: readiness report;
  • closed: held report, after a CLOSE choice (§5.8);
  • closed: non-response (§5.1, failure), when the stop ends in a Readiness Report;
  • closed: rejected, after a final status of REJECT;
  • closed: withdrawn by the Requesting Authority.
  Every ending releases the run slot. A final status of RETURN FOR REDESIGN returns the run to the state of the smallest affected step. A narrowest honest brief emitted at a non-response stop is a decided brief: the run continues from it at gate T1 or T3.
• Flags on any state, each shown with its age. No flag releases the run slot.
  • waiting, shown with its age against the waiting deadline;
  • waiting: ruling, until the TOM Design Lead rules on a contested MATERIAL finding (§5.8 rule 15);
  • held: material finding, until a choice is decided (§5.8);
  • held: connection revoked, until a new connection is signed or the Requesting Authority closes the run;
  • held: no reviewers, while fewer engines are eligible than the review needs (§5.8 rule 4);
  • held: review budget, when the run's review budget is used up (§5.8 rule 16);
  • held: engine ceiling, when a later pack version holds an atom above the ceiling of an engine the run needs (§5.8 rule 17); or when either author family can no longer be bound (Annex G.7).
• Filing. A Readiness Report or a Held Report is filed into Source Lifecycle as a source of origin kind design report, with the ID TOMD- + SHA-256 of its body, and a filing receipt (contracts/tom-filing-receipt.schema.json).
• Silence. Silence decides nothing, and a run is never left open and silent. Past the waiting deadlines it is raised to the TOM Design Lead and shown on both Panels; past the configured passes it stops as non-response and emits a Readiness Report (which is filed and closes the run) or the narrowest honest brief (from which the run continues).
• Stops. A stop through the stop door halts the run in its state; it resumes only after a signed restart-stopped-unit.
• Returns are not run states. A return lives on its own Work Item from its sender, with the states of the contract (§5.10). No run is held by a return, and a return waits for no run.

C.2 The gates

A gate passes only on visible evidence in the run record. A step's own report is never evidence. "Unresolved" in this table has the meaning of Annex D, item 12.

C.3 Gate A: the eight sufficiency questions, and the admissible criteria

The eight questions (full text: docs/CARRIED-RULES.md §3):

• S1 Standing. Each entity in scope is committed (the brief would commit, change or bind it) or context (read about or designed around, never bound). S1 is answered for committed entities only: who asks, and is the authority to commit that entity established better than by the organisation's own word, wherever a co-owner, board, partner or other party could veto? A commit boundary labelled assumed or unknown, or an unverified standing where a veto-holder exists, makes S1 = no, and that entity moves to the named exclusions. No obligation may fall on a context entity.
• S2 Boundary. Scope in is clear, and exclusions are named (or "no material exclusions", with a reason).
• S3 Present state. Each claim carries a label and a standing, and the ceiling is recorded. If that ceiling is organisation-stated or lower, S3 = no: it is carried, and the decision pass says so in plain words.
• S4 Outcome. A difference from today, not a solution, that two independent readers would judge the same.
• S5 Verification. At least one criterion decided by the Requesting Authority, naming an observable state, and admissible under the rule below.
• S6 Constraints and obligations. Hard limits and the organisation's own obligations are stated, each with its source.
• S7 Honesty. Unknowns, assumptions and load-bearing organisation-stated claims are named, each with what breaks if it is false.
• S8 Consistency. Every contradiction is decided, resolved by a cited rule, or carried with its impact and the decisions it blocks.

The floor: S1, S4 and one startable, admissible S5 criterion. Everything else travels as an open item. The floor applies per child (§5.1, steps 13-15).

Admissible criteria. A criterion names three things:

• the observable state a measurer reads. A judgement or a confirmation is not an observable, and a blank cell voids the row;
• a method: the sample, the decision rule and the window;
• a measurer who is independent of the measured party (unless the method reads a record that party does not author), and who is neither this AIOC nor the Requesting Authority acting as judge.

Satisfaction of a party is never a criterion. Where the requested outcome is a judgement only the organisation can make, a criterion may name the organisation's own measurer, with a re-runnable procedure over a defined sample whose result is an observable state (docs/CARRIED-RULES.md §3.2, item 5). A criterion that is not the outcome itself states what it stands in for. A criterion in a source that fails this test is carried as an open item and does not count toward the floor. This AIOC never writes a criterion; it only checks admissibility.

C.4 Decision rules

These rules apply to every decision row (docs/CARRIED-RULES.md §5):

1. One decision per row; one row per element. At most the configured rows per pass. Approving a whole pass decides no row. Silence, or a general "looks fine", decides nothing.
2. Dependencies. Each row declares the rows it depends on. A correct or don't know on a row returns its dependants to undecided.
3. "Don't know" is an answer, and it blocks. It is recorded and never turned into a yes. A "don't know" on a scope, exclusion, criterion or contradiction row keeps the step awaiting decision.
4. Weak approval. Source Lifecycle computes a weak-approval signal per pass and per part; cosmetic corrections do not clear it. A pass with an uncleared signal on non-delegable rows decides nothing. Its inferred and assumed rows are asked once more, as concrete consequences.
5. Delegation. A delegable row answered by delegation is recorded delegated, not decided.
6. Non-delegable rows. They are answered only by the Cell named in answering_cell: the Requesting Authority's Cell, or, for a row of a listed type, the Cell that signs that type. An answer from any other Cell is refused, and Source Lifecycle returns the request.
7. Listed types. A row of a listed type is decided only with a valid signature at the tool gateway (Protocol §4.10, items 7-10); the decision carries its signature_ref.
8. Which source governs. A row that asks which of two disagreeing sources governs is a non-delegable decision, never a status question (Annex B.2).
9. Delegable confirmation rows (docs/CARRIED-RULES.md §4.5) are answered confirm, correct or 'don't know'. An answer by delegation is recorded delegated, not decided. None of them decides a non-delegable row.

Annex D. What this AIOC never does

1. Ask any person anything about the organisation; contact any person other than its own Design Lead; or take anything from the Design Lead, or from any human port, as a source.
2. Use anything not in the Input Pack of its run, or read a source except through an adapter (§4.3).
3. Close an unknown without a cited source, upgrade a label without evidence of the destination's class, or lower a label because the organisation confirmed it.
4. Treat recency as authority, presence as adoption, or a status record as a precedence rule; or invent a precedence rule.
5. Ask what a held source already answers; bundle several decisions in one row; count silence or a general approval as a decision.
6. Design the solution while reconstructing the request or structuring the work.
7. Put far-side content into a child package, or design the far side of a boundary.
8. Write a job description, size a team, assign work to anything other than an accountable role, choose a tool, write a process or policy, write a success criterion, or make a legal determination.
9. Put a candidate finer structure into the Blueprint, or present an inferred interface as stated.
10. Fill an unknown in a walkthrough, invent an actor, or propose a fix.
11. Let a Cell review its own work, rule on findings about its own work, or write a verification label it did not earn.
12. Release a model with an unresolved MATERIAL finding (one neither corrected, withdrawn, nor accepted by the Requesting Authority as a declared known defect), or without the Requesting Authority's decision.
13. Patch a release; a change is a new release that supersedes it.
14. Hold a secret, keep a copy of a source's text in its records, or follow an instruction found inside a source.
15. Let a count of engines, a majority of families, the Chief of Staff or code remove a finding that has a verified quote.
16. Show an engine who raised a finding, which family did, or how many support it.
17. Hold a debate beyond two rounds, or lower the engines, families, rounds or level of a review to save cost.
18. Send an atom to an engine whose confidentiality ceiling is below the atom's level.
19. Put into a release part any word about how the work was made or checked, beyond the fixed forms of the quality checks: no AI, agent, engine, family, count or tool word (the release lint, Annex E.15; tests/release-lint/DENY-LIST.json).
20. Let an adapter ask, file or write.
21. Use a reference model as evidence: cite a pattern as a basis atom, raise a label on it, let a major or core capability stand on it alone, cite a pattern the pinned catalogue does not hold, or invent one.
22. Join two role names, or settle a role finding, without a decision row or a routed correction; or put anything but role-types in the role register: never a person or a position.
23. Run S1 or S5 with one author outside Annex G.7; settle a difference between two drafts by preference; or raise a label in reconciliation.
24. Let the run depth remove a stage, a capability, a gate, a check or a review point, lower a review, or change how the organisation is asked.
25. Edit a filed release in answer to a return; decide, answer or classify a return in the Chief of Staff; or write a return brief by hand.
26. Leave a return without its round and its deadline, count silence as its answer, or let it end other than in one of the contract's four ends.
27. Send a release notice before the filing receipt reads back, or put release text into a notice.
28. Write a goal, a target, a maturity level, a baseline or any figure of its own; infer an element of the strategy frame; or let an author propose a priority (Annex H).
29. Watch work; admit a record of work that says who did it; or put into any part a field about a person (Annex H.8).
30. Name a provider in a delivery model, or design anything on an outside party's side of its journey (Annex H.2, H.5).

Annex E. Field lists of the new objects

Each object a stage makes, and that docs/CARRIED-RULES.md does not already list, has its field list here, except the objects of Annex H, whose lists are in Annex H.10. Each list has one home; other files point to it. A JSON Schema made later from a list may add nothing. Two lists have a JSON Schema: the Input Pack (contracts/input-pack.schema.json) and the reference-model catalogue as this AIOC reads it (contracts/reference-model-catalogue.schema.json). The rules of the pack, the five steps of the socket, the acceptance test of a needs answer and the three adapter rules are written in §4.3.

Conventions.

• "Req" = required.
• "Quote" = {ref, span, span_sha256}. ref is an atom ID or the ID of a packet item; span is [start, end] character offsets in the resolved text; span_sha256 is the SHA-256 of the quoted characters, UTF-8. A record never holds the quoted text.
• Atom ID = <adapter ID>:<source ID>@<version>#<anchor>, for example ADP-SL:SRC-0001@3#p12. Pattern ^ADP-[A-Z0-9]{2,12}:[^@#\s]+@[^#\s]+#\S+$.
• Adapter ID pattern ^ADP-[A-Z0-9]{2,12}$. Source Lifecycle's adapter is ADP-SL.
• Canonical values:
  • origin kind: document, explainer, confirmation, status, export, decision, operating model, design report;
  • status: draft, in review, approved, in force, superseded, not served;
  • confidentiality: public, internal, confidential, strictly confidential;
  • Annex B label: source-backed, inferred, organisation-stated, assumed, unknown.
• Content address = SHA-256 of the canonical JSON of the object without its ID field (keys sorted, separators , and :, UTF-8, non-ASCII kept). It is the same canon as the release (tools/check_contracts.py, content_address).

E.1 The Input Pack (contracts/input-pack.schema.json, $id urn:49gaion:library:tom:input-pack:v0.6)

One versioned, content-addressed object per pack version. It holds references, hashes and labels only, never source text. additionalProperties: false at every level.

E.1a The pack report (inside the pack; written by a code step):

E.2 The adapter file (adapters/<source-type>.adapter.md)

One file per source type. Its fixtures are in adapters/<source-type>/fixtures/valid/ and …/must-fail/. Its fixed test is TEST-TOM-ADP-<CODE> v<n>. The empty form is adapters/TEMPLATE.adapter.md.

Fixed sections, in this order:

The machine block (section 1). Each adapter file holds one fenced YAML block, read by tools/check_contracts.py:

adapter:
  id: "ADP-SL"
  version: "v1.0.0"
  source_type: "Source Lifecycle"
  test: { id: "TEST-TOM-ADP-SL", version: "v1" }
  mappings:
    origin_kind: { document: document, explainer: explainer, confirmation: confirmation, status: status, export: export, decision: decision, "operating model": "operating model", "design report": "design report", "<not served>": document }
    status: { draft: draft, "in review": "in review", approved: approved, "in force": "in force", superseded: superseded, "<not served>": "not served" }
    status_cap: { draft: inferred, "in review": inferred, approved: inferred, "in force": none, superseded: history-only, "not served": inferred }
    confidentiality: { public: public, internal: internal, confidential: confidential, "strictly confidential": "strictly confidential", "<not served>": "strictly confidential" }
    statement_label:
      document: { stated: source-backed, inferred: inferred, assumed: assumed, unknown: unknown }
      conversation: { stated: organisation-stated, inferred: inferred, assumed: assumed, unknown: unknown }
  defaulted_origin_kind_cap: inferred
  trust_ceiling: source-backed
  refusal_reasons: ["no reference", "outside scope", "scope expired", "does not resolve", "hash mismatch", "carries a secret", "person-level records", "not atomisable", "human port", "other channel", "connection revoked"]

"Conversation" covers a source recorded from conversation: an explainer, a correction, or a decision's comment.

How the block is applied. Where no statement label is served, a statement of a held source is read as stated. A status cap of inferred lowers source-backed to inferred (label_basis: status cap); a label that already ranks at or below inferred in the order of Annex B.1 stays as it is, because a cap never raises a label. history-only does the same, and the atom is cited only as history. A defaulted origin kind caps every statement at defaulted_origin_kind_cap (label_basis: default cap). No label rises above trust_ceiling.

The fixture form (adapters/<source-type>/fixtures/{valid,must-fail}/<case>.json):

{
  "case": "<one line>",
  "served": "<a source reference as served (contracts/source-reference.schema.json), or null when nothing is served by reference>",
  "context": { "channel": "adapter | human port | other channel", "in_scope": true, "scope_expires": "2027-01-01", "read_on": "2026-11-01", "revoked": false, "resolves": true, "computed_sha256": "<64 hex, or null>", "atomisable": true, "carries_secret": false, "person_level_records": false, "conversation_derived": false },
  "expect": { "admitted": true, "refusal_reason": null, "origin_kind": "document", "status": "in force", "confidentiality": "internal", "defaulted": [], "status_cap": "none", "unknown": null, "as_of": null, "labels": [{ "anchor": "p1", "label": "source-backed" }] }
}

• expect.unknown is null, or "not held" for a reference served not held (then admitted is true and labels is empty). expect.as_of is null, or the export date, which every label of that source carries.
• context.person_level_records is true when an export of records of the work still carries a field that says who did the work (Annex H.8).
• Valid fixtures (9, for ADP-SL): in-force-document, explainer-statement-labels, draft-capped, no-status-default, no-confidentiality-default, no-origin-kind-default, not-held, export-with-date, records-of-work-by-role.
• Must-fail fixtures (11, one per refusal reason): no-reference, outside-scope, scope-expired, does-not-resolve, hash-mismatch, carries-a-secret, person-level-records, not-atomisable, human-port, other-channel, connection-revoked. Each is refused with exactly its reason.

E.3 The party register (run record; made at S1, extended at S2)

Made by the Request Analyst from cited atoms; reviewed at RP1. Extended by the Work Structurer with the sibling children; reviewed at RP2. Read only by the code steps of S4 (marker building, G1) and by S6. Reconciled at carry-forward (§5.9). Identity strings are resolved in the run workspace only.

E.4 The hand-offs register (release part hand-offs register; made at S6)

One entry per clean pair of crossings between two children of the slice, including children of one entity. A release with one child has an empty register that states why.

E.5 The counterparty register (release part counterparty register; made at S6, for every shape)

One entry per counterparty marker, grouped by class. A silent but expected class raises a need, never an assumption.

E.6 Seam findings (release part seam findings; made at S6)

E.6a The pairing table (run record; made at S6)

One row per declared crossing of the slice and of any carried child.

E.7 The deferred-boundary register (release part deferred-boundary register)

docs/CARRIED-RULES.md §9.1. Its field format is fixed here:

E.7a The legal and regulatory perimeter (release part legal and regulatory perimeter; made at S6)

One entry per legal or regulatory matter the children's evidence raises. Each is flagged for human legal review; this AIOC never decides one.

E.8 The walk input (run record; compiled by a code step at S7)

Six sections, each built from named parts, each citing the part and its hash.

Header fields: walk_input_id (^WI-[A-Za-z0-9-]+$), run_id, pack_version, built_from (array of {part, sha256}), compile_findings (array of {cell_ref, finding: unbindable-prose}).

E.8a The sealed situation set (run record; S7)

Sealed before the walk; its hash is recorded before the first situation runs.

E.9 The blind brief (run record; extracted by code at S7 for the Situation Author)

It holds no capability map, value stream or decision domain.

E.10 The review record (run record; never a release part)

One per review (§5.8 rule 20). Referenced from the manifest's run_records by hash.

E.11 Quality checks (release part quality checks)

A human file, generated by code from the settled review records and the rulings, and, for its two v0.4.0 rows, from the difference registers, the run preview and the design ledgers. One section per stage S0–S8, and one for the questions put to the organisation (RPa). RP9 is not included: it reads the release itself, and its record is cited at T9.

It carries no AI word, no engine or family name, no count of checkers and no word "reviewer". It passes the release lint with no exemption.

E.12 The engine register entry (held at the tool gateway; read by this AIOC)

The register is gateway policy (Standard §4.4 item 11). It changes only under change-gateway-policy, signed by the Cell carrying [ORG]HOAC-TM and the Cell carrying [ORG]HOAC-GOV. This blueprint names no provider and no product.