Case journeys — testing the architecture with real work

P The trainable intellect must carry a request from the customer's words to a proved outcome, retain what it learned, and apply that knowledge correctly on the next occurrence. These journeys test those boundaries against all 68 cases in the Data & Manipulation catalogue, Development catalogue and Configuration catalogue. The catalogues and their dated evidence remain the source of the historical claims. The journeys describe the proposed platform, not executions already performed.

Open the interactive case walkthrough. Choose a case, follow its actual module stages, and inspect the current card on the internal or customer surface. Five reusable screen patterns contain this case's request, observations, required outcome and actions. Where a stage has several checkpoints, State within this stage shows them without adding another workflow. Developer detail for this stage retains endpoint payloads, saved records, selected profiles, initialized tasks, assembled prompts including Karpathy discipline, communication, gates and execution/recovery contracts. Case Protocol explains the service boundaries.

The catalogue bindings, case UX examples and generated stage traces are review fixtures. Stage buttons inspect illustrative snapshots; they do not execute work, simulate elapsed time or certify that a prior state passed. First request, Similar request and Blocking variant test different conditions on the same module design.

P Case content is carried between stages. The authored evidence packs supply the original request, failure, findings, selected solution, bounded steps, checks, recovery and concrete memory/skill/tool lesson for every catalogue id. The initial solution take exposes what still needs to be established; investigation exposes the findings; the return to solution take chooses the remedy; confirmation shows the actual plan; application shows actions/receipts; verification checks the requested outcome. The same content generates the catalogue expansions, historical case-study screen notes and homepage copy.

P Source precision. DC-02's principal example is SD-1598: five policy periods existed, the print register had four entries, Bulstrad IT inserted the missing fifth entry, and the archive records subsequent database and print confirmation. It is not the uncreated-renewal or old-PDF variant from another MYR ticket. CF-05 is a composite example using named catalogue templates and documented selector/fallback behaviour; it does not claim a newly observed partner pricing incident. Historical observations, proposed v2 steps and success criteria remain labelled separately.

1. The unit of work and the unit of proof

P One customer objective owns a case. Its plan contains stable steps; a step names an actor, target, dependencies and assertions. A task is created where work must be independently scheduled, resumed, isolated or checked. A database statement, a row, a commit and a conversation turn are not automatically tasks. A family repair stays one objective even when several transactions and people are required.

P The execution-obligations contract is a versioned case paper. It joins the existing plan, task, effect and proof records. It adds no database table and is not a second scheduler. Its service-side validation is required before marking steps verified or a case resolved. The conformance checker exercises draft examples and negative cases; implementation must run the same checks against authoritative records rather than trusting references supplied by a model.

2. Module flows, shared screens

P One Support journey contains the selected work. Intake and classification → The route → the chosen work → Closure. The route selects its own Data & Manipulation stages, an accepted Configuration/Development subcase, embedded Assessment & Offers, or an explicit wait. The chosen work is expanded between the route and closure in the walkthrough; it is not a second customer journey. Stage names come from the same vocabulary as the product page. Plan, act, check and retain are responsibilities reused within those stages, not a replacement stage set.

P Stage, card state and screen pattern are different things. For example, Configuration S2 uses a workspace while rating is prepared, a Decision card at H2, a Decision card for an applicable effect gate, and a Decision card at H3 when its sign-out is ready. Those are states of S2. The prototype's small state selector exposes the relevant checkpoints; the product receives the current state from the server. No user presses “Next stage” to bypass a gate. Parallel lanes are joined by required results, not by their inspection order on this page. A stage result is not evidence that the entire customer outcome has been delivered.

P The route is the root's decision on the solution-take proposal. The root owns the route and customer result; support.resolution prepares the applicable method and solution packet. Displaying their responsibilities at different points does not create two cases or two approval queues. The UI projects the current case, plan revision and gate; inspecting another node never creates a decision. Changed scope or a newly established mechanism returns the affected packet for its required review.

P Keep the operational surface light. One primary card, one current responsibility and a short evidence summary are visible. The conversation, Ablera operator and composer remain visible; scope detail and raw proof open on demand. The concrete three-row examples stand for named business checks; they are not raw database rows or a three-assertion backend limit. Large families still require complete persisted membership/assertion matrices. The five patterns cover case work; they do not remove the separate Control, Metrics or Studio administration responsibilities in UI.

P The same UI at every level. The operations preview uses this walkthrough's renderers and styles with one selected case. Its chat, sub-plan and approval examples are embedded in the homepage accordion and UI § 6. Only the surrounding explanation changes. The full walkthrough preserves case/stage/state/surface in its link, so a preview opens at the same operation.

Cases that forced the common design

Projection rule for implementation

P Resolve (case, module, stage, task state, pending gate/obligation, result revision, viewer authority) into the existing case/card projection. Select one of the five patterns and supply only its case-specific data and allowed actions. The module/stage identifiers remain policy/manifest data, not an enum expanded with DC/CF/DV ids. A catalogue id is an evaluation fixture, never a screen or agent type.

P Root/child identity is resolved on the server. The internal view can inspect the accepted subcase and its papers. The customer stays on the parent request and sees only its scoped business question, external action or result. A child question is correlated to that parent projection; a client does not supply an arbitrary child case id. The requesting root joins required child outputs before delivery. REST reads refresh the projection; decisions/responses persist their revision-bound command and outbox work. The scheduler, not browser navigation, selects the next eligible stage. Case Protocol gives the exact endpoints and storage boundary.

3. External work, customer actions and truthful completion

P external_owner_step uses the existing parked task (question for a person, sub_case for a recruited module), with its business meaning in the execution paper. It carries the exact step id, designated actor/organisation, requested action, target, request record, opening time, expected returned evidence and resume condition. Cases and client requests project its age and waiting actor. A prepared SQL file means instructions ready. It means delivered only if instructions were the agreed objective; a request to repair the policy remains open.

P The customer may perform a UI action in their own session. The platform sends instructions through the existing send gate and waits; it neither requests their credentials nor pretends to have clicked. The client response endpoint records a scoped response or evidence against the outstanding step. The backend authenticates the actor and case, applies command deduplication and optimistic concurrency, scans attachments and queues verification. Evidence arriving by ticket or mail follows the same correlation path. An unrelated “done” message or an old plan revision cannot complete the step. Platform WRITE_LOG records platform effects only; externally reported actions remain attributed evidence in the paper.

P Resolution evaluates the objective, not a universal “write succeeded” flag. A read-only explanation needs a current-source check and delivered answer. Customer action or external application needs the promised surface proof. A proposal-only request needs the reviewed, delivered proposal. An unavailable connector or an out-of-scope programme can produce a scoped referral, with the original operational request still waiting unless that referral was the agreed outcome. A channel closure arriving early records the customer's event without fabricating outstanding technical proof.

4. Whole-family verification and temporary changes

P Before a family repair, persist a membership inventory and assertion matrix: system, member handle, layer, current observation, expected relationship, query/check reference and result. Enumerate missing members explicitly. For DC-02 this is periods 1…N across IPAL, INSIS and the MYR register; for DC-05 it is the framework date layers and cache; for DC-11 it is the object-version chain. Equality means the domain's mapped relationship, not literal equality of unlike status codes. A changed family membership invalidates the plan scope and its affected approvals.

P The five-step database discipline remains inside each connector transaction. Family proof spans all constituent effects after they land; IPAL and INSIS do not acquire an imaginary shared rollback. The plan records transaction boundaries, execution order and compensation. After a partial effect, retain claims and reconcile from the journal; do not repeat the earlier successful system. Customer-surface verification that issues a policy, consumes a number or sends a message is a separately declared effect.

P DC-19 / CF-01 are bounded temporary exceptions handled by the Data & Manipulation resolution profile. Permanent rule changes route to Configuration. The temporary packet contains both the relaxation and the restoration before the first write: original value/hash, approved temporary value, scope, restoration step, due time or action trigger, and H7 decision requirements. A row described as “for one policy” may enforce a shared rule; the impact is the row's real audience, so HW-shared applies when required. No assumption of “no shared rows” is accepted from the historical walk.

P The scheduler persists the restoration obligation before applying the relaxation. At expiry or verified customer action it creates/resumes the existing H7 task; a timer never grants authority. Restoration compares current state with the value this case wrote. External drift parks for reconciliation instead of overwriting the newer change. The temporary-exception case remains unresolved until restoration is verified. For a campaign whose agreed delivery ends before expiry, its stop-offering/removal obligations must have an explicit durable successor case and retained target references before delivery resolves. Stopping a session or closing a browser does not cancel either obligation.

5. Configuration deltas and coordinated releases

P A small change starts from a fresh export of the affected existing configuration plus the requested difference, represented by the configuration-change contract. It names targets, baseline observations, changed keys, assertions, selected stages and external dependencies. It does not invent a full new-product specification. Unchanged stages have an explicit reason and fresh baseline evidence supplying any consumed input; a missing stage result cannot be replaced by an empty “success”. Existing H1/H2/H3 checkpoints may share a reviewable packet where policy allows. Effect gates still occur before dispatch, including on a policy-authorised direct target.

P CF-05 carries a list of template work items: stable template key, selector/role scope, effective version, specification reference and expected result. Each item uses the existing single-template product schema as its leaf contract; S2 fans out bounded tasks by template and rejoins on a result matrix. Default-template fallback and an unrelated broker are negative tests. This settles the multi-template gap without making all product documents repeat every template. Target compilation/cache effects stay in the write path.

P CF-25 always checks the affected source and target table groups, schema capabilities and deployed code, in both directions. The approved desired delta plus per-group baseline is authority; TEST is not a universal source of truth. CF-09 sequencing DDL is recorded as a dependency with an authorised technical or external owner; it is not silently reclassified as transactional DML. Existing INSIS scope limits remain: CF-02/06/12/14/17 name the INSIS actor and returned proof explicitly. No new INSIS agent or blanket access is implied.

P A mixed release has one dependency graph over configuration rows, repository changes, packages, consumer images, PL/SQL, BPMN and external templates. Record exact revisions/digests and target checks for each required component. The order follows compatibility, not a fixed “backend then UI” rule. A subcase signs its result; the owning root joins all required results before preview or delivery. CF-16/19/24 and DV-02/11/14/15 fail acceptance if either the code or row half is missing.

6. Agent granularity and learning ownership

P The 68 catalogue ids are evaluation cases, not 68 profiles. Transfers, pricing, printing, access and master-data investigators retain their current responsibilities. Multi-year motor and cargo are family-tagged skills, invariants and examples under support/investigators/transfers; pricing/printing investigators consult that owner for family judgement. No child memory node is needed until the existing node-creation criteria are met. riskmodel work belongs to the backend repository implementer with a Python skill; it is not work in the unrelated intentgpt repository.

P In Development, the planner supplies a lineage-specific seam and accepted scope, implementers work in isolated worktrees, the deterministic test runner returns test evidence, the reviewer evaluates the full change and generated artefacts, and the deployer joins the release. A case can contain a commit series and reversals. Ports carry source/target heads, semantic equivalence evidence and target tests; matching subjects do not prove a port. A protected ref rewrite invalidates affected preflight and review evidence. Customer logic in a shared path still requires the applicable core-placement decision; the same human may hold both roles, but authorship does not bypass that decision.

P DV-03 reinsurance and DV-08 cross-cutting currency programmes exceed the current small-change charter. Intake records the programme request and accountable external delivery owner, and can receive individually scoped implementation cases through the same existing intake. The journey explicitly tests referral and return status. It introduces no programme-management module or claim that a long-running programme is one ordinary task.

P Post-result processing separates three decisions:

1. Experience: record what was requested, achieved, proposed but unapplied, reused, contradicted and still outstanding. Deduplicate by canonical source-request identity and result revision; mirrors, retries, subcases and forks do not inflate independent success counts.
2. Knowledge, skill or tool: retain a proposal with sources and observed versions; repair a wrong existing claim immediately through a new revision. Use the 3/7/20 review cadence and the earlier-automation rule in Memory, skills and tools: repeated mechanical work can justify source/binary tooling before the third case. Apply the relevant publication checks and dependency-scoped evaluations. Every applicable owning module participates; Data S8 is not the only module allowed to learn.
3. Authority: update clean-instance evidence only for the exact eligible operation shape. A retrieved precedent, an externally reported success, a case closure or a new article does not itself approve a write shape or accept a risk class.

P Keep the existing mechanism/object-class signature for fix-shape recurrence. Add a separate confirmed trigger family (for example revert-to-application on multi-year motor) with evidence and affected outcomes. Shared gestures alone do not prove one cause. Repeated verified trigger failures can propose a single linked Development/Configuration correction; ordinary urgent repairs continue within their authority. The known issue remains open until the causal fix is deployed and checked. A waiting or proposal-only case contributes occurrence evidence, never a clean execution instance.

7. Developer acceptance and limits

P The walkthrough defines a positive path and a falsifying variant for every catalogue id. Build acceptance in this order:

1. Run synthetic paper/contract fixtures, including incomplete family coverage, early external “done”, overdue restoration, stale plan replies, unknown effects, omitted release components, mirror-count inflation and stale precedent selection.
2. Feed the original request without its later analysis to the candidate profiles. Check route, selected specialists, required evidence, effect classification and proposed assertions against the journey. Hold out related tickets by request/causal family so the later answer is not already in the prompt.
3. Re-run the same request with a reviewed experience/skill revision available, then with an incompatible or contradicted revision. Measure retrieval use and avoided rediscovery; current preflight, target proof and authority must remain.
4. Exercise actual API/storage/worker recovery, then approved target connectors and browser flows on the declared environment. Faults after dispatch, before checkpoint, during waiting and after closure must retain obligations without replaying effects.

The offline checks establish contract consistency and catalogue coverage only. Model quality, Oracle transaction behaviour, target permissions, real deployment jobs and actual browser journeys remain implementation acceptance, and cannot be claimed from these design fixtures.

Core request examples

P DV-09's illustrated shared numeric-parser change and DV-16's generic paging-clamp change are Core Development requests. They use the embedded Assessment & Offers graph inside Support: clarify request → assess effort → prepare offer → customer decision → communicate. Core is the offer type. They have no Source implementation or reversal path. The archived material supplies no offer or delivery commitment, so the prototype marks those terms pending and does not enable acceptance of a completed commercial result. The broader case families can contain customer-specific variants; classify their actual scope again. Programme referrals DV-03/DV-08 remain separate. Mixed cases separate any new shared mechanism into a Core request while retaining independently scoped customer or target work.