Intent is not a prompt or an informal request. It is a normalized, bounded representation of what an operator or agent is authorized to attempt before an approval envelope can be issued.
The approval envelope is distinct from intent. Intent is what was requested and normalized. The envelope is what the control plane authorized and bound to specific parameters for execution.
A valid intent has structure: actor, action, target resource, parameters, constraints, policy version, and validity window. The structure is what lets an auditor compare what entered the governed path against what later executed.
Intent normalization reduces a raw request to a canonical representation. Granularity matters: the intent must be specific enough that the control plane can evaluate it, the approver can understand it, and the execution layer can compare it against the action that tries to run.
Contains: actor identity, client record identifier, field name, old value hash, proposed value hash, reason code, policy version, and validity window.
Excludes: free-form rationale that can change after approval, unrelated client attributes, or broad permission to edit the account record.
Contains: actor identity, account identifier, instrument, side, quantity, threshold classification, venue constraints, policy version, and validity window.
Excludes: approval for all trades in a session, unbounded instrument substitution, or later quantity expansion without a new authorization.
Contains: actor identity, alert identifier, disposition action, triggering parameters, required approver role, policy version, and retention class.
Excludes: a legal conclusion that the disposition is sufficient, a broad approval for future alerts, or permission to alter the STR determination outside the governed path.
Parameter binding makes approved parameters part of the approval, not a separate runtime claim. The execution layer checks the parameter digest against the approval envelope before proceeding. If the digest does not match, the action is denied.
Silent truncation is not an allowed narrowing rule. Any parameter change must be declared, deterministic, and semantically safe. If a proposed narrowing cannot be verified from the normalized representation, the system denies rather than edits the request into a different action.
Each step in a multi-step workflow produces a new intent with its own authorization. A parent workflow approval does not automatically authorize child step execution. Chained approvals are explicit, not inherited.
Intent normalization produces a canonical record from the raw request.
The policy engine evaluates the normalized intent against current policy.
The control plane issues an approval envelope bound to the intent and parameter digest.
The execution layer validates that the envelope matches the execution parameters before proceeding.
The validity window closes; the envelope can no longer authorize execution.
Any violation produces a DENY record, stops execution, and preserves evidence.
Execution stops. A DENY record is produced. The approval envelope no longer authorizes the action.
Execution stops. Re-authorization is required under the current policy version.
Execution stops. The current policy version is evaluated before any new envelope can be issued.
Execution stops fail-closed. Evidence is preserved for the rejected attempt.