Delivery
Build order and cutover. No dates, named staff, headcount or suppliers — those stay outside this wiki (Non-Goals N-6). Capacity statements are architecture, not headcount commitments (D103). What this document fixes is the order, because several people build at once and the order decides what they can start on.
1. Two phases
P The build has two phases, and only two (decision Vladimir, 03.09.2026 — D80).
Phase 1 — architecture design. The deliverable is one thing: this technical documentation, approved by every stakeholder role — Bulstrad business owner per module, Bulstrad IT and DBA, Ablera support lead, Ablera development lead, Ablera platform architect, and the data-protection role (D110). Approved means each stakeholder has read the part they will be held to and said so, not that it was circulated. Underneath that signature sit the working artefacts: every component named with its kind, what it consumes and produces, its done test and its dependencies (§ 1.4), and the contracts between components written and validated against a deliberately broken fixture. Phase 1 is complete when phase 2 can start on any component whose dependencies are met without a further design decision.
P What has to be approved, and where each part is. The signature covers four things, each with its own pages: the platform — the part that does not change per customer (Platform; Architecture § 0; Software Architecture); the agent framework — what every agent gets, and what it is denied (Agent Framework; Agents); the modules, each one as its stages — the Support root and the three working modules it routes to (Support Module, Configuration Module, Data and Information Module, Development Module; D143, D144); and the contracts between them — what one component owes another (Contracts). Until that signature exists there is nothing for phase 2 to build against; after it exists, phase 2 needs no further design decision.
Phase 2 — independent component implementation. The components are built in parallel by discipline, in two waves: Configuration first, then Development and Support together with the rest of the platform infrastructure. Nothing in this phase waits on a design question; what it waits on is another component's contract, and those exist.
1.1 Two different questions
P "How does the work divide?" and "when does each module reach a real case?" have different answers.
- How it divides: by discipline. A module is not a unit of work but a unit of behaviour, assembled from six kinds of component that different capacity roles build. There is no "configuration team" — the connector developer who writes the rating gateway and the author who writes the abacus stage prompt share no skill and no file.
- When each lands: by module. Configuration reaches a real case first; the Development module (id
source) and Support follow together, and the platform infrastructure they need is built beside them. A track in § 1.3 has capacity across both waves; what changes between waves is which module's agents, skills and connectors that track is producing.
1.2 The order inside phase 2
P Two waves (decision Vladimir, 03.09.2026 — D82).
Wave 1 — Configuration reaches a real case. Built: the platform spine a case cannot run without (backend core, agent framework, the administration UI's session, gate and papers views, governance and evaluation), the connectors Configuration touches (the rating gateway, the environment databases, document production, the host connector with its reach probe, and the intake channel), the configuration test skills and the two configure skills, and the five configuration stage agents with their memory domains and eval sets. The minimum desk intake/route needed for a client-originated case is included; the full Data and information investigators remain wave 2.
Why Configuration and not Support: it has the deepest specification, a working sibling that already executed the work end to end, skill-based tests that prove a stage without a human reading output, and configuration material without personal data — so it can use an estate-approved adapter for that input class while the Support data boundary is still being arranged (CG-9, PG-7). Support first would have made the data boundary a prerequisite of the first line of code.
Wave 1 is done when the T2 slice runs: a real product configured on an authorized target through S1, phase 1 and both branches of phase 2, with a deployment set (§ 2).
Wave 2 — Development and Support at the same time, and the rest of the platform infrastructure with them.
| Strand | What it adds | Why it can run beside the others |
|---|---|---|
| Development | the source connectors (repository, pipeline, log store), the source skills, one implementer agent per declared source, the placement catalogue | its connectors are repositories and build systems; it reuses platform and any common Oracle, GitLab, log or browser capability; new source handlers are independent |
| Support — the root desk and its Data and information stages (D143, D144) | the channel connectors (ticket system, mail, help desk, browser), the desk's classification and conversation skills, the recurring-shape skills, six symptom-domain investigators over the shared nine mechanics, the experience index, the EU-resident model route SG-9 requires | its connectors are channels and read paths into the estate; its agents are disjoint from Development's |
| Platform infrastructure | the remaining administration screens and expanded operations; essential hosting, restore, kill switch, connector health and off-database copies already exist for wave 1 | it extends contracts wave 1 froze; nothing in it re-opens a design decision |
P The two module strands are simultaneous because their new domain work can proceed concurrently: shared connectors and runtime contracts have explicit owners and are not rebuilt per module, and both consume platform contracts that wave 1 has already proved on a real case. What they share is the platform, and by wave 2 the platform is a dependency that exists rather than one being negotiated.
The track ids stay as labels: T0 contracts are phase 1; T1 platform experiment plus T2 configuration slice are wave 1; T3 is wave 2 (D80/D82).
P What is not in a wave. The knowledge migration runs beside both and gates neither — a domain crosses when its retrieval reaches at least 50 % top-5 hit-rate on held-out cases, against the measured 10 % search baseline, whichever wave is running. A wave-2 connector or skill may be started in wave 1 by anyone free, since the abstraction it is written against is a phase-1 deliverable; it simply is not required for wave 1 to close.
1.3 Where the parallelism actually is
P The two widest seams are the connectors and the skills — each of them a set of small, mutually ignorant pieces.
| # | Track | Capacity role | Builds | Parallel slots | Independent because |
|---|---|---|---|---|---|
| 1 | Backend core | a service developer | cases, sessions and tasks; the working papers service; the ledger with its chain, seal and export; gates, grants and held batches; the schema and its scripts | 1–2 | it is the contract the rest is written against, and it needs no agent to exist |
| 2 | Agent framework | a runtime developer | the turn loop, context assembly and compaction, the permission and tool pipeline, spawning and typed messages, checkpoints, budgets | 1–2 | it depends on the connector abstraction and the provider seam, not on any particular agent |
| 3 | Administration UI | a front-end developer | the operator workspaces — Inbox, Cases with the case chat, Decisions, Studio, Knowledge, Metrics, Control — in the estate's own administration application | 1–2 | it consumes the service's HTTP and realtime contracts; it needs no agent and no connector |
| 4 | Governance and evaluation | a developer | draft → test → publish for profiles, prompts and skills; the eval runner; replay fixtures | 1 | it needs persistence and the eval-set format, nothing else |
| 5 | Connectors | several developers, one per system | one library per external system — the ticket system, mail, the customer's help desk, the databases per system, the rating gateway, the source repository, the log store, the broker, the browser, document production, the Linux hosts, the process engine | 10–12, the widest seam in the build | each is an operation catalogue with a capability row per operation, written against one abstraction. No connector knows about another, and none knows about any module |
| 6 | Skills | developers paired with the owning domain | the recurring support shapes in four groups; the configuration test skills; the two configure skills; the Development skills | 8–12 at a time | a skill is inputs, connector calls and assertions. It shares nothing with another skill but the runner |
| 7 | Configuration agents | five authors, one per stage | the stage prompt, its memory domain, its eval set | 5 | disjoint prompts and disjoint domains, written against the phase-1 contracts. No code |
| 8 | Support agents | six authors, one per symptom domain, plus the desk's | the Data and information investigator prompts, their domain articles and eval corpora; the desk's triage and communicator prompts (Support Module § 0) | 6, plus the desk | the nine investigation mechanics are shared; the domains are disjoint. No code |
| 9 | Development agents | one author per declared source | the implementer prompt and its repository domain | one per repository | one per source, and a source is configuration |
| 10 | Knowledge | the domain owners | the migration waves, each accepted on its measured retrieval | 2–4 | it runs beside every other track and blocks none of them |
P What the table says about capacity — read together with the wave order in § 1.2 — without naming staff or committing headcount, which stays outside this wiki (N-6): tracks 1–4 are narrow expert-capacity lanes; tracks 5–6 absorb available capacity and are where extra hands convert directly into elapsed time; tracks 7–9 need domain knowledge and no code at all, so they draw on the estate knowledge already present.
P The only real orderings inside phase 2:
- The connector abstraction and the capability-description contract precede the connectors — they are phase-1 deliverables, so this is satisfied on day one.
- A skill can be written against a connector's operation catalogue before that connector is finished, but it cannot be proved until the connector runs read-only against a real target.
- An agent can be authored and evaluated against fixtures before its skills exist; it cannot run a real case until they do.
- The UI needs the service's contracts, not its implementation.
- The wave order is fixed: Configuration reaches a real case before Development and Support.
Other dependencies declared by the selected manifests and component contracts also apply; parallel authoring does not remove runtime or shared-write prerequisites.
1.4 The component inventory — the boundary between the phases
P Every component of the platform and the modules — the Support root and the three working modules — with its kind, the track that builds it, what it depends on and what proves it done — so that phase 2 can start on any row whose dependencies are met without a further design decision. Per-module detail stays in the three component pages (Configuration · Support · Development); the platform's libraries stay in Software Architecture.
1.4.1 The six kinds, and why the distinction is the plan
P Defined once in Components — Configuration § 0:
| Kind | Built by | Needs code | Parallel because |
|---|---|---|---|
| Agent | an agent author | no | one prompt, one owned memory domain, one eval set — disjoint from every other agent |
| Skill | a developer with the domain owner | yes | one operation with its own assertions and its own target |
| Projection | a developer | yes | deterministic input to output, no shared state |
| Contract | the contract author | schema plus validator | it is what removes coordination from everything after it |
| Connector operation | a connector developer | yes | one system, one operation, one capability row |
| Memory domain | the domain owner | no | one node, one writing profile |
Why the kinds matter more than a component list. A component's kind decides who can build it and what "done" means. The Abacus stage is not one deliverable: it is an agent (a prompt and a domain), three skills (abacus configure, rating test, seed), a projection (the rating script emitter) and a set of connector operations — four kinds, four capacity roles, one contract between them. Planning by module hides that; planning by kind is what makes the tracks real.
1.4.2 The inventory, by area
Counts are the components this wiki currently names. A count is a planning figure, not a promise: the tail of any module's skill catalogue grows on use.
| Area | Agents | Skills | Projections | Contracts | Connector libraries | Memory domains |
|---|---|---|---|---|---|---|
| Platform | 8 shared profiles | — | — | 5 seams | 12 libraries | 2 |
| Configuration | 10 | 10 | 5 | 4 | uses 7 | 6 |
| Support | 12 | 35 catalogued shapes, in 4 build groups | — | 4 | uses 8 | 3 |
| Development | 4 fixed profiles + 2 isolated sub-agents + 1 implementer per declared source | 5 | — | 4 | uses 4 | 4 + one per repository |
2.1 Platform — the components every module runs on
P Specified in Software Architecture § 2–3. Grouped here by what a builder would take on as one piece of work.
| # | Component | Kind | What it is | Depends on | Done when |
|---|---|---|---|---|---|
| P-1 | Case, session and task model | library | the durable work object, its state machine, parking and resumption, control transfer, impact keys (Agent Runtime) | persistence | a case survives a killed worker and resumes with its plan and evidence intact |
| P-2 | Working papers service | library | the token-gated store for plan, contract artefact, write log, build state, deliberate omissions, report; revisions; every access audited | persistence, ledger | a paper is rewritten many times in one case, listed by case, and every access has a record |
| P-3 | Audit ledger | library | append-only, hash-chained, sealed and exported off-database; correction records; the projections over it | persistence, contracts | a deliberately shortened chain is detected from the export |
| P-4 | Gates and grants | library | gate records and packets, decisions, grants bound to an artefact hash with an expiry, role checks, held batches | persistence, ledger, identity | a call outside the grant is refused before the connector opens a session |
| P-5 | Agent runtime | library | the turn loop, context assembly, compaction, the permission pipeline, tool middleware, spawning, messages, checkpoints, budgets (Agent Runtime) | providers, connectors, ledger | the platform experiment passes (this page) |
| P-6 | Provider access | library | the copied and owned provider abstraction, governed route selection with the data-boundary predicate, metering into the ledger | contracts | a profile declaring a route outside its module's class does not publish |
| P-7 | Memory tree | library | nodes and articles with their states and provenance, version pinning, the experience index, retrieval | persistence, a repository store | an article's states are commits and the index rebuilds from the repository |
| P-8 | Governance | library | profiles, prompts, skills and eval sets: draft → test → publish → retire; ownership; the publisher role; the eval runner; replay tests | persistence, runtime | nothing publishes with a red eval set |
| P-9 | Skill runner | library | binds an instruction to connector operations plus assertions; dry-run default; teardown | runtime, connectors | a skill runs read-only on a real target and its assertions fire on a known-bad case |
| P-10 | Connector libraries | 12 libraries | one per external system, each an operation catalogue with capability descriptions and trust-labelled results | contracts | an unlisted operation is refused, not improvised |
| P-11 | Administration UI | application | the operator workspaces and the client app (UI) | the service, realtime | a brief is opened, a gate is answered, a case chat watched and a prompt published from the screens alone |
| P-12 | Hosting unit | operations | the deployment unit, its configuration, its secrets, its schema scripts, the alert set | the estate's mechanism | the service starts, registers its endpoints and reaches one environment through a connector |
| P-13 | Shared agent profiles | 8 agents | intake monitor, compactor, summarizer, verifier base, grader, write auditor, write executor, connector agent (Agents § 1) | runtime, governance | each has its eval set and publishes |
| P-14 | Platform seams | 5 contracts | the message envelope and its versioning; the connector capability description; the eval-set format; the ledger record shape; the write shape (Gating § 4) | — | they are what the module tracks are written against |
| P-15 | Write gating | library + 1 agent | the write classification, the seven write classes, HW-approve and the instance check, shape suspension, and the isolated write auditor that runs the four checks before any gate sees a packet (D72, D73) |
gates, connectors, runtime | a packet that is vague, unbounded or without a derived teardown is refused, and the refusal names the failing check |
2.2 Configuration — 10 agents, 10 skills, 5 projections, 4 contracts
Detail: Components — Configuration. The four contracts (specification schema and validator, configuration summary, sign-out document, stage contract) are the ones that unblock five parallel stage authors. The five stage tracks each carry an agent, a memory domain, a skill and a projection.
The module also carries (reconciliation): the estate prober agent, the abacus seed skill and the PAS contract export projection (shape 1 is a product shape to build for — D125); every statement instantiates an approved template, and the emitting agent writes the revert of each artefact (D120).
It also carries the abacus configure and ipal configure skills, which drive each system's own configuration endpoints as the primary write path and fall back to guarded statements for what those endpoints do not cover, declaring a coverage map either way (D74); the sign-out document contract; and the two-phase run order — phase 1 tariff, then phase 2A wiring beside phase 2B product and offer, each phase tested and signed out (D75).
2.3 Support — the desk and its Data and information stages: 12 agents, 35 catalogued shapes, 4 contracts
The desk's own components — triage, the communicator, the route — and the working stages' investigators, verifier, resolution agent and curator share the support.* namespace; where each sits is Support Module § 0 and Data and Information Module § 0 (D143, D144).
Detail: Components — Support. The six symptom investigators are six independent tracks over one shared phase set — the nine investigation mechanics. The skills are built in four groups: the five largest shapes first, then volume, then the team-judged high-bus-factor shapes (Components § 5 group 3), then the tail on the occurrence ladder.
2.4 Development — 4 fixed profiles + 2 isolated sub-agents + 1 implementer per declared source, 5 skills, 4 contracts
Detail: Components — Development. Four fixed profiles (root, planner, reviewer, deployer), two isolated sub-agents (Camunda developer, database extractor) and one implementer per declared source make the module's agent set; the placement analysis is the module's core judgement and is always human-approved.
1.4.3 Tracks — who builds what, at the same time
P A track is a person or a pair working without waiting. The tracks below are the phase-2 breakdown; they map onto the six work streams of § 5.
| Track | Builds | Blocked until |
|---|---|---|
| Contracts | P-14, and the three contracts of each module | — this is the first work |
| Platform core | P-1 … P-5 | the contracts exist |
| Platform surfaces | P-10 connectors, P-11 the UI, P-12 hosting | the capability-description contract exists |
| Governance and evaluation | P-8, P-9, the eval-set format, the replay fixtures | the contracts exist |
| Configuration, five stage tracks | one stage each: agent, domain, skill, emitter | the Configuration contracts exist |
| Configuration, beside the stages | the two isolations, the verifier, the renderer, the acceptance and rollback projections | the same |
| Support, six investigator tracks | one symptom domain each | the mechanics phase set and the experience entry shape exist |
| Support, skills | the four build groups, in order | the case shape and the write executor exist |
| Development, one track per declared source | one implementer agent and its repository domain | the brief contract and the worktree skill exist |
| Knowledge | the migration waves, per domain, each accepted on its measured retrieval | nothing — it runs beside every other track |
P The count that matters for planning is not the component count but the track count: ten tracks (§ 1.3, § 1.4.3), one of them the five Configuration stage authors who need no code and no coordination once the contracts land. That is why the contracts are phase 1's deliverable and not phase 2's first task.
1.4.4 What phase 1 has to produce
P Phase 1 is complete when, for every row of § 2.1–§ 2.4:
- the component is named, with its kind;
- its consumed and produced artefacts are named;
- its done test is a statement a tool or a reviewer can evaluate;
- its dependencies are named, and no dependency cycle exists;
- the contracts between components are written and validated against a deliberately broken fixture.
Items 1–4 are this page and the three module pages. Item 5 is the T0 contracts of § 2.1 (P-14) and the three per module, and F it is met in two strengths (Contracts, written 04.09.2026): the five platform seams (P-14 — message envelope, connector capability, eval set, ledger record, write shape) each have a closed schema, a valid and a deliberately broken fixture, and one validator that recomputes what a schema cannot express (python validate_contracts.py → 11 fixtures, 0 unexpected outcomes); the eleven inter-stage papers are published as drafts — required core validated, open body a case may extend (D139) — and the earlier Configuration specification contract (contracts/product.schema.json, 02.09.2026) stays in force. The SRD_SUPPORT DDL baseline is written alongside (Data Model, D140 — linted, not yet executed).
2. First proofs
P Developer implementation order. Implementation Guide specifies the first three increments and their crash/refusal/acceptance tests. Wave 1 includes journal/inbox/checkpoint storage, the operational kill switch, working paper/ledger backup and restore, and off-database exports before a real target write. Offline replay remains available while estate prerequisites are arranged. The first client slice uses the existing four client screens; it adds no optional client feature.
Each track ends in a demonstration, not a document.
- Platform experiment (T1) — the C# session host showing: concurrent isolated sessions with sub-agents; plan confirmation upward; escalation to the human; resume after an answer with nothing lost; model route swap without session-record migration; tool interception with policy enforcement; an audit record for every connector result. An SDK handshake alone proves nothing.
- One real configuration slice (T2) — a real source folder on an authorized target through S1, phase 1 and both branches of phase 2, closed by the joint proof and a full deployment set, deliberately including one initially missing element and one discovered mid-run, so the early ask (H1), the per-stage iteration loop and MISSING handling are demonstrated rather than described. The 9951 run is the single-environment precedent; this slice adds sessions, gates, audit and deployment.
- Round-trip golden set (T2) — export ≥5 shape-diverse selling products with their real sources; re-derive each from sources alone in a clean session; grade with the isolated grader; re-run on knowledge or model change (Agent Framework § 6.5).
P The thinnest slice that is worth deploying is abacus-only: a tariff change on an existing product runs S1→S2 and deploys the rating alone (Configuration Module § 3). It exercises intake, normalization, a stage protocol, a skill test, scripts, a gate and a deployment without needing S3–S5 to exist.
3. v1's role: the baseline and the one-time migration
P v1 is not a coexistence peer of v2 (decision Vladimir, 02.09.2026 — D64). It serves v2 in exactly two ways: as the frozen baseline every metric is measured against (Baseline), and as the one-time source of the memory migration (Agents Memory). The build focus is v2 alone; no coordination machinery is built for v1.
| Rule | |
|---|---|
| Baseline, frozen | v1's measured facts (volumes, cost, failure record) are the denominator of every ROI and metrics claim; the baseline table is not refreshed |
| Migration is one-time | v1 keeps its memory/, v2 has its own tree, neither writes into the other and nothing synchronises them (decision 01.09.2026). The corpus crosses once, in waves, each domain measured before the next |
| A v1 skill retires when its v2 equivalent has passed its eval set and run a real case to closure — not when it exists | |
| The transition window is kept short | while the migration waves run, v1 still works tickets by hand; its writes in that window are uncoordinated with v2's — accepted, and the reason the waves move module by module rather than lingering |
| v1's end state is declared | the analyses, mail and HelpDesk archives remain evidence linked from the experience index; the v1 memory is read-only after the last migration wave; the workspace is archived, not deleted |
4. Non-functional expectations
P Modest, because this is an internal tool with a small operator population — but stated, so they are designed for rather than discovered:
| Concern | Expectation |
|---|---|
| Concurrency | tens of concurrent cases, not thousands; per-case budgets enforce the estate's real caps (Agent Runtime § 11.5) |
| Availability | business-hours service; a failed worker must not lose a case — the papers and build state live in the case, not the worker |
| Latency | a gate decision and a live transcript update are interactive; a stage run is long-running and asynchronous by nature |
| Durability | cases, papers, ledger and memory are backed up with the estate's Oracle schemas; the ledger is append-only and never silently rewritten |
| Retention | configuration per artefact class, with cases and the ledger never expiring and manual actions gated (D109, PG-13); the retention evaluator exists from day one but is idle until a class is given an expiry |
| Recovery | worker death mid-apply is a designed case, not an incident (Failure and Recovery) |
P Proposed numbers (01.09.2026; configuration defaults in nfr.targets, Whitelabel Catalogue; conditional on D45 and on schema creation) — small deliberately, because the operator population is a handful of people and inventing enterprise targets would be dishonest. These are the figures to confirm or amend with whoever owns the estate's operations:
| Metric | Proposed | Why this and not more |
|---|---|---|
| Concurrent cases | 20 design target, 50 ceiling | v1 runs one at a time; twenty is a real improvement and stays inside the estate's DB session caps |
| Gate decision round-trip | < 2 s | it is interactive; anything slower and operators batch their approvals, which defeats the gate |
| Live transcript lag | < 5 s | it is a monitor, not a control surface |
| Stage run | asynchronous, no timeout; progress visible | a configuration stage legitimately runs for hours |
| Availability | business hours, Sofia | there is no out-of-hours operator to serve |
| Ledger RPO | ≤ 15 min | this is the load-bearing one: the RPO is the audit gap. Fifteen minutes of unrecoverable audit is defensible; a day is not |
| Case/paper RPO | ≤ 1 h | recoverable work, not evidence |
| RTO | 4 h business-hours | the inbox, the papers and the ledger read without a model, so the desk continues by hand while the platform is down — v1 is retired tooling, not the fallback (PG-22, D64) |
| Restore test | quarterly, and the procedure is a runbook that has actually been run | an untested restore is a hope |
P Operational controls that follow from the above: a kill switch with soft admission/checkpoint stop and hard effect-dispatch stop (Runtime § 7); canary activation for a published prompt or profile — one case, reviewed, before it becomes the default; connector health as a first-class case field, since a degraded connector must park a case rather than fail it; attachment scanning before any file from an external channel is opened by a connector.
P Backup and disaster-recovery of the target schema SRD_SUPPORT (not yet created — verified 03.09.2026; D30/D47) are the estate's DBA process (decision Vladimir, 02.09.2026 — D45; confirmed 04.09.2026 — D131: SRD_SUPPORT enters the QA backup inventory at creation and the RPO target above stands); the platform adds its own off-database copies of what a restore can lose: every 15 minutes the ledger seal and the delta since the previous seal as canonical JSONL, plus the PL/SQL snapshots, into the agent-owned GitLab repository — which is what makes the 15-minute ledger RPO true independently of the RMAN schedule. Case papers are files on the host volume and follow the host backup. F As of 02.09.2026 there is no QA backup inventory to be in: the last RMAN job on QA failed on 26.07.2024 and nothing ran since (Software Architecture § 10.5); the DBA request is to restore QA backups before SRD_SUPPORT exists (Decision register § 7).
5. Work streams
P The streams below are the ownership view of the same work — who holds a body of rules over time — while § 1.1 is the build view of who implements what. Staffing and dates stay outside this wiki (N-6), but the streams are fixed now — each with its goal, its done-state and the protocols that govern it (decision Vladimir, 02.09.2026 — D71). A person holds work in several streams over time; a stream has goals and gates, not a permanent owner.
| Stream | Goal | Done looks like | Defined in |
|---|---|---|---|
| Software | the platform itself — runtime, connectors, persistence, papers, the UI section, the hosting unit | the T1 experiment passes; every library carries its Software Architecture verdict; the whitelabel lint runs in CI | Agent Runtime · Software Architecture |
| Knowledge | the memory tree — migration waves, domain seeds, the experience index | a domain migrates only when its retrieval reaches at least 50 % top-5 hit-rate on held-out cases, against the measured 10 % search baseline; each wave measured before the next | Agents Memory and Skills § 7.2 |
| Agents | the profiles, the stage prompts, the skills | nothing publishes with a red eval set; every stage prompt carries its own set | Agents · Agent Framework · Agents Memory and Skills |
| Testing | the eval corpora, replay fixtures, the round-trip golden set, the T1 experiment | the eval format of Agent Framework § 6.5 is filled per module; a red set blocks a publish | Agent Framework § 6.5 · the modules' Evaluation sections |
| Protocols | the operating rules of this wiki turned into executable policy — grants, gates, the ledger, memory promotion, the DDL protocol, handles | each protocol names its acceptance test on its own page | Trust and Data · Architecture § 3.2 / § 3 · Failure and Recovery |
| Operations | the estate-side asks and the run state — the role rows the platform adds (D134), QA backups, the specific network requests (D132), the deploy job shape, the alert set | the action table of Software Architecture § 10.7 is empty | Software Architecture § 5, § 7 |
P The whitelabel invariant is a software-stream protocol (PG-23), not a person: a CI lint step fails the build when a catalogued value appears outside the customer plug-in, and the catalogue rule (Whitelabel Catalogue § 7) makes a page that introduces a number add the row in the same change.
C Open, from the component inventory:
- C The component counts of § 2.1–§ 2.4 are what this wiki names today. The first plug-in's build finds what was still assumed; the inventory is amended in the same change, like the Whitelabel Catalogue.
- P Whether a stage author and a skill developer are the same person is a staffing question and stays outside this wiki (Non-Goals N-6); the tracks are capacity lanes, defined so that they need not be held by the same person.