# ── Blueprint metadata (machine-readable; the panel generator and the back-office builder read this block) ──
blueprint:
  aioc: "[ORG]AIOC-SL"
  parent: "[ORG]AIOC-CH"                  # example code of the Charter; each organisation writes its own Charter's code (Standard §1.7, item 13)
  full_name: "Source Lifecycle"
  organisation: "<organisation>"          # filled in each organisation's own copy
  type: "foundational"
  org_aion: "[ORG]AION"
  blueprint_version: "v0.1.6"
  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 Source Lifecycle"
    version: "part card v4 (DRAFT)"
    source: "github.com/49g-holding/49GAION-protocol, library/cards/source-lifecycle.part-card.json and the Protocol section Source Lifecycle (§13); Standard §3.1, item 7. This text is its mother blueprint, in its mother repository github.com/49g-holding/49GAION-source-lifecycle (49GAION DR-0024)"
  writing_repository: "<org>aioc-sl"
  code_project: "<org>aioc-sl, on the organisation's code platform"
  panel_register_id: "none yet"
  capabilities:
    standard: ["Chief of Staff", "Office", "Input socket", "Panel"]
    functional: ["Conversation to Record", "Gap Finding", "Classification and Sharing", "Document Production", "Publication and Activation", "Revision and Retirement", "Agent and Knowledge Governance", "Connections and the Output Socket", "Needs Requests", "Trial and Exit"]

Blueprint · [ORG]AIOC-SL · Source Lifecycle · v0.1.6

Draft, 15 October 2026; v0.1.1, 16 October 2026, takes the filings of every design stage (49GAION/DR-0016 to DR-0018): two new origin kinds, process and position design and delivery and implementation, and a write scope for each stage limited to its own kinds and its design reports, which hold its returns. v0.1.2, 16 October 2026, adds the organisation dictionary, the essentials checklist and the rule for records of the work as it runs, and takes the v0.6 sockets contract (49GAION/DR-0023; Annex F). v0.1.3, 17 October 2026, takes the feeds of the Operations Event Register (49GAION/DR-0027): the origin kind correspondence, fixed as received; the register's write scope; and gap signals. v0.1.4, 19 October 2026: the Chief of Staff takes its COS code [ORG]CELL-COSSL (decisions/DR-0002). This is the mother blueprint of the Library part 49GAION Source Lifecycle, for any organisation (49GAION/DR-0024; decisions/DR-0001). It was written from the blueprint of the part's first instance, v0.1.2, with every value of that organisation removed; each organisation fills its own copy (§0, §2.1). It sets the product, as its requirements document describes it, into the form of the 49GAION AIOC template: its card, its positions, its Cells and Pods, and each capability in four parts. It adds no product requirement. Every rule rests on a 49GAION text, on the product requirements document, the PRD of the Source Lifecycle product (cited by requirement ID; §0), or is new in this blueprint and marked New. Nothing here has run. Every fixed test reads NOT_RUN.

Source Lifecycle in one page

Source Lifecycle (SL) keeps an organisation's own sources: its documents, and what its people say once they have approved it. It records each one, gives it a reference, classifies it and fixes it, so that every source has one valid version, and anyone can see where it came from.

It serves anyone who owns sources: one person, a household, a company, a group of companies, or an institution. It is sold and used on its own. It is also the first stage of every larger system: in 49GAION, every source enters through it, and every later part reads from it.

What goes in

1. Files and folders of any kind, existing collections, and items pulled from the owner's other systems.
2. A person's own words, by typing, chat or voice. An owner with no documents at all becomes documented by talking.
3. Requests from connected parts: to read a source, to file one, or to ask for what is missing.

Before anyone gives anything, they accept a contributor agreement. Secrets (passwords, keys, codes) are refused everywhere.

What SL does

1. Checks everything at the door, and refuses with a reason.
2. Turns talk into text, shows the person the exact text item by item, and records only what they approve. Silence approves nothing.
3. Labels every statement: stated, inferred, assumed or unknown.
4. Classifies each source: its class, how confidential it is, what kind of document it is, and its status.
5. Lets the owner decide who sees what, like the settings of a code repository.
6. Takes a document from request to draft, review, decision, approval, publication and archive, with a human HOAC position deciding at every step that needs one.
7. Tells the owner what is missing for an owner of its kind.
8. Lets other systems connect only by request, approved and scoped by a human HOAC position, and revocable at any time.
9. Answers connected systems by reference only: the ID, the version and the hash, "held" or "not held".
10. Takes the questions of connected systems, finds the right HOAC position, gets the answer approved and recorded, and answers by reference. No connected system ever asks a person anything.

What comes out

• The owner's sources, each with one valid version, its history and its classification.
• Answers to connected systems, by reference, within what they were allowed.
• What is missing, ranked by consequence.
• A full export at any time.

Who decides

• Every human position in SL is a HOAC position: a position, never a person. The organisation's HOAC positions decide everything that is theirs: their content, what is in force, who sees it, who connects. SL prepares and records; it never decides.
• SL has at least one HOAC position of its own: the Source Lifecycle Lead, its accountable [ORG]HOAC-ACS position. It approves each connection and its scope, and owns the tests of its parts. The organisation may add more HOAC positions to SL in SL's own design (§17).
• No natural person exists in the system (Standard §1.1, item 9). Who holds a position, and how, is the organisation's own mechanism, outside the system. SL never sees it; it deals with positions only.

Where this blueprint stands. In the first instance, the product exists and runs on a demonstration branch; its live qualification there was 0 of 3 cycles when this mother was written (PRD §10). Most of what Protocol §13 and the next stage need is not built yet (PRD §11). This blueprint states what the AIOC is. The PRD states what the product must do. The two must match (§9, case 85). The decisions only a human seat can take are listed once, in §13.

Reading (49GAION DR-0041). The complete definition of 49GAION, approved by its governing seat on 25 October 2026, is 49GAION-FRAMEWORK.md in github.com/49g-holding/49GAION. Where this repository differs from it, the definition governs, and this text is read with it. Every rule here that names [ORG]AIOC-OCO or the human hub reads as the Top Management Group, the hub of the operation, human and AI. The panel is the organisation's own code interface, and the AI chat workspace is its back office. The readings are in decisions/DR-0003. Nothing here is removed.

0. Identity and lineage

Lineage. The product began, in the part's first organisation, as a document-production engine for governed AI work; earlier names may remain in that instance's stored identifiers. Its requirements were consolidated into the product's PRD and widened into an independent product and the first stage of every larger system, with the needs-request path a connected organisation-design part needs. The governing seat of 49GAION made it a Library part, with its Protocol section (49GAION/DR-0008), and set where its mother lives (49GAION/DR-0024). The first instance's own history stays in that instance's writing repository.

Requester stewardship. An earlier organisation-design chain had a stage, CS1, that read back what was said, labelled each statement, recorded contradictions without ruling on them, and asked for what was missing in plain words. That work is carried here, as the person-facing half of intake (PRD FR-27; §4.2, §5.1). The organisation-design part [ORG]AIOC-TOM keeps the other half: capturing its request, tracking what it lacks, and carrying its decision rows.

1. Card (49GAION Operating Protocol §3)

card:
  unit_kind: "AIOC"
  code: "[ORG]AIOC-SL"
  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-SLL", "[ORG]CELL-COSSL", "[ORG]CELL-SLIA", "[ORG]POD-SLIR", "[ORG]POD-SLDP"]
  type: "foundational"
  org_aion: "[ORG]AION"
  card_version: "v0.1.6"
  input_door: "Chief of Staff"
  wake: { method: "queue", verified: false }
  receives:
    - kind: "input"                       # files, folders, archives, existing collections and items pulled by a data-source connector; through the HU input port or the connector port
      format: "file, received through the Input socket under a current contributor agreement"
      acceptance_test: "TEST-SL v1, cases 3, 4, 17, 18, 26, 40, 60"
      decision_needed: false
    - kind: "contributor words"           # typed text, chat or voice
      format: "conversation, recorded only after the contributor approves a preview of the exact text, item by item"
      acceptance_test: "TEST-SL v1, cases 1, 2, 19, 20, 31"
      decision_needed: false
    - kind: "connection request"          # from a part or an outside system that wants to read, file or ask
      format: "Work Item (Protocol §4.1) naming the scopes asked: universes, collections, confidentiality levels, read or write, purpose, duration"
      acceptance_test: "TEST-SL v1, cases 8, 14, 24, 25, 37"
      decision_needed: true               # connect-external-port, signed at the tool gateway by the Source Lifecycle Lead
    - kind: "read request"                # a connected part asks for a source, within its grant
      format: "reference request through the output socket (ID, or ID and version, optionally at a pinned snapshot)"
      acceptance_test: "TEST-SL v1, cases 5, 6, 9-12, 15, 34, 35"
      decision_needed: false
    - kind: "needs request"               # a connected part asks for what its sources do not answer
      format: "needs request (contracts: the sockets contract, §5.8), as a sub-item of the part's own Work Item"
      acceptance_test: "TEST-SL v1, cases 28-33, 39"
      decision_needed: false
    - kind: "missing report"              # sent by a connected part with each pass
      format: "Missing Report (sockets contract)"
      acceptance_test: "TEST-SL v1, case 28"
      decision_needed: false
    - kind: "needs status"                # withdrawn or superseded, from the connected part
      format: "needs status (sockets contract)"
      acceptance_test: "TEST-SL v1, case 30"
      decision_needed: false
    - kind: "filing"                      # a connected part files a source of a named origin kind
      format: "source of an origin kind within the filing part's write scope (operating model, process and position design, delivery and implementation, or design report; for [ORG]AIOC-OER, correspondence and export), filed on behalf of a named HOAC position that holds a current contributor agreement"
      acceptance_test: "TEST-SL v1, cases 36, 87, 92, 93, 95"
      decision_needed: false
    - kind: "gap signal"                  # from [ORG]AIOC-OER: an act done without a source
      format: "one signal per act, by reference to the register entry, never content (Protocol §13, item 12)"
      acceptance_test: "TEST-SL v1, case 94"
      decision_needed: false
  delivers:
    - kind: "source"
      format: "versioned record (ID, version, SHA-256 hash), with its class, confidentiality level, sensitivity tags, document type, status and, for an item from conversation, each statement's label"
      usual_receivers: ["the HOAC positions, through the HU output port"]
    - kind: "source reference"
      format: "source reference (sockets contract): held or not held, within the grant"
      usual_receivers: ["[ORG]AIOC-TOM", "[ORG]AIOC-PPD", "[ORG]AIOC-DI", "any connected part"]
    - kind: "needs answer"
      format: "needs answer (sockets contract), by reference only"
      usual_receivers: ["[ORG]AIOC-TOM"]
    - kind: "needs status"
      format: "needs status (sockets contract): accepted, returned or asked"
      usual_receivers: ["[ORG]AIOC-TOM"]
    - kind: "notice"
      format: "notice naming each affected reference and version, never the content: revocation, narrowing, reclassification, supersession"
      usual_receivers: ["any connected part"]
    - kind: "filing receipt"
      format: "receipt naming the filed source's ID, version and hash, and its status"
      usual_receivers: ["[ORG]AIOC-TOM", "[ORG]AIOC-OER"]
    - kind: "gap list"
      format: "what is missing for this kind of owner, ranked by consequence, in plain words"
      usual_receivers: ["the HOAC positions, through the HU output port"]
    - kind: "export"
      format: "complete authorised export with digests (PRD FR-22)"
      usual_receivers: ["the HOAC positions, through the HU output port"]
  anatomy:
    panel: { health: { tests: true, metrics: ["stuck", "returned", "late", "inputs refused", "previews waiting", "gaps open", "needs open", "needs past deadline", "grants active", "grants expiring", "notices sent", "candidates by stage", "publication verified", "live qualification cycles"] } }
    back_office: { converses_with_humans: true, hosts: ["Chief of Staff", "Office"], protocol_traffic: true }
    definition: { location: "<org>aioc-sl, blueprint/SL-BLUEPRINT.md", version: "v0.1.6" }
    delivery: { rollback: "one-click" }
    connectors:
      - { role: "inbound data sources (document stores, code repositories, wikis)", connector: "data-source connector, one per source type", access_managed_in: "panel" }   # the Panel shows and requests it; the grant is signed at the tool gateway as connect-external-port (Protocol §13, item 5)
      - { role: "publication targets", connector: "publication adapter, one per target", access_managed_in: "panel" }
      - { role: "broadcast", connector: "broadcast adapter, one per channel", access_managed_in: "panel" }
    gateway: { metering_id: "<per-AIOC metering id>" }
  full_name: "Source Lifecycle"
  version: "0.1.6"
  lineage: { id: "[ORG]AIOC-SL", version: "0.1.5", relation: "original" }
  lifecycle_state: "designed"
  blueprint_version: "v0.1.6"
  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-SLL"
  hoac: "[ORG]HOAC-ACS"
  label_holder: "[ORG]CELL-SLL"
  fixed_test: { id: "TEST-SL", version: "v1", owner: "[ORG]CELL-TMS" }
  skills:
    - { id: "sl-intake", name: "Intake of every input from every kind of owner", tags: ["intake"] }
    - { id: "sl-conversation-to-record", name: "Conversation to record, with preview and approval", tags: ["intake"] }
    - { id: "sl-gap-finding", name: "Gap finding against owner profiles", tags: ["intake"] }
    - { id: "sl-document-production", name: "Governed document production, request to archive", tags: ["production"] }
    - { id: "sl-sockets", name: "Connections, output socket and needs requests", tags: ["connection"] }
  ports:
    - { unit: "[ORG]AIOC-SL", port: "ai-in", direction: "input", type: "AI", identification: "technical-key", accepted_content: ["connection request", "read request", "needs request", "missing report", "needs status", "filing", "gap signal"], authority_limit: "within each connected part's signed grant; nothing outside it is read, accepted or filed", audit_trail: "unit register and the serve log", required_tests: ["TEST-SL v1"], enforcement: "shared-gateway-outside-unit" }
    - { unit: "[ORG]AIOC-SL", port: "ai-out", direction: "output", type: "AI", identification: "technical-key", accepted_content: ["source reference", "needs answer", "needs status", "notice", "filing receipt"], authority_limit: "by reference only, within the grant; never a person's name; never a source's text outside a held, granted read", audit_trail: "serve log and the Work Item record", required_tests: ["TEST-SL v1"], enforcement: "shared-gateway-outside-unit" }
    - { unit: "[ORG]AIOC-SL", port: "hu-in", direction: "input", type: "HU", identification: "live-human-sign-in-at-gateway", accepted_content: ["contributor agreement acceptance", "input from a contributor", "approval, correction or rejection of a preview item", "answer to a row", "sharing setting by an authorised position"], authority_limit: "the contributor's current agreement and the position's authority_scope; a decision row needs a fresh live sign-in", audit_trail: "the event record of each item", required_tests: ["TEST-SL v1"], enforcement: "shared-gateway-outside-unit" }
    - { unit: "[ORG]AIOC-SL", port: "hu-out", direction: "output", type: "HU", identification: "live-human-sign-in-at-gateway", accepted_content: ["preview of the exact text to approve", "question in plain words", "gap list", "status of a request", "export", "brief to the Source Lifecycle Lead"], authority_limit: "information only; never a decision taken for the person", audit_trail: "the event record of each item", required_tests: ["TEST-SL v1"], enforcement: "shared-gateway-outside-unit" }
    - { unit: "[ORG]AIOC-SL", 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-SL 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: "<code of [ORG]AIOC-OCO>", 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"
    application_role_map: { value: "<one position code per application role, Annex A>", set_by: "<Cell carrying [ORG]HOAC-TM>", date: "<date>", version: "<vN>" }
    owner_profiles: { value: "<profile set, Annex C>", set_by: "<position>", date: "<date>", version: "<vN>" }
    default_confidentiality: { value: "<open: PRD D-15; proposed Confidential>", set_by: "<Cell carrying [ORG]HOAC-GOV>", date: "<date>", version: "<vN>" }
    contributor_agreement_version: { value: "<open: PRD D-17>", set_by: "<Cell carrying [ORG]HOAC-GOV>", date: "<date>", version: "<vN>" }
    gateway_present: { value: "yes", set_by: "<position>", 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). Until then its lifecycle_state stays designed and no Work Item is routed to it. The parts of the card that serve the next stage (needs requests, needs status, filing, notices, the reference fields and pinned snapshots) rest on PRD FR-35 to FR-46, which are Proposed until the decision PRD D-20 (§13). Until this card declares the sockets contract as adopted, [ORG]AIOC-TOM cannot start a run (its gate T0 fails with SL contract not supported). 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, as central texts do (Naming Standard R13). Each organisation fills [ORG] in its own copy. Positions only; who holds each one is kept only in the private register copy (Standard §5.2, Position Principle; 49GAION/DR-0011).

2.2 Placement

• Where it sits. A top-level AIOC under the Charter: the first part an organisation receives after the Charter, with [ORG]HOAC-GOV, [ORG]HOAC-TM and [ORG]AIOC-OCO installed in it (Protocol §13, item 1).
• Its role. It keeps the organisation's own sources, each with one valid version, and serves them by reference to the parts the organisation allows.
• Scope.
  • It does: take every kind of input from every kind of owner; check it at the door; turn talk into approved records; label statements; classify; let the owner set who sees what; take a document from request to archive through governed stages, with people deciding; govern its own AI agents and knowledge releases; find what is missing; connect other systems by approved, scoped and revocable grants; answer by reference; take needs requests, reach the right position, and answer by reference; accept filings from connected parts within their write scope; run trials and full exports.
  • It does not: decide anything that belongs to the owner; treat talk as true by default; record anything a person has not approved; store a secret; design the organisation; serve a source outside a grant; name a person to a connected part; enter the 49GAION Library with any of the owner's sources (Protocol §13, item 3).
• Owners it serves. Any owner: one person, a household, a company, a group or holding, or an institution (PRD §1).
• Boundaries with other AIOCs.
  • [ORG]AIOC-TOM and every later design stage read sources only through the output socket, ask for what they lack only through this AIOC's Chief of Staff, and file their releases here (PRD FR-35 to FR-46). They never reach a person. This AIOC never designs.
  • [ORG]AIOC-OER, the Operations Event Register, keeps what the organisation did, where SL keeps what it knows. It files only an entry a position asks to keep, as correspondence, and its projection of the work, as an export, within its write scope (§5.8), and sends gap signals (§5.2). It reads only the references of the sources its entries cite, never content, and SL never records its register (49GAION/DR-0027; New in v0.1.3).
  • [ORG]AIOC-OCO installs, fixes and upgrades this AIOC, builds its Panel, and carries its blueprint changes; it never grades it (Standard §2.3, item 9).
  • The IT and infrastructure division hosts the vault. SL never holds a secret; a socket to the vault comes later (PRD FR-33, D-16).
  • A replacement source. In a stage after the first, another source may stand beside SL, read only, through the reading part's own adapter. Asking and filing stay with SL (Protocol §13, item 7; the reading proposed by the Target Operating Model mother, github.com/49g-holding/49GAION-target-operating-model, upstream/PROPOSALS.md, item 8).
• Overlap. None known inside an [ORG]AION. Outside one, the product runs alone for owners with no [ORG]AION (PRD FR-34); the differences are in §11.

3. Positions

• Every human position is a HOAC position. This AIOC starts with one, the Source Lifecycle Lead, and the organisation may add more in this AIOC's own design (§17, Adding a HOAC position). The human application roles of the product (Annex A: the requester, the reviewers, the approvers, the final authority, the publication administrator and the others) are HOAC positions too: each is either a HOAC position of this AIOC, or a HOAC position elsewhere in the organisation, for example the [ORG]HOAC-GOV position as the final authority. No AI Cell ever holds one.
• No natural person (Standard §1.1, item 9; 49GAION/DR-0013). This blueprint deals with positions only. Who holds them, and how, is the organisation's own mechanism, outside the system; no part of this AIOC holds, reads or infers it.
• The Independent Auditor reports to the Lead, not to the Chief of Staff, so that the part that runs the work does not direct the part that checks it (PRD FR-11; New as a placement).
• No AI Cell signs, approves or decides anything that belongs to a person (Protocol §10, item 3; PRD FR-10 to FR-12). Each AI Cell's bot has its own identity card (§17).
• Each position's role pack is carried in the role cards of the capabilities it performs (§4, §5).

4. Standard capabilities

Defaults are in docs/STANDARD-CAPABILITIES.md of 49GAION-aioc 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 when the Lead needs more than one Chief of Staff, for example one instance per language or per owner, or a separate needs desk under heavy load (windowed position). It is proposed to the Lead, never self-created.

Process (SOP)

Default.

Role card

None while the form is a single Chief of Staff.

Fixed test

TEST-SL-COSSL v1 (TEST-SL v1, case 74) · result NOT_RUN

4.2 Chief of Staff

Definition

Default, connecting kind: it connects the owner's people with the parts that need them, and reports to its HOAC seat, the Source Lifecycle Lead. With these additions:

• The intake steward (PRD FR-27, FR-36). It is the person-facing half of requester stewardship: it reads back what was said, keeps each statement's label, never records less than what was asked, records contradictions without ruling on them, and asks for what is missing in plain words.
• The needs desk (PRD FR-35 to FR-40; §5.9). It is the only Cell that asks the owner's people anything on behalf of a connected part. It accepts or returns each needs request, chooses who answers a delegable row, asks only the named position for a non-delegable row, and answers by reference. It never answers for a person, never records content the person has not approved, and never decides.
• The orchestrator of the stages. It moves each item through intake, recording, classification and the document stages S0 to S12 (§5.0), dispatches the Cells, runs the code steps (the security scanner, the canonical build, the publication gates, the serve log, the notices) and writes the event record. Code is a tool, never a seat.
• Its HOAC seat is a position (Position Principle). It names the Lead by position code only. Open work, commitments and the delegation ladder in force stay with the position, whoever holds it.
• Position Chief of Staff. It also serves the Lead as the Position Chief of Staff (docs/STANDARD-CAPABILITIES.md §4.2, DR-0010; 49GAION/DR-0011, item 6), within the delegation ladder of §15. It signs for the Lead only within the grant the Lead has given it, which may reach a type of upstream/human-floor-signature-types.json; what it signs under that grant is the Lead's own decision (49GAION/DR-0053, item 11). The Lead's HU ports and stop door never pass through it.

Process (SOP)

Default, plus:

1. Intake. Every arrival goes first to the Input socket (§4.3). Admitted items are recorded as events with ID, version, status and owner position → admitted item (evidence: the event record).
2. Conversation. For talk, it opens a conversation with the Conversation Recorder (§5.1), and stays the voice to the person → preview items (evidence: the preview record, bound by hash).
3. Triage. Each item gets one class: decide (for the Lead or for another HOAC position), inform, file or act within limits. A decide item for the Lead goes as a decision request: one recommendation, the reason and the risks, whether it can be reversed, its own dissent, and what the waiting party does meanwhile → decision request (evidence: the request record).
4. Stages. It moves each document candidate through S0 to S12 only when the stage's actor, candidate and evidence check pass (PRD FR-05) → stage transition (evidence: the transition event).
5. Needs. It runs the needs desk (§5.9): accept or return, route, ask, approve, record, answer → needs answer (evidence: the needs log).
6. Waiting. Overdue items are reminded, then escalated, under waiting_deadlines; they show on the Panels of both sides. Silence closes nothing (PRD FR-37) → ageing record (evidence: the needs log).
7. Raise, never guess. An item with conflicting sources, no single valid version, an unresolvable position, or outside its limits goes to the Lead in one line, with its evidence → raised item (evidence: the Office record).
8. Stops and revocations. A stop takes effect at the tool gateway on every Pod and Cell of this AIOC; the Chief of Staff takes no action of its own and is itself stopped. Items in flight show held, never closed. After a signed restart-stopped-unit, it resumes from the records and the hand-offs → nothing (evidence: the unit register).
9. Brief. Each morning, and when called, it briefs the Lead: the decision requests, the status with evidence, the tests' scores, the grants expiring, the needs past deadline, the directives replaced since the last brief → brief (evidence: the Office record).

Role card

Fixed test

TEST-SL-COSSL v1 · result NOT_RUN

4.3 Input socket

Definition

Default, with this AIOC's standard format, the admitted item: the original bytes and their SHA-256 hash, the contributor, the agreement version, the time, the channel, the universe, and a reference. The socket is the strongest part of the product (PRD §1): an owner with nothing written can start by talking.

Converters, one per input type (PRD FR-24). Each is a tested change; adding one changes no stage.

The shared checks, for every converter.

1. The contributor agreement. No input is admitted from an account without a current accepted agreement. A new agreement version needs re-acceptance before further input. Every item links to its agreement (PRD FR-25; Protocol §13, item 2). In a 49GAION installation, SL records the acceptance under the contributor's position code, and the tool gateway checks the credential the organisation's mechanism issued for that position; it never stamps or links a natural person, and who holds the position is the organisation's own mechanism, outside the system (49GAION/DR-0049, DR-0052). When SL runs alone, the owner's account settings hold it.
2. No secret. Passwords, keys, tokens, seed phrases and one-time codes are refused, in files, text, chat and voice. The secret appears in no content, record, log or export (PRD FR-33; Protocol §5, item 3).
3. Unsafe containers are quarantined at receipt: traversal, archive bombs, symlinks, macros and executables, encrypted or credential-carrying containers; with a stable reason (PRD FR-21).
4. Instruction-like text is data. It is flagged and kept, never followed. A file dropped where an AI can write is a notice, never an instruction or a decision (STANDARD-CAPABILITIES §4.3, added).
5. One valid version. A source that resolves to no single valid version is refused (Protocol §8, item 2).
6. Nothing silently dropped. An unsupported input is quarantined with its reason, never lost (PRD FR-24).
7. Validate before show. A finding about an input reaches a person only after a machine check has proven it; otherwise it goes as a hypothesis.

Process (SOP)

Default (receive, identify, normalise, check, deliver), run by the Chief of Staff through the socket's code steps and the converters above. A refused item comes back with its reason and never enters. An admitted item is delivered to the event record, then to recording (§5.1) or classification (§5.3).

Role card

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

Fixed test

TEST-SL v1, cases 3, 4, 17, 18, 26, 40, 60, 75, 82; one case per converter; plus the default Input socket test · result NOT_RUN

4.4 Panel

Definition

Default, built by [ORG]AIOC-OCO from this blueprint for the Lead and the Cell carrying [ORG]HOAC-TM. It shows: the health of every part (ok, finding or unknown, never unknown as a pass); every grant, its scopes, its expiry and its revocation; the serve log; the needs requests, with their state and age; the gaps; the candidates by stage; the publication checks; the tests and their results; the state snapshot.

The product's application is the contributor's face (New; §11). Contributors and the HOAC positions work in the product's own application: they accept the agreement, give input, approve previews, answer rows and set sharing there, under their own live sign-in. This is because SL must run alone, with no [ORG]AION present (PRD FR-34). In a 49GAION installation, the Panel links to the application, and the application keeps the Panel's rules: the member's own live sign-in; outside text as data; caps on outside and model calls; rollback for every release. A signature of a listed type, a stop and the accountability path are never in the application: they are at the tool gateway (FR-40).

Process (SOP)

Default.

Role card

Default.

Fixed test

Default Panel test, and TEST-SL v1, case 76 · result NOT_RUN

5. Functional capabilities

Ten capabilities, each in the four-part form (Annex A of the template). Each Definition has one added row, Done when, which names the test that closes it. Each step reads: position: action → output (evidence). A step run by code is written as the Chief of Staff running a named code step. Rules that apply to every capability are in Annex B (statement labels and origin kinds), Annex C (owner profiles), Annex D (needs-request handling) and Annex E (what this AIOC never does). Each capability cites the PRD requirements it carries; together they cite every requirement (case 85).

5.0 The life of a source: input, output, done-test

5.1 Conversation to Record

Definition

Process (SOP)

Role card

Fixed test

TEST-SL-SLCR v1 (TEST-SL v1, cases 1, 2, 19, 20, 31, 82) · result NOT_RUN

5.2 Gap Finding

Definition

Process (SOP)

Role card

Fixed test

TEST-SL-SLGF v1 (TEST-SL v1, cases 6, 21, 89, 94) · result NOT_RUN

5.3 Classification and Sharing

Definition

Process (SOP)

Role card

Fixed test

TEST-SL-SLSC v1 (TEST-SL v1, cases 22, 23, 42, 43) · result NOT_RUN

5.4 Document Production

Definition

Process (SOP)

Role card

Fixed test

TEST-SL-SLD v1 (TEST-SL v1, cases 41, 44, 46, 88) and TEST-SL-SLIA v1 (TEST-SL v1, cases 50, 51, 79) · result NOT_RUN

5.5 Publication and Activation

Definition

Process (SOP)

Role card

No AI Cell of its own. The code steps are run by the Chief of Staff (§4.2); the decisions are the HOAC positions' (Annex A).

Fixed test

TEST-SL v1, cases 53 to 55, 57 (owner: [ORG]CELL-SLL) · result NOT_RUN

5.6 Revision and Retirement

Definition

Process (SOP)

Role card

No AI Cell of its own; code steps run by the Chief of Staff; decisions by the HOAC positions (Annex A).

Fixed test

TEST-SL v1, cases 56, 61 (owner: [ORG]CELL-SLL) · result NOT_RUN

5.7 Agent and Knowledge Governance

Definition

Process (SOP)

Role card

No AI Cell of its own. Each AI Cell of this AIOC (§17) runs only as an eligible package of this capability.

Fixed test

TEST-SL v1, cases 45 to 49, 58 (owner: [ORG]CELL-SLL) · result NOT_RUN

5.8 Connections and the Output Socket

Definition

The reference (PRD FR-41; the sockets contract's source reference). The ID, version and SHA-256 hash; held or not held; the snapshot ID; the origin kind (Annex B); the status from SL's own list (draft, in review, approved, in force, superseded); the confidentiality level; for an export, the date it is as of; and, for an item from conversation, each statement's label with its anchor.

Pinned snapshots (PRD FR-42). A connected part may pin a content-addressed snapshot (SLM-<sha256>) and read every reference at it for the life of its run, and read the references named in a needs answer at the snapshot that answer names. A version superseded after the pin is served at the pinned bytes with its current status shown as superseded. Every snapshot named by a filed release stays readable at its pinned bytes while that release, or a release that carries it forward, is not withdrawn.

The organisation-design grant (PRD FR-32, FR-44). It has three parts: unrestricted read; least-privilege write for filing only, limited to the filing part's own origin kinds; and needs requests. The write scope of each design stage (New in v0.1.1; PRD FR-41 and FR-44 to be amended at the PRD's next opening):

A design report that holds a return is filed with the hash of the return as sent, and each later version of the return supersedes the one before; the filed copy never changes. The approval screen states plainly that Strictly confidential items will be visible. A partial scope cannot be granted for this connector type.

Filing (PRD FR-43). A connected part with a write scope files a source of one of its own origin kinds, on behalf of a named HOAC position whose answering sign-in has a current contributor agreement. The filing is content-addressed, records what it supersedes, and takes its status from the approval decision it cites. A filing without a write scope, or without a contributor position, is refused. Correspondence (New in v0.1.3): a source of origin kind correspondence is filed only by [ORG]AIOC-OER, on behalf of the position that asked to keep the entry; its hash equals the register entry's content hash; it is class EVIDENCE, kept as received, and never served as the owner's own statement (Annex B).

Notices (PRD FR-45). On a revocation, a narrowing, a reclassification or a supersession that affects references a part has read, that part receives a notice naming each affected reference and version, never the content.

The sockets contract (PRD FR-46). The needs-request, needs-answer, needs-status, Missing Report and source-reference contracts are versioned JSON Schemas with fixtures. The first drafts are those of the Target Operating Model mother (github.com/49g-holding/49GAION-target-operating-model; its versions before v0.6.1 are in the archived github.com/49g-holding/49aioc-tom) v0.4.0 (contracts/README.md of this repository names them by path and hash). SL adopts or changes them under PRD D-20. A change names every connected part it affects and re-runs the cross-AIOC test (Protocol §11, item 2). The v0.6 drafts (the same mother, v0.6.0; New in v0.1.2): an element row carries its proposed priority, which SL shows with the row; the priority decided is recorded with the decision; an export request for records of the work states its aggregation, by role-type and process (Annex F.3).

Process (SOP)

Role card

No AI Cell of its own. The socket's code steps are run by the Chief of Staff; the grant is the Lead's.

Fixed test

TEST-SL v1, cases 5, 6, 8 to 15, 24, 25, 34 to 39, 87, 91, 92, 93 and 95 (owner: [ORG]CELL-SLL) · result NOT_RUN

5.9 Needs Requests

Definition

Process (SOP)

Role card

Performed by the Chief of Staff ([ORG]CELL-COSSL, §4.2), with the Conversation Recorder for explainers (§5.1).

Fixed test

TEST-SL-COSSL v1 (TEST-SL v1, cases 28 to 33, 77, 80, 81) · result NOT_RUN

5.10 Trial and Exit

Definition

Process (SOP)

Role card

No AI Cell of its own.

Fixed test

TEST-SL v1, cases 27, 61, 72 (owner: [ORG]CELL-SLL) · result NOT_RUN

6. Coordination and routes

• With connected parts (the design stages [ORG]AIOC-TOM, [ORG]AIOC-PPD and [ORG]AIOC-DI, and any other): through the 49GAION Operating Protocol only. A connected part's needs request is a sub-item of its own Work Item; SL answers the sub-item and never opens a new item back, so the chain never loops (Protocol §4.6, item 2). Reads and filings pass through the output socket within the grant. Every route passes the tool gateway.
• With the HOAC positions: through the HU ports, in the product's application, under a live sign-in at the tool gateway (§4.4). The Chief of Staff is the only Cell that asks them anything for a connected part.
• With [ORG]AIOC-OCO: install, fixes, upgrades, the Panel, and every blueprint change, as design-proposal Work Items (template §6).
• Routing rows this AIOC contributes: needs request → [ORG]AIOC-SL; filing of origin kind operating model, process and position design, delivery and implementation, or design report → [ORG]AIOC-SL; filing of origin kind correspondence or export from [ORG]AIOC-OER → [ORG]AIOC-SL; gap signal → [ORG]AIOC-SL; read of a source → [ORG]AIOC-SL output socket.
• Requests and objections. Owners do not design or change this AIOC's AIs: every proposal, correction or critique is a design-proposal Work Item to OCO; where they disagree, the Lead may hold the objection open until it reaches the position accountable for OCO, which decides.

7. Records and where things live

8. Tools and the shared AI gateway

All model calls go through the shared AI gateway in the [ORG]AION (Standard §4.4, item 11). This AIOC's AI use and cost are metered separately; its budget cap is set in §15. Open reconciliation: the product holds connector credentials in its own server-side vault (PRD §4.3); Protocol §13, item 5 allows a connection's token only in the platform's secret store or behind the tool gateway. Whether the product's vault is the platform's secret store is to be confirmed by the SL technical lead (§13, H-12).

Mechanism register. Read on 14 October 2026 from the PRD's inventory (§4, §11), in the first instance; "built" means running there on a demonstration branch, never qualified (0 of 3 cycles). An instance keeps its own register. A row is never deleted.

Reserve.

9. Fixed tests: index, triggers and scores

The cases are written in tests/TEST-SL.md. Cases 1 to 16 are the Library's TEST-SOURCE-LIFECYCLE v1, cases 1 to 16, unchanged. Cases 17 to 72 are the PRD's own acceptance, one case per requirement. Cases 73 to 91 test this AIOC's form. Cases 92 to 95 test the feeds of the Operations Event Register (New in v0.1.3).

• Re-run triggers: any change to a model, instructions, this AIOC's card, this blueprint, the PRD, the sockets contract or the 49GAION Operating Protocol re-runs the affected tests; also any change to tools or access, a converter, or a shared panel part.
• The product's qualification is separate and stays as the PRD sets it: exactly three integrated cycles on one frozen candidate (PRD §10). A case of TEST-SL is never counted as a qualification cycle, and a passing case never qualifies a changed candidate.
• The non-functional requirements NFR-01 to NFR-10 apply across every capability; they are cases 63 to 72. Most of their targets are open in the PRD, and a case with no target stays NOT_RUN.
• Complete only when every capability's test has a visible result. NOT_RUN is never PASS.

Checks that are not fixed tests.

• Discriminating evidence. A passing check counts only if it has been shown able to fail on the case it guards, and evidence is written by the runner, never by the worker.

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. The product's own delivery stays on its code project's path, with its own audit and qualification (PRD §10).

11. Exceptions

1. The product's application is the contributor's face (§4.4). The Standard makes the Panel the only surface humans use. SL must run alone, with no [ORG]AION (PRD FR-34), so contributors and the HOAC positions work in the product's application, which keeps the Panel's rules. Proposed to the mother (§12, item 1).
2. A Chief of Staff of the connecting kind that also orchestrates. The Chief of Staff connects people with parts and also moves items through the stages. One Cell does both because every person-facing question must pass one door; if load grows, an Office is proposed (§4.1).
3. The Position Chief of Staff is this AIOC's Chief of Staff. The Standard attaches a Position Chief of Staff to the position's Cell. Here the AIOC's own Chief of Staff serves the Lead in that role, with no attached Cell, so that the Lead has one voice to deal with.
4. "The seat that [ORG]AIOC-SL is accountable to" (Protocol §13, item 5) is read as the position carrying [ORG]HOAC-ACS over this AIOC, the Source Lifecycle Lead, and not as the Cell carrying [ORG]HOAC-TM named in the card's accountable_to. Proposed to the mother (§12, item 2).
5. Human application roles map to HOAC positions in or out of this AIOC (Annex A). The template's positions table lists this AIOC's own positions; here a human role of the product may also be filled by a HOAC position elsewhere in the organisation, such as the [ORG]HOAC-GOV position.

12. Lessons and proposals to the mother

One dated line per lesson, each written without the organisation's details. Nothing is proposed upstream without the word of the [ORG]HOAC-GOV position; the drafts are in upstream/PROPOSALS.md.

1. 2026-10-15 · A part that is also sold alone needs a face that runs without an [ORG]AION. Test question added: case 76 (the application keeps the Panel's rules). Proposed to the mother as a draft: allow a product face that keeps the Panel's rules, with signatures, stops and the accountability path still at the gateway.
2. 2026-10-15 · Protocol §13, item 5 names "the [ORG]HOAC-ACS seat that [ORG]AIOC-SL is accountable to", while the card's accountable_to names the TM Cell. Test question added: case 8 reads the label holder. Proposed to the mother as a draft: write "the holder of [ORG]HOAC-ACS over [ORG]AIOC-SL".
3. 2026-10-15 · The Library's Source Lifecycle card has 16 cases; the next stage needs twelve more (SL-A1 to SL-A12, already proposed by the Target Operating Model mother, upstream/PROPOSALS.md, item 5). Not proposed again here.
4. 2026-10-16 · A study of comparable products found that an owner's sources are judged complete only against a fixed list of essentials, and that every design stage needs the owner's own words. Test questions added: cases 88 and 89. Proposed to the mother as a draft, with the rule for records of the work (case 90): 49GAION/DR-0023.

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

Money, people and legal matters are marked. The PRD's open decisions are named by their PRD ID and not restated.

14. Change log

15. Configuration

Every slot is filled by the organisation; an AIOC with any empty slot does not pass the joining test (Protocol §11). Each value records who set it, when, and in which version.

16. Type

• Type: Foundational, as in §0.
• Why this AIOC exists in this organisation: every source of <organisation> enters through it, and every later part of its [ORG]AION builds on what it holds.
• Type-specific test: TEST-SL v1, case 15 (the next stage receives sources only by reference, and asks through SL) · 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 Source Lifecycle Lead. Every field that points to a human takes a position code only (template, Position codes only).

The card data (the blueprint governs). The block below holds every value of every Pod and Cell card and of the bot identity card of every AI Cell. tools/make_cards.py expands it into the complete forms of the template and of spec/schemas/unit-card.schema.json and bot-identity-card.schema.json of 49GAION-protocol, writes them into cards/ as generated copies, and checks them against the schemas, the code rules of tests/cards/check_cards.py of 49GAION-protocol, and this blueprint.

parts:
  defaults:
    accountable_to: "[ORG]CELL-SLL"
    card_version: "v0.1.6"
    version: "0.1.6"
    lifecycle_state: "designed"
    test_version: "v1"
    test_owner: "[ORG]CELL-SLL"
    audit_trail: "the event record of [ORG]AIOC-SL"
    hu_in: ["direction from the Source Lifecycle Lead (never a source)"]
    hu_out: ["report to the Source Lifecycle Lead"]
  cells:
    - code: "[ORG]CELL-SLL"
      full_name: "Source Lifecycle Lead"
      parent: "[ORG]AIOC-SL"
      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: ["connect-external-port", "grant-or-widen-access", "change-fixed-test-or-threshold", "change-filler", "move-work-toward-ai"]
        entity: "<entity>"
        expires: "2027-10-15"                # placeholder; the organisation sets it
        authority: "delegated"
      test: { id: "TEST-SL-SLL", cases: "8, 13, 14, 23, 25, 37, 78, 81", owner: "[ORG]CELL-TMS" }
      ai_in: ["decision requests from the Chief of Staff", "brief", "findings of the Independent Auditor"]
      ai_out: ["direction and configuration"]
      hu_in: ["direction from the Cell carrying [ORG]HOAC-TM"]
      hu_out: ["grants, scopes and revocations, signed at the tool gateway", "rulings on raised items", "report to the Cell carrying [ORG]HOAC-TM"]
    - code: "[ORG]CELL-COSSL"
      code_rule: "R16"                     # 49GAION/DR-0028; replaces [ORG]CELL-SLCS (retired, R5)
      lineage: { id: "[ORG]CELL-SLCS", version: "0.1.3", relation: "derived" }
      full_name: "Source Lifecycle Chief of Staff"
      role: "Chief of Staff"
      parent: "[ORG]AIOC-SL"
      type: "AI Chief of Staff"
      filler_kind: "ai"
      cell_kind: "chief-of-staff-cell"
      test: { id: "TEST-SL-COSSL", cases: "3 to 7, 9 to 12, 15, 17, 18, 24, 26, 28 to 36, 38, 40, 44, 53 to 55, 57, 59, 60, 73 to 77, 80 to 83, 92 to 95" }
      ai_in: ["admitted item", "connection request", "read request", "needs request", "missing report", "needs status", "filing", "gap signal", "draft items", "classification proposal", "gap list", "contradiction record", "candidate", "audit finding"]
      ai_out: ["source reference", "needs answer", "needs status", "notice", "filing receipt", "dispatch to a Cell", "decision request to the Source Lifecycle Lead"]
      hu_out: ["preview of the exact text to approve", "question in plain words", "gap list", "brief to the Source Lifecycle Lead"]
      external_ports:
        - { port: "src-in", direction: "input", accepted_content: ["items pulled by a data-source connector"], authority_limit: "the scopes signed under connect-external-port for that connector", audit_trail: "unit register connected and disconnected events" }
        - { port: "pub-out", direction: "output", accepted_content: ["canonical artefacts of an approved candidate"], authority_limit: "the approved targets of the universe only", audit_trail: "unit register connected and disconnected events; the S9 and S10 receipts" }
        - { port: "notify-out", direction: "output", accepted_content: ["change brief and broadcast of an effective version"], authority_limit: "the channels set for the universe; never a source's text beyond its sharing setting", audit_trail: "unit register connected and disconnected events" }
      bot:
        allowed_actions: ["record and triage items", "dispatch Cells of this AIOC", "run the code steps of the Input socket, the stages and the output socket", "accept or return a needs request on the contract's reasons", "choose who answers a delegable row", "ask the HOAC positions in plain words", "show previews for approval", "answer by reference within a grant", "send needs status, notices and filing receipts", "brief the Source Lifecycle Lead"]
        ask_first_actions: ["a new explainer template or owner profile", "any change to configuration", "any act on a grant", "a budget above the cap", "anything outside its role card"]
    - { code: "[ORG]CELL-SLIA", full_name: "Source Lifecycle Independent Auditor", role: "Independent Auditor", parent: "[ORG]AIOC-SL", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-SL-SLIA", cases: "50, 51, 79" }, ai_in: ["candidate", "its evidence", "the controlling sources"], ai_out: ["audit finding"], bot: { allowed_actions: ["audit a candidate and write findings"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-SLCR", full_name: "Source Lifecycle Conversation Recorder", role: "Conversation Recorder", parent: "[ORG]POD-SLIR", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-SL-SLCR", cases: "1, 2, 19, 20, 31, 82" }, ai_in: ["conversation", "explainer template"], ai_out: ["draft items with statement labels"], bot: { allowed_actions: ["ask plain questions", "draft and label items", "read back what was said"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-SLSC", full_name: "Source Lifecycle Source Classifier", role: "Source Classifier", parent: "[ORG]POD-SLIR", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-SL-SLSC", cases: "22, 23, 42, 43" }, ai_in: ["admitted item"], ai_out: ["classification proposal"], bot: { allowed_actions: ["propose a category, class, confidentiality level, tags and document type, with reasons"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-SLGF", full_name: "Source Lifecycle Gap Finder", role: "Gap Finder", parent: "[ORG]POD-SLIR", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-SL-SLGF", cases: "6, 21, 89, 94" }, ai_in: ["corpus, read only", "owner profile set", "gap signal"], ai_out: ["gap list"], bot: { allowed_actions: ["compare holdings with the profile and list gaps, ranked"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-SLCA", full_name: "Source Lifecycle Consistency Auditor", role: "Consistency Auditor", parent: "[ORG]POD-SLIR", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-SL-SLCA", cases: "5, 20, 43" }, ai_in: ["new source", "corpus, read only"], ai_out: ["contradiction record"], bot: { allowed_actions: ["find and record contradictions and conflicts without ruling"], ask_first_actions: ["anything outside its role card"] } }
    - { code: "[ORG]CELL-SLD", full_name: "Source Lifecycle Drafter", role: "Drafter", parent: "[ORG]POD-SLDP", type: "AI Agent", filler_kind: "ai", test: { id: "TEST-SL-SLD", cases: "41, 44, 46, 88" }, ai_in: ["classified request", "eligible knowledge"], ai_out: ["candidate"], bot: { allowed_actions: ["draft a candidate within its governed package"], ask_first_actions: ["anything outside its role card"] } }
  pods:
    - { code: "[ORG]POD-SLIR", full_name: "Source Lifecycle Intake and Recording", type: "AI Pod", inner_units: ["[ORG]CELL-SLCR", "[ORG]CELL-SLSC", "[ORG]CELL-SLGF", "[ORG]CELL-SLCA"], top_cell: "[ORG]CELL-SLCR", test: { id: "TEST-SL-SLIR", cases: "1, 2, 5, 6, 19 to 23, 31, 42, 43, 89, 90, 94" }, ai_in: ["admitted item", "conversation", "explainer template", "owner profile set"], ai_out: ["draft items", "classification proposal", "gap list", "contradiction record"] }
    - { code: "[ORG]POD-SLDP", full_name: "Source Lifecycle Document Production", type: "AI Pod", inner_units: ["[ORG]CELL-SLD"], top_cell: "[ORG]CELL-SLD", test: { id: "TEST-SL-SLDP", cases: "41, 44, 46, 88" }, ai_in: ["classified request", "eligible knowledge"], ai_out: ["candidate"] }

• Accountability. Every Pod and Cell of this AIOC is accountable_to [ORG]CELL-SLL. The AIOC itself and the Lead are accountable_to the Cell carrying [ORG]HOAC-TM, which signs the AIOC's install, its change-parent and its restart-stopped-unit.
• The Lead's authority. The authority_scope of [ORG]CELL-SLL lists the listed types it signs on this AIOC's connections and Cells. The expiry date is a placeholder. The listed types on the owner's own data (export-share-or-purge-personal-data, dispose-records-or-data, set-purpose-or-values and the others) are signed by the owner's HOAC positions, never by the Lead for them.
• Bots. Each AI Cell's bot (seven) has its own identity card, with its own credential, never_signs: true, and its memory sealed on a change of filler (Protocol §10, item 3). The credential IDs in cards/bots/ are placeholders; the credentials live only in the organisation's vault.
• Engines. A bot's identity card names no engine. The gateway binds engines per call (engine_binding). The Independent Auditor's binding is distinct from the Drafter's, and of another engine family where the register allows (case 79).
• Not Cells of this AIOC: the HOAC positions elsewhere in the organisation that Annex A maps (for example the [ORG]HOAC-GOV position), and the Chief of Staff of any connected part.

Adding a HOAC position.

• At least one; more may be added. This AIOC has at least one HOAC position, the Source Lifecycle Lead. The organisation may add more in this AIOC's own design: for example an ACS position for each universe, for a stage of Document Production, or for a human application role it wants inside SL (Annex A), including ACS positions that act for the [ORG]HOAC-GOV position.
• How. Each is a tested change to this blueprint, made through OCO and approved by the human hub. It adds one human Cell to the parts block, with its HOAC label (a board behind a position is the organisation's own; decision_rule is withdrawn, 49GAION/DR-0049); its accountable_to, the HOAC position above it (the Lead, the [ORG]HOAC-GOV position for an ACS position acting for it, or the Cell carrying [ORG]HOAC-TM); its authority_scope, the listed types it signs, delegated under delegate-authority where it acts for a position above it; and its fixed test. tools/make_cards.py regenerates the cards and refuses a human Cell with no HOAC label.
• Position, not person. Each names a position only (Standard §1.1, item 9). Who holds it, and how, is the organisation's own mechanism, outside the system (49GAION/DR-0048, DR-0049). This blueprint never names a person and never reads who holds a position.

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 code is checked again against the organisation's unit register before first use (R6, R15.3).

The codes checked against: the ten codes above against each other; the codes of [ORG]AIOC-TOM v0.4.0 ([ORG]CELL-TDL, -TCS, -TSP, -TRA, -TSRA, -TFR, -TWS, -TP, -TD, -TSD, -TLR, -THA, -TSA, -TSW, -TBRA to -TBRE; [ORG]POD-TRR, -TS, -TEP, -TEM, -TH, -TW, -TR); the example codes [ORG]AIOC-CH, [ORG]AIOC-OCO, [ORG]CELL-TMS, [ORG]CELL-GOV, [ORG]POD-RV. UNVERIFIED against any organisation's unit register; each organisation checks them in its own.

Annex A. The product's application roles and the HOAC positions that fill them

The product names its application roles in code (src/lib/stageRolePolicy.ts; 14 roles, PRD §4.1). Each human role is filled by a HOAC position, set in the configuration slot application_role_map (§15): a HOAC position of this AIOC (§17), or one elsewhere in the organisation. No AI Cell ever fills one. The list below is read from the PRD; the code's registry governs, and the SL technical lead confirms it (PRD §4).

Annex B. Statement labels, origin kinds, status and confidentiality

Statement labels (PRD FR-27). Every statement in an item from conversation carries one:

• stated: the person said it in their own words and approved it;
• inferred: drawn from what was said, but not said;
• assumed: taken without basis in what was said;
• unknown: asked, not answered.

A label is never raised: an inferred or assumed statement becomes stated only when the person says it in their own words and approves it. An inferred or assumed item is never shown or exported as stated.

Origin kinds (PRD FR-41): document, explainer, confirmation, status, export, decision, operating model, process and position design, delivery and implementation, design report, correspondence. The two kinds of the later design stages are New in v0.1.1, and correspondence in v0.1.3; the PRD's list follows at its next opening.

Correspondence (New in v0.1.3; 49GAION/DR-0027). A letter, a formal e-mail, a post or another formal item that the organisation sent or received, kept because a position asked to keep its entry in the Operations Event Register. It is class EVIDENCE: evidence that the item was sent or received as it stands. It is kept as received, never edited, and its hash equals the register entry's content hash. Its status is approved once the asking position approves the filing. Its content is never served as the owner's own statement, and its statements carry no label of the owner (statement labels apply to the owner's own words). Correspondence with counsel is filed by reference only, Strictly confidential.

Status (PRD FR-29; the reference's list): draft, in review, approved, in force, superseded. A source has exactly one valid version (Protocol §8).

Confidentiality levels (PRD FR-29, Proposed): Public, Internal, Confidential, Strictly confidential (named people only). Sensitivity tags: personal data, financial, legal or privileged, staff, security.

Classes (PRD FR-03): CONTROLLING, OPERATIONAL_SUPPORTING, DERIVED_COMMUNICATION, EVIDENCE, HISTORICAL_PROVENANCE, PACKAGING, NON_DOCUMENT. A derived text never gains authority by relabelling.

Annex C. Owner profiles

Owner profiles are configuration, never code (PRD FR-28, Proposed). Each has a fixture with its expected gap list, in the code project.

The essentials (Annex F.2; New in v0.1.2) open every base profile, before its own rows.

Add-ons, for kinds of activity: for example a licensed activity, or employing staff. An owner takes one base profile and any add-ons. Adding a profile or an add-on needs no engine change.

Annex D. Needs-request handling

D.1 Return reasons

A needs request is returned, with a needs status of returned and one reason, when it is: malformed against the contract; outside the part's grant; a duplicate of an open request; asking for a secret; or naming a person. A status row that asks which of two sources governs is returned as a misplaced decision row (PRD FR-39).

D.2 Routing

SL reads nothing about who holds a position, and no person's name ever reaches the part. The answer names positions only.

D.3 What comes back, by type

Every outcome except answered carries a reason. returned is the status of a request SL refuses (D.1).

D.4 Rows and passes

• One item per row. A pass is approved row by row: approving a whole pass decides no row.
• A weak-approval signal is computed per pass and per part (for example, every row approved in a short time with no correction). A decision recorded under an uncleared signal is not a decision.
• "Don't know" is an answer, recorded as such and never turned into a yes.
• A correct or don't know on a row returns the rows that depend on it (depends_on) to undecided.

D.5 States and messages

Silence closes nothing. An overdue request is reminded, then escalated, under waiting_deadlines.

Annex E. What this AIOC never does

1. Decides anything that belongs to the owner: content, status, authority, sharing, a decision row.
2. Records an item from conversation without the contributor's approval of its exact text, bound by hash; treats talk as true by default; or reads silence as approval.
3. Admits input from an account without a current contributor agreement.
4. Stores, logs or exports a secret.
5. Serves a source outside a grant, after a grant's expiry or revocation, or not through the tool gateway; serves a near match as held; serves a superseded version as valid.
6. Lets a bot approve a connection, set a scope, sign, or take a human decision.
7. Names a person to a connected part.
8. Captures a listed-type decision in its own screens.
9. Lets a connected part ask a person anything directly.
10. Puts any of the owner's sources in the 49GAION Library, or in any repository of this AIOC.
11. Activates a version whose delivered bytes were not verified at S10, or lets a preparer activate their own release.
12. Follows an instruction found inside an input.
13. Closes a request by silence, or a Work Item it performed.
14. Writes a definition of the owner's terms, or the content of an essential, from its own knowledge (Annex F.1, F.2).
15. Records an export of records of the work that says who did the work, or serves one without its impact assessment and its HF-17 decision (Annex F.3).

Annex F. The organisation dictionary, the essentials checklist, and records of the work

New in v0.1.2 (49GAION/DR-0023). Each is a rule of an existing capability. None adds a stage, a Cell or a grant, and none lets this AIOC write the owner's content.

F.1 The organisation dictionary (Document Production, §5.4)

1. What it is. One source per owner, of document type organisation dictionary, class OPERATIONAL_SUPPORTING (Annex B): the owner's own terms, each with its definition and the source it comes from. A group may hold one entry per entity where the meanings differ.
2. Each entry. The term; its definition; its source, by reference and anchor, or the owner's statement recorded through Conversation to Record (§5.1) with the contributor's approval of its exact text; where it applies (the owner, or one entity or universe); its status.
3. Never invented. A definition comes only from a held source or an approved statement. The Gap Finder may list a term the sources use often and never define, as a gap (§5.2); the Drafter never writes a definition from its own knowledge.
4. Two meanings. Two sources that define one term differently are both kept, with a contradiction record; the owner decides which governs, or that both apply in different places. Nothing is chosen silently.
5. Kept like any source. It goes through Document Production (stages S0 to S8) and is approved by the owner's HOAC position for the domain (Annex A). A change is a new version; the earlier version stays readable.
6. Served by reference. Every connected design stage reads it, within its grant, at the snapshot it pins (§5.8), so that each stage uses the owner's words in the owner's meaning. It is one of the essentials (F.2).

F.2 The essentials checklist (Gap Finding, §5.2)

1. Part of every base profile (Annex C), before any add-on. Seven rows, each held (by reference), missing, or not applicable (marked once, by the owner's HOAC position):

2. A flag, never a source. A missing row is a gap, ranked like any other. It never closes by silence, and this AIOC never drafts its content for the owner; the owner may open a Document Production request for it.
3. Before a design run. When a Design Request is put to its approving position, the Chief of Staff shows beside it the essentials still missing, in plain words. The approval decides nothing about them; a design stage that needs one asks for it by needs request (§5.9).

F.3 Records of the work as it runs (Classification and Sharing, §5.3; Needs Requests, §5.9)

1. What it is. An export of records of the work as it runs: work queues, case logs, workflow and time records.
2. Only the owner's projection. It is recorded only as the owner's projection by role-type and process. The owner's own mechanism removes who did the work, and any line that would still point to whoever did it, before the export reaches this AIOC. This AIOC never receives the records before that projection.
3. Data protection first. Before it is recorded, the position that holds data protection (HF-17) records an impact assessment of the export and its decision on it. Where the projection moves personal data, the decision is the listed type export-share-or-purge-personal-data, signed at the tool gateway (Annex D.2).
4. Refused. An export offered with a field that says who did the work (a name, an identifier, a contact) is not recorded, and nothing of it is kept; the reason is person-level records. An export without its impact assessment and its HF-17 decision is not served.
5. Served as origin kind export, with its as_of date (§5.8). Where a needs request asked for it, the request states the aggregation by role-type and process (the v0.6 sockets contract).
6. Why. A connected design stage may read how the work runs today, by role-type and process, and never anything about a person. Where no such export exists, nothing is put in its place.
7. From the Operations Event Register (New in v0.1.3; 49GAION/DR-0027). Where the organisation has [ORG]AIOC-OER, its projection of the work by role-type and process is one such export. It is filed by that part within its write scope (§5.8), under every rule of this annex, and refused at this AIOC's Input socket if any field says who did the work.

[ORG]AIOC-SL mother blueprint v0.1.6 · Powered by 49GAION