Follow a support decision through the system

The request and its contract

This fictional example follows a support request through the AI-system blueprint. It shows which rules and facts each component needs, what the analyst receives, and how the application checks the result. The service has not been implemented and its model and service tests remain unrun.

A training provider’s booking service is unavailable during planned maintenance. A support analyst asks: “Recommend a priority for ticket T17 and explain the rule. Leave the ticket unchanged.” The provider also has a separate emergency access route for urgent booking assistance. An outage can receive a lower priority during maintenance only while that route is available.

The proposed controller creates a task for organisation A, booking service B, at 10:15 UTC (Coordinated Universal Time) on 19 October 2026. Identity and permitted actions come from the application’s authenticated session. The mode is draft_only: the application permits no ticket write or external message. The accepted result is a supported recommendation or a precise request for assessment, with the ticket still at revision 4.

First follow the advisory task to its returned answer. The later action and recovery section adds a separately authorised write. The regression guide then uses the same case to compare two prompt versions.

Resolve the policy and facts

The policy owner supplies this deliberately small rule set. All three rules are version 1, effective for this organisation and service at the task time. These identifiers are local to this example.

SP-R2 declares SP-R3 as a dependency. The context builder resolves the full rule set from explicit applicability conditions. Searching only for “maintenance priority” would be an inadequate rule-selection contract.

The knowledge service reads these authorised records and returns their versions and field locations. In this example, the incident service guarantees that its current read at 10:15 contains the route status effective then. A real design must agree the freshness requirement and what to do if that guarantee is unavailable. The model cannot infer freshness from a search ranking.

Follow the handovers

The registry identifies the versions used for this task. A schema defines the fields and structure required in a proposal. The context manifest records which rules, sources and versions the model receives.

1. Registry → controller: resolve support procedure version 2, priority prompt version 4, policy version 1 and proposal schema version 1. Reject unresolved dependencies before making a model call.
2. Controller → context builder: supply the trusted scope, task mode and ticket revision. The builder selects SP-R1, SP-R2 and SP-R3, then requests the facts those rules require.
3. Knowledge service → context builder: return T17, M8 and I9 with source locations, current-read time and any gaps. The builder records all selected versions in its manifest and keeps source text distinct from instructions.
4. Context builder → model adapter: supply the task, procedure, rule set, source facts and output contract. The required response identifies priority, applied rule, supporting locations and unresolved questions.
5. Model adapter → validator: return a model proposal for priority 1, applying SP-R3, supported by I9’s unavailable route status and M8’s maintenance window. The validator checks the schema, source references and fixed policy decision independently.
6. Controller → analyst: show the accepted recommendation and explanation. Record the configuration and observations. Confirm T17 remains at revision 4.

The fixed rule calculation is simple enough for code. The proposed role for the model is to interpret the request and explain the source material. A team adopting this design should compare that contribution with a simpler service that applies the rules and returns a prepared explanation.

If the model proposes priority 3, the validator blocks that proposal. The model-step test still records a failure. Record the validator’s successful rejection separately, so it does not conceal the faulty recommendation.

An illustrative context manifest connects selection to later diagnosis:

task: recommend_T17
scope: {organisation: A, service: B, at: "2026-10-19T10:15:00Z"}
mode: draft_only
configuration:
  skill: support_procedure_v2
  prompt: priority_v4
  policy: support_priority_v1
  output_schema: proposal_v1
rules:
  - {id: SP-R1, version: 1, reason: complete_outage}
  - {id: SP-R2, version: 1, reason: approved_maintenance}
  - {id: SP-R3, version: 1, reason: required_exception_of_SP-R2}
sources:
  - {id: T17, revision: 4, field: service_status}
  - {id: M8, revision: 2, fields: [status, window, service]}
  - {id: I9, revision: 1, fields: [route_status, valid_from, service]}
gaps: []
allowed_effects: []

A real run also records content fingerprints (hashes), the model and its settings, context size, tool contract versions, access decisions and elapsed time. The manifest records what was supplied; it does not reveal the model’s internal reasoning.

Return a result the next component can check

An illustrative model proposal for this case is:

proposal: proposal_17
task: recommend_T17
ticket: {id: T17, expected_revision: 4}
status: recommendation
priority: 1
applied_rule: {id: SP-R3, version: 1}
supporting_locations:
  - T17@4.service_status
  - M8@2.status
  - M8@2.window
  - I9@1.route_status
unresolved_questions: []

The validator checks those references against the authorised snapshot and calculates the policy result independently. The application records validation separately from the model’s proposal. Only after acceptance does the controller show the analyst: “Priority 1: the emergency access route is unavailable during approved maintenance. The ticket has not been changed.” The system verifies the unchanged ticket; that claim cannot rest on the model’s text.

The alternative result is status: assessment_required, with priority: null and named unresolved questions. In this worked design, missing or conflicting required facts make the controller return that result before any model call. If a model proposal is rejected, record the defect and apply the configured retry limit or route it for human assessment; do not silently replace it and count the original trial as a pass.

Handle a missing or conflicting fact

If I9 cannot be read, the builder records route_status_unknown. The controller requests assessment from the support owner and leaves the ticket unchanged. It must not interpret absence of a retrieved incident as proof that the route is available.

If two current authoritative records disagree, the knowledge service returns both with their scope and times. Apply a declared precedence rule if one resolves the conflict; otherwise pause for the owner. A newer ingestion time does not settle it. If SP-R3 itself is missing from the registry, SP-R2’s unresolved dependency prevents execution.

Test these paths separately. Missing or conflicting facts require assessment by the support owner. A missing SP-R3 is a configuration failure for the configuration owner to repair before any model call.

Apply an approved change and recover its result

Suppose the analyst later authorises setting T17 to priority 1. This creates a separate action against the specific proposal and expected ticket revision. The controller rechecks the decision’s facts and policy at the action time. Changed facts invalidate the earlier proposal and require a fresh decision. The service owner must define how current those facts need to be at execution. A ticket revision check protects the ticket; it does not make reads from the maintenance and incident services part of the same transaction. If the required freshness cannot be established, the controller pauses the action for assessment.

The following is an illustrative service contract, not an existing interface:

request:
  operation: set_priority
  ticket: T17
  expected_revision: 4
  priority: 1
  approved_proposal: proposal_17
  operation_key: set_T17_from_rev4_proposal17

The gateway verifies current permission, approval scope and decision validity. The ticket service checks revision 4, applies the update and stores a receipt under the operation key as one atomic operation: all three succeed together or none takes effect. In the proposed success case it returns revision 5. Repeating the same request with the same key returns that receipt. Reusing the key with different request data is rejected.

If the response times out, the task records outcome unknown. The controller queries the receipt using that key. A receipt confirming revision 5 completes the action. An authoritative result that the operation did not commit permits a retry under the same contract. If the service cannot establish either, the work remains unresolved for reconciliation; the controller must not create a new key and risk a duplicate change.

A concurrent change to the ticket causes a revision conflict. Reload the current state and reassess. Any replacement proposal or expected ticket revision needs approval that covers it. If the target service cannot provide atomic receipts and repeat protection, design a reconciliation process before allowing automatic writes.

Define acceptance at every stage

Use these observations as the acceptance contract for the example. The regression guide shows how to select cases, repeat trials and compare the old and candidate prompts within a budget.