# ── Blueprint metadata (machine-readable; the panel generator and the back-office builder read this block) ──
blueprint:
  aioc: "[ORG]AIOC-PPD"
  parent: "[ORG]AIOC-CH"                  # example code of the Charter; each organisation writes its own Charter's code (Standard §1.7, item 13)
  full_name: "Process and Position Design"
  organisation: "<organisation>"          # filled in each organisation's own copy
  type: "specialised"
  org_aion: "[ORG]AION"
  blueprint_version: "v0.5.3"
  status: "draft"
  template:
    name: "49GAION AIOC Blueprint Template"
    version: "v1.5.0, with the unreleased v1.6.0 additions on main"
    source: "github.com/49g-holding/49GAION-aioc, template/AIOC-BLUEPRINT-TEMPLATE.md @ e89ed1d"
  mother:
    name: "49GAION Process and Position Design"
    version: "part card v2 (DRAFT)"
    source: "github.com/49g-holding/49GAION-protocol, library/cards/process-and-position-design.part-card.json and Protocol §17, items 1 to 11 (pull requests #33 and #36); Standard §3.1, items 3 and 6 (49GAION pull requests #66 and #68; DR-0014, DR-0018). This text is its mother blueprint"
  writing_repository: "<org>aioc-ppd"
  code_project: "<org>aioc-ppd, on the organisation's code platform"
  panel_register_id: "none yet"
  capabilities:
    standard: ["Chief of Staff", "Office", "Input socket", "Panel"]
    functional: ["Release Intake and Returns", "Needs Requests", "Process Architecture", "Process Writing", "Position Shaping", "Structure", "Workload", "Operational Walkthrough", "Independent Review", "Decision Package and Release", "Returns from Delivery and Implementation"]

Blueprint · [ORG]AIOC-PPD · Process and Position Design · v0.5.3

Draft, 15 October 2026; v0.4.0, 16 October 2026, connects the chain on both sides (decisions/DR-0004): every return to the Target Operating Model now follows the Library's design return contract and always ends; each decided release is announced to Delivery and Implementation directly, and its returns come back here and end in the same way. v0.5.0, 16 October 2026, reads what the TOM release now also states (decisions/DR-0005; TOM blueprint v0.6.0, Annex H): the objectives cascade starts from its strategy frame; the critical value streams are designed first; work delivered outside becomes a hand-off, never an in-house process; today's activity profile is read for workload; priority orders the work. v0.5.1, 19 October 2026: the Chief of Staff takes its COS code [ORG]CELL-COSPPD (decisions/DR-0006). Written by [ORG]AIOC-OCO on the directions recorded in decisions/DR-0001 to decisions/DR-0005. This is the first blueprint of Process and Position Design, written for any organisation as the mother text of the Library part 49GAION Process and Position Design (Protocol §17). Every rule rests on a 49GAION text, on the blueprint of [ORG]AIOC-TOM (cited by section and version), or is new here and marked New. Nothing here has run. Every fixed test reads NOT_RUN.

Process and Position Design in one page

Process and Position Design (PPD) takes an organisation's decided target operating model and designs how its work runs and the positions that carry it. It is the stage after the Target Operating Model (TOM), and a part of its own.

What goes in

1. The decided TOM release, handed over directly by [ORG]AIOC-TOM, by reference and hash. PPD reads its role register first, then its value streams (which are critical), capabilities (how each is delivered), decision domains and hand-offs, and its strategy on one page, outside parties' journeys, priorities and how the work runs today.
2. The organisation's other sources, only from Source Lifecycle: the processes, procedures, policies, volumes and times it already has.
3. Answers to what the release and the sources do not say. PPD never asks a person. It asks the Chief of Staff of Source Lifecycle, who gets the answer approved and recorded.

The link with TOM goes both ways. PPD never changes the TOM release. When it finds a defect, it sends a return straight back to TOM, naming the part and the reason: cannot use, missing what; contradiction found; assumption invalid; request kind unsupported. The elements the return touches wait; the rest of the work goes on. TOM answers with a new decided release, or the organisation answers by decision, and the two go back and forth in rounds, each with a deadline. No return is left open: it ends answered, or set aside by decision and carried forward as a known defect or a decided assumption, so that PPD delivers.

The link with Delivery and Implementation works the same way. PPD tells Delivery and Implementation (DI) of each decided release at once. DI sends back what it cannot use, and PPD carries each return to an end in the same way.

What PPD does, in ten stages, processes first

1. Admit: check the request, the release and the connections.
2. Read the release: account for every role, phase, capability, decision domain and hand-off, or return it.
3. Architecture: the processes under each part of the model, in three levels, each with one owner.
4. Critical processes: choose the processes that cross parts or lie on a critical value stream, and design them first, in the order of their priority.
5. Write each process: purpose, trigger, steps in role lanes, what goes in and out of each step, the decision at each step and who decides it, exceptions and escalation, measures, volumes and step times. Each step also says when it is done, its worst error and whether it can be undone, what kind of act it is, where its input comes from and how far it is trusted, how confidential it is, and its risk, control and record.
6. Shape the positions: group the steps and decisions of each role into positions, and generate each job description from what the position holds. No job description is written by hand.
7. Structure: group the positions into units (teams, sections, departments), each with its head position and a generated charter; reporting lines, spans and layers, standing forums with charters, and the crosswalk from the organisation as it is today.
8. Workload: the work each position carries, from the volumes and step times of its processes, beside how the work runs today where the release records it.
9. Walk: test the design against realistic situations.
10. Decide and release: the organisation decides each element; the release is frozen, filed in Source Lifecycle, and Delivery and Implementation is told at once.

Each stage has one input, one output and one test that says when it is done. Critical processes are written twice, separately, by two authors of two engine families. Every stage is checked by three or more other engines before the next starts. A person, the PPD Design Lead, rules on what they still dispute.

What comes out: the PPD Release

• the process architecture and the process book;
• the decision-rights register and the authority matrix;
• the policy register;
• the controls catalogue and the segregation-of-duties check;
• the position register, with a job description and a competence profile for every position;
• the objectives cascade, from the goals and critical numbers of the decided strategy frame down to each position's measures;
• the unit register, with a generated charter for each unit;
• organisation charts, standing forums with their charters and tiers, and the review calendar;
• structure scenarios side by side, when the organisation asks for them;
• the workload of each position, its peak-load check, and the end-to-end time of each process and value stream;
• the crosswalk from today's organisation;
• the walkthrough report and the quality checks;
• the Decision Package.

Who decides. The organisation's Requesting Authority decides each element: accept, correct or reject. Silence decides nothing. PPD designs positions only (Standard §1.1, item 9). It makes no choice of what fills a position; that belongs to a later stage.

Where this blueprint stands. Fifth draft (v0.5.0 supersedes v0.4.0; v0.5.1 gives the Chief of Staff its COS code; §14). The stages, their inputs, outputs and done-tests are set (§5.0). The engine rules it shares with [ORG]AIOC-TOM (the Review Panel rule, two authors, labels, decision rules, and the receiving end of returns) are carried from the TOM blueprint v0.6.0 by section, not copied (§5.9; Annex E). The decisions only a human seat can take are listed once, in §13.

0. Identity and lineage

Lineage. The stage after the operating model was first proposed as "positions and job descriptions". A study of how leading organisation-design practices run this stage, made on 15 October 2026, found that every one of them designs processes and decision rights together with the roles below the operating model, and warns that a structure drawn without them fails. The governing seat then directed a separate AIOC, linked directly to the TOM, never merged with it or with the stage after it (decisions/DR-0001; 49GAION/DR-0014). The study is summarised in docs/HISTORY.md. No earlier code or result is carried here.

1. Card (49GAION Operating Protocol §3)

card:
  unit_kind: "AIOC"
  code: "[ORG]AIOC-PPD"
  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-PDL", "[ORG]CELL-COSPPD", "[ORG]POD-PRI", "[ORG]POD-PA", "[ORG]POD-PPW", "[ORG]POD-PPS", "[ORG]POD-PS", "[ORG]POD-PW", "[ORG]POD-PR"]
  type: "specialised"
  org_aion: "[ORG]AION"
  card_version: "v0.5.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 one TOM Release reference and, optionally, the children in scope"
      acceptance_test: "TEST-PPD v3, cases 1, 23"
      decision_needed: false
    - kind: "release notice"              # from [ORG]AIOC-TOM, directly, through the tool gateway
      format: "release notice of [ORG]AIOC-TOM (its contracts/release-notice.schema.json, urn:49gaion:library:tom:release-notice:v0.5): the TOM Release ID, version and manifest hash, its filed reference, and the returns it answers"
      acceptance_test: "TEST-PPD v3, cases 2, 3, 24, 25"
      decision_needed: false
    - kind: "return answer"               # from [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, pinned in contracts/PINS.json)"
      acceptance_test: "TEST-PPD v3, cases 98, 99, 104"
      decision_needed: false
    - kind: "return"                      # from [ORG]AIOC-DI, directly, on elements of a PPD Release (§5.11)
      format: "design return (49GAION-protocol library/contracts/design-return.schema.json, pinned in contracts/PINS.json)"
      acceptance_test: "TEST-PPD v3, cases 101-103"
      decision_needed: true
    - kind: "source reference"            # 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-PPD v3, cases 4, 30"
      decision_needed: false
    - kind: "needs answer"                # the output of a needs request sub-item
      format: "needs answer, by reference only"
      acceptance_test: "TEST-PPD v3, cases 8, 33"
      decision_needed: false
    - kind: "needs status"                # accepted, returned or asked, from [ORG]AIOC-SL
      format: "needs status"
      acceptance_test: "TEST-PPD v3, case 31"
      decision_needed: false
  delivers:
    - kind: "return"                      # to [ORG]AIOC-TOM, directly; also filed into [ORG]AIOC-SL as a design report
      format: "design return (49GAION-protocol library/contracts/design-return.schema.json, pinned in contracts/PINS.json), prefix PPDR"
      usual_receivers: ["[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: "PPD Release filing"
      format: "PPD Release manifest and its parts (Annex A), filed as a source of origin kind process and position design; filing receipt"
      usual_receivers: ["[ORG]AIOC-SL"]
    - kind: "release notice"              # to the next stage, by reference (Protocol §20, item 9)
      format: "release notice (contracts/release-notice.schema.json): the PPD Release ID, version and manifest hash, the TOM Release it rests on, its filed reference, and the returns it answers; never release text"
      usual_receivers: ["[ORG]AIOC-DI"]
    - kind: "return answer"               # the end of a return from [ORG]AIOC-DI, or its next round (§5.11)
      format: "the return at its next version (49GAION-protocol library/contracts/design-return.schema.json): its status, the answering release or decision reference, and for a return set aside, its carried_forward_on"
      usual_receivers: ["[ORG]AIOC-DI"]
  anatomy:
    panel: { health: { tests: true, metrics: ["stuck", "returned", "late", "run state", "returns open", "returns answered", "returns from DI open", "returns past deadline", "return round", "needs open", "needs past deadline", "processes by state", "positions by state", "assumptions open", "reviews held", "review budget used"] } }
    back_office: { converses_with_humans: false, hosts: ["Chief of Staff", "Office"], protocol_traffic: true }
    definition: { location: "<org>aioc-ppd, blueprint/PPD-BLUEPRINT.md", version: "v0.5.3" }
    delivery: { rollback: "one-click" }
    connectors:
      - { role: "operating model source", connector: "[ORG]AIOC-TOM release port", access_managed_in: "panel" }   # the grant is signed at the tool gateway as connect-external-port (Protocol §17, item 8)
      - { role: "source of record", connector: "[ORG]AIOC-SL output socket", access_managed_in: "panel" }      # as above (Protocol §13, item 5)
      - { role: "next design stage", connector: "[ORG]AIOC-DI input port: release notices out, returns in", access_managed_in: "panel" }   # signed by the [ORG]HOAC-ACS position over this AIOC (Protocol §20, item 9; H-16)
    gateway: { metering_id: "<per-AIOC metering id>" }
  full_name: "Process and Position Design"
  version: "0.5.3"
  lineage: { id: "[ORG]AIOC-PPD", version: "0.5.2", relation: "original" }
  lifecycle_state: "designed"
  blueprint_version: "v0.5.3"
  template_version: "v1.5.0"
  accountable_to: "[ORG]CELL-TMS"         # example code of the Cell carrying [ORG]HOAC-TM (Naming Standard R15); never a Cell inside this AIOC
  top_cell: "[ORG]CELL-PDL"
  hoac: "[ORG]HOAC-ACS"
  label_holder: "[ORG]CELL-PDL"
  fixed_test: { id: "TEST-PPD", version: "v3", owner: "[ORG]CELL-TMS" }
  skills:
    - { id: "ppd-release-intake", name: "Reading a decided operating model, and returning its defects", tags: ["design", "intake"] }
    - { id: "ppd-process-design", name: "Process architecture and process design", tags: ["design"] }
    - { id: "ppd-position-design", name: "Positions and generated job descriptions", tags: ["design"] }
    - { id: "ppd-structure", name: "Reporting lines, forums and crosswalk", tags: ["design"] }
    - { id: "ppd-walkthrough", name: "Operational walkthrough of processes and positions", tags: ["assurance"] }
    - { id: "ppd-returns", name: "Returns both ways, each carried to an end", tags: ["coordination"] }
  ports:
    - { unit: "[ORG]AIOC-PPD", port: "ai-in", direction: "input", type: "AI", identification: "technical-key", accepted_content: ["release notice", "return answer", "return", "source reference", "needs answer", "needs status"], authority_limit: "read only, within the scopes signed for the TOM and Source Lifecycle connections; returns only on the connection signed with [ORG]AIOC-DI", audit_trail: "unit register; the serve logs of [ORG]AIOC-TOM and [ORG]AIOC-SL; the Work Item record", required_tests: ["TEST-PPD v3"], enforcement: "shared-gateway-outside-unit" }
    - { unit: "[ORG]AIOC-PPD", port: "ai-out", direction: "output", type: "AI", identification: "technical-key", accepted_content: ["return", "needs request", "missing report", "needs status", "PPD Release filing", "release notice", "return answer"], authority_limit: "returns, requests, reports, filings, notices and answers only, by reference; files only its own releases and design reports; never an instruction to a person", audit_trail: "Work Item record and the unit register", required_tests: ["TEST-PPD v3"], enforcement: "shared-gateway-outside-unit" }
    - { unit: "[ORG]AIOC-PPD", 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)", "run control and configuration from the PPD Design Lead (never a source)"], authority_limit: "the signer's authority_scope; nothing received here is a source", audit_trail: "Office record", required_tests: ["TEST-PPD v3"], enforcement: "shared-gateway-outside-unit" }
    - { unit: "[ORG]AIOC-PPD", port: "hu-out", direction: "output", type: "HU", identification: "live-human-sign-in-at-gateway", accepted_content: ["run brief to the PPD Design Lead", "ruling sheets to the PPD Design Lead", "release notice to the Requesting Authority's Cell"], authority_limit: "information only; never a question about the organisation", audit_trail: "Office record", required_tests: ["TEST-PPD v3"], enforcement: "shared-gateway-outside-unit" }
    - { unit: "[ORG]AIOC-PPD", port: "stop", direction: "input", type: "HU", identification: "live-human-sign-in-at-gateway", accepted_content: ["stop"], authority_limit: "stop only", audit_trail: "unit register", required_tests: ["TEST-PPD v3"], 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>" }
    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>" }
    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>" }
    span_range: { value: "<set by the organisation>", set_by: "<Cell carrying [ORG]HOAC-TM>", date: "<date>", version: "<vN>" }
    layers_max: { value: "<set by the organisation>", set_by: "<Cell carrying [ORG]HOAC-TM>", date: "<date>", version: "<vN>" }
    workload_period: { value: "<set by the organisation>", set_by: "<position>", date: "<date>", version: "<vN>" }
    return_round_deadline: { value: "<set by the organisation>", set_by: "<Cell carrying [ORG]HOAC-TM>", date: "<date>", version: "<vN>" }
    return_rounds_max: { value: "<set by the organisation>", set_by: "<Cell carrying [ORG]HOAC-TM>", date: "<date>", version: "<vN>" }

Joining the protocol. This AIOC joins only after every input and output on this card passes fixed samples (the joining test, Protocol §11, item 1; Standard §3.2, item 4). It also needs [ORG]AIOC-TOM to send release notices and answer returns (made in the TOM blueprint v0.5.0), and Source Lifecycle to accept filings of origin kind process and position design. Its link with [ORG]AIOC-DI is not a condition of joining: without it, this AIOC stands alone. Until then its lifecycle_state stays designed and no Work Item is routed to it. The cards of its Pods and Cells are set in §17 and generated into cards/.

2. Organisation table and placement

2.1 Organisation table

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, item 9; §5.2, Position Principle).

2.2 Placement

• Where it sits. A top-level AIOC under the Charter, beside [ORG]AIOC-SL and [ORG]AIOC-TOM. It is the stage after the target operating model (Protocol §17, item 1).
• Its role. It turns a decided target operating model into the organisation's processes and the positions that carry them, decided by the organisation's own authority.
• Scope.
  • It does: read the decided TOM release, role register first; return every defect it finds to [ORG]AIOC-TOM; ask, through Source Lifecycle, for what the release and the sources lack; lay out the process architecture; choose the critical processes; write each process; shape positions from the steps and decisions they hold; generate job descriptions, the decision-rights register and the authority matrix; draw reporting lines and forums; map today's organisation to the target; compute workload; walk the design through situations; have every stage checked under the Review Panel rule; prepare the decision; release, file and hand over.
  • It does not: change the TOM release; ask any person anything about the organisation; name a person; read who occupies a position; choose what fills a position; set pay (H-07); write the full text of a policy; invent a measure, a volume, a time or a limit; decide anything for the organisation.
• Shapes it serves. Any shape the TOM release covers: one person's work, a single entity, a group of entities, or a group with independent institutions inside it. Where the release covers several entities, processes that cross entities follow the release's hand-offs register and counterparty register.
• Boundaries with other AIOCs.
  • [ORG]AIOC-TOM designs the operating model. This AIOC reads its decided release and returns defects; it never redesigns the model. A return is a request to TOM, never a change (§5.1; Annex B).
  • [ORG]AIOC-SL holds every source and every contact with a person. This AIOC holds only references and its own design records. It files its releases and its returns there.
  • [ORG]AIOC-DI, the next stage, is told of each decided PPD Release directly (§5.10), reads it from Source Lifecycle by reference, and returns its defects to this AIOC under the same contract; each ends by §5.11.
  • [ORG]AIOC-OCO installs, fixes and upgrades this AIOC; it never grades it (Standard §2.3, item 9).
• Overlap. None known. Where an organisation already holds process maps or job descriptions, they are sources, read through Source Lifecycle and mapped in the crosswalk (§5.6).

3. Positions

• Every human position is a HOAC position. This AIOC has one, the PPD Design Lead. The organisation may add more in this AIOC's own design (§17).
• No natural person (Standard §1.1, item 9). Every human position this AIOC deals with, its own and the organisation's, is a HOAC position. It addresses positions only, through their HU ports.
• The Requesting Authority is not a position of this AIOC (§2.1). It decides the design; 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).
• Job descriptions, the decision-rights register, the authority matrix and the organisation charts are made by code steps of the Chief of Staff, never by a Cell (§5.5, §5.6). Code is a tool, never a seat.

4. Standard capabilities

Defaults are in docs/STANDARD-CAPABILITIES.md of 49GAION-aioc at e89ed1d (v1.5.0, with the v1.6.0 additions). The differences are listed in §11.

4.1 Office

Definition

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

Process (SOP)

Default.

Role card

None while the form is a single Chief of Staff.

Fixed test

TEST-PPD-COSPPD v3 (TEST-PPD v3, case 73) · 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-TOM, an accepted return included; needs requests, Missing Reports and filings to [ORG]AIOC-SL; the release notice to [ORG]AIOC-DI and the answers to its returns. The six external ports sit on its card (§17).
• No question to a person. It never asks any person anything about the organisation. Every question for the organisation goes to the Chief of Staff of [ORG]AIOC-SL as a needs request (§5.2). Its only human contact is its own HOAC position, the PPD Design Lead, about the run.
• An orchestrator that never judges itself. It runs the gates of each run (Annex C), dispatches the Cells, locks outputs, runs the code steps, draws the Review Panel and writes the run record. It never rules on a finding, never dismisses or downgrades one, and never lowers a review (TOM blueprint v0.5.0, §5.8, carried).

Process (SOP)

Default, plus:

1. Admission (S0). On a run request: open the run record; check that the request carries references only; receive or fetch the release notice; 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. One run per organisation. A second run in parallel needs the Design Lead's approval, recorded in the run record → run slot (evidence: run record).
3. Returns. Collect the return drafts of the Pods; have each reviewed at its review point; send each to [ORG]AIOC-TOM under the Library's design return contract and file it into [ORG]AIOC-SL as a design report, with the same hash; mark the elements it touches held: return open; on TOM's answer, re-open them, or carry them forward on the basis a set-aside decision states (Annex B.1) → return sent; return ended (evidence: the return at each version, and its filing receipt).
4. Passes. Batch the Pods' needs candidates into passes of at most rows_per_pass rows, one decision per row; send each pass with its Missing Report → pass sent (evidence: Work Item IDs in the needs log).
5. Waiting. Overdue requests and returns follow the waiting deadlines and escalation (Protocol §4.6, item 1). Past non_response_passes, the run stops as non-response, and every element resting on a missing fact goes to decision as an assumption → ageing record (evidence: the needs log).
6. Answers. Hand each needs answer and each new release notice to the Input socket, which makes a new pack version; re-open only the work that cites what changed → re-opened items (evidence: the pack's increment).
7. Code steps. Run the code steps of §5.5 and §5.6 (job descriptions, decision-rights register, authority matrix, charts) and of §5.7 (workload) → generated parts (evidence: the step's output hash, re-generated byte-identical).
8. Stops and revocation. A stop takes effect at the gateway on every part; the Chief of Staff is itself stopped. A revoked or narrowed connection holds the run as held: connection revoked; no restart is needed when a new connection is signed → held run (evidence: unit register).
9. Returns from DI. Run §5.11 for every return received from [ORG]AIOC-DI, whether or not a run is open → each return carried to its end (evidence: the returns log).

Role card

Fixed test

TEST-PPD-COSPPD v3 · 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. Two kinds of input. The release: the decided TOM Release, by manifest and parts, each by hash, from the release notice. The sources: the organisation's other sources, by reference from Source Lifecycle's output socket, cut into atoms and labelled once (TOM Annex B, carried).
2. The release is read, never atomised as a source. Its elements keep their own IDs (ROLE-n, HO-n, CPR-n, CHILD-… and the ledger entry 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; its hash equals the copy filed in Source Lifecycle; and its role register re-compiles from its parts (TOM Annex E.17, rule 6). Otherwise nothing of it is used, and a return goes back with the failed condition (Annex B).
4. A new release from [ORG]AIOC-TOM 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; the words around them are not admitted.
6. The pack's ID is PPDI- followed by the SHA-256 of its body.

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-COSPPD) through the socket's code steps.

Fixed test

TEST-PPD v3, cases 2, 3, 4, 23, 24, 25, 30, 33 · 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 TOM release in use and any newer one; every return, both ways, with its round, the deadline of that round, its state and its age (a return past its deadline in red, here and on the other stage's Panel); every needs request; each gate with its result; per review, its point, verdict and findings; the assumptions waiting for decision; the decision state of each element.

Process (SOP)

Default.

Role card

Default.

Fixed test

Default Panel test · result NOT_RUN

5. Functional capabilities

Ten stages (§5.0) are performed by the Input socket (§4.3: S0) and these capabilities: Release Intake and Returns (S1); Process Architecture (S2, S3); Process Writing (S4); Position Shaping (S5); Structure (S6); Workload (S7); Operational Walkthrough (S8); Decision Package and Release (S9). Needs Requests (§5.2) is a service every stage uses. Returns from Delivery and Implementation (§5.11) runs outside the runs, on each return received. Independent Review (§5.9) is the rule that closes every stage. Each capability is written in the four-part form (Annex A of the template), with one added row, Done when, which names its gate. Each step reads: position: action → output (evidence). Rules that apply to every capability are in Annex A (release parts and field lists), Annex B (returns), Annex C (run states and gates), Annex D (what this AIOC never does) and Annex E (what is carried from the TOM blueprint).

One word per meaning.

• Release, unqualified, is the TOM Release this run reads. PPD Release is this AIOC's output.
• Role: a role-type of the TOM release's role register (ROLE-n). Position: a position this AIOC designs (POS-n). A role may give rise to several positions; a position belongs to exactly one role.
• Process (PRC-n): a level-3 entry of the process architecture. Step (STP-n): one step of a process, in one role lane. Decision (DEC-n): a decision taken at a step.
• Return (PPDR-n): this AIOC's notice to [ORG]AIOC-TOM about its release (Annex B.1). A return from [ORG]AIOC-DI about a PPD Release carries DI's prefix (DIR-n; Annex B.2; §5.11).
• Assumption: a value no source gives (a volume, a time, a limit, a measure), marked as such and put to decision. It is never a fact.

5.0 The stages: input, output, done-test

Not stages: services and rules used by every stage.

Run states. admitting (S0) → reading (S1) → architecting (S2) → choosing (S3) → writing (S4) → shaping (S5) → structuring (S6) → loading (S7) → walking (S8) → deciding (S9) → released → filed. Endings, flags and holds: Annex C.1.

5.1 Release Intake and Returns

Definition

Process (SOP)

1. Release Reader: read the role register entry by entry, then the other parts of the children in scope → release-reading record, draft (evidence: one row per element).
2. Release Reader: for each element that cannot be used as decided, draft a return with its kind, its elements and its evidence → return draft (evidence: the draft, citing the elements and atoms).
3. Chief of Staff: lock the record and the drafts; run review point RP1 (§5.9) → settled review (evidence: the RP1 record).
4. Chief of Staff: send each return to [ORG]AIOC-TOM, file it into [ORG]AIOC-SL, mark the touched elements held → sent return (evidence: the Work Item and the filing receipt, with one hash).
5. Chief of Staff: on a new release notice, have the Input socket make a new pack version, re-open what cites a changed element, and close each answered return → re-opened items; closed returns (evidence: the pack's increment; the return's status).

Role card

Fixed test

TEST-PPD-PRI v3 and TEST-PPD-PRR v3 · 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 organisation's current process documents and procedures; volumes per period; step times; decision limits (for example spending thresholds); measures already in use; the time available per position per period; the policies a process applies. Each request names the process, step or decision it is for, and the unit of a figure. 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, and its sub-item is done only when the Input socket's acceptance test passes.

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-PPD v3, cases 8, 31, 32, 33, 34 · result NOT_RUN

5.3 Process Architecture

Definition

Process (SOP)

1. Process Architect: draft the architecture from the release-reading record and the pack → architecture draft (evidence: one row per process, with its trace).
2. Chief of Staff: run RP2, then send the architecture rows to the Requesting Authority → decided architecture (evidence: decision references).
3. Process Architect: propose the critical processes and their order → choice draft (evidence: reasons per process).
4. Chief of Staff: run RP3, then send the choice for decision → decided choice (evidence: decision references).

Role card

Fixed test

TEST-PPD-PA v3 and TEST-PPD-PPA v3 · result NOT_RUN

5.4 Process Writing

Definition

Process (SOP)

1. First Process Author (and, for a critical process, Second Process Author, blind): write the process record → locked draft(s) (evidence: draft hashes).
2. Chief of Staff: for a critical process, run the compare code step → difference register (evidence: the register).
3. Process Reconciler: reconcile into one record, disposing every material difference with its reason → reconciled record (evidence: the dispositions).
4. Chief of Staff: run the process checks and the modelling conventions by code (rules 2 to 4, 6, 7, 11 to 16), and compute the end-to-end time, then RP4 → settled review (evidence: the RP4 record; the convention results).
5. Chief of Staff: compile the policy register and the controls catalogue from the process records → policy register; controls catalogue (evidence: each re-compiles byte-identical).
6. Chief of Staff: send assumption, contradiction, control-gap and target rows for decision → decided rows (evidence: decision references).

Role card

Fixed test

TEST-PPD-PPW v3 and the tests of its Cells · result NOT_RUN

5.5 Position Shaping

Definition

Process (SOP)

1. Position Builder: propose the positions, with their reasons → position register, draft (evidence: every step and decision placed once).
2. Chief of Staff: run the placement and segregation checks by code (rules 1, 2, 4, 9) → check record (evidence: the record).
3. Chief of Staff: generate the job descriptions with their competence profiles, the decision-rights register, the authority matrix and the objectives cascade → generated parts (evidence: re-generated byte-identical).
4. Chief of Staff: run RP5, then send position rows, limit rows, segregation rules with no source and separation breaches for decision → decided rows (evidence: decision references).

Role card

Fixed test

TEST-PPD-PPS v3 and TEST-PPD-PPB v3 · result NOT_RUN

5.6 Structure

Definition

Process (SOP)

1. Structure Designer: propose the units with their heads and reasons, the reporting lines and the forums, and draft the crosswalk → structure draft (evidence: one row per unit, position, forum and current element).
2. Chief of Staff: run the unit and line checks, the span and layer report, and generate the unit charters, the charts, the review calendar and, with scenarios, the side-by-side view → check record; charts; review calendar; scenario view (evidence: re-generated byte-identical).
3. Chief of Staff: run RP6, then send the rows for decision → decided rows (evidence: decision references).

Role card

Fixed test

TEST-PPD-PS v3 and TEST-PPD-PSD v3 · result NOT_RUN

5.7 Workload

Definition

Process (SOP)

1. Workload Analyst: check every input's source or assumption; raise needs candidates for gaps → input check (evidence: one row per step).
2. Chief of Staff: compute the register, the peak-load check and the value-stream times by code → workload register; peak-load check (evidence: re-computed byte-identical).
3. Chief of Staff: run RP7, then send the time-available row, the assumptions and the peak findings for decision → decided rows (evidence: decision references).

Role card

Fixed test

TEST-PPD-PWA v3 · result NOT_RUN

5.8 Operational Walkthrough

Definition

As in the TOM blueprint v0.5.0 §5.7, carried, read with "processes, positions and decisions" for "operating model". The Situation Author writes situations blind to the design, from a blind brief compiled by code (the parts of the release in scope, the roles, the hand-offs; never the process records). The set is sealed before the walk. The Situation Walker walks each situation through the processes, positions, decisions and forums, and records where it holds and where it breaks: a step with no position, a decision with no decider, a hand-off that ends nowhere, an exception with no escalation, a forum asked to decide what it may not. Done when: T8 (§5.0).

Process (SOP)

As carried: compile the walk input and the blind brief; author; seal; walk; classify; RP8; route each finding (fix upstream, or put to decision).

Role card

Situation Author ([ORG]CELL-PSA) and Situation Walker ([ORG]CELL-PSW), in the Walkthrough Pod ([ORG]POD-PW); as carried, with their own tests.

Fixed test

TEST-PPD-PW v3, TEST-PPD-PSA v3, TEST-PPD-PSW v3 · result NOT_RUN

5.9 Independent Review

Definition

The Review Panel rule of the TOM blueprint v0.5.0 §5.8, carried whole: three to five engines from two or more families review each locked output, alone first, then in a short debate held to quotes; code settles; the PPD Design Lead rules only on what stays contested; at the full level no engine is of an author's family (its rule 4); the Chief of Staff never rules, dismisses, downgrades or lowers. This AIOC's review points: RP0 (P0), RP1 (release-reading record and return drafts), RP2 (architecture), RP3 (critical-process choice), RP4 (each process record), RP5 (positions and generated parts), RP6 (structure), RP7 (workload), RP8 (walk findings), RP9 (the release, before filing), and RPa (each needs pass). Done when: as carried.

Process (SOP)

As carried.

Role card

Blind Reviewers A to E ([ORG]CELL-PBRA to [ORG]CELL-PBRE), in the Review Pod ([ORG]POD-PR); as carried.

Fixed test

TEST-PPD-PR v3 and the tests of its Cells · result NOT_RUN

5.10 Decision Package and Release

Definition

Process (SOP)

1. Chief of Staff: generate the quality checks and the Decision Package; obtain the Design Lead's attestation of T0 to T8 → Decision Package (evidence: hashes).
2. Chief of Staff: run RP9; send the element rows and the final status for decision → decided rows (evidence: decision references).
3. Chief of Staff: freeze the manifest, run the release lint, file into [ORG]AIOC-SL, read back, send the release notice to [ORG]AIOC-DI → filed PPD Release; release notice (evidence: the filing receipt, the read-back hash, and the notice's hash).

Role card

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

Fixed test

TEST-PPD-COSPPD v3 (cases 64 to 67, 99 and 100) · result NOT_RUN

5.11 Returns from Delivery and Implementation

New in v0.4.0 (decisions/DR-0004). The receiving end of the Library's design return contract for the stage after this one, as the TOM blueprint v0.5.0 §5.10 is for the stage before (carried, Annex E).

Definition

Process (SOP)

1. Chief of Staff: admit or refuse the return by rule 1; record it; show it on the Panel with its age; end an accepted return at once → recorded return (evidence: the returns log, with the return's hash).
2. Chief of Staff (runs the return-brief code step): generate the brief and its rows → return brief (evidence: hash).
3. Chief of Staff: send the rows as decision needs requests through [ORG]AIOC-SL (§5.2) → decision rows (evidence: the needs log).
4. Requesting Authority (in Source Lifecycle): decide one row → decision reference.
5. Chief of Staff: record the decision on the return as its next version; on a new PPD Release that answers it, mark it answered by release; send the answer back to DI on its connection → return answer (evidence: the return's version, valid against the pinned contract).
6. Chief of Staff: on DI's next round, repeat 1 to 5; past a deadline, or at return_rounds_max, escalate by rule 6 → escalated return (evidence: the returns log).
7. PPD Design Lead: classify each ended return by rule 8 → classification record (evidence: run record, live sign-in).

Role card

Performed by the Chief of Staff (§4.2); the classification by the PPD Design Lead (§13, H-19).

Fixed test

TEST-PPD-COSPPD v3 (cases 101 to 104) and TEST-PPD-PDL v3 (PDL-6) · result NOT_RUN

6. Coordination and routes

• [ORG]AIOC-TOM. The operating model source, linked directly (Protocol §17, items 2 and 3).
  • 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-TOM as connect-external-port, with two scopes: read its decided releases; send returns. A wider scope is grant-or-widen-access. A revocation cuts it at the gateway at once and holds the run.
  • Loops. A return is a Work Item to TOM. TOM answers it on that Work Item (and, for an answer by release, with a new release notice); 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.1).
• [ORG]AIOC-SL. The source of record, and the only route to any person in the organisation.
  • The connection. Signed by the [ORG]HOAC-ACS position over [ORG]AIOC-SL as connect-external-port (Protocol §13, item 5), with three scopes: read; needs requests; write only this AIOC's own releases and design reports (its returns).
  • Needs requests are sub-items of the run, with chain depth 1.
• [ORG]AIOC-DI, the next stage, linked directly (Protocol §20, item 9). New in v0.4.0.
  • Routes. On every filing of a decided PPD Release, a release notice leaves through the output port (§5.10, rule 5). DI reads the release from Source Lifecycle, by the reference in the notice. DI's returns arrive at the Chief of Staff's port and end by §5.11.
  • The connection. One connection with two scopes: release notices to DI; returns from DI and their answers. Signed by the [ORG]HOAC-ACS position over this AIOC, the PPD Design Lead's, as connect-external-port (H-16). A revocation cuts it at the gateway at once; notices and answers wait, shown on the Panel. This AIOC stands alone without it.
  • Loops. A return is a Work Item from DI; this AIOC answers it on that Work Item and never opens a new item back.
• Work Items.
  • The run. One Work Item, opened by the Requesting Authority's Cell through the HU input port. Requested output: a PPD Release (Annex A). Acceptance test: the Requesting Authority's (T9 decided; the manifest valid; the filed reference reads back). Sources: the TOM Release reference and, optionally, the children in scope.
• [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-TOM; return filing → [ORG]AIOC-SL; needs request → [ORG]AIOC-SL; missing report → [ORG]AIOC-SL; PPD Release filing → [ORG]AIOC-SL; release notice → [ORG]AIOC-DI; return answer → [ORG]AIOC-DI.

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.
• Revocation or reclassification. On a notice from Source Lifecycle or TOM, 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 (Standard §4.4, item 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-PPD, its fixtures or §9.

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-PPD.md (v3). Cases 1 to 22 are the Library's TEST-PROCESS-AND-POSITION-DESIGN v1, cases 1 to 22, unchanged. Cases 23 to 111 are this AIOC's own; case 27 is struck in v2 and replaced by case 98. The Design Lead's seat test is PDL-1 to PDL-6. The Library's TEST-PROCESS-AND-POSITION-DESIGN v2 numbers its added cases 23 to 34 in its own series; they are covered here as follows: 23 → 78 to 81; 24 → 82; 25 → 83, 84; 26 → 95, 96; 27 → 97; 28 → 86; 29 → 87; 30 → 88; 31 → 89, 90; 32 → 85, 94; 33 → 93; 34 → 98, 104. The owner of every part's test is the PPD Design Lead; the owner of the AIOC's whole test, and of the Design Lead's own seat test, is the Cell carrying [ORG]HOAC-TM.

• Re-run triggers. The template defaults, plus any change to the pin of the Library's design return contract, to the release notice contract, to the TOM release or notice format, to the Source Lifecycle output socket, or to the release lint's word list.
• 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 Chief of Staff never asks the organisation's people anything. It reaches the organisation only through the Chief of Staff of [ORG]AIOC-SL. Reason: as for [ORG]AIOC-TOM (its §11, item 1); a design rests on recorded sources, never on words spoken to the designer.
2. The Back office does not converse with humans (converses_with_humans: false). Reason: as in item 1.
3. Two operating sources. The template's Input socket takes sources. This one also takes a design release directly from another AIOC, by reference and hash, and returns defects to it. Reason: the direction of the governing seat that this AIOC is linked to the TOM itself (decisions/DR-0001; Protocol §17, items 2 and 3).
4. Rules carried by reference. The Review Panel rule, the two-author rule, labels, decision rules and the receiving end of returns are carried from the TOM blueprint v0.6.0 by section, not restated. A change there reaches this AIOC only when this blueprint pins the new version (Annex E).

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 · The stage after the operating model was first framed as positions alone. Leading design practice designs processes and decision rights with the roles, processes first. Test question added: case 12 (no position without a step or decision). This text is the mother.
2. 2026-10-15 · A stage that reads a design release must be able to send defects back to the stage that made it, without a person relaying them. Test question added: cases 5 to 7. Proposed: the TOM changes in upstream/PROPOSALS.md, item 1.
3. 2026-10-15 · Fifteen products that design, launch or run organisations were taken apart from public material, and each useful feature was placed in the stage where it truly belongs. Those that belong here: the facts of each step, controls and segregation of duties, the objectives cascade, measures of three kinds, structure scenarios, peak load, variants, modelling conventions, forum tiers, end-to-end time and re-approval. Anything that rates or watches a person was not taken. Test questions added: cases 78 to 94 (decisions/DR-0002). Proposed: upstream/PROPOSALS.md, item 5.
4. 2026-10-15 · A review of what launching an organisation needs after this stage found three small additions that belong here: a competence profile in each job description; risk, control and record per step; measure definitions and the review calendar beside the forums. Test questions added: cases 82, 85 and 87 (decisions/DR-0002).
5. 2026-10-15 · Positions alone do not make an organisation that can launch: they must be grouped into units, each with a head and a mandate, and that grouping belongs in the same stage as the positions. Test questions added: cases 95 to 97 (decisions/DR-0003).
6. 2026-10-16 · A return that can only wait does not end, and a stage that is never told of a release learns of it late. Returns, both ways, now follow the Library's contract and always end; the stage after this one is told of each release directly. Test questions added: cases 98 to 104 (decisions/DR-0004; 49GAION/DR-0016, DR-0018).
7. 2026-10-16 · The stage before this one now states what this stage needs to start: the strategy, how each capability is delivered, which streams are critical, each outside party's journey, a priority per element, and how the work runs today. This stage reads them and never fills them. Test questions added: cases 105 to 111 (decisions/DR-0005).

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-08). People: H-07 (decided); this AIOC designs positions, never who fills them. Legal: none decided here.

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 processes and positions designed from its decided operating model, traced to it and decided by its own authority.
• Type-specific test: TEST-PPD v3, case 76 · 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 PPD Design 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, the code rules of its tests/cards/check_cards.py, Naming Standard R15 and R16, and this blueprint.

parts:
  defaults:
    accountable_to: "[ORG]CELL-PDL"
    card_version: "v0.5.3"
    version: "0.3.0"
    lifecycle_state: "designed"
    test_version: "v3"
    test_owner: "[ORG]CELL-PDL"
    audit_trail: "the run record of [ORG]AIOC-PPD"
    hu_in: ["run control and configuration from the PPD Design Lead (never a source)"]
    hu_out: ["run report to the PPD Design Lead"]
  cells:
    - code: "[ORG]CELL-PDL"
      full_name: "PPD Design Lead"
      parent: "[ORG]AIOC-PPD"
      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-PPD-PDL", cases: "PDL-1 to PDL-6", owner: "[ORG]CELL-TMS" }
      ai_in: ["run brief", "ruling sheets for contested MATERIAL findings", "release notice", "ended returns from DI to classify"]
      ai_out: ["run control and configuration"]
      hu_in: ["direction from the Cell carrying [ORG]HOAC-TM"]
      hu_out: ["rulings, attestations, reduced-level acceptances and the classification of ended returns, under live sign-in", "report to the Cell carrying [ORG]HOAC-TM"]
    - code: "[ORG]CELL-COSPPD"
      code_rule: "R16"                     # 49GAION/DR-0028; replaces [ORG]CELL-PCS (retired, R5)
      lineage: { id: "[ORG]CELL-PCS", version: "0.3.0", relation: "derived" }
      full_name: "PPD Chief of Staff"
      role: "Chief of Staff"
      parent: "[ORG]AIOC-PPD"
      type: "AI Chief of Staff"
      filler_kind: "ai"
      cell_kind: "chief-of-staff-cell"
      test: { id: "TEST-PPD-COSPPD", cases: "1-4, 8, 13, 18, 19, 21-26, 29-34, 48, 51, 62, 64-67, 73-75, 83, 84, 86, 87, 90, 92, 94, 96, 98-104" }
      ai_in: ["release notice", "return answer", "return", "source reference", "needs answer", "needs status", "needs candidate", "return draft", "locked outputs of the Pods", "settled review records"]
      ai_out: ["Input Pack version", "dispatch to a Pod", "review packet", "return", "needs request", "missing report", "generated parts", "PPD Release filing", "release notice", "return brief", "return answer"]
      hu_out: ["run brief to the PPD Design Lead", "ruling sheets to the PPD Design Lead", "release notice to the Requesting Authority's Cell"]
      external_ports:
        - { port: "tom-in", direction: "input", accepted_content: ["release notice", "return answer"], authority_limit: "the read scope signed under connect-external-port over [ORG]AIOC-TOM", audit_trail: "unit register connected and disconnected events; serve log of [ORG]AIOC-TOM" }
        - { 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: "sl-in", direction: "input", accepted_content: ["source reference", "needs answer", "needs status"], 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", "PPD Release filing"], authority_limit: "the request and write scope signed over [ORG]AIOC-SL: this AIOC's own releases and design reports only", audit_trail: "unit register; serve log of [ORG]AIOC-SL" }
        - { port: "di-out", direction: "output", accepted_content: ["release notice", "return answer"], authority_limit: "notices and answers by reference only, under the scope signed under connect-external-port over this AIOC", audit_trail: "unit register; the Work Item record" }
        - { port: "di-in", direction: "input", accepted_content: ["return"], authority_limit: "returns only, under the scope signed under connect-external-port over this AIOC", audit_trail: "unit register; the Work Item record" }
      bot:
        allowed_actions: ["dispatch Cells of this AIOC", "build Input Pack versions through the code steps", "lock outputs and run code steps", "draw review engines and run the review code steps", "write the run record", "send reviewed returns to [ORG]AIOC-TOM and file them in [ORG]AIOC-SL", "send needs requests and Missing Reports to [ORG]AIOC-SL", "generate job descriptions, registers, charts and workload through the code steps", "file a release whose elements are decided", "send release notices to [ORG]AIOC-DI after filing", "admit or refuse a return from [ORG]AIOC-DI by the pinned contract and record it", "generate return briefs through the code step and send their rows to [ORG]AIOC-SL", "send return answers to [ORG]AIOC-DI"]
        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-PRR", full_name: "PPD Release Reader", role: "Release Reader", parent: "[ORG]POD-PRI", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-PPD-PRR", cases: "3, 5, 28, 30, 47" }, ai_in: ["Input Pack version", "the TOM release, role register first"], ai_out: ["release-reading record", "return draft"], bot: { allowed_actions: ["read and account for every element of the release", "draft returns with their evidence"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-PPA", full_name: "PPD Process Architect", role: "Process Architect", parent: "[ORG]POD-PA", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-PPD-PPA", cases: "9, 10, 35-37, 93" }, ai_in: ["release-reading record", "Input Pack version"], ai_out: ["process architecture draft", "critical-process proposal", "return draft", "needs candidate"], bot: { allowed_actions: ["draft the process architecture with its trace", "propose the critical processes and their order"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-PFPA", full_name: "PPD First Process Author", role: "First Process Author", parent: "[ORG]POD-PPW", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-PPD-PFPA", cases: "11, 16, 40-45, 78-82, 86, 91" }, ai_in: ["architecture entry", "release elements", "Input Pack atoms"], ai_out: ["process record draft", "return draft", "needs candidate"], bot: { allowed_actions: ["write a process record, blind to the other author"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-PSPA", full_name: "PPD Second Process Author", role: "Second Process Author", parent: "[ORG]POD-PPW", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-PPD-PSPA", cases: "11, 16, 39-45, 78-82, 86, 91" }, ai_in: ["architecture entry", "release elements", "Input Pack atoms"], ai_out: ["process record draft", "return draft", "needs candidate"], bot: { allowed_actions: ["write a process record, blind to the other author"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-PPR", full_name: "PPD Process Reconciler", role: "Process Reconciler", parent: "[ORG]POD-PPW", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-PPD-PPR", cases: "39, 41" }, ai_in: ["two locked drafts", "difference register", "the atoms and elements the drafts cite"], ai_out: ["reconciled process record", "the dispositions of the difference register"], bot: { allowed_actions: ["reconcile two locked drafts, disposing each difference with its reason"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-PPB", full_name: "PPD Position Builder", role: "Position Builder", parent: "[ORG]POD-PPS", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-PPD-PPB", cases: "12, 20, 46, 47, 52, 77, 85" }, ai_in: ["written processes", "role register"], ai_out: ["position register draft", "return draft"], bot: { allowed_actions: ["group steps and decisions into positions, with reasons"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-PSD", full_name: "PPD Structure Designer", role: "Structure Designer", parent: "[ORG]POD-PS", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-PPD-PSD", cases: "14, 53-56, 87, 88, 95, 97" }, ai_in: ["position register", "release parts and governance", "Input Pack atoms"], ai_out: ["unit register", "reporting lines", "forum register", "crosswalk"], bot: { allowed_actions: ["propose units, reporting lines and forums", "draft the crosswalk"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-PWA", full_name: "PPD Workload Analyst", role: "Workload Analyst", parent: "[ORG]POD-PS", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-PPD-PWA", cases: "15, 16, 57, 58, 89, 90" }, ai_in: ["written processes", "position register"], ai_out: ["workload input check", "needs candidate"], bot: { allowed_actions: ["check each workload input's source or assumption", "raise needs candidates for gaps"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-PSA", full_name: "PPD Situation Author", role: "Situation Author", parent: "[ORG]POD-PW", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-PPD-PSA", cases: "59" }, ai_in: ["blind brief"], ai_out: ["blind situation pack"], bot: { allowed_actions: ["write the blind situation pack"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-PSW", full_name: "PPD Situation Walker", role: "Situation Walker", parent: "[ORG]POD-PW", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-PPD-PSW", cases: "17, 60" }, ai_in: ["sealed situation set", "walk input"], ai_out: ["trace", "finding register"], bot: { allowed_actions: ["walk sealed situations", "classify findings"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-PBRA", full_name: "PPD Blind Reviewer A", role: "Blind Reviewer A", parent: "[ORG]POD-PR", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-PPD-PBRA", cases: "22, 61, 63" }, 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-PBRB", full_name: "PPD Blind Reviewer B", role: "Blind Reviewer B", parent: "[ORG]POD-PR", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-PPD-PBRB", cases: "22, 61, 63" }, 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-PBRC", full_name: "PPD Blind Reviewer C", role: "Blind Reviewer C", parent: "[ORG]POD-PR", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-PPD-PBRC", cases: "22, 61, 63" }, 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-PBRD", full_name: "PPD Blind Reviewer D", role: "Blind Reviewer D", parent: "[ORG]POD-PR", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-PPD-PBRD", cases: "22, 61, 63" }, 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-PBRE", full_name: "PPD Blind Reviewer E", role: "Blind Reviewer E", parent: "[ORG]POD-PR", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-PPD-PBRE", cases: "22, 61, 63" }, ai_in: ["review packet", "collated findings of its review"], ai_out: ["review card", "positions on findings"], bot: { allowed_actions: ["write its own review card", "state its own positions on the findings of its review"], ask_first_actions: ["anything outside its role card"] } }
  pods:
    - { code: "[ORG]POD-PRI", full_name: "PPD Release Intake", type: "AI Pod", inner_units: ["[ORG]CELL-PRR"], top_cell: "[ORG]CELL-PRR", test: { id: "TEST-PPD-PRI", cases: "3, 5-7, 28, 30, 47" }, ai_in: ["Input Pack version", "release notice"], ai_out: ["release-reading record", "return draft"] }
    - { code: "[ORG]POD-PA", full_name: "PPD Architecture", type: "AI Pod", inner_units: ["[ORG]CELL-PPA"], top_cell: "[ORG]CELL-PPA", test: { id: "TEST-PPD-PA", cases: "9, 10, 35-38, 93" }, ai_in: ["release-reading record"], ai_out: ["process architecture", "critical-process proposal"] }
    - { code: "[ORG]POD-PPW", full_name: "PPD Process Writing", type: "AI Pod", inner_units: ["[ORG]CELL-PFPA", "[ORG]CELL-PSPA", "[ORG]CELL-PPR"], top_cell: "[ORG]CELL-PFPA", test: { id: "TEST-PPD-PPW", cases: "11, 16, 39-45, 78-82, 86, 91" }, ai_in: ["decided architecture", "Input Pack atoms"], ai_out: ["process records"] }
    - { code: "[ORG]POD-PPS", full_name: "PPD Position Shaping", type: "AI Pod", inner_units: ["[ORG]CELL-PPB"], top_cell: "[ORG]CELL-PPB", test: { id: "TEST-PPD-PPS", cases: "12, 13, 20, 46-52, 77, 84, 85" }, ai_in: ["written processes", "role register"], ai_out: ["position register"] }
    - { code: "[ORG]POD-PS", full_name: "PPD Structure", type: "AI Pod", inner_units: ["[ORG]CELL-PSD", "[ORG]CELL-PWA"], top_cell: "[ORG]CELL-PSD", test: { id: "TEST-PPD-PS", cases: "14, 15, 53-58, 87-90, 95-97" }, ai_in: ["position register", "written processes"], ai_out: ["unit register", "reporting lines", "forum register", "crosswalk", "workload input check"] }
    - { code: "[ORG]POD-PW", full_name: "PPD Walkthrough", type: "AI Pod", inner_units: ["[ORG]CELL-PSA", "[ORG]CELL-PSW"], top_cell: "[ORG]CELL-PSW", test: { id: "TEST-PPD-PW", cases: "17, 59, 60" }, ai_in: ["walk input", "blind brief"], ai_out: ["walkthrough report"] }
    - { code: "[ORG]POD-PR", full_name: "PPD Review", type: "AI Pod", inner_units: ["[ORG]CELL-PBRA", "[ORG]CELL-PBRB", "[ORG]CELL-PBRC", "[ORG]CELL-PBRD", "[ORG]CELL-PBRE"], top_cell: "[ORG]CELL-PBRA", test: { id: "TEST-PPD-PR", cases: "22, 61-63" }, ai_in: ["review packet"], ai_out: ["review cards and positions"] }

• Accountability. Every Pod and Cell of this AIOC is accountable_to [ORG]CELL-PDL. The AIOC itself and the Design Lead are accountable_to the Cell carrying [ORG]HOAC-TM.
• Adding a HOAC position. The organisation may add HOAC positions to this AIOC in its own design, each a human Cell with a HOAC label and its own fixed test, through OCO (create-or-install-unit).
• Bots. Each AI Cell's bot (sixteen) 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 Chief of Staff of [ORG]AIOC-SL and the Cells of [ORG]AIOC-TOM are not Cells of this AIOC.

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

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

Annex A. The PPD Release: its parts and their 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 (release element IDs and source atom IDs, at least one) and, after T9, its decision reference. JSON Schemas are made from these lists before the first run and may add nothing.

A.1 Release-reading record (run record). One row per element of the release in scope: element_id (ROLE-n, HO-n, CPR-n, JNY-n, VC-n, a capability, a value-stream phase, a decision domain, an element of the strategy frame, or the activity profile), part, child, state (used, returned, out of scope), used_by (process IDs, after S2), return_id (when returned), reason (when out of scope).

A.2 Process architecture (release part). Per entry: id (L1-n, L2-n or PRC-n), level (1, 2, 3), name, parent, traces_to (release element IDs; at least one for level 1), owner_role (ROLE-n, level 3), owner_position (POS-n, level 3, after S5), carries (HO-n and CPR-n), critical (yes or no, with reason, among them critical value stream), priority (the highest decided priority of the release elements it carries), delivery (the delivery model of the capability it serves: in-house, shared service, outsourced, partner or not decided), order, current (the current processes from the sources it replaces, for the crosswalk).

A.3 Process record (one per process; release part "process book"). process_id; purpose; trigger; end; lanes (roles); steps[]: {step_id, lane, action, input, output, accountable_role, decision_id (or none), volume {value, unit, per, basis, peak {value, period, basis} or none}, step_time {value, unit, basis}, wait_before {value, unit, basis}, done_when, worst_error {description, reversible (yes, partly, no), basis}, act_kinds (from the fixed list of §5.4, rule 11), input_source {kind, trust (verified, unverified), basis}, confidentiality (a class of the organisation's classification), risks (risk IDs), controls (control IDs), record {name, basis}}; decisions[]: {decision_id, question, decides (one role), recommends, must_agree, gives_input, carries_out, limit {value, basis}}; exceptions[]: {trigger, handling, escalates_to (role)}; risks[]: {risk_id, what, at_steps, basis}; measures[]: {name, kind (quality, time, cost, volume), definition, unit, basis, target (a decision reference, or not set), reviewed_by (forum ID, after S6)}; variants[]: {variant_id, applies_to (an entity, a site or a product), differs_at (step IDs), reason}; end_to_end_time {value, unit, path (step IDs), complete}; conventions (the modelling conventions in force and their results); method_refs (reference models used as methods, never as evidence); policies[] (policy IDs); hand_offs (HO-n, CPR-n, and the lane hand-offs inside the process); authors (one, or two with the difference register's ID); after T9: owner_position, approved_by (decision reference), re_approval_due.

A.4 Policy register (release part; compiled by code). Per policy: policy_id, name, applied_at (step IDs), owner_role, basis (source atom), state (held, or needed when no source holds it). No policy text.

A.5 Position register (release part). Per position: position_id (POS-n), title, role (one ROLE-n), part and child, holds_steps, holds_decisions, grouping_reason (same expertise, same counterpart, same location, same decision chain, or the release's own grouping), job_family and level (each with its basis, or not given), reports_to (POS-n, after S6), forums (after S6). Never: a person, a pay amount, or what fills the position.

A.6 Job descriptions (release part; generated by code, one per position). position_id; title; job_family and level (as in A.5); purpose (from its processes' purposes); accountabilities (from its steps); decisions (with their limits); works_with (positions at its lane hand-offs); measures (from its processes' measures for its steps); competences (each a knowledge or skill, with the steps and decisions it serves); reports_to; trace (every line to a step or decision). The release lint fails any field that does not trace.

A.7 Decision-rights register and authority matrix (release parts; generated by code). Register: one row per decision: decision_id, process_id, decider (POS-n), the other parts by position, limit, basis. Matrix: positions by decision class, each cell the part the position plays, generated from the register.

A.8 Structure (release parts). Reporting lines: position_id, reports_to. Organisation charts: generated from the units and the lines, one per part of the release. Span and layer report: per manager position, its span; per part, its layers; each value against the configured range, with findings. Forum register: per forum, forum_id, purpose, decides and advises (decision IDs), members and chair (POS-n), tier, cadence, reviews (measure names), inputs, outputs. Review calendar (generated): per forum and period, the measures it reviews. Result lines: per part, result_line, with its basis. Crosswalk: per current unit, position or process named in the sources: current_ref (source atom), maps_to (target IDs), or state retired or not mapped, with reason.

A.9 Workload register (release part; generated by code). Per position: position_id, period, time_needed (sum of volume × step time over its steps), time_available (with its basis), steps (the terms of the sum), complete (no when any term is a gap), gaps. Per process (New in v0.5.0): today (the activity-profile lines of the processes it replaces, with their atoms and date, or no observation) beside its designed volume and time.

A.10 Decision Package (release part). A plain summary; the elements for decision, each with its row; the unknowns, the assumptions and the open returns, in plain words; the control gaps and the separation breaches; the span and layer findings; the structure scenarios side by side, when there are any; the peak findings; the walk's findings and their choices; the quality checks.

A.11 Controls catalogue and segregation-of-duties rules (release part; compiled by code). Per control: control_id, objective (the risk IDs it answers), kind (preventive, detective), at_steps, performed_by (POS-n, after S5), evidence (the record it leaves), frequency, basis. Per rule: rule_id, conflict (two classes of step or decision one position may not hold together, for example start and approve, keep and record, record and reconcile), basis (a source or a decision). Check, after S5: per position, each rule it breaks, with any compensating control and the decision reference.

A.12 Objectives cascade (release part; generated by code). Per goal: goal (a one-year goal or a critical number of the release's strategy frame, by its reference; for a release with no strategy frame, a goal a source gives), value_stream_measures, process_measures, position_measures (by POS-n), each link traced. Findings: a goal with nothing under it; a measure that serves no goal.

A.13 Structure scenarios (release part, when structure_scenarios is above one). Per scenario: scenario_id, its reporting lines, and side by side: positions, management positions, spans, layers, cost (not given without the organisation's cost rates); chosen (the decision reference of the one chosen).

A.14 Peak-load check and value-stream times (release part; generated by code). Per position: peak_period, time_needed_at_peak, time_available, terms, complete, findings. Per value stream: end_to_end_time, processes, complete.

A.15 Unit register and unit charters (release parts; charters generated by code). Per unit: unit_id (UNIT-n), name, kind (the organisation's own word: team, section, department), part (the release part), parent_unit, head_position (POS-n, one of its positions), positions, grouping_reason, forums, measures, result_line. Charter, one per unit: mandate (its processes and decisions, from its positions' steps and decisions), head_position, positions, works_with (units at its hand-offs), forums, measures, result_line, trace (every line to a step, decision or forum). Never a person.

The manifest. release_id (PPDREL- + SHA-256 of the manifest body); run_id; tom_release {release_id, manifest_sha256}; parts[] {name, sha256}; input_packs[]; returns[] (return IDs with their states, both ways); set_aside[] (per element carried forward on a set-aside return: return_id, element_id, carried_forward_on, decision); decided_at; final_status.

Annex B. Returns, both ways

Returns follow the Library's design return contract, library/contracts/design-return.schema.json of 49GAION-protocol (Standard §3.1, item 6; Protocol §17, item 11; 49GAION/DR-0018), pinned by commit and hash in contracts/PINS.json. This AIOC keeps no copy of it. (v0.4.0: supersedes this AIOC's own contracts/release-return.schema.json v0.1, which had no rounds and no set-aside end.)

B.1 Returns this AIOC sends to [ORG]AIOC-TOM.

1. A return goes to [ORG]AIOC-TOM directly, through the gateway, and its copy is filed into Source Lifecycle as a design report with the same hash.
2. A return never changes the release. It asks TOM to answer.
3. TOM answers with a new decided release (a continuation run), or the Requesting Authority answers by decision. If a new release still does not answer it, the same return is sent again, under the same return_id, in its next round. TOM counts the rounds, holds the deadlines and escalates (TOM blueprint v0.5.0, §5.10). Silence answers nothing.
4. When the whole release is used without defect, the run sends one accepted return; TOM ends it at once.
5. Set aside. A return set aside by the Requesting Authority's decision lets its touched elements go forward on the stated basis. Each is marked in this AIOC's work and in the PPD Release as a known defect or a decided assumption, with the decision reference; it is listed in the Decision Package in plain words and in the manifest (set_aside[]).
6. A return for something TOM should have obtained is a defect of TOM; a return for something only this stage could find is normal (TOM blueprint v0.5.0, docs/CARRIED-RULES.md §4.4, items 2 and 3). TOM's Design Lead classifies it.

B.2 Returns this AIOC receives from [ORG]AIOC-DI. Under the same contract, ended by §5.11. A defect DI finds in the TOM Release that a PPD Release rests on is DI's to return to TOM (§5.11, rule 7).

Done when. Each return validates against the pinned contract; it is sent and filed with one hash; its touched elements show held: return open until it ends; 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 release: closed: not admitted (T0 failed, with 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. No flag releases the run slot; every ending releases it. A return from DI is not a run state: it lives on its own Work Item, with the states of the contract (§5.11), and holds no run.

C.2 The gates. T0 to T10 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) the release check passes (§4.3, part 3); (c) the TOM connection is signed and in scope; (d) the Source Lifecycle connection is signed and in scope; (e) the engine register holds eligible engines for the highest confidentiality level in scope, and two author families; (f) requesting_authority_cell is set; (g) RP0 is settled.

Annex D. What this AIOC never does

1. Change, merge, split or drop an element of the TOM release.
2. Ask any person anything about the organisation, or send a request that names a person.
3. Name a person, or read who occupies a position.
4. Say what fills a position.
5. Set pay.
6. Write the text of a policy.
7. Invent a measure, a volume, a time or a limit.
8. Write a job description by hand.
9. Add a role that the role register does not hold.
10. Change a reporting line, span or layer to fit a range.
11. Decide anything for the organisation, or take silence as a decision.
12. Grade its own work: no Cell reviews its own output, and the Chief of Staff rules on nothing.
13. Set or propose a cost rate, or choose a structure scenario.
14. Use a reference model, a taxonomy or a measure library as evidence.
15. Claim that the organisation complies with a law or a standard.
16. Edit a filed PPD Release in answer to a return; decide, answer or classify a return in the Chief of Staff; or write a return brief by hand.
17. Leave a return, either way, without its round and its deadline, count silence as its answer, or let it end other than in one of the contract's four ends.
18. Carry an element forward on a set-aside return without marking its basis in the release.
19. Send a release notice before the filing reads back, or put release text into a notice.
20. Fill what the release states as not given, not decided, not set, unknown or no observation; or write a goal of its own (TOM Annex H).
21. Design an in-house process for work the release delivers outside, or use today's activity profile to say anything about a person.

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. A change there reaches this AIOC only when this annex pins the new version.

Powered by 49GAION