Architecture

The home of this section. Where everything lives and how it communicates. Detailed diagrams live here and in the module documents (Configuration, Development module (id source), Support, Data and Information); 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 one of the three working modules — Configuration, Development, or Data and information, the former Support module's working stages (D144). 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
and executable skills"]:::learn
  A["Trainable agent profiles"]:::work
  R["Support root
one durable case"]:::owner
  C["Configuration"]:::work
  D["Data and information"]:::work
  S["Development"]:::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 -.->|"when needed"| W
  C -->|"propose"| G
  D -->|"propose"| G
  S -->|"propose"| 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 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 page opens with its agent tree, then its branch of the memory tree, then its skills and tools: Configuration Module § 0 · Support Module § 0 · Data and Information Module § 0 · Development Module § 0. The platform pages of this chapter state the rules those trees obey and one example each; they draw no module.

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.