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 and Information 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. Select a case and follow ten moments through arrival, investigation, plan, execution, proof, reversal, completion, learning and the next request. Each includes the wireframe, endpoint request/payload, saved records and agent work. At Establish, expand the agent initializations and full task/model prompts, including Karpathy discipline; at Plan/Prove inspect typed responses and inter-agent messages. Case Protocol explains the exact service boundaries and protocol examples. The walkthrough data is the per-case acceptance inventory. Screen drawings illustrate the existing layout; adjacent text supplies this case's content.
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.
| Unit | Required granularity | Cases that test it |
|---|---|---|
| Customer objective | Requested result, agreed scope revision, target surfaces and required acceptance; source aliases refer to the same request | DC-14 notification/Jira mirror; CF-18 amended requirements; DV-03 programme referral |
| Plan step | One independently verifiable action with a stable id; multiple statements may implement it | DC-02 family repair; DC-19 relaxation and restoration; DV-15 library plus rows |
| Agent task | One owning profile, bounded inputs, result contract and dependencies; isolated verification uses a separate task | DC-02 transfers investigator plus verifier; DV-02 backend, PL/SQL and configuration work |
| Connector operation | One declared transaction or external effect; exact mutation identity survives retries | DC-07 recalculation sequence; CF-09 sequence DDL; DV-01 deployment job |
| Assertion | One named invariant or target observation over an explicitly enumerated scope, with evidence and revision | DC-05 all date layers; CF-05 every template/selector; DV-07 both shipped halves |
| Learning item | One reusable mechanism or procedure, owned by an existing profile; case history remains provenance | DC-02 variant discrimination; CF-01 repeated relaxation; DV-17 lineage mappings |
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. One journey across the screens, backend and agents
| Moment | Customer and operator | Backend and durable result | Agent responsibility |
|---|---|---|---|
| Arrival | Client Start a request / My requests; operator Inbox shows the linked case and origin | Connector authenticates, scans attachments, substitutes handles, resolves mirror aliases and atomically stores ARRIVALS, CASES, initial papers and outbox work. An authorised arrival opens automatically; ambiguous initiation authority waits visibly |
platform.intake normalises; support.triage classifies and searches precedents; support.root validates the route through its governed gate plan |
| Establish scope | Case chat shows what is known; One request asks only the unresolved business question | Pin manifest, case type, profile/model/skill versions. Store target inventory and required result in a plan revision. Shared object handles alone never merge unrelated requests | Root chooses the permitted stage subset; specialist investigates the current estate and tests the retrieved mechanism, not just the matching symptom |
| Plan and decide | Plan gate, then Case at a gate / Decisions show exact changes, scope, restore path and decision holder | Validate dependency graph, capabilities, target schemas, impact keys and assertions. Bind decisions and grants to current artefacts; a plan approval does not itself dispatch effects | Stage owner proposes; independent verifier tests the mechanism where required; platform.write_auditor reviews semantics plus mechanical checks |
| Act or wait | Case chat shows applied steps or who must act and since when; One request gives a clear instruction | Scheduler leases tasks. RUNTIME_CALLS journals each platform effect; executor applies through the connector. External work is an obligation with a request reference, never an invented platform write. Waiting releases the worker |
Stage owner interprets results and coordinates dependencies. The deterministic executor performs mutations; an LLM cannot hold an open transaction or bypass a grant |
| Prove | Where and the report show each layer and target; the customer sees the achieved result | Assertion runner records current evidence for every required member and surface. Partial or unknown effects block dependent work and resolution. A report of success wakes verification; it is not proof | Specialist checks domain invariants; verifier checks independently; the root compares achieved proof against the requested outcome |
| Deliver | One request / Acceptance distinguishes preview, instructions, delivered result and remaining work | Record gated send/delivery and the correct acceptance scope. Resolve only after required obligations pass and post-result work is durably queued; customer acceptance closes the request | Communicator prepares plain-language output; root does not close a parent because one subcase, script or image build completed |
| Learn | Customer delivery proceeds; operator Knowledge / Studio shows proposed experience, changed skill and evaluation | In the resolution transaction, enqueue an idempotent post-result task keyed by case and verified result revision. Store proposals, uses, evaluation and publication independently of the session | The stage that learned proposes; the canonical domain owner reviews; support.curator owns the shared case index. A justified “nothing new” still records outcome and reuse |
| Next occurrence | New request begins with relevant precedents and a shorter justified plan | Dedup delivery retries, not distinct customer requests. Search active, compatible versions; record use and current applicability evidence. Fresh plan, impact scope and grants are required | Triage retrieves by symptom, product family and confirmed trigger; specialist discriminates variants and rechecks current state. Existing knowledge can remove rediscovery, never current verification |
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 and Information 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:
- 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.
- Knowledge or skill: retain a proposal with sources and observed versions; repair a wrong existing claim immediately through a new revision. Apply the existing 3/7/20 creation/refinement ladder, review/independent-use publication rules and dependency-scoped evaluations. Every applicable owning module participates; Support S8 is not the only module allowed to learn.
- 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:
- 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.
- 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.
- 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.
- 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.