Architecture

The home of this section. Where everything lives and how it communicates. Detailed diagrams live here and in the module documents (Configuration, Customer-specific development module (id source), Support, Data & Manipulation); the goals chapter carries no diagrams — the platform picture below is the one place it is drawn (D150), in the four states of Gating § 1b (D148). Memory and skills are one page: Agents Memory and Skills.

0. The platform, and the modules on it

P The middle of this picture is the product: five platform parts that do not change per customer, and the modules — each one a graph of profiled agents — that run on them. Support is the root module (decision Vladimir, 04.09.2026 — D143): every client request enters there, is classified and identified, and either waits or is routed to Configuration, Data & Manipulation, customer-specific Development, or Assessment & Offers. Core Development is an offer type whose scope and effort are assessed before customer approval; it has no code pipeline. The channels above and the estate below are the Bulstrad case study; a second customer replaces those bricks and nothing else (PG-23, D77).

Every box is clickable. A module opens its page, whose head carries its agent tree, its branch of the memory tree and its skills, in that order (D145); everything else opens the document that specifies it — and a channel or a system opens the Whitelabel Catalogue, because which channels and which systems is a plug-in value, not a rule of the architecture. Every profile, with what it boots from, what it may write and what it is denied, is in Agents and the modules' components pages.

flowchart TB
  H["People teach and decide"]:::owner
  K["Reviewed knowledge
methods and executable helpers"]:::learn
  A["Trainable agent profiles"]:::work
  R["Support root
one durable case"]:::owner
  C["Configuration"]:::work
  D["Data & Manipulation"]:::work
  S["Customer-specific development"]:::work
  O["Assessment and Offers"]:::work
  G["Audited proposal
required decisions"]:::decision
  X["Backend executes
through connectors"]:::work
  V["Prove the requested result"]:::proof
  L["Retain experience
evaluate proposed changes"]:::learn
  W["Wait on an explicit trigger"]:::store
  H -->|"teach"| K
  K -->|"context and skills"| A
  A -->|"work as a case"| R
  R --> C
  R --> D
  R --> S
  R --> O
  R -.->|"when needed"| W
  C -->|"propose"| G
  D -->|"propose"| G
  S -->|"propose"| G
  O -->|"gated communication only"| G
  H -.->|"role or eligible policy"| G
  G -->|"authorised packet"| X
  X -->|"current evidence"| V
  V -.->|"queue after result"| L
  L -.->|"review and publish"| K
  classDef work fill:#eef4ff,stroke:#6889ba,color:#17365b,stroke-width:1.3px
  classDef decision fill:#fff4df,stroke:#b78c36,color:#65470d,stroke-width:1.5px
  classDef proof fill:#e9f5ef,stroke:#689b81,color:#224e39,stroke-width:1.3px
  classDef learn fill:#f1edf9,stroke:#9580b9,color:#534172,stroke-width:1.3px
  classDef store fill:#f5f7fa,stroke:#98a6b7,color:#34445a,stroke-width:1.2px
  classDef owner fill:#24486b,stroke:#24486b,color:#ffffff,stroke-width:1.4px
  click H href "ui.html" "People define outcomes, review learning and hold the required decisions."
  click K href "50-agents/agents-memory.html" "Owned, versioned knowledge informs future work; it never grants authority."
  click A href "50-agents/agent-framework.html" "Prompts, skills and model routes change through evaluation and publication."
  click R href "40-support/support-module.html" "Authorised requests enter here; the root retains clocks and the customer outcome."
  click C href "20-configuration/configuration-module.html" "Existing-product deltas, rating templates and scoped product changes."
  click D href "40-support/data-and-information-module.html" "Answers and repairs under the same Support root."
  click S href "30-source/source-module.html" "Bounded code changes across the actual source lineage."
  click O href "45-commercial/assessment-and-offers.html" "Assess effort, prepare terms, obtain customer approval and communicate; no implementation authority."
  click G href "gating.html" "Compose checkpoint and effect requirements for the exact revision and target."
  click X href "software-architecture.html" "Deterministic software owns grants, execution, persistence and recovery."
  click V href "case-protocol.html" "Join family members, targets and external obligations; distinguish preview from delivery."
  click L href "50-agents/agents-memory.html" "Learning is durably queued from every module; only confirmed knowledge is reused."
  click W href "40-support/support-module.html" "Customer action, external work or a future release stays visible with its age."

The operating model: teach → apply → prove → retain. Solid arrows carry work; dashed arrows show conditional work or feedback. All modules use the same governed execution path.

Stage ids name the stage documents, not a running order (D83).

Inside the platform, in the order a case travels: the interface is the only place a person answers anything; the backend owns the case, its papers, its grants and the ledger; the framework runs the turn loop and the tool pipeline; the graphs are the profiles the framework instantiates; and every profile reads one memory tree and writes only its own node. The concrete map — which library, which table, which transport — is § 1. Every module reaches every system it needs; the single arrows below are drawn to keep the picture legible, not to say a module is limited to one target.

P Where the agent trees are (D145). Each module head shows its operating model and links to the owned agent/method subpages: Configuration Module § 0 · Support Root § 0 · Data & Manipulation Module § 0 · Customer-Specific Development Module § 0. Assessment & Offers handles the Core offer type and other requests needing assessment and customer agreement. The stage/agent/tool inventory is the detailed map across all classifications. The platform pages state the rules those trees obey.

1. Where and how — the concrete map

P Developer entry. Implementation Guide gives the first build increments and acceptance tests. Modules binds the business graphs to versioned data. Model Execution explains the actual provider seam and LLM/software boundary. Runtime defines the transactions and recovery; the proposed schema includes its journal, inbox and impact claims.

3.1 SRD_SUPPORT — the table set P

Versioned DbScripts in the reused pattern: baseline → numbered upgrades → grants → verify → retention (Software Architecture § 9.2). The scripts exist (D140, 04.09.2026): Data Model lists them, draws the schema and names what the DDL adds beyond this table — 50 tables, 26 unique guard triggers after the runtime upgrade; linted, not yet executed (no SRD_SUPPORT user — D47).

3.2 The ledger P

Append-only and tamper-evident — the mechanism, not just the adjective:

P The threat model is the honest gap. These controls stop the service and its agents from rewriting history, which is what they are for. They do not stop a DBA: triggers can be disabled, and whoever can restore a backup can replace the chain wholesale. Defeating that needs an anchor outside the database — the periodic seal written where the DB account cannot reach, or countersigned externally. P The DBA is in the threat model for detection, not prevention (Challenge Rounds § R2 § 11): the 15-minute seal export to a repository/storage boundary unavailable to the database credential (D45) is the anchor the database account cannot reach; verify-ledger.sql compares the chain head against the last exported seal, so a rewrite of already anchored history is detectable against that export; the unsealed tail is bounded by the export interval; external countersigning is not built. P The restore rehearsal must detect a deliberately shortened chain from the export; no rehearsal has run yet. P After a point-in-time restore the chain is intact but shorter: the gap between restore point and failure is lost audit. A restore is itself a ledger event and the retention policy must say so.

A mistake is corrected by a linked correction record, never by rewriting. Each record carries actor and case/task ancestry · profile, prompt and adapter versions · plan revision and parent decision · applicable policy and grant · the exact requested action · what actually ran · verification result · payload hash and artefact hashes, never payloads or result rows (Trust and Data § 5).

The evidence graph is a projection over it: sources, extracted statements, queries, logs, code references, interpretations, plans, clarifications, changes, test results and recovery evidence, related by support / contradiction / derivation / confirmation / supersession. It answers, per case: what did the agent know before proposing this · which source or precedent supports the interpretation · what did the parent confirm and what authority permitted execution · what was requested and what actually changed · what was verified · what remains uncertain.

Metrics are parsed from the ledger by tools, never counted by agents (CR-1, Metrics).

2. Communication

sequenceDiagram
  autonumber
  actor U as Person or channel
  participant B as Case service
  participant A as Root and specialist
  participant X as Executor and connector
  participant K as Knowledge owner
  U->>B: Request or scoped response
  B->>A: Durable task and pinned context
  A-->>B: Plan, evidence or question
  opt Required decision
    B->>U: Exact packet and decision role
    U->>B: Verdict on revision and hash
  end
  B->>X: Permitted operation
  X-->>B: Observed result or uncertainty
  B->>A: Evidence for complete-scope verification
  A-->>B: Typed result and remaining obligations
  B-->>U: Achieved outcome and acceptance scope
  B-->>K: Durable learning task
  K-->>B: Reviewed version for future cases

The backend mediates every boundary. Agents exchange typed plans and evidence; current authority governs target execution. Learning is durably queued from the verified result.

Peer agents (backend/frontend/db owners) and module handovers (gate Hd) use the same delegation contract over RabbitMQ; lateral consults are evidence, never authority.

Authorization, the trust boundary and the data classes that constrain every arrow above are defined in Trust and Data; what happens when an arrow fails mid-flight is Failure and Recovery.

3. Common rules

3.1 The rules

4. Runtime P

P The agent loop is native C# in the Support webservice, continuing the AI program's stated direction ("replace MCP Proxy, IntentGPT and long-lived AI sessions with native C# services" [F: docs/architecture/health-ai/00-program.md, inspected 31.08.2026]) — decision 01.09.2026.

P No third-party harness is adopted as the runtime (decision 02.09.2026). The design of the loop, the instantiation of the agent graph, inter-agent communication and the write-approval flow — with the patterns taken from surveyed harnesses and their sources — is Agent Runtime.

The loop is reached through one internal contract — start/continue, lineage, plan submission, parent responses, interruption, recovery, model selection, event correlation — so the choice stays reversible. Model adapters per profile; session records store profile + adapter version, never bare model ids.