Follow a support decision through the system

The request and its contract

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 organisation also has a separate emergency access route for urgent booking assistance. Its status can change the decision.

This is the connected example for the AI-system blueprint. You can follow it without reading the Portal’s general service example. The records below specify expected behaviour. The service is unimplemented, and the proposed model and service checks remain unrun.

The 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; no ticket write or external message is permitted. Success means a supported priority recommendation, or a precise request for missing information, with the ticket still at revision 4.

The blueprint defines the reusable responsibilities; this page specifies one request, its records and the expected result. The regression guide uses the same case to compare prompt versions. The advisory path ends at a validated recommendation. The later action and recovery section applies only if the service will also perform approved writes.

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

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: propose 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 model’s useful work is interpreting and explaining the request and source material. If it proposes priority 3, the validator blocks the answer. The model-step test still records a failure. Record the successful blocking of the answer separately, so it does not hide a defective prompt.

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 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 all three cases. They distinguish a missing fact, conflicting facts and an incomplete policy configuration. Each produces a different diagnostic even though all may lead to human assessment. The first two concern incomplete or disputed information. The missing rule dependency 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 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. A repeat with the same key and payload returns the same receipt; reuse of the key with a different payload 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 current state and reassess; do not silently reuse approval for a different decision. If the target service cannot provide atomic receipts and repeat protection, design a reconciliation process before allowing automatic writes.

Define acceptance at every stage

These checks provide the starting cases for prompt-change regression testing. Keep this table as the acceptance contract. The testing guide owns test selection, repetition, cost and comparison of the old and candidate prompts.