Who may act?
Principal, operation, scope and applicable limits become explicit authority state.
Inspect authority →PLATFORM
The stack stays yours. The change gets a governed envelope.
Before consequential software changes, the decision should be explicit: who may act, on which exact state, under which conditions, and with what evidence? Causance represents that authority-and-evidence state around the change lifecycle. Your source systems retain their facts. Customer systems remain authoritative for execution and effects.
Composition, not replacement. Source control, CI/CD, identity, policy, security, GRC, cloud, observability and customer-operated systems keep the responsibilities they already own. A named system does not imply a current connector to every provider or product.
POSITION IN THE STACK
Facts in. Governed decision state. Effects stay customer-owned.
The useful architecture boundary is not “Causance replaces the SDLC.” It is whether consequential changes have an explicit, reconstructable authority-and-evidence contract before downstream systems act.
AUTHORITATIVE SOURCE FACTS
Source controlIdentityPolicySecurityTickets / GRCCloud / observability
Owning systems remain authoritative for the facts they produce.
CAUSANCE · GOVERNED DECISION PLANEConsequential software change
BOUNDIdentity + context
→ AUTHORIZEPrincipal + operation + scope
→ PROVEEvidence + verification + review
→ DECIDEEligible · held · rejected · indeterminate
History remains attributableFailure can stop progressionRecovery requires supported context
CUSTOMER-CONTROLLED EFFECTS
The customer still owns the power to act.
Credentials, enforcement, deployment, product ownership, emergency authority and operational effects remain in customer-controlled systems.
Observed state↺returns as attributable evidence
THE GOVERNED CORE
Four questions define the depth of the platform.
The public site separates these mechanisms so a serious evaluator can inspect them instead of accepting one broad product paragraph.
What proves eligibility?
Evidence is source-bound, checked for applicability and freshness, and tied to verification.
Inspect evidence →What happened?
Observed state and exact decision history support reconstruction rather than inference from final state alone.
What happens when the condition cannot proceed?
Failure can stop progression while preserving the context needed for revalidation and bounded recovery.
Inspect failure & recovery →OWNERSHIP BOUNDARY
Causance does not acquire the customer’s powers.
CAUSANCE LAYERReasoned state
- Identity and authority decision state
- Evidence applicability, freshness and provenance
- Verification, review and eligibility semantics
- Retained history, replay/reconstruction and bounded recovery mechanics
CUSTOMER LAYERPower and effects
- Credentials and enforcement
- Deployment and product ownership
- Emergency and break-glass authority
- Operational responsibility for downstream systems and effects
INSPECT THE MECHANISM