Modules and their runtime declarations

1. What a module is in software

P A business module is a versioned declaration of behaviour, not a second C# service. The platform loads its root profile, stage graph, contracts, skills, memory owners, evaluation references and checkpoint placements from a module manifest. The shared runtime executes the declaration as TASKS and plan revisions. Executable handlers live in the libraries of Software Architecture; customer values are rows and plug-in content. The existing C# namespace AI.Support names the host platform and remains stable.

P Data and information is deliberately an embedded working graph. data identifies the declaration and the UI's working module; it is not added to CASES.MODULE, and it creates neither a data.root profile nor an extra Hd gate. The desk owns route/closure; support.resolution owns the working plan. Existing support.* identifiers and memory paths keep their meaning. A root can route and delegate work without personally doing the work.

2. Declaration, publication and pinning

P CASE_TYPES.GATE_PLAN entries can assign required_role and business acceptance scope to a declared checkpoint. For client-led Configuration, H1 scope and H3 business-result confirmations can belong to Customer representative and use the existing client card. H2 technical planning and effect gates still require their assigned technical role or eligible policy. The model cannot choose a cheaper role by changing its packet.

P Store each manifest as POLICY_VALUES.KEY = modules.<id>.manifest, VALUE_TYPE = json, under the existing governed policy lifecycle. The file examples under contracts/manifests are declaration seeds, not published profiles or enabled connectors. CASE_TYPES.STAGE_SET selects a subset/variant of the declared graph; CASE_TYPES.GATE_PLAN may strengthen its checkpoints. It cannot introduce an unknown handler or weaken an effect gate.

P Publication validates these rules before marking the policy version usable:

1. The manifest schema passes; stage ids and edge keys are unique.
2. Referenced profiles, skills, contracts and eval sets resolve to published versions, or the manifest remains a draft.
3. Every stage names its input/output contract and completion assertion; every edge names its triggering result or condition.
4. Every case variant has an entry and a reachable terminal outcome. Rework cycles are explicit; ordinary dependency edges are acyclic.
5. Every checkpoint names a registered gate kind and lifecycle event. Effects are classified by Gating, never by a diagram colour.
6. A memory node has exactly one canonical owning profile. A profile may own several explicitly listed nodes; ownership is checked against MEMORY_DOMAINS, not inferred from a boot path.
7. The declared model/data class is compatible with every profile. Deterministic handlers declare execution_kind = deterministic and a code handler key; they have no model route.

P On case open, persist the selected manifest policy id/version/hash and case-type id/version in the initial state paper. Every child task inherits that selection. Later publishing changes new cases only. A resumed case either reads its pinned declaration or runs an explicit state migration recorded in the ledger; “load latest” is not a resume strategy.

3. From a declaration to running tasks

P Configuration inputs and subsets. S1 produces configuration input: a full product or a scoped change. S2–S5 consume it plus the results of their selected dependency stages. A delta binds unchanged prerequisite facts to fresh baseline papers; it does not fabricate a sign-out for an unrun stage. The case-type stage set supplies explicit entry/dependency edges for its chosen subset and must pass the same acyclic/reachable/contract checks; simply deleting nodes from the full-product graph is invalid. Joint proof joins every selected stage and external obligation required by the objective. Template tasks are bounded instances of S2 keyed by template, using the existing profile; their result matrix must cover the declared keys before the parent continues. Case journeys § 5 and its fixtures define this case variant.

P A stage's profile_variants map enumerates permitted domain/source specialisations. CASE_TYPES selects its key and the runtime persists the chosen profile version; it never treats a display label as a class name to load. Handover state carries handle_scope_case_id so a subcase uses the authorised parent handle namespace without exposing values or inventing a second identity map.

P The root proposes a stage subset in plan revision 1, constrained by the manifest and the case type. The service validates it and creates the root/stage TASKS rows. Parents, stage ids and task paths are immutable identities; task state changes through the scheduler. Completion returns a validated result paper, not the predecessor's transcript. A dependent stage starts only after the required result revision exists and its assertions pass.

P Gate ownership is explicit: H1 validates agreed scope; H2 validates a route or working plan at the event named in the manifest; H3 validates the produced packet/result. For Support, route H2 and a revised working-plan H2 have different task/plan identities. Returning from investigation does not recreate an unchanged route approval. A material route or plan change creates a new revision and invalidates only decisions bound to the superseded revision.

P The root service, not a stage's prose, evaluates whether prerequisites are met. A stage can return blocked, needs_investigation, needs_handover, ready or another declared result in its open business body; the persisted task state remains one of the closed runtime states. Business outcomes are extensible policy data; engine states change only with a runtime/schema version.

4. The four declarations

P Seed manifests are Support, Data and information, Configuration and Development. Their stage graphs express the existing design:

• Support: intake → S1 → route; wait or recruit Configuration/Development or activate Data; return to customer closure.
• Data: S3 ready-solution check → S2 only when needed → S3 working packet → S4 confirmation → S5 execution → S6 verification; S7 on a failed outcome; S8 queued from the completed working stage.
• Configuration: S1 → phase 1 → phase 2A alongside phase 2B (S3 then S4) → joint preview proof → the requested deployment set and target proof. A tariff-only case selects the required subset. A bootstrap catalogue dependency is an explicit prepass, not a hidden violation of this order.
• Development: S1 scope/reproduction and S2 placement → S3 implementation → S4 tests → S5 review/MR → S6 release packet → S7 target decision → S8 deploy/verify/port → S9 only when reversal is needed.

P The module pages explain the domain decisions and their evidence. Their component inventories remain the implementation work breakdown. Manifests own the executable stage wiring; prose and diagrams must agree with them but are not independently editable runtime configuration.

5. Authoring and extension boundary

P An author supplies a prompt, schema-valid examples, the owned memory material and an eval corpus. A developer supplies skills, projections and connector handlers. Registering a new product family changes its field catalogue and case variant; registering an operation the engine does not implement is a capability gap, not an instruction to improvise. A new business outcome may extend a draft stage body; a new platform message or permission operation requires a versioned software contract.

P A summarizer may draft a missing repository node on behalf of its future owner. It never becomes an alternative writer of an active node. The owning profile confirms the content under Memory publication; a utility handler can create the empty domain/index metadata from the manifest without claiming that the knowledge is verified.