STATUS: EXTERNAL — share-safe, bounded, regulator-visible.
Apply External / Share-Safe Codex AI rules.
Owner review required before publication.
Thesis
“In transactional enterprise applications, execution admissibility must be resolved before irreversible business object mutation.”
Flow (conceptual)
Workflow / application action → RAP behaviour / transactional boundary → execution admissibility check → allow / block / escalate → state mutation
What this is
A placement pattern for pre-commit admissibility inside transactional enterprise applications:
- The application (or workflow) may propose a change through its transactional behaviours.
- The enterprise must only allow irreversible business object mutation when admissibility resolves at the commit boundary (T=0).
- The boundary is defined by where transactional intent becomes committed state, not by where a user or agent initiated the action.
Why prior approval is not enough
Prior approval is necessary in many operating models, but it is not sufficient when:
- authority can change between approval and commit (delegations expire, roles change, thresholds are crossed),
- state can change (the business object or dependencies have moved since approval),
- constraints can change (policy, risk controls, or separation-of-duties conditions become applicable),
- context can change (the workflow rationale no longer holds, operational mode changes),
- and evidence may no longer be valid (the facts used to justify the action are stale).
Admissibility is therefore a T=0 question, not a historical one.
Where consequence binds
Consequence binds at the point where the system:
- commits a transactional mutation, and
- makes the resulting state authoritative for downstream processing, reporting, and obligations.
This is the point after which “undo” is no longer an institutional control (even if a technical rollback is possible).
What must be admissible at T=0
At the commit boundary, admissibility must resolve with current:
- Authority
- Who is accountable for this mutation right now?
- Under what delegation, mandate, or entitlement envelope does it proceed?
- State
- What is the current state of the business object and required dependencies?
- Are preconditions still true?
- Constraints
- What prohibitions, limits, approvals, and separation-of-duties controls apply right now?
- Context
- What workflow, case, or operational purpose is this mutation part of?
- What operational mode applies (e.g. normal operations vs exception handling)?
- Evidence
- What evidence supports admissibility?
- What evidence must be bound to the mutation so later review can see what was asserted at commit time?
AoR mapping (mutation surface identification)
Architecture of Record (AoR) contributes by identifying and describing:
- the authoritative business object mutation surfaces (where state can change),
- the commit points where those surfaces become consequential,
- and the ownership and control expectations that attach to those mutation points.
AoR does not implement controls; it makes the mutation surfaces explicit so admissibility can be placed where it matters.
SCIA Runtime (conceptual governance of the boundary)
SCIA Runtime governs the commit boundary conceptually by ensuring admissibility is resolved using:
- current enterprise state,
- explicit authority,
- applicable constraints,
- operating context,
- and bound evidence
…before the transactional mutation is allowed to bind.
This is not monitoring or after-the-fact reconciliation. It is pre-execution governance at the point of consequence.
Typed outcomes
The admissibility decision should yield stable outcomes such as:
- Allow
- Allow with conditions
- Block
- Escalate
What this is not
- Not ABAP code or application implementation detail
- Not RAP annotations or configuration guidance
- Not integration patterns or API specifications
- Not a policy overlay applied after the fact
- Not post-event audit or reconstruction
IP boundary
This page specifies architectural intent and placement only:
- No protocol internals
- No schemas
- No code
- No product-specific configuration steps
Request Briefing
Request a briefing to identify one transactional workflow, map its business object mutation surfaces, and define the T=0 admissibility boundary where consequence binds.