Components — Configuration module

Purpose

Configuration Module says what the module does; Configuration Module says what each stage owes its neighbours. This page says what has to be built: every component of the module, its kind, what it consumes and produces, how it is proved done, and who can build it without waiting for anyone else. It is the phase-1 deliverable for this module and the work breakdown for phase 2 (Delivery § 1, Delivery § 1.4).

Evidence base: the wiki's stage pages, and the three configurator documents of 03.09.2026 — Requirements, Design, Product design — reconciled in Product Configurator § A. Rows marked new 03.09 come from that reconciliation and are additions to the module as previously specified.

0. The six kinds of component

P Every component of every module is one of six kinds. The kind decides who builds it, what "done" means, and whether two of them can be built in parallel.

P The kinds are not layers. One deliverable of the module — "the Abacus stage" — is an agent, three skills, one projection and a memory domain, and those four are built by different people against the contracts of § 2.

1. The map

flowchart TB
  C["Product / delta input
stage sign-outs"]:::store
  A["Normalizer and
selected stage profiles"]:::work
  S["Rating, offer and
catalogue assertions"]:::work
  G["Auditor, gates and grants"]:::decision
  X["Connector execution"]:::work
  P["Template and target proof"]:::proof
  M["Configuration knowledge
and evaluation"]:::learn
  C -->|"validated input"| A
  A -->|"invoke"| S
  S -->|"effect proposal"| G
  G -->|"authorised operation"| X
  X -->|"recorded result"| P
  P -.->|"learn after result"| M
  M -.->|"published revision"| A
  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 C href "../contracts.html" "Inputs, selected plan, obligations and signed result contracts are built first."
  click A href "configuration-module.html" "normalizer; Abacus, IPAL, Offer and Serdica stage owners"
  click S href "../50-agents/agents-memory.html" "Deterministic procedures and assertions; no target permission is inherited from a skill."
  click G href "../gating.html" "Every applicable requirement is bound to the current proposal."
  click X href "../contracts/Connectors.Abstractions.cs.html" "Registered read operations and separately granted effects use their own recovery form."
  click P href "../case-protocol.html" "Verify the complete requested target and any external dependencies."
  click M href "../50-agents/agents-memory.html" "Record outcome; evaluate proposed knowledge or skill changes before reuse."

Configuration component responsibilities. The tables below enumerate each profile, skill and connector; this map shows their contracts and handoffs.

2. Contracts — the four that block everything else

P These are track T0 (Delivery § 1). Until they exist, five stage authors cannot start; once they exist, the five never need to talk to each other.

P The drafts are drafts on purpose (D139, Contracts § 2): a required core the platform validates and an open body a case may extend; a stage that adds a field records it in its sign-out, and the author lifts recurring additions into the next draft version.

P Three additions from the configurator documents (new 03.09):

• provenance.kind ∈ {spec, system, decision} on every specification line, beside the existing source — the SPEC / SYS / DEC discipline, where a decision line is by construction an unresolved[] item and a system line cites a measured count (C-7 — decided 04.09.2026, D124: schema 1.1 carries it; Stage Normalization § WS-7).
• meta.sources[].authoritative_for[] and a conflicts list — the source set is inventoried before it is read, and a later file supersedes only where it says so F (Design § 04).
• unresolved[] entries gain assumed and cost_of_being_wrong, so an open question does not block: work continues under the stated assumption and the answer either confirms it or triggers a known amount of rework F (Design § 04).

3. Agents — one author, one prompt, one memory domain

P Every row is a profile in the Agents catalogue. The two right-hand columns are what makes the authors independent: a disjoint domain, and an eval set that runs without the other four stages.

P The graph — who spawns whom, which sub-agents are isolated, and where the write path runs. The table under it carries every profile in full; the platform-wide profiles these draw on are Agents § 1.

flowchart TB
  R["Configuration root"]:::owner
  P["Normalizer and
selected stage tasks"]:::work
  K["Own index and
selected domain knowledge"]:::learn
  T["Delta plan and
stage result papers"]:::store
  V["Independent review"]:::proof
  G["Required decisions"]:::decision
  E["Execution coordinator"]:::work
  R -->|"assign bounded task"| P
  K -.->|"context"| P
  P -->|"propose and report"| T
  T -->|"independent evidence"| V
  V -.->|"verdict"| R
  T -->|"reviewable packet"| G
  G -->|"permit"| E
  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 R href "configuration-module.html" "The root owns the bounded objective and confirms child plans."
  click P href "configuration-module.html" "normalizer; Abacus, IPAL, Offer and Serdica stage owners"
  click K href "../50-agents/agents-memory.html" "Read compatible knowledge; consult its owner for judgement; write only in owned domains."
  click T href "../case-protocol.html" "Task text, evidence, scope and completed assertions remain durable."
  click V href "../50-agents/agents.html" "The validator receives scoped evidence without the author's transcript."
  click G href "../gating.html" "Root presents unresolved scope and permission decisions; it cannot invent authority."
  click E href "../50-agents/agent-runtime.html" "The deterministic handler applies only a current permitted packet."

Task ownership and review: a profile is reusable across cases. Each task has its own parent, inputs, evidence and restricted tool catalogue; the root remains responsible for the result.

P The estate prober is new, and it is an isolation, not a specialisation (new 03.09). It is told nothing about the product being built and cannot ask, so it cannot return the answer the caller wants; it returns the constraint, the live distribution, the counts and the measurement date, never a recommendation or a "usual value" F (Design § 04). Why it is worth a profile: the estate is evidence, not a template, and the failure it prevents is measured — PR_BASIC_LD.LD_TYPE permits FEE (check constraint PR_BASIC_LD_TYPE_CK, verified on PROD 07.09.2026) and 0 of 1 465 rows use it; MSG_TYPE permits LABEL and 22 rows carry it F (Requirements § 04). Being the first product to use a permitted value is allowed; doing it without noticing is the failure.

P What each isolation denies, because isolation is provisioning and not an instruction (Agents § 0.2): the source analyst's scope contains no database connector and no schema vocabulary, so storage cannot bend its reading; the estate prober's task carries no product intent; the validator receives original requirements, source citations, current baselines, dependencies and known uncertainties, while its context excludes the author transcript and private reasoning.

P Every write of every stage additionally passes the shared common.effect-applier skill's four checks before its gate — exactness, boundedness, reversibility and scope — run by the stage agent that owns the write, with the connector scope refusing anything outside grant and shape (Gating § 6, D200). It is a common definition, not a module one, so it is not a track of this module; it is listed here because no stage's write reaches a target without it.

4. Methods and executable helpers

P The module method subpage defines the procedures and their optional source/binary helpers. Runtime and connector operations are implementation mechanisms; they are not separately counted as learned skills or tools.

5. Projections — model in, artefact out, no model call

P The rule, stated once (D74, D120, D136). A configuration write goes through the system's own configuration endpoint wherever the coverage map (configure.endpoint_coverage) declares one, and otherwise through an approved statement template with parameters (Write Envelopes § 1). The agent never authors a statement that reaches a database: it supplies the parameters, the executor renders the template and applies it past the effect applier, and the same template emits the revert, in the same step as the artefact (D120) — so a phase is revertable without reading its transcript. The template, not a projection, is the permanently reviewable part, and two runs of one product diff at template + parameters. Why: model-written SQL is reviewable exactly once, by whoever is looking that day; a reviewed template applied to validated parameters is reviewable permanently, in code F (Product design § 10).

6. Connector operations the module needs

P Each is a versioned capability row; a connector refuses an operation that has no row (Failure and Recovery § 4).

P Intake is immutable (new 03.09): the source set is unpacked, hashed and stored once, and every later step reads the same rendition; later material creates a new immutable input revision in the same case when the objective continues; affected plans/acceptances reopen, and unrelated objectives become new cases F (Product design § 03).

P The write path's own contract (new 03.09), adopted from the service design for the rating surface, where the estate itself provides the safety property: write into a new version, then compile and deploy it on the working environment only; never update a row belonging to another deployed version; never write the compiled runtime artefact; an allow-listed table set in code, reviewed like any other security boundary; the exact statements previewed with a row-count estimate and a diff against the previous version; one transaction, one audit record; undo is discarding the version, not repairing it; and customer-facing deployment is a separate decision whose packet lists every version consuming a changed rate file F (Product design § 05, D113). The IPAL surface has no version boundary, so the same argument does not carry there — hence the three conditions of C-1.

7. Memory domains

P Engine knowledge and estate knowledge are separated (new 03.09): the rate-file grammar, the premium vocabulary and the version-and-deploy model are generic and travel with the platform; product codes, counted defaults and role names are per customer, measured on first connection and refreshed on a schedule, every count carrying its date F (Product design § 04).

8. What can be built in parallel

P Three waves. Inside a wave, the rows have no dependency on each other.

P The build tracks and the run phases are different axes, and confusing them wastes people. Five authors build five stages at once because the contracts make the stages independent to write. A configured product then runs through those stages in two phases with a sign-out between them, because the artefacts have real dependencies at run time (Configuration Module § 1, D75). The stage author of Serdica and the stage author of IPAL work in parallel in both senses; the stage author of Abacus works in parallel with them at build time and ahead of them at run time.

P The rehearsal that is usually skipped: before configuring a real product, re-emit a product that already works and explain every difference. It is the only rehearsal with an answer key, and its differences are exactly where the knowledge base is wrong F (Design § 08). It is the acceptance test of wave 2.

9. What this module does not build

P Named so nobody assumes otherwise, following the configurator's own list F (Design § 09):

• Moving a finished product between environments. Nothing in the estate carries a complete product across — the migration package touches neither the tariff nor the INSIS-side rating configuration. The module re-emits against the target instead.
• Keeping a configured product correct as the system changes. The specification is a statement about one moment; when a shared register or a validation framework changes underneath, no part of this design notices.
• Anything needing code. A backend branch for a product-aware package, an INSIS user exit, a column too short for a code — all leave as a handover at gate Hd, not as a configuration row.
• Judging the tariff. The module implements pricing and raises numbered questions about it; whether the price is right stays an actuarial decision.

Challenges

• P The nine contradictions of the reconciliation § C are all decided (C-1, C-3 by D72/D74/D75 on 03.09.2026; C-2, C-4–C-9 by D120–D126 on 04.09.2026); this page's § 5 and § 6 carry the D120 erratum (the emitting agent writes the revert; templates, not a projection, are the reviewable part).
• C The acceptance bar for a configured tariff — one reconciling quote, or a set across a factor matrix — is undecided and defines what verified means; settle it on the first slice (Product design § 11 DEC-6).
• P The estate prober's operation set is drawn from the configurator's domain probe; the first stage that needs a column it cannot answer extends it.