# ── Blueprint metadata (machine-readable; the panel generator and the back-office builder read this block) ──
blueprint:
  aioc: "[ORG]AIOC-DI"
  parent: "[ORG]AIOC-CH"                  # example code of the Charter; each organisation writes its own Charter's code (Standard §1.7, item 13)
  full_name: "Delivery and Implementation"
  organisation: "<organisation>"          # filled in each organisation's own copy
  type: "specialised"
  org_aion: "[ORG]AION"
  blueprint_version: "v0.2.3"
  status: "draft"
  template:
    name: "49GAION AIOC Blueprint Template"
    version: "v1.6.0"
    source: "github.com/49g-holding/49GAION-aioc, template/AIOC-BLUEPRINT-TEMPLATE.md @ acdcbe5"
  mother:
    name: "49GAION Delivery and Implementation"
    version: "part card v1 (DRAFT)"
    source: "github.com/49g-holding/49GAION-protocol, library/cards/delivery-and-implementation.part-card.json and the Protocol section Delivery and Implementation (pull request #36); Standard §3.1, item 5 (49GAION pull request #68, DR-0017)"
  writing_repository: "<org>aioc-di"
  code_project: "<org>aioc-di, on the organisation's code platform"
  panel_register_id: "none yet"
  slice: "1 to 4, complete: launch essentials; accompany and operate; improve; small business"
  capabilities:
    standard: ["Chief of Staff", "Office", "Input socket", "Panel"]
    functional: ["Intake and Design Map", "Needs Requests", "Gap Audit", "Health Check", "Procedure Writing", "Briefs and Drafts", "Transition and Go-live Criteria", "Answers", "Independent Review", "Decision Package and Filing", "Light Design", "Implementation Plan", "Change Impact and Adoption", "Learning Paths", "Readiness and Go-live", "Problem Records", "Operating Rhythm", "Measures", "Value Register", "Versions and Checklists", "Process Watching", "Proposals", "Trials", "Hand-over and Mentor", "Export"]

Blueprint · [ORG]AIOC-DI · Delivery and Implementation · v0.2.3

Draft, 15 October 2026. v0.1.1 and v0.1.2, 16 October 2026: the answers to its returns, and the value case and priority carried unchanged (decisions/DR-0002, DR-0003). v0.2.0, 18 October 2026: complete, on the governing seat's direction to complete this stage (decisions/DR-0004). v0.2.1, 19 October 2026: the Chief of Staff takes its COS code [ORG]CELL-COSDI (decisions/DR-0005). Written by [ORG]AIOC-OCO on the directions recorded in decisions/DR-0001 to decisions/DR-0004. This is the blueprint of Delivery and Implementation, written for any organisation as the mother text of the Library part 49GAION Delivery and Implementation. It now covers all four slices of the product requirements: the gap audit and the launch essentials (slice 1); accompanying the launch, with the operating rhythm (slice 2); improving the running organisation (slice 3); and the small business with no design (slice 4). The slices stay the order in which the parts are built and switched on (§5.0, "The slices"). Every rule rests on a 49GAION text, on the blueprints of [ORG]AIOC-PPD or [ORG]AIOC-TOM (cited by section and version), or on the product requirements of this part (PRD-[ORG]AIOC-DI-001 v0.4, in its code project), or is new here and marked New. Nothing here has run. Every fixed test reads NOT_RUN.

Delivery and Implementation in one page

Delivery and Implementation (DI) takes an organisation's decided design into a running organisation, and stays to run and improve it with the organisation. It is the last stage of the design chain, after Process and Position Design (PPD).

What goes in

1. Mode A: the decided PPD release, handed over directly by [ORG]AIOC-PPD, by reference and hash, with the decided TOM release it was designed from.
2. Mode B: a design made elsewhere, filed as a source in Source Lifecycle.
3. Mode C: no design. The owner position's sources, in Source Lifecycle; DI builds a light design with the owner position. It is switched on only after the launch and accompany parts have given evidence.
4. The organisation's other sources, only from Source Lifecycle, and answers to what they do not say, asked only through its Chief of Staff.
5. Records of the organisation's work, only through a projection owned by top management that removes who did the work, and only after the organisation records its impact assessment.

What DI does, in four parts

1. Launch (S0 to S4): admit the design; map it, or in mode C build a light design; audit the gaps in two tiers and run the health check at entry; prepare the procedures, briefs and drafts, the transition plan and the go-live criteria; the organisation decides each element, and the launch package is filed in Source Lifecycle.
2. Accompany (S5): the implementation plan by position; change impact and adoption; learning paths; readiness, rehearsals and the go or no-go package; problem records; stabilisation after go-live.
3. Operate (S6): the operating rhythm and its single logs; forum packs and minutes; measures; versions and acknowledgements; runnable checklists; quarterly priorities; the value register.
4. Improve (S7): watching processes and their conformance; findings; proposals; trials; new processes when the organisation changes; scheduled reassessment; the quarterly health check; and the hand-over of DI's skills, proven by a yearly drill without DI.

All the while, any position may ask DI how the organisation works. DI answers only from the decided design, citing the element, its version and a quoted span, and a second engine checks every citation. Where the design is silent, DI says it does not know.

Who decides. DI decides nothing for the organisation. What it may do is set per class of action by the owner position: level 0, read; level 1, propose (a draft enters a record only when a position inserts it); level 2, apply a reversible change with no legal, pay or employment effect, within a class the owner position signed in advance. No level allows a type of the Human Floor signature list. The go or no-go is always the deciding position's. Any accountable position can stop DI at once.

Processes, not persons. DI addresses positions only, never ranks, scores or watches a single position, and shows no measure for one.

Where this blueprint stands. Complete draft, slices 1 to 4. The stages, their inputs, outputs and done-tests are set (§5.0). The review rule it shares with [ORG]AIOC-PPD and [ORG]AIOC-TOM is carried by section (§5.9; Annex E). The permission ladder is Annex G; records of work and their conditions are Annex H. The decisions only a human seat can take are listed once, in §13.

0. Identity and lineage

Lineage. A review of what an organisation still needs, after its processes and positions are designed, to start working without AI found that the decided design is not yet a working organisation: procedures, policy and pay drafts, authority instruments, controls, the transition plan and the go-live criteria are still missing, and the organisation needs someone beside it through launch and after. The governing seat directed a stage of its own for that, with an assistant that stays (decisions/DR-0001; 49GAION/DR-0017). A study of fifteen products that design, launch or run organisations then placed each useful feature in the stage where it truly belongs. Both are summarised in docs/HISTORY.md. On 18 October 2026 the governing seat directed that this stage be completed: every requirement of the product requirements is designed here, and the slices stay the order of building (decisions/DR-0004). No earlier code or result is carried here.

1. Card (49GAION Operating Protocol §3)

card:
  unit_kind: "AIOC"
  code: "[ORG]AIOC-DI"
  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-DDL", "[ORG]CELL-COSDI", "[ORG]POD-DD", "[ORG]POD-DP", "[ORG]POD-DA", "[ORG]POD-DR", "[ORG]POD-DL", "[ORG]POD-DO", "[ORG]POD-DCI"]
  type: "specialised"
  org_aion: "[ORG]AION"
  card_version: "v0.2.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; references only
      format: "Work Item (Protocol §4.1) whose sources field holds the mode (A, B or C), and one PPD Release reference, the reference of a design filed in Source Lifecycle, or (mode C) the references of the owner position's sources"
      acceptance_test: "TEST-DI v1, cases 1, 18, 19"
      decision_needed: false
    - kind: "release notice"              # from [ORG]AIOC-PPD, directly, through the tool gateway
      format: "release notice of [ORG]AIOC-PPD (its contracts/release-notice.schema.json, urn:49gaion:library:ppd:release-notice:v0.4): the PPD Release ID, version and manifest hash, the TOM Release it rests on, its filed reference, and the returns it answers"
      acceptance_test: "TEST-DI v1, cases 1, 20, 48"
      decision_needed: false
    - kind: "return answer"               # from [ORG]AIOC-PPD or [ORG]AIOC-TOM: the end, or the next round, of a return this AIOC sent
      format: "the return at its next version (49GAION-protocol library/contracts/design-return.schema.json)"
      acceptance_test: "TEST-DI v1, case 48"
      decision_needed: false
    - kind: "source reference"            # the outside design (mode B) and the organisation's other sources, from the output socket of [ORG]AIOC-SL
      format: "source reference (ID + version + hash; held or not held)"
      acceptance_test: "TEST-DI v1, cases 2, 21"
      decision_needed: false
    - kind: "needs answer"
      format: "needs answer, by reference only"
      acceptance_test: "TEST-DI v1, case 22"
      decision_needed: false
    - kind: "needs status"
      format: "needs status"
      acceptance_test: "TEST-DI v1, case 22"
      decision_needed: false
    - kind: "question"                    # from any position of the organisation, through the HU input port; never a source
      format: "question from a position (its position code), text only"
      acceptance_test: "TEST-DI v1, cases 7, 36, 37"
      decision_needed: false
    - kind: "service request"             # from the Requesting Authority's Cell, through the HU input port: switches on accompaniment, operation and improvement for a filed launch package; references only
      format: "Work Item (Protocol §4.1) whose sources field holds the filed launch package reference and the parts switched on (accompany, operate, improve)"
      acceptance_test: "TEST-DI v1, cases 55, 62"
      decision_needed: false
    - kind: "problem report"              # from any position, through the HU input port; never a source of the design
      format: "problem report from a position (its position code): the process or step, and what happened, text only"
      acceptance_test: "TEST-DI v1, case 61"
      decision_needed: false
    - kind: "decision"                    # a position's act on a row: decide, insert, approve a preview, acknowledge a version
      format: "decision reference; a signed record at the gateway for a listed type"
      acceptance_test: "TEST-DI v1, cases 10, 64, 70"
      decision_needed: false
    - kind: "records of work"             # through the projection owned by top management, only while process watching is on (Annex H)
      format: "record references through the tools-in connection, with no field that identifies who did the work"
      acceptance_test: "TEST-DI v1, cases 73, 74"
      decision_needed: false
    - kind: "change notice"               # from [ORG]AIOC-SL: a source that records a change of the organisation (a new product, site, market or law)
      format: "source reference (ID + version + hash) with its change kind"
      acceptance_test: "TEST-DI v1, case 78"
      decision_needed: false
  delivers:
    - kind: "return"                      # to the stage that made the release; also filed into [ORG]AIOC-SL as a design report
      format: "design return (49GAION-protocol library/contracts/design-return.schema.json), prefix DIR"
      usual_receivers: ["[ORG]AIOC-PPD", "[ORG]AIOC-TOM", "[ORG]AIOC-SL"]
    - kind: "needs request"
      format: "needs request, as a sub-item of the run Work Item"
      usual_receivers: ["[ORG]AIOC-SL"]
    - kind: "missing report"
      format: "Missing Report, one per pass"
      usual_receivers: ["[ORG]AIOC-SL"]
    - kind: "launch package filing"
      format: "launch package manifest and its parts (Annex A), filed as a source of origin kind delivery and implementation; filing receipt"
      usual_receivers: ["[ORG]AIOC-SL"]
    - kind: "answer"
      format: "answer with its citations (Annex A.7), or 'I do not know'; to the asking position only"
      usual_receivers: ["the asking position"]
    - kind: "rows for decision"           # plan tasks, criteria, proposals, trials, priorities, value gates: each to the position that decides it
      format: "decision row with its draft, evidence and trace; the position decides or inserts it"
      usual_receivers: ["the deciding position the row names"]
    - kind: "forum pack"
      format: "forum pack (Annex A.15), built from versioned records"
      usual_receivers: ["the chair and member positions of the forum"]
    - kind: "notice"                      # a changed version, a re-approval due, an off-track item, a dropped follow-up, value or a date at risk
      format: "notice naming the record and its version"
      usual_receivers: ["the positions the record concerns"]
    - kind: "living design filing"        # each decided later version of a process, procedure, policy, job description or forum
      format: "versioned record, filed as a source of origin kind delivery and implementation; filing receipt"
      usual_receivers: ["[ORG]AIOC-SL"]
    - kind: "export"
      format: "full export with its trace, in open formats (§5.25)"
      usual_receivers: ["the Requesting Authority's Cell"]
  anatomy:
    panel: { health: { tests: true, metrics: ["stuck", "returned", "late", "run state", "returns open", "returns answered", "needs open", "needs past deadline", "gaps by tier", "gaps by state", "procedures by state", "briefs by state", "go-live criteria by state", "answers given", "answers 'I do not know'", "citations refused by the verifier", "reviews held", "review budget used", "tasks by state", "go-live criteria met, not met, unknown", "rehearsal defects open", "actions past their date", "risks and issues open", "milestone date changes", "packs built", "minutes awaiting preview", "versions due", "acknowledgements pending, by version", "initiatives by gate", "value planned and realised", "proposals by state", "trials running", "conformance by process", "hand-over items left", "ladder level by class"] } }
    back_office: { converses_with_humans: true, hosts: ["Chief of Staff", "Office"], protocol_traffic: true }
    definition: { location: "<org>aioc-di, blueprint/DI-BLUEPRINT.md", version: "v0.2.3" }
    delivery: { rollback: "one-click" }
    connectors:
      - { role: "design source", connector: "[ORG]AIOC-PPD release port", access_managed_in: "panel" }   # the grant is signed at the tool gateway as connect-external-port
      - { role: "returns to the operating model", connector: "[ORG]AIOC-TOM return port", access_managed_in: "panel" }
      - { role: "source of record", connector: "[ORG]AIOC-SL output socket", access_managed_in: "panel" }      # as above (Protocol §13, item 5)
      - { role: "records of work", connector: "the projection owned by top management over the organisation's own tools", access_managed_in: "panel" }   # read only; signed as connect-external-port; off until Annex H holds
    gateway: { metering_id: "<per-AIOC metering id>" }
  full_name: "Delivery and Implementation"
  version: "0.2.3"
  lineage: { id: "[ORG]AIOC-DI", version: "0.2.2", relation: "original" }
  lifecycle_state: "designed"
  blueprint_version: "v0.2.3"
  template_version: "v1.6.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-DDL"
  hoac: "[ORG]HOAC-ACS"
  label_holder: "[ORG]CELL-DDL"
  fixed_test: { id: "TEST-DI", version: "v1", owner: "[ORG]CELL-TMS" }
  skills:
    - { id: "di-design-map", name: "Reading a decided design, or mapping a design made elsewhere", tags: ["delivery", "intake"] }
    - { id: "di-gap-audit", name: "The gap audit in two tiers, and the organisation health check", tags: ["delivery", "diagnosis"] }
    - { id: "di-procedures", name: "Procedures under each process", tags: ["delivery"] }
    - { id: "di-briefs", name: "Briefs for counsel and finance", tags: ["delivery"] }
    - { id: "di-transition", name: "Transition plan and go-live criteria", tags: ["delivery"] }
    - { id: "di-answers", name: "Answers grounded in the decided design, with verified citations", tags: ["delivery", "assurance"] }
    - { id: "di-light-design", name: "A light design built with the owner position, every element provisional until decided", tags: ["delivery", "small business"] }
    - { id: "di-accompany", name: "The implementation plan, change impact, learning paths, readiness and the go or no-go package", tags: ["delivery", "launch"] }
    - { id: "di-operate", name: "The operating rhythm, logs, forum packs, measures, versions and the value register", tags: ["delivery", "operations"] }
    - { id: "di-improve", name: "Process watching at process level, conformance, proposals and trials", tags: ["delivery", "improvement"] }
    - { id: "di-hand-over", name: "Handing DI's skills to the organisation, proven by a drill without DI", tags: ["delivery", "capability"] }
  ports:
    - { unit: "[ORG]AIOC-DI", port: "ai-in", direction: "input", type: "AI", identification: "technical-key", accepted_content: ["release notice", "return answer", "source reference", "needs answer", "needs status", "change notice", "records of work through the projection"], authority_limit: "read only, within the scopes signed for the PPD, Source Lifecycle and records-of-work connections; return answers on the PPD and TOM connections; records of work only while process watching is on (Annex H)", audit_trail: "unit register; the serve logs of [ORG]AIOC-PPD and [ORG]AIOC-SL", required_tests: ["TEST-DI v1"], enforcement: "shared-gateway-outside-unit" }
    - { unit: "[ORG]AIOC-DI", port: "ai-out", direction: "output", type: "AI", identification: "technical-key", accepted_content: ["return", "needs request", "missing report", "needs status", "launch package filing", "living design filing", "export"], authority_limit: "returns, requests, reports and filings only; files only its own packages, decided versions and design reports; never an instruction to a person", audit_trail: "Work Item record and the unit register", required_tests: ["TEST-DI v1"], enforcement: "shared-gateway-outside-unit" }
    - { unit: "[ORG]AIOC-DI", port: "hu-in", direction: "input", type: "HU", identification: "live-human-sign-in-at-gateway", accepted_content: ["run request from the Requesting Authority's Cell (references only)", "service request from the Requesting Authority's Cell (references only)", "a question from a position about how the organisation works (never a source)", "a problem report from a position (never a source)", "a decision of a deciding position on a row", "an insertion, a preview approval or an acknowledgement by a position", "run control and configuration from the DI Delivery Lead (never a source)"], authority_limit: "the signer's authority_scope; nothing received here is a source", audit_trail: "Office record", required_tests: ["TEST-DI v1"], enforcement: "shared-gateway-outside-unit" }
    - { unit: "[ORG]AIOC-DI", port: "hu-out", direction: "output", type: "HU", identification: "live-human-sign-in-at-gateway", accepted_content: ["answer to the asking position", "run brief to the DI Delivery Lead", "ruling sheets to the DI Delivery Lead", "Decision Package rows to the deciding positions", "rows for decision to the deciding positions", "forum packs to the chair and member positions", "notices to the positions a record concerns", "a learning path and its check results to the learner position only", "filing notice to the Requesting Authority's Cell"], authority_limit: "information and proposals only; never a decision, an instruction or a question about a person", audit_trail: "Office record", required_tests: ["TEST-DI v1"], enforcement: "shared-gateway-outside-unit" }
    - { unit: "[ORG]AIOC-DI", port: "stop", direction: "input", type: "HU", identification: "live-human-sign-in-at-gateway", accepted_content: ["stop"], authority_limit: "stop only; open to every accountable position of the organisation (FR-34)", audit_trail: "unit register", required_tests: ["TEST-DI v1"], 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: "<position>", date: "<date>", version: "<vN>" }
    central_head: { value: "<the OCO of this [ORG]AION>", set_by: "<position>", date: "<date>", version: "<vN>" }
    discussion_limits: { value: "<set by the organisation>", set_by: "<position>", 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: "<position>", date: "<date>", version: "<vN>" }
    chain_depth: { value: "<number, at least 1>", set_by: "<position>", date: "<date>", version: "<vN>" }
    halt_request_priority: { value: "immediate", set_by: "<position>", 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>" }
    modes_enabled: { value: ["A", "B"], set_by: "<Cell carrying [ORG]HOAC-TM>", date: "<date>", version: "<vN>" }
    rows_per_pass: { value: 12, set_by: "<position>", date: "<date>", version: "<vN>" }
    non_response_passes: { value: "<set by the organisation>", 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>" }
    review_engines: { value: 3, set_by: "<position>", date: "<date>", version: "<vN>" }
    review_families_min: { value: 2, set_by: "<position>", 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>" }
    gap_bars: { value: "<blocking gaps found, at or above; false gaps, at or below>", set_by: "<Cell carrying [ORG]HOAC-TM>", date: "<date>", version: "<vN>" }
    answer_bars: { value: "<grounded answers, at or above; 'I do not know' on unanswerable questions, at or above>", set_by: "<Cell carrying [ORG]HOAC-TM>", date: "<date>", version: "<vN>" }
    mapping_bars: { value: "<mode B mapping accuracy on a sample set, at or above>", set_by: "<Cell carrying [ORG]HOAC-TM>", date: "<date>", version: "<vN>" }
    deciding_positions: { value: "<position codes: go or no-go; counsel per jurisdiction; finance; data protection; owner, where not the Requesting Authority>", set_by: "<Requesting Authority Cell>", date: "<date>", version: "<vN>" }
    ladder: { value: "every class at level 1, a read-only class at level 0; level 2 only for a class the owner position signed as sign-standing-action-class (Annex G)", set_by: "<owner position>", date: "<date>", version: "<vN>" }
    ladder_thresholds: { value: "<per class: the fixed-test score at or above which it may move up>", set_by: "<owner position>", date: "<date>", version: "<vN>" }
    process_watching: { value: "off", set_by: "<Cell carrying [ORG]HOAC-TM>", date: "<date>", version: "<vN>" }       # on only when Annex H holds
    min_group: { value: 3, set_by: "<Cell carrying [ORG]HOAC-TM>", date: "<date>", version: "<vN>" }
    trial_baseline_points: { value: 10, set_by: "<owner position>", date: "<date>", version: "<vN>" }
    reassessment_schedule: { value: "<set by the organisation>", set_by: "<owner position>", date: "<date>", version: "<vN>" }
    health_check_schedule: { value: "quarterly", set_by: "<owner position>", date: "<date>", version: "<vN>" }
    drill_schedule: { value: "yearly", set_by: "<Cell carrying [ORG]HOAC-TM>", date: "<date>", version: "<vN>" }
    in_flight_rule: { value: "<set by the organisation>", set_by: "<owner position>", date: "<date>", version: "<vN>" }
    growth_triggers: { value: "<set by the organisation>", set_by: "<owner position>", date: "<date>", version: "<vN>" }
    reference_models: { value: "unavailable", set_by: "<DI Delivery Lead>", date: "<date>", version: "<vN>" }
    mentor: { value: "off", set_by: "<Cell carrying [ORG]HOAC-TM>", date: "<date>", version: "<vN>" }
    advice_bars: { value: "<advice quality on an expert-rated rubric, at or above>", set_by: "<Cell carrying [ORG]HOAC-TM>", date: "<date>", version: "<vN>" }
    council: { value: "off", set_by: "<Cell carrying [ORG]HOAC-TM>", date: "<date>", version: "<vN>" }
    point_of_work_guidance: { value: "off", set_by: "<Cell carrying [ORG]HOAC-TM>", date: "<date>", version: "<vN>" }
    language: { value: "<the organisation's language>", 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 [ORG]AIOC-PPD to send it release notices and accept its returns, [ORG]AIOC-TOM to accept its returns, and Source Lifecycle to accept filings of origin kind delivery and implementation (upstream/PROPOSALS.md, items 1 to 4). Until then its lifecycle_state stays designed and no Work Item is routed to it. Records of work are read only after Annex H holds; until then process watching is off and the rest of DI runs without 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

The blueprint writes [ORG] for the organisation's prefix (Naming Standard R13). Positions only; who holds each one is the organisation's own mechanism, outside the system (Standard §1.1, items 9 and 10).

2.2 Placement

• Where it sits. A top-level AIOC under the Charter, beside [ORG]AIOC-SL, [ORG]AIOC-TOM and [ORG]AIOC-PPD. It is the last stage of the design chain.
• Its role. It takes the decided design into a running organisation and stays with it. It prepares the launch, accompanies it, keeps the operating rhythm with the organisation, and helps it improve, until the organisation can do each of these without it (§5.24).
• Scope.
  • It does:
    • Launch: admit a decided PPD release (mode A) or a design made elsewhere (mode B), or build a light design with the owner position (mode C); map it; return every defect of a release to the stage that made it; audit the gaps in two tiers; run the health check; write the procedures under each process; write briefs, and drafts from the organisation's own templates, for counsel and finance; draft the transition plan and the go-live criteria; prepare the decision; file the launch package.
    • Accompany: draft the implementation plan by position; set out what changes for each position, and how adoption is measured; build learning paths; assess readiness, write rehearsal scripts and prepare the go or no-go package; keep problem records; track stabilisation.
    • Operate: keep the operating rhythm and its single logs; build forum packs and draft minutes; build measures at process and unit level; keep versions with their re-approval dates and acknowledgements; run procedures as checklists; draft quarterly priorities; keep the value register.
    • Improve: watch processes through the projection, with their conformance; find bottlenecks, rework and control gaps; propose changes and new processes; design trials and have them judged by another seat; reassess the design on schedule; run the health check each quarter; hand its skills over and prepare the yearly drill without it.
    • Always: answer positions' questions from the decided design, with verified citations; trace every artefact both ways; export everything with its trace.
  • It does not: decide anything for the organisation, the go or no-go included; give legal, tax, employment or pay advice; state an amount that no source or decision gives; ask any person anything about the organisation; name a person, or read who occupies a position; rank, score or watch a single position, or show a measure for one; change a design release; read records of work except through the projection, after Annex H holds; apply a change outside a class signed at level 2 (Annex G); act on a type of the Human Floor signature list.
• Shapes it serves. Any shape the design covers: one owner's work, a single entity, a group of entities, or a group with independent institutions inside it. Where a design covers several entities or jurisdictions, every brief and every go-live criterion records its entity and jurisdiction.
• Boundaries with other AIOCs.
  • [ORG]AIOC-PPD designs processes, positions and units. This AIOC reads its decided release and returns defects; it never changes a release, and proposes later changes for decision (§5.22). A return is a request, never a change (§5.1; Annex B).
  • [ORG]AIOC-TOM designs the operating model. A defect this AIOC finds in a TOM element goes back to TOM by return.
  • [ORG]AIOC-SL holds every source and every contact with a person. This AIOC holds only references and its own records, and files its package and its returns there.
  • [ORG]AIOC-OCO installs, fixes and upgrades this AIOC; it never grades it (Standard §2.3, item 9).
  • [ORG]AIOC-OER, where the organisation runs it, gives every formal act one number. Where a decision of a forum entered in this AIOC's decision log is a formal act, the log holds the reference to its register entry, never a number of its own (§5.17, rule 2; Protocol §22).
• Overlap. None known. Where an organisation already holds procedures, policies, plans, logs or a workflow tool, they are sources, read through Source Lifecycle and mapped (§5.1); a workflow tool keeps running, and runnable procedures can be exported to it (§5.20).

3. Positions

• Every human position is a HOAC position. This AIOC has one, the DI Delivery Lead. The organisation may add more in this AIOC's own design (§17).
• Present as positions (Standard §1.1, items 9 and 10). Every human this AIOC deals with, its own Lead and the organisation's positions, is present as a position. It addresses positions only, through their HU ports.
• The Requesting Authority and the deciding positions are not positions of this AIOC (§2.1). They decide; this AIOC prepares the decision.
• No AI Cell signs anything (Protocol §10, item 3). Each AI Cell's bot has its own identity card (§17).
• The trace query, the package manifest, the checks of §5, the version register, the acknowledgements and notices, the checklist runner, the dashboards' refresh, the export and the ladder's own record are code steps of the Chief of Staff, never a Cell. Code is a tool, never a seat.
• Three of them judge or check work of another Cell and are kept apart from it: the Citation Verifier and the Trial Judge each run on an engine of another family than the writer's or the proposer's; the Blind Reviewers review only outputs they did not write.

4. Standard capabilities

Defaults are in docs/STANDARD-CAPABILITIES.md of 49GAION-aioc at acdcbe5 (v1.6.0). The differences are listed in §11.

4.1 Office

Definition

Default · form: single Chief of Staff. An Office forms only if the Delivery Lead needs more than one Chief of Staff; it is proposed to the Delivery Lead, never self-created.

Process (SOP)

Default.

Role card

None while the form is a single Chief of Staff.

Fixed test

TEST-DI-COSDI v1 (TEST-DI v1, case 44) · result NOT_RUN

4.2 Chief of Staff

Definition

Default, managing kind, with these additions:

• The only door. It is the only Cell of this AIOC that sends anything outside it: returns to [ORG]AIOC-PPD and [ORG]AIOC-TOM; needs requests, Missing Reports and filings to [ORG]AIOC-SL; answers, Decision Package rows, rows for decision, forum packs, minutes previews, learning paths and notices to positions, through the HU output port. The external ports sit on its card (§17).
• No question about a person, and none to a person about the organisation. Every question for the organisation goes to the Chief of Staff of [ORG]AIOC-SL as a needs request (§5.2). It sends a position only an answer it was asked for, a row for decision, a pack or preview for a forum it belongs to, its learning path, or a notice about a record that concerns it.
• An orchestrator that never judges itself. It runs the gates (Annex C), dispatches the Cells, locks outputs, runs the code steps, draws the reviewers and writes the run record. It never rules on a finding, never dismisses or downgrades one, never lowers a review, and never decides for a deciding position.

Process (SOP)

Default, plus:

1. Admission (S0). On a run request: open the run record; check that the request carries references only and names an enabled mode; receive or fetch the release notice (mode A) or the design's source reference (mode B); have the Input socket build Input Pack P0 (§4.3); check gate T0 (Annex C.2) → P0 and the T0 record (evidence: the T0 record, with P0's ID).
2. One run at a time per organisation. A second run in parallel needs the Delivery Lead's approval, recorded in the run record.
3. Returns. Collect the return drafts; have each reviewed; send each to the stage that made the release, under the design return contract, and file it into [ORG]AIOC-SL with the same hash; mark the elements it touches held: return open; count its rounds; past return_round_deadline or return_rounds_max, put it to the Requesting Authority, who answers it or sets it aside on a stated basis → return sent; return ended (evidence: the return, its filing receipt and its end).
4. Passes. Batch needs candidates into passes of at most rows_per_pass rows, one decision per row, each with its Missing Report.
5. Questions. On a question from a position, dispatch the Answer Guide, then the Citation Verifier; send the verified answer, or "I do not know", to the asking position only; record the question by ID, never as a source (§5.8).
6. Code steps. Run the checks of §5.1 to §5.7, the trace query (§5.10) and the package manifest → generated parts (evidence: re-generated byte-identical).
7. Stops and revocation. A stop from any accountable position takes effect at the gateway on every part, and on any draft in flight; the Chief of Staff is itself stopped. A stop may also name one change this AIOC applied: that change is rolled back at once (FR-34). A revoked connection holds the run as held: connection revoked.
8. The service (S5 to S7). New in v0.2.0. On a service request: check that it carries references only, names a filed launch package that reads back by its hash, and names the parts switched on; open the service record; dispatch as §5.0 sets → service record (evidence: the record, with the package ID).
9. Rows and insertions. Send each draft to the position that decides it, as a row. Enter a draft into a record, log or plan only when that position inserts it (level 1), or apply it within a signed class (level 2, step 15) → row decided or inserted (evidence: the decision reference).
10. Versions, notices and acknowledgements. Keep the version register; raise a notice on each re-approval due and on each changed version, to every position it concerns; record each acknowledgement by version and position code (§5.20) → version register (evidence: the notices and acknowledgements by version).
11. Checklists. Run each procedure as a checklist per case, or export it to the organisation's own workflow tool (§5.20).
12. Records of work. Admit records of work only through the projection, and only while Annex H holds. Refuse whole any record with a field that identifies who did the work, and keep nothing of it (Annex H, rule 3).
13. Rolling up. Before any measure, finding or view leaves this AIOC, check by code that it describes a process, a step or a unit, never a position, and that it rests on at least min_group positions; otherwise roll it up to the parent unit (Annex H, rule 5).
14. Export. On a request of the Requesting Authority's Cell, produce the full export with its trace (§5.25).
15. Level 2 and rollback. Apply a level-2 change only within a class the owner position signed, as a new version with one-step rollback, and report it to the owner position the same day. Any error, complaint or change of engine drops the class to level 1 at once (Annex G).

Role card

Fixed test

TEST-DI-COSDI v1 · result NOT_RUN

4.3 Input socket

Definition

Default, with this AIOC's standard format, the Input Pack, as in the TOM blueprint v0.5.0 §4.3, parts 1 to 3 and 6 to 8, read with these changes:

1. Three kinds of input. The releases (mode A): the decided PPD Release, by manifest and parts, from the release notice, and the decided TOM Release it names, read by reference from Source Lifecycle. The outside design (mode B): a source in Source Lifecycle, cut into atoms and labelled once (TOM Annex B, carried). The other sources: by reference from Source Lifecycle's output socket.
2. A release is read, never atomised as a source. Its elements keep their own IDs. Every element of this AIOC's output traces to a release element or a source atom.
3. The release check. A release is admitted only when its manifest validates, its final status is decided, and its hash equals the copy filed in Source Lifecycle; the PPD Release must name the TOM Release it was designed from, and that release must pass the same check, with its role register re-compiling from its parts. Otherwise nothing of it is used, and a return goes back with the failed condition.
4. A new release makes a new pack version. The elements that changed re-open the work that cites them; decided work that cites nothing changed is kept by hash.
5. Nothing that arrives through a human port is a source. A run request is admitted only if it carries references. A question from a position is never a source and never changes the design.
6. The pack's ID is DII- followed by the SHA-256 of its body.
7. Mode C. New in v0.2.0. The owner position's sources in Source Lifecycle are cut into atoms and labelled as in mode B. There is no design to map: the Light Designer builds one with the owner position (§5.11).
8. Records of work are not sources of the design. They enter only through the projection, while Annex H holds, by reference, with no field that identifies who did the work. An item with such a field is refused whole, and nothing of it is kept.
9. Change notices from Source Lifecycle enter as source references with their change kind (a new product, site, market or law), and open the work of §5.22.

Process (SOP)

Default (receive, identify, normalise, check, deliver), run by the Chief of Staff through the socket's code steps. A refused item comes back with its reason and never enters.

Role card

Default; performed by the Chief of Staff ([ORG]CELL-COSDI) through the socket's code steps.

Fixed test

TEST-DI v1, cases 1, 2, 18 to 22, 51, 73, 74, 78, 92 · result NOT_RUN

4.4 Panel

Definition

Default. The Panel also shows, for each run: the run state and its flags with their ages; the mode; the releases or the design in use, and any newer release; every return, with its round, state and age; every needs request; each gate with its result; the gaps by tier and state; each procedure, brief and go-live criterion with its decision state; the questions answered and those answered "I do not know"; per review, its point, verdict and findings. For the service it shows: tasks by state; the go-live criteria and stabilisation; rehearsal defects; the logs, with items past their date; packs and minutes awaiting preview; versions due; acknowledgements pending, by version only; initiatives by gate, with value planned and realised; proposals and trials; conformance by process; hand-over items left; the ladder level of each class. It shows no measure for a single position, and every figure rests on at least min_group positions (Annex H, rule 5). Every output is in the organisation's language (language, NFR-08).

Process (SOP)

Default.

Role card

Default.

Fixed test

Default Panel test · result NOT_RUN

5. Functional capabilities

The launch has five stages (§5.0, S0 to S4), performed by the Input socket (§4.3: S0) and these capabilities: Intake and Design Map, or Light Design in mode C (S1); Gap Audit and Health Check (S2); Procedure Writing, Briefs and Drafts, and Transition and Go-live Criteria (S3); Decision Package and Filing (S4). The service has three parts: Accompany (S5: §5.12 to §5.16), Operate (S6: §5.17 to §5.20) and Improve (S7: §5.21 to §5.24). Needs Requests (§5.2), Answers (§5.8) and Export (§5.25) are services. Independent Review (§5.9) closes every stage. Each capability is written in the four-part form (Annex A of the template), with one added row, Done when. Each step reads: position: action → output (evidence). Annexes: A (the parts and their field lists), B (returns), C (run states and gates), D (what this AIOC never does), E (rules carried), F (the gap checks), G (the permission ladder), H (records of work).

One word per meaning.

• Release: a decided design release this run reads (PPD or TOM). Outside design: a design made elsewhere, read as a source (mode B). Design: either.
• Launch package: the output of the launch, S0 to S4 (Annex A.1 to A.8).
• Gap (GAP-n): a check of Annex F that the design fails. Brief (BRF-n): a draft for counsel or finance. Criterion (GLC-n): a go-live criterion.
• Deciding position: the position that decides a row (§2.1). Return (DIR-n): this AIOC's notice to the stage that made a release (Annex B).
• Service: the work after the launch package is filed: Accompany (S5), Operate (S6) and Improve (S7). Living design: the decided design as the organisation keeps it after launch, each later decided version filed in Source Lifecycle.
• Insert: a position's act that enters a draft of this AIOC into a live record, log or plan. Apply: this AIOC's own act at level 2, within a signed class (Annex G).
• Task (TSK-n), Problem (PRB-n), Initiative (INI-n), Finding (FND-n), Proposal (PRP-n), Trial (TRL-n): the records of the service, in Annex A.

5.0 The stages: input, output, done-test

Services and rules used by every stage.

Run states. The launch: admitting (S0) → mapping (S1), or building in mode C (S1C) → diagnosing (S2) → preparing (S3) → deciding (S4) → filed. The service: accompanying (S5) → stabilised; operating (S6) and improving (S7) are standing states, each worked in cycles. Endings, flags and holds: Annex C.1.

The slices. The product requirements build this AIOC in four slices, each usable on its own (PRD-[ORG]AIOC-DI-001 v0.4). Every slice is designed here; the slices stay the order in which its parts are built and switched on.

1. Slice 1, launch (S0 to S4; modes A and B; FR-01 to FR-03, FR-05 to FR-13, FR-15, FR-33, FR-34, FR-43): on when the AIOC joins.
2. Slice 2, accompany and operate (S5, S6; FR-14, FR-16 to FR-18, FR-20 to FR-22, FR-35 to FR-37, FR-40 to FR-42): on by a service request for a filed launch package.
3. Slice 3, improve (S7; FR-19, FR-23 to FR-26, FR-38, FR-39, FR-43): proposals, trials, reassessment, the quarterly health check and the hand-over switch on with the service. Process watching and conformance switch on only when Annex H holds. Level 2 applies only to a class the owner position signed (Annex G).
4. Slice 4, small business (S1C; FR-04): mode C switches on only when the Cell carrying [ORG]HOAC-TM records that slices 1 and 2 have given evidence (§13, H-21), and then through modes_enabled. The later parts are written here too: reference models, the full mentor, the multi-engine council and guidance at the point of work (FR-27 to FR-29, FR-44). Each stays off until its own switch is set (§15).
5. The tools (FR-30 to FR-32) serve every slice (§5.25; §6).

5.1 Intake and Design Map

Definition

Process (SOP)

1. Design Mapper: read the release or the outside design, element by element → design map, draft (evidence: one row per element).
2. Design Mapper: for each defect of a release, draft a return with its kind, elements and evidence → return draft.
3. Chief of Staff: lock; run RP1 (§5.9) → settled review.
4. Chief of Staff: send each return and file it into [ORG]AIOC-SL; mark the touched elements held; follow each return to its end → ended return (evidence: the return's status and its answer or decision reference).

Role card

Fixed test

TEST-DI-DD v1 and TEST-DI-DDM v1 · result NOT_RUN

5.2 Needs Requests

Definition

As in the TOM blueprint v0.5.0 §5.2, carried, with these changes. What this AIOC typically asks for: the jurisdictions and entities in scope; existing procedures, forms and templates; the systems in use; known legal obligations; the dates the organisation has in mind for launch. Each request names the gap, procedure, brief or criterion it is for. One decision per row; at most rows_per_pass rows per pass. A request never names a person. Done when: each request ends answered by reference, or with another outcome of the needs-answer contract.

Process (SOP)

As carried: the Pods raise needs candidates; the Chief of Staff batches, reviews (RPa), sends, waits, and admits each answer through the Input socket as a new pack version.

Role card

Performed by the Chief of Staff (§4.2).

Fixed test

TEST-DI v1, case 22 · result NOT_RUN

5.3 Gap Audit

Definition

Process (SOP)

1. Chief of Staff: run the code checks of Annex F on the design map → check record.
2. Gap Auditor: judge the remaining checks; write each gap → gap report, draft.
3. Chief of Staff: run RP2; send the route rows for decision → decided routes.

Role card

Fixed test

TEST-DI-DGA v1 · result NOT_RUN

5.4 Health Check

Definition

Process (SOP)

1. Health Checker: answer each item with evidence → health check, draft.
2. Chief of Staff: run RP2 with the gap report → settled review.

Role card

Fixed test

TEST-DI-DHC v1 · result NOT_RUN

5.5 Procedure Writing

Definition

Process (SOP)

1. Procedure Writer: write each procedure → procedure drafts.
2. Citation Verifier: check every citation → verification record.
3. Chief of Staff: run the trace check by code, then RP3 → settled review.

Role card

Fixed test

TEST-DI-DPW v1 · result NOT_RUN

5.6 Briefs and Drafts

Definition

Process (SOP)

1. Brief Writer: write each brief → brief drafts.
2. Citation Verifier: check every citation → verification record.
3. Chief of Staff: run the brief lint by code (mark, entity, jurisdiction, addressee, no amount except in the cost draft, where every amount is cited; no name), then RP3 → settled review.

Role card

Fixed test

TEST-DI-DBW v1 · result NOT_RUN

5.7 Transition and Go-live Criteria

Definition

Process (SOP)

1. Transition Planner: draft the plan and the criteria → drafts.
2. Citation Verifier: check every citation → verification record.
3. Chief of Staff: run RP3; send the threshold rows for decision → decided rows.

Role card

Fixed test

TEST-DI-DTP v1 · result NOT_RUN

5.8 Answers

Definition

Process (SOP)

1. Answer Guide: draft the answer with its citations → answer draft.
2. Citation Verifier: check each citation → verified answer or refused citation.
3. Chief of Staff: send the verified answer, or "I do not know", to the asking position → answer record (evidence: the record with its citations and the verifier's result).

Role card

Fixed test

TEST-DI-DA v1 and the tests of its Cells · result NOT_RUN

5.9 Independent Review

Definition

The Review Panel rule of the TOM blueprint v0.5.0 §5.8, carried as [ORG]AIOC-PPD carries it (PPD blueprint v0.3.0 §5.9): several engines from two or more families review each locked output, alone first, then in a short debate held to quotes; code settles; the DI Delivery Lead rules only on what stays contested; the Chief of Staff never rules, dismisses, downgrades or lowers. This AIOC's review points: RP0 (P0), RP1 (design map, or light design, and return drafts), RP2 (gap report and health check), RP3 (procedures, briefs, drafts, plan and criteria), RP4 (the package, before filing), RP5 (the accompany outputs, before T6), RP6 (a sample of each operating cycle's packs, measures and value figures), RP7 (findings, proposals, trial designs and judgements, hand-over records), and RPa (each needs pass). Done when: as carried.

Process (SOP)

As carried.

Role card

Blind Reviewers A to C ([ORG]CELL-DBRA to [ORG]CELL-DBRC), in the Review Pod ([ORG]POD-DR); as carried.

Fixed test

TEST-DI-DR v1 and the tests of its Cells · result NOT_RUN

5.10 Decision Package and Filing

Definition

Process (SOP)

1. Chief of Staff: generate the Decision Package; obtain the Delivery Lead's attestation of T0 to T3 → Decision Package.
2. Chief of Staff: run RP4; send each row to its deciding position → decided rows.
3. Chief of Staff: freeze the manifest, run the lint, file, read back, send the notice → filed launch package (evidence: the filing receipt and the read-back hash).

Role card

Performed by the Chief of Staff (§4.2); the attestation by the DI Delivery Lead (§13, H-12).

Fixed test

TEST-DI-COSDI v1 (cases 40, 41, 94) · result NOT_RUN

5.11 Light Design

Definition

Process (SOP)

1. Light Designer: from the pack, draft the decision list, the process checklists, who does what and the weekly rhythm, each element with its source atoms → light design, draft.
2. Chief of Staff: ask through Source Lifecycle for what is missing (§5.2); run RP1; send each element to the owner position → decided elements.

Role card

Fixed test

TEST-DI-DLD v1 · result NOT_RUN

5.12 Implementation Plan

Definition

Process (SOP)

1. Implementation Planner: draft the plan from the package → plan draft.
2. Citation Verifier: check every trace → verification record.
3. Chief of Staff: run the plan check by code (owner, dependencies, date, trace; no cycle among dependencies), then RP5; send the plan to the owner position → decided plan.

Role card

Fixed test

TEST-DI-DIP v1 · result NOT_RUN

5.13 Change Impact and Adoption

Definition

Process (SOP)

1. Change Analyst: draft the change impact, the stakeholder register, the briefings and the adoption measures → drafts.
2. Chief of Staff: run RP5; send each to its deciding position → decided rows.

Role card

Fixed test

TEST-DI-DCA v1 · result NOT_RUN

5.14 Learning Paths

Definition

Process (SOP)

1. Learning Builder: draft each path with its checks → path drafts.
2. Citation Verifier: check every trace → verification record.
3. Chief of Staff: run RP5; send each path to its learner position → paths delivered (evidence: the path's version and its delivery record, never a result).

Role card

Fixed test

TEST-DI-DLB v1 · result NOT_RUN

5.15 Readiness and Go-live

Definition

Process (SOP)

1. Readiness Assessor: write the rehearsal scripts; after each rehearsal, record the defects; read each criterion's evidence → readiness record.
2. Readiness Assessor: draft the go or no-go package → package draft.
3. Chief of Staff: run RP5; send the package to the go or no-go position, and record its signed decision → decision recorded (evidence: the signature record's reference).
4. Readiness Assessor: after go-live, track the stabilisation criteria → stabilisation record.

Role card

Fixed test

TEST-DI-DRA v1 · result NOT_RUN

5.16 Problem Records

Definition

Process (SOP)

1. Issue Analyst: open the record from the report; draft its cause and options → record draft.
2. Chief of Staff: place it in the issue list of the forum the design names; send its decision row to the deciding position → decided record (evidence: the decision reference and its actions in the action log).

Role card

Fixed test

TEST-DI-DIA v1 · result NOT_RUN

5.17 Operating Rhythm

Definition

Process (SOP)

1. Rhythm Keeper: before each forum, build its pack; after it, draft the minutes → pack; minutes draft.
2. Chief of Staff: send the pack to the chair, and the minutes preview to the participant positions; enter the minutes in the logs on approval → logs updated (evidence: the approved preview's hash).
3. Rhythm Keeper: each week, list items off track and follow-ups dropped; each quarter, draft priorities → notices; priority drafts.

Role card

Fixed test

TEST-DI-DRK v1 · result NOT_RUN

5.18 Measures

Definition

Process (SOP)

1. Measures Builder: draft each measure's definition and dashboard → drafts.
2. Chief of Staff: run RP6 on the drafts; send each to its process owner position; refresh the decided dashboards by code each cycle → dashboards (evidence: the source and time of each figure).

Role card

Fixed test

TEST-DI-DMB v1 · result NOT_RUN

5.19 Value Register

Definition

Process (SOP)

1. Value Tracker: keep each initiative's record; each month, update value from its sources and apply the warning rules → register version.
2. Chief of Staff: run RP6 on the month's sample; send L2 and L5 rows to the finance position → decided gates.

Role card

Fixed test

TEST-DI-DVT v1 · result NOT_RUN

5.20 Versions and Checklists

Definition

Process (SOP)

1. Chief of Staff: on each decided version, update the register, file the version into Source Lifecycle and send the notices → version register; living design filing (evidence: the filing receipt).
2. Chief of Staff: on each acknowledgement, record it by version and position code → acknowledgement record.
3. Chief of Staff: run each opened case through its checklist, holding each gate until its approval arrives → checklist run.

Role card

Performed by the Chief of Staff (§4.2), by code steps.

Fixed test

TEST-DI-COSDI v1 (cases 69 to 71) · result NOT_RUN

5.21 Process Watching

Definition

Process (SOP)

1. Process Analyst: compute conformance by code; judge what code cannot; write findings → conformance record; findings.
2. Chief of Staff: run the roll-up check (Annex H, rule 5), then RP7; send findings to their process owner positions → findings delivered.

Role card

Fixed test

TEST-DI-DPA v1 · result NOT_RUN

5.22 Proposals

Definition

Process (SOP)

1. Change Proposer: draft each proposal from its trigger → proposal draft.
2. Chief of Staff: run RP7; send each to its deciding position, or as a return → decided proposal or return (evidence: the decision or the return's end).

Role card

Fixed test

TEST-DI-DCP v1 · result NOT_RUN

5.23 Trials

Definition

Process (SOP)

1. Trial Designer: draft the trial's rules → trial design.
2. Chief of Staff: run RP7; send the design to the process owner position; start the trial only when it is decided → started trial.
3. Trial Judge: at the end, or on the rollback trigger, judge by the decided rules → judgement.
4. Chief of Staff: send the judgement to the process owner position; record lessons → decided outcome.

Role card

Fixed test

TEST-DI-DTD v1 and TEST-DI-DTJ v1 · result NOT_RUN

5.24 Hand-over and Mentor

Definition

Process (SOP)

1. Capability Mentor: each quarter, draft the list and the hand-over plan; before each drill, prepare it → hand-over record; drill plan.
2. Chief of Staff: stop this AIOC for the drill as decided; afterwards, send the drill's evidence to the Cell carrying [ORG]HOAC-TM → drill record (evidence: that Cell's decision).
3. Capability Mentor: on a request for advice, draft it from the skills library and the design → advice record.

Role card

Fixed test

TEST-DI-DCM v1 · result NOT_RUN

5.25 Export

Definition

Process (SOP)

1. Chief of Staff: generate the export and its manifest; re-import it into a fresh instance by code; send it → export (evidence: the re-import check).

Role card

Performed by the Chief of Staff (§4.2), by code steps.

Fixed test

TEST-DI-COSDI v1 (case 89) · result NOT_RUN

6. Coordination and routes

• [ORG]AIOC-PPD. The design source, linked directly.
  • Routes. Release notices arrive through the Input socket. Returns leave as Work Items through the output port, each also filed into Source Lifecycle.
  • The connection. Signed by the [ORG]HOAC-ACS position over [ORG]AIOC-PPD as connect-external-port, with two scopes: read its decided releases; send returns. A revocation cuts it at the gateway at once and holds the run.
• [ORG]AIOC-TOM. Its decided release is read by reference from Source Lifecycle. Returns on it leave through a connection signed over [ORG]AIOC-TOM, scope: send returns and receive their answers (TOM blueprint v0.5.0, §5.10).
• Loops. A return is a Work Item to the stage that made the release. That stage answers it on that Work Item: by a new release (announced, for PPD, by a new release notice) or by a decision of the Requesting Authority; it never opens a new item back to this AIOC, so the chain never loops (Protocol §4.6, item 2). Every return ends (Annex B).
• [ORG]AIOC-SL. The source of record, and the only route to any person in the organisation about the organisation. The connection (Protocol §13, item 5) has three scopes: read; needs requests; write only this AIOC's own packages and design reports (its returns).
• The organisation's positions. Questions and problem reports arrive through the HU input port, and answers leave through the HU output port, to the asking position only. Decision Package rows, rows for decision, forum packs, minutes previews and notices go to the positions they concern the same way; insertions, approvals and acknowledgements come back the same way, under live sign-in.
• The organisation's tools (FR-31). Connectors to the document store, accounting, HR, ticketing and calendar are read only by default. Each is signed as connect-external-port by the [ORG]HOAC-ACS position over the tool, scoped, and revoked at the gateway at once. A connector feeds only two places: Source Lifecycle, for documents, which this AIOC then reads as sources; and the projection, for records of work (Annex H). This AIOC reads a tool through nothing else. A connector that writes needs a class at level 2 (Annex G); one that touches HR or legal records never writes.
• [ORG]AIOC-OER, where the organisation runs it. A decision of a forum that is a formal act carries its register reference in the decision log (§5.17, rule 2).
• Work Items.
  • The run. One Work Item, opened by the Requesting Authority's Cell through the HU input port. Requested output: a launch package (Annex A). Acceptance test: the Requesting Authority's (T4 decided; the manifest valid; the filed reference reads back). Sources: the mode and the design reference.
  • The service. One standing Work Item, opened by the Requesting Authority's Cell for a filed launch package. Requested output: the service records (Annex A.9 to A.25). Acceptance test: the Requesting Authority's (T6 and the go or no-go decided; T7; each cycle's T8; each drill decided). It is reviewed each quarter, and closed only by the Requesting Authority.
• [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. return → [ORG]AIOC-PPD or [ORG]AIOC-TOM; return filing → [ORG]AIOC-SL; needs request → [ORG]AIOC-SL; missing report → [ORG]AIOC-SL; launch package filing → [ORG]AIOC-SL; living design filing → [ORG]AIOC-SL; answer → the asking position; rows for decision → the deciding position; forum pack → the forum's positions; notice → the positions a record concerns; export → the Requesting Authority's Cell.

7. Records and where things live

• References, not copies. Atom text and release text are held only in the run workspace. Records store IDs and hashes.
• Questions. A question is recorded by ID, with the asking position's code and the answer's citations; its text stays in the run workspace.
• Revocation or reclassification. On a notice from Source Lifecycle or a design stage, the run is held and its workspace copies are sealed.
• Engine ceilings. No atom or release part is sent to an engine whose confidentiality ceiling is below its level (TOM blueprint v0.5.0 §5.8, rule 17, carried).

8. Tools and the shared AI gateway

• Metering. Every engine call goes through the tool gateway of the [ORG]AION, metered for this AIOC within budget_cap (Standard §4.4, item 11; NFR-11).
• Null default. Every AI Cell runs with no tools, no outside access, no memory and a fresh context for each dispatch.
• Tests stay hidden from the runners. No Cell under test sees TEST-DI, its fixtures or §9.
• Standing alone. Outside an [ORG]AION, this AIOC runs behind its own gateway, which fails closed: one negative case for every Human Floor type passes before each release (NFR-09).

Mechanism register. Read on 15 October 2026. A row is never deleted.

Reserve.

9. Fixed tests: index, triggers and scores

The cases are written in tests/TEST-DI.md. Cases 1 to 17 are the Library's TEST-DELIVERY-AND-IMPLEMENTATION v1, unchanged. Cases 18 to 94 are this AIOC's own; cases 51 to 94 were added on 18 October 2026, before any use (decisions/DR-0004). The Delivery Lead's seat test is DDL-1 to DDL-5. The owner of every part's test is the DI Delivery Lead; the owner of the AIOC's whole test, and of the Delivery Lead's own seat test, is the Cell carrying [ORG]HOAC-TM. Library cases 9, 11 (level 2), 13 (the projection), 14 and 16 (the full export) test features now designed here (§5.17 to §5.25; Annexes G and H).

• Re-run triggers. The template defaults, plus any change to the design return contract, to the PPD or TOM release format, to the Source Lifecycle output socket, to the check list of Annex F, to the package lint, to the ladder (Annex G), to the projection (Annex H), or to min_group.
• Complete only when every part's test has a visible result. NOT_RUN is never PASS.

Checks that are not fixed tests.

10. Build: what is generated from this file

Delivery path: definition change → tests → Panel and Back office update → one-click rollback to the previous commit.

11. Exceptions

1. The Back office converses with humans (converses_with_humans: true). Reason: answering positions' questions is part of this AIOC's purpose (FR-15). Bounds: it answers only from the decided design, to the asking position only; a question is never a source (§5.8).
2. The Chief of Staff never asks the organisation's people anything about the organisation. It reaches the organisation for facts only through the Chief of Staff of [ORG]AIOC-SL. Reason: as for [ORG]AIOC-TOM (its §11, item 1).
3. Two design sources. The template's Input socket takes sources. This one also takes a design release directly from [ORG]AIOC-PPD, by reference and hash, and returns defects to it and to [ORG]AIOC-TOM. Reason: the chain of design stages (49GAION Standard §3.1, items 3 to 6).
4. Rules carried by reference. The review rule, labels and decision rules are carried from the TOM blueprint v0.5.0 by section (Annex E).
5. It reads records of the organisation's work (FR-19). Reason: improving the running organisation needs the work as it runs. Bounds: only through the projection, only after Annex H holds, at process level only.
6. It applies changes at level 2. Reason: small reversible upkeep should not wait on a row each time. Bounds: only within a class the owner position signed, never a type of the Human Floor signature list (Annex G).

12. Lessons and proposals to the mother

One dated line per lesson, each written without any organisation's details. Nothing is proposed upstream without the governing seat's word; the drafts are in upstream/PROPOSALS.md.

1. 2026-10-15 · A decided design is not yet a working organisation: procedures, briefs for counsel and finance, the transition plan and the go-live criteria are still needed, and the organisation needs a stage beside it through launch and after. Test questions added: cases 30 to 35. This text is the mother.
2. 2026-10-15 · An assistant that answers questions about how an organisation works must answer only from the decided design, with a second engine checking each citation, and say "I do not know" otherwise. Test questions added: cases 36 to 38.
3. 2026-10-16 · The value an organisation expects from its new design, and the order in which its parts matter, are decided before this stage; this stage carries them unchanged and starts its rollout and its register of value from them. Test questions added: cases 49 and 50 (decisions/DR-0003).
4. 2026-10-18 · A stage that stays with an organisation after launch needs, beyond the launch package: one rhythm with single logs; a value register whose gates finance alone passes; versions acknowledged by the positions they concern; process watching at process level, only through a projection that removes who did the work; trials judged by a seat that did not propose them; and a drill that proves the organisation can run without it. Test questions added: cases 51 to 94 (decisions/DR-0004).

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. Silence decides nothing; a general approval decides no row.

Money: the budget cap and the review budget (H-06); a brief holds no amount, and lists the decisions on amounts the organisation must take; every amount in the cost draft is read from a source or a decision row; gates L2 and L5 are the finance position's (H-20). People: this AIOC prepares for positions, never for who fills them; the go or no-go is the deciding position's (H-11); records of work are read only under H-17. Legal: every brief and draft goes to the counsel position of its jurisdiction before any decision.

14. Change log

15. Configuration

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

16. Type

• Type: Specialised.
• Why this AIOC exists: an organisation needs its decided design taken into a running organisation, with someone beside it through launch and after, who decides nothing for it and hands its skills over until the organisation can run without it.
• Type-specific test: TEST-DI v1, case 47 · 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 DI Delivery Lead. Every field that points to a human takes a position code only.

The card data (the blueprint governs). tools/make_cards.py expands the block below into the complete unit cards and bot identity cards, writes them into cards/, and checks them against the schemas of 49GAION-protocol, Naming Standard R15 and R16, and this blueprint.

parts:
  defaults:
    accountable_to: "[ORG]CELL-DDL"
    card_version: "v0.2.3"
    version: "0.2.3"
    lifecycle_state: "designed"
    test_version: "v1"
    test_owner: "[ORG]CELL-DDL"
    audit_trail: "the run record of [ORG]AIOC-DI"
    hu_in: ["run control and configuration from the DI Delivery Lead (never a source)"]
    hu_out: ["run report to the DI Delivery Lead"]
  cells:
    - code: "[ORG]CELL-DDL"
      full_name: "DI Delivery Lead"
      parent: "[ORG]AIOC-DI"
      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"]
        entity: "<entity>"
        expires: "2027-10-15"                # placeholder; each organisation sets it
        authority: "delegated"
      test: { id: "TEST-DI-DDL", cases: "DDL-1 to DDL-5", owner: "[ORG]CELL-TMS" }
      ai_in: ["run brief", "ruling sheets for contested MATERIAL findings", "release notice"]
      ai_out: ["run control and configuration"]
      hu_in: ["direction from the Cell carrying [ORG]HOAC-TM"]
      hu_out: ["rulings, attestations and reduced-level acceptances, under live sign-in", "report to the Cell carrying [ORG]HOAC-TM"]
    - code: "[ORG]CELL-COSDI"
      code_rule: "R16"                     # 49GAION/DR-0028; replaces [ORG]CELL-DCS (retired, R5)
      lineage: { id: "[ORG]CELL-DCS", version: "0.2.0", relation: "derived" }
      full_name: "DI Chief of Staff"
      role: "Chief of Staff"
      parent: "[ORG]AIOC-DI"
      type: "AI Chief of Staff"
      filler_kind: "ai"
      cell_kind: "chief-of-staff-cell"
      test: { id: "TEST-DI-COSDI", cases: "1, 2, 4, 8, 10-13, 15-22, 25, 40-46, 48, 51, 55, 66, 69-71, 73, 74, 78, 83, 84, 86, 89, 92, 94" }
      ai_in: ["release notice", "return answer", "source reference", "needs answer", "needs status", "change notice", "records of work through the projection", "needs candidate", "return draft", "locked outputs of the Pods", "settled review records", "verified answer"]
      ai_out: ["Input Pack version", "dispatch to a Pod", "review packet", "return", "needs request", "missing report", "Decision Package", "launch package filing", "living design filing", "export"]
      hu_in: ["run request from the Requesting Authority's Cell (references only)", "service request from the Requesting Authority's Cell (references only)", "a question from a position (never a source)", "a problem report from a position (never a source)", "a decision of a deciding position", "an insertion, a preview approval or an acknowledgement by a position", "run control from the DI Delivery Lead"]
      hu_out: ["answer to the asking position", "Decision Package rows to the deciding positions", "rows for decision to the deciding positions", "forum packs and minutes previews to the forum's positions", "notices to the positions a record concerns", "a learning path and its check results to the learner position only", "run brief and ruling sheets to the DI Delivery Lead", "filing notice to the Requesting Authority's Cell"]
      external_ports:
        - { port: "ppd-in", direction: "input", accepted_content: ["release notice", "return answer"], authority_limit: "the read scope signed under connect-external-port over [ORG]AIOC-PPD", audit_trail: "unit register; serve log of [ORG]AIOC-PPD" }
        - { port: "ppd-out", direction: "output", accepted_content: ["return"], authority_limit: "returns only, under the scope signed over [ORG]AIOC-PPD", audit_trail: "unit register; the Work Item record" }
        - { port: "tom-out", direction: "output", accepted_content: ["return"], authority_limit: "returns only, under the scope signed over [ORG]AIOC-TOM", audit_trail: "unit register; the Work Item record" }
        - { port: "tom-in", direction: "input", accepted_content: ["return answer"], authority_limit: "answers to this AIOC's returns only, under the scope signed over [ORG]AIOC-TOM", audit_trail: "unit register; the Work Item record" }
        - { port: "sl-in", direction: "input", accepted_content: ["source reference", "needs answer", "needs status", "change notice"], authority_limit: "the read scope signed under connect-external-port over [ORG]AIOC-SL", audit_trail: "unit register; serve log of [ORG]AIOC-SL" }
        - { port: "sl-out", direction: "output", accepted_content: ["needs request", "missing report", "return filing", "launch package filing", "living design filing"], authority_limit: "the request and write scope signed over [ORG]AIOC-SL: this AIOC's own packages, decided versions and design reports only", audit_trail: "unit register; serve log of [ORG]AIOC-SL" }
        - { port: "tools-in", direction: "input", accepted_content: ["records of work through the projection"], authority_limit: "read only, within the scope signed under connect-external-port over the projection; only while process watching is on (Annex H)", audit_trail: "unit register; the projection's log" }
      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 reviewed returns and file them in [ORG]AIOC-SL", "send needs requests and Missing Reports to [ORG]AIOC-SL", "send verified answers to the asking position", "send Decision Package rows to the deciding positions", "file a package whose elements are decided", "send rows for decision, forum packs, minutes previews and notices to positions", "enter a draft a position inserted", "apply a level-2 change within a class the owner position approved in advance, with its rollback", "keep the version register and record acknowledgements", "run checklists per case", "produce the export"]
        ask_first_actions: ["a second run in parallel", "a budget above the cap", "a reduced review level", "any change to configuration", "anything outside its role card"]
    - { code: "[ORG]CELL-DDM", full_name: "DI Design Mapper", role: "Design Mapper", parent: "[ORG]POD-DD", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-DI-DDM", cases: "2, 23, 24, 49, 93" }, ai_in: ["Input Pack version"], ai_out: ["design map", "return draft", "needs candidate"], bot: { allowed_actions: ["read a release or map an outside design, element by element", "draft returns with their evidence"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-DGA", full_name: "DI Gap Auditor", role: "Gap Auditor", parent: "[ORG]POD-DD", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-DI-DGA", cases: "5, 26-28" }, ai_in: ["design map", "check record", "Input Pack version"], ai_out: ["gap report draft", "needs candidate"], bot: { allowed_actions: ["judge the checks code cannot decide", "write each gap with its consequence, evidence, fix and route"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-DHC", full_name: "DI Health Checker", role: "Health Checker", parent: "[ORG]POD-DD", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-DI-DHC", cases: "29, 81" }, ai_in: ["design map", "Input Pack version", "the living design, the logs and the measures"], ai_out: ["health check draft"], bot: { allowed_actions: ["answer the health checklist with evidence"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-DLD", full_name: "DI Light Designer", role: "Light Designer", parent: "[ORG]POD-DD", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-DI-DLD", cases: "3, 52-54" }, ai_in: ["Input Pack version"], ai_out: ["light design draft", "needs candidate"], bot: { allowed_actions: ["draft the light design from the pack, every element provisional"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-DPW", full_name: "DI Procedure Writer", role: "Procedure Writer", parent: "[ORG]POD-DP", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-DI-DPW", cases: "6, 30, 31" }, ai_in: ["process records of the design", "decided gap routes"], ai_out: ["procedure drafts", "gap candidate"], bot: { allowed_actions: ["write procedures, forms and templates under each process"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-DBW", full_name: "DI Brief Writer", role: "Brief Writer", parent: "[ORG]POD-DP", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-DI-DBW", cases: "6, 32, 85-87" }, ai_in: ["design registers", "decided gap routes", "jurisdictions and entities in scope"], ai_out: ["brief drafts", "needs candidate"], bot: { allowed_actions: ["write briefs, and drafts from the organisation's own templates, for counsel and finance"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-DTP", full_name: "DI Transition Planner", role: "Transition Planner", parent: "[ORG]POD-DP", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-DI-DTP", cases: "8, 33-35, 50" }, ai_in: ["units, positions, processes and the crosswalk of the design", "decided gap routes"], ai_out: ["transition plan draft", "go-live criteria draft"], bot: { allowed_actions: ["draft the transition plan and the go-live criteria"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-DAG", full_name: "DI Answer Guide", role: "Answer Guide", parent: "[ORG]POD-DA", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-DI-DAG", cases: "7, 36, 37, 91" }, ai_in: ["question by ID", "the admitted design and the filed package"], ai_out: ["answer draft with citations"], bot: { allowed_actions: ["draft answers only from the decided design, with citations"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-DCV", full_name: "DI Citation Verifier", role: "Citation Verifier", parent: "[ORG]POD-DA", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-DI-DCV", cases: "36, 38" }, ai_in: ["draft with citations", "the cited elements and spans"], ai_out: ["verification record"], bot: { allowed_actions: ["check that each citation resolves and supports its claim"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-DBRA", full_name: "DI Blind Reviewer A", role: "Blind Reviewer A", parent: "[ORG]POD-DR", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-DI-DBRA", cases: "39" }, 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-DBRB", full_name: "DI Blind Reviewer B", role: "Blind Reviewer B", parent: "[ORG]POD-DR", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-DI-DBRB", cases: "39" }, 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-DBRC", full_name: "DI Blind Reviewer C", role: "Blind Reviewer C", parent: "[ORG]POD-DR", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-DI-DBRC", cases: "39" }, 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-DIP", full_name: "DI Implementation Planner", role: "Implementation Planner", parent: "[ORG]POD-DL", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-DI-DIP", cases: "56" }, ai_in: ["filed launch package"], ai_out: ["implementation plan draft"], bot: { allowed_actions: ["draft the implementation plan by position from the launch package"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-DCA", full_name: "DI Change Analyst", role: "Change Analyst", parent: "[ORG]POD-DL", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-DI-DCA", cases: "57" }, ai_in: ["the crosswalk and the launch package"], ai_out: ["change impact draft", "stakeholder register draft", "briefing drafts", "adoption measure drafts"], bot: { allowed_actions: ["draft the change impact, the stakeholder register, the briefings and the adoption measures"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-DLB", full_name: "DI Learning Builder", role: "Learning Builder", parent: "[ORG]POD-DL", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-DI-DLB", cases: "58" }, ai_in: ["job descriptions and procedures"], ai_out: ["learning path drafts"], bot: { allowed_actions: ["draft learning paths and their checks"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-DRA", full_name: "DI Readiness Assessor", role: "Readiness Assessor", parent: "[ORG]POD-DL", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-DI-DRA", cases: "8, 59, 60" }, ai_in: ["go-live criteria and their evidence", "the plan and the defect log"], ai_out: ["readiness record", "rehearsal scripts", "go or no-go package draft", "stabilisation record"], bot: { allowed_actions: ["read the criteria's evidence, write rehearsal scripts and records, draft the go or no-go package"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-DIA", full_name: "DI Issue Analyst", role: "Issue Analyst", parent: "[ORG]POD-DL", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-DI-DIA", cases: "61" }, ai_in: ["problem report by ID", "the living design and the logs"], ai_out: ["problem record draft", "issue list order"], bot: { allowed_actions: ["draft problem records and order issues by their effect on processes"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-DRK", full_name: "DI Rhythm Keeper", role: "Rhythm Keeper", parent: "[ORG]POD-DO", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-DI-DRK", cases: "62-64, 72" }, ai_in: ["forum register and review calendar", "the logs", "the measures", "the value register", "notes submitted by a participant position"], ai_out: ["forum pack", "minutes draft", "notices of items off track", "priority drafts"], bot: { allowed_actions: ["build forum packs, draft minutes and quarterly priorities, list items off track"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-DMB", full_name: "DI Measures Builder", role: "Measures Builder", parent: "[ORG]POD-DO", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-DI-DMB", cases: "65, 66, 91" }, ai_in: ["the measures of the design", "records of work through the projection"], ai_out: ["measure and dashboard drafts"], bot: { allowed_actions: ["draft measures and dashboards at process, step and unit level"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-DVT", full_name: "DI Value Tracker", role: "Value Tracker", parent: "[ORG]POD-DO", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-DI-DVT", cases: "9, 67, 68" }, ai_in: ["the value case carried", "the plan, proposals and measures", "decisions of the finance position"], ai_out: ["value register version", "value warnings"], bot: { allowed_actions: ["keep the initiative and value register from sources and decisions"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-DPA", full_name: "DI Process Analyst", role: "Process Analyst", parent: "[ORG]POD-DCI", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-DI-DPA", cases: "13, 75, 76, 88" }, ai_in: ["records of work through the projection", "the living design"], ai_out: ["conformance record", "findings"], bot: { allowed_actions: ["analyse records of work through the projection at process level, and write findings"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-DCP", full_name: "DI Change Proposer", role: "Change Proposer", parent: "[ORG]POD-DCI", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-DI-DCP", cases: "77, 78" }, ai_in: ["findings", "problem records", "change notices", "the living design"], ai_out: ["proposal drafts", "return drafts"], bot: { allowed_actions: ["draft proposals and returns from their triggers"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-DTD", full_name: "DI Trial Designer", role: "Trial Designer", parent: "[ORG]POD-DCI", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-DI-DTD", cases: "79" }, ai_in: ["decided proposal", "the measures"], ai_out: ["trial design draft"], bot: { allowed_actions: ["draft each trial's rules before it starts"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-DTJ", full_name: "DI Trial Judge", role: "Trial Judge", parent: "[ORG]POD-DCI", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-DI-DTJ", cases: "14, 80" }, ai_in: ["the trial design as decided", "the trial's data"], ai_out: ["trial judgement"], bot: { allowed_actions: ["judge a trial it neither proposed nor designed, by its decided rules"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-DCM", full_name: "DI Capability Mentor", role: "Capability Mentor", parent: "[ORG]POD-DCI", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-DI-DCM", cases: "82, 90" }, ai_in: ["the living design", "the logs", "the skills library", "a request for advice"], ai_out: ["hand-over record", "drill plan", "advice record"], bot: { allowed_actions: ["draft the hand-over list and plan, prepare the drill, draft advice from the skills library"], ask_first_actions: ["anything outside its role card"] } }
  pods:
    - { code: "[ORG]POD-DD", full_name: "DI Diagnosis", type: "AI Pod", inner_units: ["[ORG]CELL-DDM", "[ORG]CELL-DGA", "[ORG]CELL-DHC", "[ORG]CELL-DLD"], top_cell: "[ORG]CELL-DGA", test: { id: "TEST-DI-DD", cases: "2, 3, 5, 23, 24, 26-29, 49, 52-54, 81, 93" }, ai_in: ["Input Pack version"], ai_out: ["design map", "light design", "gap report", "health check", "return draft"] }
    - { code: "[ORG]POD-DP", full_name: "DI Preparation", type: "AI Pod", inner_units: ["[ORG]CELL-DPW", "[ORG]CELL-DBW", "[ORG]CELL-DTP"], top_cell: "[ORG]CELL-DPW", test: { id: "TEST-DI-DP", cases: "6, 8, 30-35, 50, 85-87" }, ai_in: ["design map", "decided gap routes"], ai_out: ["procedures", "briefs and drafts", "transition plan", "go-live criteria"] }
    - { code: "[ORG]POD-DA", full_name: "DI Answers", type: "AI Pod", inner_units: ["[ORG]CELL-DAG", "[ORG]CELL-DCV"], top_cell: "[ORG]CELL-DAG", test: { id: "TEST-DI-DA", cases: "7, 36-38, 91" }, ai_in: ["question by ID", "drafts with citations"], ai_out: ["verified answer", "verification record"] }
    - { code: "[ORG]POD-DR", full_name: "DI Review", type: "AI Pod", inner_units: ["[ORG]CELL-DBRA", "[ORG]CELL-DBRB", "[ORG]CELL-DBRC"], top_cell: "[ORG]CELL-DBRA", test: { id: "TEST-DI-DR", cases: "39" }, ai_in: ["review packet"], ai_out: ["review cards and positions"] }
    - { code: "[ORG]POD-DL", full_name: "DI Launch", type: "AI Pod", inner_units: ["[ORG]CELL-DIP", "[ORG]CELL-DCA", "[ORG]CELL-DLB", "[ORG]CELL-DRA", "[ORG]CELL-DIA"], top_cell: "[ORG]CELL-DIP", test: { id: "TEST-DI-DL", cases: "8, 56-61" }, ai_in: ["filed launch package", "problem reports by ID"], ai_out: ["implementation plan", "change impact", "learning paths", "readiness record", "go or no-go package", "problem records"] }
    - { code: "[ORG]POD-DO", full_name: "DI Operations", type: "AI Pod", inner_units: ["[ORG]CELL-DRK", "[ORG]CELL-DMB", "[ORG]CELL-DVT"], top_cell: "[ORG]CELL-DRK", test: { id: "TEST-DI-DO", cases: "9, 62-68, 72, 91" }, ai_in: ["the living design", "the logs", "the measures", "the value register"], ai_out: ["forum packs", "minutes drafts", "measures and dashboards", "value register version", "priority drafts"] }
    - { code: "[ORG]POD-DCI", full_name: "DI Continuous Improvement", type: "AI Pod", inner_units: ["[ORG]CELL-DPA", "[ORG]CELL-DCP", "[ORG]CELL-DTD", "[ORG]CELL-DTJ", "[ORG]CELL-DCM"], top_cell: "[ORG]CELL-DCP", test: { id: "TEST-DI-DCI", cases: "13, 14, 75-80, 82, 88, 90" }, ai_in: ["records of work through the projection", "the living design", "change notices"], ai_out: ["findings", "proposals", "trial records", "hand-over records"] }

• Accountability. Every Pod and Cell of this AIOC is accountable_to [ORG]CELL-DDL. The AIOC itself and the Delivery Lead are accountable_to the Cell carrying [ORG]HOAC-TM.
• Bots. Each AI Cell's bot (twenty-six) has its own identity card, its own credential, never_signs: true, and its memory sealed on a change of filler (Protocol §10, item 3). The credential IDs in cards/bots/ are placeholders.
• The Requesting Authority, the deciding positions, the Chief of Staff of [ORG]AIOC-SL and the Cells of [ORG]AIOC-PPD and [ORG]AIOC-TOM are not Cells of this AIOC.

Code checks (Naming Standard R15, R16 and §5), recorded on 15 and 18 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.

No code of this blueprint uses the suffix DI alone, so no part can be read as the AIOC itself.

Annex A. The launch package and the service records: their parts and field lists

Every part is a versioned, content-addressed object. Every element carries an ID, its provenance (stated, inferred, unresolved or assumed, as in TOM Annex B, carried), its basis (design element IDs and source atom IDs, at least one) and, after T4, its decision reference. JSON Schemas are made from these lists before the first run and may add nothing.

A.1 Design map (run record, summarised in the package). Mode A: one row per element in scope: element_id, part, state (used, returned, out of scope), return_id, reason, priority (as the release decided it, or none). The value case carried (New in v0.1.2): per entry of the TOM Release's value case, entry_id (VC-n), outcome_ref, measures (each with its baseline and target references, or unknown and not set, as the release states them) and elements, by reference, unchanged. Mode B: one row per element of the outside design: source_atom, read_as (process, step, decision, position, unit, forum, policy, measure), maps_to (an ID in this map's own structure), state (mapped, not mapped, out of scope), reason.

A.2 Gap report (package part). Per check: check_id (Annex F), tier, result (met, gap, unknown), evidence. Per gap: gap_id (GAP-n), check_id, tier (blocking, completeness), elements, consequence, evidence, proposed_fix, route (return with its ID; decision with its row; prepare with the S3 output that answers it), state.

A.3 Health check (package part; in the service, a record each quarter). Per item: item_id, heading (strategy, structure, processes, measures, rhythm, controls), question, result (met, not met, unknown), evidence. A summary per heading, counts only. In the service (New in v0.2.0): run (entry, or the quarter) and, per item, earlier (its results in the organisation's own earlier checks). Never a person, and never another organisation.

A.4 Procedures (package part; one per process). procedure_id; process_id; version; owner_position; steps[]: {step_id (the process step it traces to), position, instructions, form_or_template (IDs), record_left, done_when, worst_error, controls}; forms_and_templates[]: {id, name, fields (position placeholders only)}; citations.

A.5 Briefs (package part). Per brief: brief_id (BRF-n); kind (policy, pay structure, contract and offer templates, authority instruments, obligations register, control matrix, systems, data and suppliers); entity; jurisdiction (or unknown, then outline only); serves (design element IDs); what_it_must_achieve; known; open_questions; decisions_needed (never an amount); addressed_to (a position code from deciding_positions); mark ("Draft, not legal advice"); citations. Drafts (New in v0.2.0): per draft: draft_id (DRF-n), kind (as for a brief), template_ref (the template's source and the counsel position's decision that approved it), entity, jurisdiction, serves, text_ref, mark, addressed_to, reviewed_by (the counsel position's review reference; a pay range carries it too), citations. The cost draft: entity; jurisdiction; mark; lines[] {what, traces_to (a position, a process or a need), amount {value, source or decision} or not given}; totals; authority_check (its result against the authority matrix); addressed_to (the finance position).

A.6 Transition plan and go-live criteria (package part). Plan: waves[] {units, processes, order, priority (the highest decided priority of what the wave starts), departs_because (when it departs from the order of priority)}; cut_over[] {step, position, rollback}; parallel_run (decided or none); communication[] {to position, what, when}; consultation {required by (per counsel), before which notice}; review_chair (position). Criteria: per criterion: criterion_id (GLC-n), what_must_be_true, measure, evidence_source, threshold (decision reference), kind (blocking gaps closed, adoption, readiness, other); go_no_go_position.

A.7 Answer record (run record). question_id; asking_position; answer or I do not know; citations[] {element_id, version, span_sha256}; verifier {engine family, result}; sent_at.

A.8 Decision Package (package part). A plain summary; the elements for decision, each with its deciding position and row; the blocking gaps and their routes; the unknowns, the assumptions and the open returns, in plain words; the review findings and their choices.

The manifest. package_id (DIP- + SHA-256 of the manifest body); run_id; mode; design {PPD and TOM release IDs and manifest hashes, or the outside design's source reference}; parts[] {name, sha256}; input_packs[]; returns[] (return IDs with their end states); decided_at; final_status.

A.9 Implementation plan (service record; New in v0.2.0). plan_id; version; tasks[] {task_id (TSK-n), what, owner_position, depends_on (task IDs), date, traces_to (a wave, a cut-over step, a gap route or a criterion of the launch package), state (open, done, late, or dropped with its decision)}; milestones[] {id, date, date_changes[] {from, to, approved_by (the review chair's decision reference)}}; decided_by (decision reference).

A.10 Change impact and stakeholder register (service record). Per position: position_id, changes[] {kind (process, system, tool, role, reporting line, location), from, to, traces_to}. Stakeholder register, per entry: stakeholder (a position code, or an outside party by kind), affected_by, communication {what, when, by which position}. Briefings, per manager position: units, what_changes, when. Adoption measures, per critical process: process_id, measure ("completes critical work unaided"), source, threshold (decision reference).

A.11 Learning path (service record). path_id; position_id; version; rests_on (the job description and procedure versions); items[] {item_id, kind (competence, step, decision), traces_to, material, check {question, expected}}. There is no field for a result.

A.12 Readiness record, rehearsal scripts and defect log (service records). Readiness, per criterion: criterion_id, state (met, not met, unknown), evidence (source reference and the time it was read). Rehearsal script: script_id, process_id, position, steps[] {step_id, action, expected (the step's done_when)}. Defect: defect_id, script_id, step_id, what, severity, owner_position, state.

A.13 Go or no-go package and stabilisation record (service records). Package: the state of each criterion with its evidence; the open defects; the open blocking gaps with their decisions; the risks of going and of not going, in plain words; deciding_position; decision (the signature record's reference, type accept-irreversible-risk). Rollout health view: the plan, the criteria, the defects and the problems, by process and unit. Stabilisation: per stabilisation criterion, as for readiness; ended_by (decision reference).

A.14 Operating rhythm, logs and quarterly priorities (service records). Rhythm, per forum: forum_id (from the decided design), tier, cadence, chair, members, reviews; during launch, the weekly review and its chair. Action log: action_id, what, owner_position, date, from (a forum's meeting or a record), state. Risk and issue log: id, kind (risk, issue), what, owner_position, date, effect, state. Dependency register: id, from, to, owner_position, date, state. Decision log: decision_id, what, decided_by (position), date, forum, register_ref (the entry in the Operations Event Register, where one exists). Lessons: id, at (a phase close or a trial end), lesson. Quarterly priorities, per position and quarter: priority_id, position_id, quarter, what, tied_to (a measure or an initiative), inserted_by (the position's act).

A.15 Forum pack and minutes (service records). Pack: pack_id, forum_id, meeting, agenda (decided by the chair), pre_reads (record references by version), measures (dashboard references), log_extracts. Minutes: minutes_id, pack_id, text_sha256, preview_approved_by (the participant positions' acts), entered_at. Rating, per meeting: counts per point of the scale, rolled up into the forum's quarter where fewer than min_group positions rated it; never per participant.

A.16 Measures and dashboards (service records). Per measure: measure_id; process_id or unit_id; step_id or none; definition; unit; source; target (decision reference, or not set); level (process, step, unit); positions_count (at least min_group, or rolled_up_to the parent unit). Per dashboard figure: measure_id, value, read_at, source_ref. Adoption funnel, where switched on: per step, counts that entered and completed, aggregated.

A.17 Version register, acknowledgements and checklist runs (service records). Version register, per element: element_id, kind (process, procedure, policy, job description, forum), version, owner_position, approved_by, re_approval_due, status (verified, due), filed_ref. Acknowledgement: version_ref, position_id, acknowledged_at; the gateway checks the position's credential with a fresh live sign-in and keeps no reference to a person. Checklist run, per case: case_id, procedure_ref (its version), gates[] {gate, approved_by (a position's act at the gateway)}, trail, in_flight_rule (as applied).

A.18 Problem record and issue list (service records). problem_id (PRB-n), reported_by (position code), process_id, step_id, statement, evidence, cause, options[] {option, trade-offs}, recommendation, deciding_position, decision (reference), actions (action IDs). Issue list, per forum: problem_ids in order, each with its effect on the process and its measures.

A.19 Initiative and value register (service record). Per initiative: initiative_id (INI-n), what, owner_position, from (a value-case entry VC-n, a plan task or a proposal), baseline {value, source, read_at} or unknown, benefit_class, value_by_month[] {month, planned, realised, source}, gate (L0 to L5), gate_decisions (L2 and L5, by the finance position), attribution, warnings[] {rule, what, at}. Reports: value leaking between gates; the pipeline's coverage of the target.

A.20 Light design (mode C; run record, then package part). decision_list[] {decision, decider (position), limit or not given, state (provisional, or its decision reference)}; process_checklists[] {process, steps[] {step, position}, state}; who_does_what[] {position, steps}; weekly_rhythm {forum, chair, standing items}; solo_note (where one position holds every seat: the statement, and the compensating control offered as a draft); growth_triggers (decided); briefs_needed (texts with legal effect, for counsel). Every element carries its source atoms or its decision reference.

A.21 Conformance record and findings (service records). Conformance, per process and period: process_id, rate, deviations[] {type, step_id, count, dimension (step, case type, site, system), accepted (its entry on the accepted-deviation list, or none)}. Accepted-deviation list: deviation, decided_by (the process owner position), times_accepted. Finding: finding_id (FND-n), kind (bottleneck, overload, rework, control gap), process_id, steps, unit (where at unit level), evidence, positions_count (at least min_group), method_ref (a pinned reference model used as a method, or none).

A.22 Proposal (service record). proposal_id (PRP-n), kind (process, position, job description, forum, new process), trigger (a finding, a deviation, a problem, a change notice or the reassessment; by reference), evidence, expected_effect, risk, to (the deciding position, or a return ID), as_trial (yes or no), decision, version_made (the living design version, once decided).

A.23 Trial record (service record). trial_id (TRL-n), proposal_id, process_id, change, expected_result, guardrail_measure, duration, rollback_trigger, default, decided_by (before the start), baseline_points, method (run chart, or plan-do-study-act, labelled "judgement, not proof"), side_by_side (where two teams or sites exist), judge {Cell, engine family}, judgement, outcome (adopt, adjust, roll back; decided by the process owner position), lessons.

A.24 Hand-over and drill records (service records). Each quarter: only_di_can_produce[] {output, hand-over plan, learning path reference}. Drill: drill_id, period, export_ref, di_stopped {from, to}, what_ran, what_failed, decided_by (the Cell carrying [ORG]HOAC-TM), result (passed, failed).

A.25 Export manifest. export_id (DIX- + SHA-256 of the manifest body); records[] {kind, id, version, sha256, format}; traces (every artefact to its design element, deciding position and decision); reimport_check {instance, result}.

Annex B. Returns

Returns follow the Library's design return contract, library/contracts/design-return.schema.json of 49GAION-protocol (49GAION Standard §3.1, item 6), with the prefix DIR. This AIOC keeps no copy of the contract.

Rules.

1. A return goes to the stage that made the release, directly through the gateway, and its copy is filed into Source Lifecycle with the same hash.
2. A return never changes the release.
3. It is answered by a new decided release, or by a decision of the Requesting Authority; each answer that does not end it opens the next round. Past return_round_deadline or return_rounds_max, it goes to the Requesting Authority, who answers it or sets it aside on a stated basis (known defect or decided assumption).
4. In mode B there is no release to return to: a defect of the outside design is a gap (§5.3).
5. Answers. A return answer arrives on the connection of the stage that made the release and is recorded on the return. An answer by release makes a new pack version through the release check and re-opens only the work that cites a changed element. A return set aside by decision lets its touched elements go forward on the stated basis, each marked known defect or decided assumption with the decision reference, and listed in the Decision Package in plain words. (v0.1.1.)

Done when. The return validates; it is sent and filed with one hash; its touched elements show held: return open; it ends in a status other than open.

Annex C. Run states and gates

C.1 Run states. As §5.0. Endings other than a filed package: closed: not admitted (T0 failed, each failed condition named); closed: non-response; closed: rejected; closed: withdrawn by the Requesting Authority. Flags on any state, each with its age: waiting; waiting: ruling; held: return open (on the touched elements only); held: material finding; held: connection revoked; held: no reviewers; held: review budget; stopped. No flag releases the run slot; every ending releases it. The service (New in v0.2.0): accompanying → stabilised; operating and improving are standing. It ends only as closed: by the Requesting Authority. Its flags: those above, and waiting: decision (a row waits for its position); held: Annex H not met (process watching only); stopped: drill (while the drill runs); rolled back (on a change, with its reference).

C.2 The gates. T0 to T5 as in §5.0. A gate passes only on its settled review (§5.9) and its done-test. T0 has these conditions: (a) the run request carries references only; (b) its mode is in modes_enabled; (c) mode A: the release check passes for the PPD Release and the TOM Release it names; mode B: the outside design is a source held in Source Lifecycle; (d) the connections are signed and in scope; (e) the engine register holds eligible engines for the highest confidentiality level in scope, of two families; (f) requesting_authority_cell and deciding_positions are set; (g) RP0 is settled; (h) mode C only: modes_enabled holds C, after H-21. T1C and T6 to T10 are as §5.0; each passes only on its settled review and its done-test.

Annex D. What this AIOC never does

1. Change, merge, split or drop an element of a design release, or rewrite an outside design.
2. Decide anything for the organisation, the go or no-go included, or take silence as a decision.
3. Give legal, tax, employment or pay advice, write a final legal text, or state an amount that no source or decision gives.
4. Ask any person anything about the organisation, or send a request that names a person.
5. Name a person, read who occupies a position, or prepare a named offer.
6. Rank, score or watch a single position, infer emotion, or show a measure for one.
7. Read records of the organisation's work outside the projection, or before Annex H holds.
8. Insert a draft into a live record, log or plan; apply a change outside a class signed at level 2 (Annex G).
9. Answer a question from outside the decided design, or send an answer or draft whose citation failed verification.
10. Mark a go-live criterion met on its own report.
11. Grade its own work: no Cell reviews its own output, and the Chief of Staff rules on nothing.
12. Act on a type of the Human Floor signature list, at any level.
13. Change a value case, or set a baseline, a target or a priority of its own (TOM blueprint v0.6.0, Annex H.6, H.7).
14. Keep, read or report a learner's check result.
15. Show a measure, finding or view for a single position, or one that rests on fewer than min_group positions.
16. Judge a trial it proposed or designed, or judge the drill.
17. Issue a statement or transition notice on the organisation's behalf to staff, authorities or customers; its own notices to positions about records are not such statements.
18. Propose a change to its own ladder, tests or measures of success.

Annex E. What is carried from the Target Operating Model blueprint

This AIOC carries these rules from the blueprint of [ORG]AIOC-TOM v0.6.0 (its writing repository, <org>aioc-tom), by section, not by copy, as [ORG]AIOC-PPD v0.5.0 carries them (its Annex E), the version of PPD that carries TOM v0.6.0. A change there reaches this AIOC only when this annex pins the new version.

Annex F. The gap checks

Version 1. Each check names its tier and whether code decides it. In mode B, a check that needs an element not mapped reads unknown.

Annex G. The permission ladder

New in v0.2.0. As the product requirements set it (PRD-[ORG]AIOC-DI-001 v0.4, the permission ladder), read with the Standard's Human Floor signature list.

Rules.

1. Per class. The owner position sets each class's level; every class starts at level 1, and a read-only class at level 0.
2. Moving up. A class moves up one level only by the owner position's signed decision and a fixed-test score at or above its recorded threshold (§13, H-07).
3. Level 2 is a signed class. The owner position signs the class once as sign-standing-action-class, for reversible actions only (§13, H-18). It never covers any type of the Human Floor signature list.
4. Dropping back. Any error, complaint or change of engine drops the class to level 1 at once; the drop is recorded and reported to the owner position.
5. Never. A trial that changes a position or a job description never runs at level 2 (§5.23, rule 6).
6. Who approves. A process owner position decides changes inside its process, within its limits; a change that crosses processes or touches a position goes to the position the authority matrix names.
7. Enforcement. Inside an [ORG]AION, the tool gateway enforces the ladder and the stop. Standing alone, this AIOC's own gateway fails closed, with one negative case for every Human Floor type passed before each release.
8. Over-trust. Time-to-approve and approve-all rates are logged by class, and rubber-stamping is flagged to the owner position (NFR-03); neither is logged or shown by position.

Default classes.

Annex H. Records of work: the projection and its conditions

New in v0.2.0 (FR-19, FR-39, FR-44; NFR-04, NFR-05; Protocol §20, item 7).

1. Off by default. process_watching stays off until every condition of rule 2 is recorded (§13, H-17). The rest of this AIOC runs without it.
2. Before it is switched on:
   • the data-protection position records an impact assessment for the records in scope, and a lawful basis other than staff consent;
   • workers or their representatives are informed, and consulted where the law requires it, as the counsel position confirms for each jurisdiction;
   • the projection is built and owned by the Cell carrying [ORG]HOAC-TM, and its connection is signed as connect-external-port;
   • the negative cases of rule 7 pass.
3. The projection removes who did the work. It passes records by process, step, case type, site and system. Every field that identifies a person or the occupant of a position is removed: author, assignee, approver, sender, user, device and the like. A record that cannot be cleared is refused whole, and this AIOC keeps nothing of it.
4. Kept briefly. Records of work are held by reference, and only as long as the cycle that uses them. Conformance records and findings keep counts, never the records.
5. No figure for one position. Every measure, finding and view is at process, step or unit level. A figure that would rest on fewer than min_group positions rolls up to the parent unit. Nothing is ranked, scored or allocated to any person, and no emotion is inferred.
6. Not a high-risk employment system. The provider documents why this AIOC is not one, or meets the duties of one where a law makes it so (NFR-05); counsel confirms for each jurisdiction.
7. Negative cases, before use: a record with a person field is refused; a question about one position over time is refused and recorded to the data-protection position; a figure on fewer than min_group positions rolls up; a stop reaches the projection's connection at once.
8. Switched off at once by a stop, by the data-protection position, or by revocation of the connection. Work in flight is held, never closed.
9. The same rules govern the adoption funnels of guidance at the point of work (§5.18, rule 5).

Powered by 49GAION