Detailed standard · Controlled system design
From request to confirmed outcome.
A useful conversation is not the same as an authorized action. Reliable systems keep identity, information access, interpretation, approval, execution, and confirmation visibly separate.
Conceptual control flow. The appropriate stages depend on the actual system and approved scope.
Authority begins before an action is proposed.
Securing only the final write is insufficient. An unauthorized system may already have retrieved confidential information, combined records from the wrong customer, or disclosed details. Authorization belongs on reads and writes.
The model or interface may interpret a request. The business-owned control layer decides whether information may be retrieved and whether an action is eligible.
Conceptual sequence
Eight distinct responsibilities.
Request
Capture what the person is asking for without treating the request as authorization.
Identity and context
Establish the actor, organization or record, and permitted operating context.
Authorized retrieval
Retrieve only information the actor and workflow are allowed to use.
Interpret or propose
Organize facts, classify intent, calculate, or prepare a proposed action.
Validate
Check policy, eligibility, current state, required fields, conflicts, and limits.
Approve where required
Obtain confirmation or specialist review when consequence or uncertainty requires it.
Execute
Invoke only the specifically authorized operation with duplicate protection where appropriate.
Reconcile
Confirm the authoritative result and record success, rejection, partial completion, or follow-up.
Transaction integrity
Attempted, accepted, and completed are not interchangeable.
A request may time out after the receiver completed it. A provider may accept a job without performing it. A telephone connection may occur without a successful service handoff. Reliable records preserve those distinctions.
Retries must be bounded. Duplicate protection should fit the provider. Uncertainty should trigger reconciliation rather than an invented success message.
Partial failure
Recovery is part of the primary workflow.
Multi-step work can fail between systems. The design should identify which record is authoritative, which changes can be reversed, which require compensation, and who owns unresolved work.
- Keep the last confirmed state rather than inferring the desired state.
- Record correlation identifiers without exposing secrets or unnecessary personal information.
- Make safe retry, reconciliation, and manual correction explicit.
- Do not claim completion until the source of truth confirms it.
- Preserve a fallback when automation or a reviewer is unavailable.
Illustrative applications
The pattern applies without making every system an AI system.
Appointment change
Capture intent, then verify identity, current state, rules, availability, and confirmation before a permitted change. Read the result from the booking source.
Field-service request
Record the property, issue, timing, and known facts. Apply eligibility and destination rules before offering the request. Acceptance, dispatch, and completion remain separate.
Operational report
Retrieve authorized records, apply versioned definitions, reconcile totals, and separate observed results from forecasts. Material figures remain traceable.
Acceptance evidence
What to inspect before relying on the workflow.
Correct and incorrect identities, tenants, roles, resources, and actions.
Stale records, conflicts, duplicates, concurrency, and changed conditions.
Timeouts, provider rejection, partial completion, unavailable reviewers, and recovery.
Readback, reconciliation, audit records, limitations, and responsible owners.
Define the boundary before building the interface