49GAION Organisation Design and Delivery · product blueprint · v0.1.3

Draft, 20 October 2026. The blueprint of the first assembly of the 49GAION Library (49GAION/DR-0025; Standard §3.1, item 12). It lists the product's parts by pin, how they connect, what goes in, what comes out, what the product is for, what the product itself sets, and its one shared test. The product adds no capability of its own: its features are its parts' features. Every rule here rests on a 49GAION text or on a part's blueprint, cited by section. Nothing here has run. Every fixed test reads NOT_RUN until the part is built and run; that is the policy of the Library, not a defect.

The product in one page

What it is. One product made of four Library parts placed side by side and connected:

• Source Lifecycle (SL) keeps the organisation's own sources;
• Target Operating Model (TOM) designs what the organisation does and how it is governed;
• Process and Position Design (PPD) designs how the work runs and the positions that carry it;
• Delivery and Implementation (DI) takes the decided design into a running organisation, and runs and improves it with the organisation.

Each of the four is built and kept on its own: Source Lifecycle and the Target Operating Model are offered alone, and Delivery and Implementation runs without the others. Together they are this product.

What goes in. The organisation's own documents, and what its people say once they have approved it. A Design Request, approved by the organisation's Requesting Authority, says what should be different. Answers to questions, asked only through Source Lifecycle. Optionally, the running work as an export by role-type and process, or a design made elsewhere.

What comes out. A decided design of an organisation of human positions, taken into a running organisation:

• a decided operating model (capabilities, value streams, decision rights, interfaces, a role register, a strategy frame, a value case and priorities);
• decided processes, positions with job descriptions, units, controls, workload and the crosswalk from today's organisation;
• a launch package (procedures, briefs, transition plan, go-live criteria);
• then go-live, stabilisation, one operating rhythm and a living design.

Every release is decided element by element by the organisation's own positions and is filed in Source Lifecycle.

What it is for. An organisation, new or existing, goes from its own sources to a working organisation of human positions, with every element traced to a source or a decision.

What it never does. It never decides which positions an AI fills: that is the next level (§12). No output names a person, and no stage reads who occupies a position. It never decides for the organisation. AI prepares; human positions decide.

How to start. The organisation names its Requesting Authority, arranges the four accountable positions, connects the parts and approves a Design Request. The organisation may stop after any stage, and no stage waits for a later one (§8).

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. This product designs an organisation of human positions; how human and how much AI the organisation is, is the [ORG]AION's own design work, prepared by it and decided by the governance seat. Every rule here that names [ORG]AIOC-OCO reads as the Top Management Group, the hub of the operation, human and AI. The readings are in decisions/DR-0002. Nothing here is removed.

0. Identity

1. Why one product

1. Built from the smallest units (Standard §1.7, item 16; 49GAION/DR-0025, item 1). Each part is built once and kept, with its own blueprint, card, fixed test, repository and version. A product is made by combining parts, never by rebuilding them.
2. Each part stands alone (Protocol §21, item 1; Standard §3.1, item 10). Source Lifecycle is offered alone. The Target Operating Model "is a product on its own" (Protocol §19, item 9). Delivery and Implementation runs without any other part, behind its own gateway (Protocol §20, item 11).
3. This set is one product because its input and its output are known. It starts from the organisation's own sources and ends with a decided design of human positions, taken into a running organisation. No part alone covers that whole way.
4. A part may serve in more than one product (49GAION/DR-0025, item 3). Source Lifecycle also serves in 49GAION Organisation Memory, beside the Operations Event Register (Standard §3.1, item 14). The Operations Event Register is not a part of this product.

2. The parts, by pin

The pins are in pins/PINS.json and equal the Library register at 47fb6e1. tools/check_pins.py reads every file back at its commit, checks its SHA-256, and checks that each part's pin equals its row in the Library register (TEST-DESIGN-CHAIN v2, case 10).

A new version of a part moves only its pin here; the shared test runs again (49GAION/DR-0025, item 3). The part's own blueprint governs everything about the part; this text only says how the parts are put together.

3. How the product works, step by step

The order is Source Lifecycle, then the Target Operating Model, then Process and Position Design, then Delivery and Implementation (Protocol §21, item 1). No stage waits for a later one.

Step 0 · Set up

Step 1 · The sources: Source Lifecycle

• In. The organisation's documents (files, archives, folders, a corpus import with its manifest), and what its people say, typed or spoken. A spoken account is recorded only after its contributor approves an exact preview, item by item. Silence and "yes to all" record nothing. Every contributor first accepts an agreement (SL §4.3, §5.1).
• The Design Request. A source in Source Lifecycle, approved by the Requesting Authority. It holds nine fields: the requesting seat, the entities in view, what should be different, why now, the known limits, what is out, the request kind, the earlier release it continues, and the run depth (light, standard or deep). With no written brief, Source Lifecycle's Chief of Staff builds it through explainers (TOM docs/ASKING-CATALOGUE.md, DRQ-01; docs/INTAKE-WITH-SOURCE-LIFECYCLE.md §1.4).
• Beside it. The essentials checklist: strategy, plan, measures, structure of positions, processes, meetings, dictionary. Source Lifecycle shows the essentials still missing beside the Design Request; it flags them and never drafts them (SL Annex F.2). The organisation dictionary is served by reference to every stage (SL Annex F.1).
• Out. Sources by reference: ID, version, SHA-256, held or not held, at a pinned snapshot SLM-<sha256> (SL §5.8; Protocol §13, item 9).

Step 2 · The operating model: Target Operating Model

• Starts from one Work Item of the Requesting Authority's Cell that carries only the reference of an approved Design Request (TOM §1, §6). Gate T0 checks, among others, that the connections are signed, Source Lifecycle's card declares the sockets contract, and enough engines are eligible: at least three reviewer engines from at least two families, none of an author's family (TOM Annex C.2 (g); TOM H-05).
• Reads only sources served by reference from Source Lifecycle, sealed into an Input Pack. It asks what is missing only through Source Lifecycle's Chief of Staff, at most twelve rows a pass (TOM §4.3, §5.2; Protocol §19, items 2 and 3). Where the organisation admitted an export of its running work by role-type and process, it reads it as the activity profile; with none, it reads no observation (TOM Annex H.8).
• Produces the TOM Release: the Design Brief; the decided structure and slice; per entity, the Blueprint and the Rationale and Evidence Brief (capabilities with their delivery model and maturity, value streams with their criticality, decision domains, interfaces); hand-offs, counterparties and the legal and regulatory perimeter; the role register (role-types only); the strategy frame; the outside parties' journeys; the value case; the priority of every element; the activity profile; the walkthrough report and the quality checks (TOM docs/OUTPUT.md; Protocol §19, items 4 and 12).
• Decided element by element by the Requesting Authority, ACCEPT, CORRECT or REJECT, each with a priority (must, should or could), then the value case and the final status. Purpose and values, where no source in force states them, are signed by the GOV Cell (Protocol §19, item 12). Silence decides nothing (TOM §5.9; Annex C.4).
• Filed in Source Lifecycle as origin kind operating model. Once it reads back, a release notice goes to Process and Position Design (TOM step 8a; Protocol §21, item 3).

Step 3 · Processes and positions: Process and Position Design

• Starts from a Work Item that carries one TOM Release reference. The release is admitted only if its manifest validates, its status is decided, its hash equals the copy filed in Source Lifecycle, and its role register re-compiles (PPD §4.3, part 3).
• Reads the role register first, then every value-stream phase, capability, decision domain, hand-off and crossing, the strategy frame, journeys, value case, activity profile, delivery models, maturity, criticality and priority. Other sources come only from Source Lifecycle; questions go only through its Chief of Staff (PPD §5.1, §5.2).
• Produces the PPD Release: process architecture (levels 1 to 3), the process book, the policy register (names, not texts), the position register with job families and levels, job descriptions with competence profiles, the decision-rights register and authority matrix, reporting lines and organisation charts, the forum register and review calendar, the crosswalk from today's organisation, the workload register, the controls catalogue and segregation-of-duties check, the objectives cascade, the peak-load check, the unit register and unit charters, and the Decision Package (PPD Annex A).
• Decided element by element by the Requesting Authority (PPD §5.10, rule 1). The release holds no person, no pay, nothing on what fills a position and no policy text (PPD §5.10, rule 4).
• Filed in Source Lifecycle as origin kind process and position design. A release notice goes to Delivery and Implementation, naming the TOM release it rests on (Protocol §17, item 12).

Step 4 · Into a running organisation: Delivery and Implementation

• Starts on the Requesting Authority's request, which opens the run, its mode and its scope (Protocol §20, item 2; DI H-09). In mode A, once the PPD release notice has arrived, it reads the PPD release, and the TOM release it rests on, by reference from Source Lifecycle (DI §4.3, part 1).
• Slice 1, Launch. Admit, map, diagnose, prepare, decide and file:
  • the design map;
  • the gap report in two tiers;
  • the health check;
  • the procedures under each process;
  • briefs for counsel and finance: policies, pay structure, contract templates, authority instruments, obligations register, control matrix, systems, data and suppliers;
  • a cost draft, every amount cited;
  • the transition plan and go-live criteria;
  • the Decision Package (DI Annex A.1 to A.8).
• Slice 2, Accompany and Operate. Implementation plan, change impact, learning paths, readiness, rehearsal, the go or no-go package, stabilisation; then one operating rhythm with single logs, forum packs, measures, versions and a value register with gates L0 to L5 (DI Annex A.9 to A.19).
• Slice 3, Improve. Conformance, proposals and trials, the quarterly health check, hand-over and a yearly drill that proves the organisation runs without DI (DI Annex A.21 to A.24).
• Decided by the organisation's deciding positions: the Requesting Authority, the go or no-go position, counsel, finance, data protection, the owner, process owners and forum chairs. DI decides nothing; a draft enters a record only when a position inserts it (DI §5.10; Annex G).
• Filed in Source Lifecycle as origin kind delivery and implementation, the launch package and each later decided version of the living design.

Returns · every defect goes back to the stage that made it

• A later stage that finds a defect in a release returns it, directly, to the stage that made the release, under the design return contract, with a filed copy of the same hash in Source Lifecycle as a design report. Process and Position Design returns to the Target Operating Model; Delivery and Implementation returns process, position, unit and control defects to Process and Position Design, and operating-model defects to the Target Operating Model (Protocol §21, item 4).
• Only the elements a return touches are held; the rest of the work goes on.
• Every return ends, in one of four ends: answered by release, answered by decision, set aside by decision (carried forward as a known defect or a decided assumption), or withdrawn. Past its deadline or its rounds, it goes to the Requesting Authority and the Cell carrying [ORG]HOAC-TM. Silence ends nothing (Protocol §21, item 5).
• No loop. A return is answered on its own Work Item; no stage opens a new item back (Protocol §21, item 6).

Throughout

• One home. Every release is frozen, content-addressed and filed in Source Lifecycle; every stage reads every other by reference. No stage keeps or edits another's release (Protocol §21, item 2).
• What one stage leaves open, no later stage fills (49GAION/DR-0023, item 6; Protocol §21, item 12).
• The priority and the value case of the operating model reach Process and Position Design and Delivery and Implementation unchanged (Protocol §21, item 12).
• Checked by many engines. Every step after Source Lifecycle is checked by three or more engines from two or more model families, each alone first; code settles; no vote (Protocol §21, item 8).
• Positions only. No output names a person, and no record of the work about a person enters any stage (Protocol §21, items 9 and 12).

4. The connections

A return travels on the same connection as the notice it answers: each connection is signed by the [ORG]HOAC-ACS position over the stage whose releases it serves (Protocol §21, item 7).

What each stage may file in Source Lifecycle (Protocol §13, item 9; SL §5.8):

A revocation takes effect at once; after it, a notice or return through that link is refused at the gateway, and each stage still runs alone (Protocol §21, item 7; TEST-DESIGN-CHAIN v2, case 7).

5. What goes in

6. What comes out

At each stage, a decided release, filed in Source Lifecycle and read by reference:

What is left to the organisation (DI §5.12; Annex G): every decision and signature; every task of the implementation plan, each owned by a position; final legal texts by its counsel and every amount by its finance; consultation with workers and every statement or notice; appointing and hiring people into positions; paying; and marking physical steps done.

What it is for. To design an organisation of human positions from the organisation's own sources, decided by its own positions, and to take that design into a running organisation, with every element traced to a source or a decision. It serves a new organisation and an existing one; the crosswalk and the transition plan carry an existing one from today's organisation to the designed one.

7. What the product sets

Each part keeps its own Configuration (each part's §15). The product sets only what must be the same across its parts, so that one organisation runs one product:

The parameters an organisation chooses for each use (the parts' own settings, named here so the whole is visible):

8. Ways to use the product

The organisation may stop after any stage, and no stage waits for a later one (Protocol §21, item 1). Every stage after the first reads Source Lifecycle; Process and Position Design needs a decided TOM release, and Delivery and Implementation in mode A needs both releases (upstream/PROPOSALS.md, item 5).

Another source in place of Source Lifecycle, in later phases. In the stages after the first, another source of documents or knowledge may stand beside Source Lifecycle, read only, through the reading stage's own adapter, once it uses the same sockets and passes the joining test. It answers by reference (ID, version and hash), "held" or "not held", within the approved scope (Protocol §13, item 7; SL §2.2). Asking and filing stay with Source Lifecycle. A source that replaces Source Lifecycle needs the Protocol first to name the new asking route (Protocol §13, item 10); none is named yet (upstream/PROPOSALS.md, item 3).

A part replaced by another part. Built like a puzzle (Protocol §2): any other part may be replaced by one that offers the same ports and contracts, once it passes the joining test (Standard §3.2, item 4; Protocol §11, item 1). Its pin moves here, and the shared test runs again.

9. The decisions the product needs, by position

10. The shared test

TEST-DESIGN-CHAIN v2, 15 cases, held in the Library register (49GAION-protocol library/README.md, at 47fb6e1). It is the product's one shared test (49GAION/DR-0025, item 4). This repository keeps no copy. Each part's own fixed test passes first (case 11). Every case reads NOT_RUN until the parts are built and run.

In short, the cases cover:

1. each stage alone;
2. filing and read-back;
3. the notices;
4. returns to the stage that made the release;
5. every return ends;
6. no loop;
7. revocation;
8. many engines;
9. no person named;
10. the pins read back;
11. the four stages together;
12. the dictionary;
13. what is left open stays open;
14. the priority and the value case unchanged;
15. nothing about a person.

Run here on every pull request. Case 10 runs on every pull request of this repository: tools/check_pins.py reads back every part and contract at its pinned commit and checks its SHA-256.

11. What must be true before the first real run

These come from the parts' own texts. Until each holds, the joining test of the part concerned fails.

1. Source Lifecycle adopts its sockets contract (SL H-02, PRD D-20). Until then the Target Operating Model's gate T0 fails with SL contract not supported.
2. Each stage's additions to Source Lifecycle are accepted: TOM's SL-A1 to SL-A13 (TOM H-15), PPD's and DI's origin kinds (PPD H-05, DI H-04).
3. The connections are signed by the accountable positions (§4).
4. In an [ORG]AION, the Charter is installed first and holds the tool gateway, the records and the Work Item queue (Protocol §23). Outside an [ORG]AION, Delivery and Implementation runs behind its own gateway, which fails closed (DI §8); Source Lifecycle may run with no gateway (SL §15, gateway present: no; SL H-05); the Target Operating Model and Process and Position Design assume one.
5. Enough engines are eligible in the engine register: at least three reviewer engines from at least two families, none of an author's family; with two author families that means at least four families (TOM Annex C.2 (g); TOM H-05).
6. The positions are arranged and the Requesting Authority is named (§3, step 0).

12. The next level, not in this product

This product designs an organisation of human positions. It does not decide which positions an AI fills, which a human fills, or which both fill (49GAION/DR-0025, item 5). That is the next level, the path of an [ORG]AION. It will read this product's decided releases (the role register, the processes, the positions and the units) as its input. Nothing in this blueprint prepares or limits that level.

13. Lessons and gaps found while writing it

Each is a draft for 49GAION, in upstream/PROPOSALS.md, not yet proposed. None changes a part here.

14. Change log

49GAION Organisation Design and Delivery · product blueprint v0.1.3 · Powered by 49GAION