Factor V

Context In, Decisions Out

Principle

Governance decisions should be computed from structured requests and return explicit results.

A visible decision boundary—context in, permit/deny/obligations out—turns governance from tribal memory into something you can inspect, reuse and prove.

Problem

Without a defined request shape and an inspectable result, governance becomes a mixture of scripts, tickets and human memory. Hidden chains and UI-only toggles cannot explain why they permitted or denied—or what obligations followed.

Sensitive activities need concrete questions: may this principal perform this action on this resource in this context? If the answer is only a silent state change, you have automation, not governance.

Characteristics

Structured context

Inputs have a shape: principal, action, resource and context. Engines and humans can see what was considered.

Explicit decisions

Outputs are more than a boolean when needed: permit, deny, obligations, reasons and references to evidence.

A visible boundary

Policy evaluation is a named step between request and action—not an opaque side effect buried in a workflow.

Positive examples

“May this agent call this tool on this dataset?”

A concrete question with principal, action, resource and context—answerable by an engine and explainable afterwards.

“May this branch be promoted?”

A promotion decision that returns permit/deny, reasons and any obligations.

Permit with obligations

A decision that is more than a boolean—encrypt, notify, record—travelling with the permit into the path of execution.

Negative examples

Hidden script chains

Outcomes produced by opaque automation with no request/response boundary.

Approval by tribal knowledge

Decisions that live only in people’s heads and cannot be audited or reused.

UI-only toggles with no decision record

State changes that look like policy but leave no context, reasons or evidence.

Anti-patterns

Policy as workflow

Treating a ticket queue as the decision engine. Workflow can orchestrate remediation; it should not replace an inspectable policy evaluation.

Assumptions instead of context

Evaluating on implied context that was never stated in the request—so nobody can reproduce why the decision went the way it did.

Allow/deny with no rationale

Opaque results that cannot cite inputs, rules or obligations. Unexplainable decisions are unverifiable ones.

Diagram

How are decisions made?

Context enters a policy boundary; an explicit decision, action and explanation come out.

Discussion

Applying this principle means making every governance decision look like a question with an answer.

1. Define the request shape for each sensitive activity you evaluate.
2. Put policy evaluation on a visible boundary between request and action.
3. Return structured results—permit/deny, obligations, reasons.
4. Record the context and the decision so evidence can cite them later.
5. Keep workflow for remediation and escalation, not as a substitute for decisioning.

The lineage is familiar: XACML, Cedar, OPA and DMN differ in style but agree that the decision boundary must be visible and the request must have a defined shape.

Related factors

Concrete decisions sit on top of scoped activities and feed continuous control:

• Govern Sensitive Activities — which questions deserve a decision boundary
• Continuous Governance — where those decisions interrupt or condition change
• Evidence by Default — decision logs as normal exhaust
• Governance is Version Controlled — policy logic stored as artefacts
• Governance Is Composable — how layered policies combine into one evaluation

References

• Cedar — principals, resources, actions and schema’d context
• Open Policy Agent — structured input and structured decisions
• XACML — request/response evaluation and obligations
• DMN — explicit, business-readable decision logic
• Gatekeeper — admission-time evaluation of structured requests
• Gemara — layered artefacts that decision engines can consume