01 · IDENTITY
Who or what acted?
Bind the authenticated subject, tenant and role on the trusted side instead of accepting identity claims from the request body.
AI DECISION ASSURANCE
A valid output is not yet
a defensible decision.
When AI influences an approval, recommendation, prioritisation, exception, service promise or workflow action, the important question is not only whether the model produced an answer. It is whether the decision used the right identity, authority and evidence, avoided duplicate intent, executed correctly, and produced a verifiable outcome.
THE DECISION PATH
Can you prove why an AI-assisted decision deserved to happen?
AI Decision Assurance examines the operational decision path around a consequential AI-assisted action. It does not replace model monitoring, governance, ERP, CRM, WMS, MES or the organisation's responsible functions. It adds a bounded evidence layer around one decision workflow.
02 · EVIDENCE
What did the decision actually know?
Check source provenance, freshness, contradictions and missing dependencies before consequential intent is accepted.
03 · AUTHORITY
Was the action permitted?
Apply explicit authority and default-deny policy before the system is allowed to proceed.
04 · REPLAY
Was this intent already executed?
Recognise exact replays while rejecting materially changed intent that attempts to reuse an earlier action identity.
05 · EXECUTION
What was actually attempted?
Separate the decision from execution records so an approved recommendation is not confused with a completed real-world action.
06 · OUTCOME
What really happened?
Observe the downstream result independently so the system does not certify its own success by assumption.
SYNTHETIC EXAMPLE
“Approved” and “completed” are not the same statement.
Imagine an AI-assisted workflow recommends a customer refund and policy permits the amount. Decision assurance still asks whether the correct user and tenant were bound, the policy version was current, the request was not a replay, the payment instruction was actually executed, and an independent downstream receipt exists. A permitted decision can still end with insufficient evidence of the outcome.
Decision-assurance rule: preserve what was known, what authority applied, what decision was allowed, what execution was attempted, and what outcome was independently observed. Missing evidence stays missing; it is not converted into assumed success.
WHAT SHANX HAS ACTUALLY PROVEN
Claims stay inside tested boundaries.
The current SHANX reference and managed-staging evidence supports bounded synthetic and approved read-only validation of several decision-path controls. It is deliberately not presented as blanket enterprise production readiness.
| Capability | Status | Evidence boundary |
|---|---|---|
| Managed synthetic user → JWT → protected Edge identity boundary | PROVEN | Authenticated subject, tenant context and role context reached a live managed boundary. |
| Server-controlled tenant and role context | PROVEN | Identity context is bound on the trusted side rather than accepted from caller-supplied actor fields. |
| Intent idempotency and replay protection | PROVEN | Exact replay is recognised; changed intent conflicts rather than silently reusing the earlier action identity. |
| Durable queue, lease ownership, retry and dead-letter behaviour | PROVEN | Reference and managed Postgres paths validated stale-worker rejection, retry exhaustion and dead-letter handling. |
| Allowlisted read-only connector fail-closed behaviour | PROVEN | Unknown, disabled, hostile, DNS-failed, credential-missing and timeout cases fail closed. |
| Tamper-evident audit and separated outcome verification | PROVEN | Reference implementation validates hash-chain integrity, tamper detection and post-execution outcome observation. |
| Enterprise IdP, key rotation and forced session revocation | NOT YET PROVEN | These remain separate readiness gates. |
| Private network or mTLS, platform DR, external penetration test and production HA/SLA | NOT YET PROVEN | Not claimed as current production evidence. |
For the wider workflow context, see SHANX Enterprise AI Assurance.
BOUNDED DECISION REVIEW
Start with one consequential decision path.
A first validation should be narrow enough to reconstruct end to end. One workflow, one accountable owner, one approved evidence boundary and measurable acceptance criteria.
01Select the decision
02Map identity + authority
03Map evidence + replay
04Observe execution + outcome
05Go / modify / stop
Typical first boundary: synthetic or explicitly approved read-only evidence, no production credentials by default, no live production writes, and no claim beyond what the resulting evidence establishes.
FAQ
AI decision assurance, in plain language.
What is AI decision assurance?
It is the discipline of validating the operational evidence around an AI-assisted decision: identity, authority, source evidence, replay status, execution and downstream outcome.
Is this the same as model validation?
No. Model validation examines model behaviour and performance. Decision assurance focuses on whether a consequential operational decision was properly authorised, evidence-backed, executed once, and independently observable afterward.
Is this the same as AI governance?
No. Governance defines ownership, policy and acceptable use. Decision assurance tests whether one real workflow actually follows those expectations under normal and failure conditions.
Does SHANX certify compliance?
No. SHANX does not currently claim legal, regulatory or compliance certification. The evidence supports a bounded technical and operational validation within an agreed scope.
What should the first review contain?
One consequential decision, the systems and evidence it relies on, the authority that should apply, the expected execution, and an independently observable downstream outcome.
BRING ONE DECISION PATH
Customer asks. SHANX shows evidence.
If an AI-assisted decision in your workflow could create material operational, customer or financial consequences, send us the decision path and its current system boundary. We will tell you what is already proven, what remains unproven, and what a bounded validation would need to establish.