Define the control in the same model as the work
A policy becomes more useful when the application does not have to translate it into separate implementation logic before it can act on it. The Policy Builder lets teams express application controls against the same concepts used by execution.
Subject - Workload - Tenant - Resource - Action - Purpose - State - Environment - Proposal
Benefit: Keep the rule and the application behavior it governs connected instead of recreating the same control across UI, workflow, model, API, and integration code.
See whether every path to an effect crosses the required control
A policy can be perfectly written and still fail to govern the application if one execution path bypasses it. The Execution Graph makes policy coverage inspectable.
Does every path to this effect cross the required policy decision?
Does every permit result complete the required obligations?
Does every fallback path preserve the same residency restrictions?
Does every retry revalidate an expired decision?
Does every evidence view enforce its inspection policy?
Keep prompts separate from policy enforcement
A model can be instructed not to reveal restricted information. That instruction can be useful. It is not the same as independently enforcing whether information may be disclosed. Access, data eligibility, tool use, approvals, persistence, and external actions can be enforced independently by the application runtime.
Give policy decisions facts with known meaning
A policy decision is only as reliable as the facts it evaluates. A policy fact should be more than a variable named risk_score, user_role, or amount.
What kind of value is this?
What proposition does it establish?
Which system or calculation produced it?
Which tenant, resource, taxonomy branch, or application does it describe?
When was it valid and is it still current?
What should policy do if the value is unavailable?
How was the value produced?
Return more than allow or deny
Permit
The application may continue.
Deny
The requested path is not allowed.
Require additional evidence
The application must gather facts before continuing.
Require human review
A qualified reviewer must intervene.
Require stronger assurance
The actor must complete step-up authentication.
Transform or redact
Information must be changed before crossing the boundary.
Reroute
The workload must use another eligible route.
Limit
The action may proceed only within specified constraints.
Re-evaluate
Policy must be checked again at a later boundary.
Turn policy decisions into enforceable application work
A decision alone does not enforce a control. Decision, obligation, enforcement point, and evidence remain distinct but connected responsibilities.
Decision
What does the rule require?
Obligation
What mandatory work must happen?
Policy Enforcement Point
Where does the application ensure required work happens?
Evidence
How do we prove the decision, obligation, and enforcement were honored?
Make policy scope explicit
Policy scope can depend on tenant, legal entity, Taxonomy Scope, resource class, action, purpose, jurisdiction, data classification, application state, and model or capability class.
Combine policies without hiding precedence
The Policy Builder should make precedence, conflict behavior, exception authority, and obligation aggregation explicit.
Test policy before publishing it
Policy testing should be part of the application lifecycle, not a separate exercise after deployment.
Expected permitted behavior.
Expected denial.
Values around thresholds.
Behavior when evidence is unavailable.
Multiple applicable rules that disagree.
Whether required runtime work is produced.
Whether every consequential path crosses the enforcement point.
Whether a new version changes expected behavior.
Version policy with the application it governs
The application should know which policy version applied to a particular Execution Instance. New executions can use new versions while running executions remain associated with the version needed to interpret their current state.
Benefit: Change governance without silently rewriting work already in flight.
Re-evaluate policy when the business state changes
A policy decision that was correct five minutes ago is not automatically valid forever. Re-evaluation may be needed when proposals, resources, actors, authority, waits, assurance, effects, or business state change.
Bind human approval to the exact proposal
Human approval is a policy obligation. It should remain bound to the exact proposal, evidence reviewed, approver identity, authority, policy conditions, assurance level, versions, validity, expiry, and resume semantics.
Explore Durable Execution & Human Approval
Preserve policy decision evidence
A completed application should be able to explain which control governed a consequential action: policy identity and version, facts evaluated, authority context, decision, obligations, enforcement, and business consequence.
Trace policy all the way to the effect
Policy-to-Effect Lineage connects governance decisions to the business consequences they were intended to control.
Policy -> Decision -> Obligation -> Enforcement -> Approval -> Business Operation -> Effect
Explore Behavior IntelligenceSee Governance by Construction in one business application
Supplier submits a proposal
The proposed bank-account change becomes a typed application object.
Data eligibility applies
Policy determines which information may participate.
Context is assembled
The application creates a governed Context Package.
Risk facts are calculated
Deterministic capabilities produce facts under declared definitions.
Policy evaluates the proposal
Subject, workload, tenant, proposal, facts, and version form the proposition.
Obligations are created
The result may require evidence, human review, or assurance.
The graph enforces them
The business action cannot continue until obligations are satisfied.
The effect boundary revalidates
Authority, proposal, approval, policy, and state are checked before commit.
Evidence remains
The completed history connects policy, approval, action, and effect.
Governance by Construction is the resulting application property
Governance by Construction describes the architectural property created when identity, authorization, policy, contracts, approvals, provenance, and evidence remain intrinsic to the application definition and runtime.
Durable Execution
Preserve proposal binding, waits, expiry, and re-evaluation.
Explore Durable ExecutionModel Routing
Apply policy before selecting models, providers, tools, or deterministic capabilities.
Explore Model RoutingIdentity & Security
Provide the subject, workload, tenant, purpose, scope, delegation, and assurance facts policy needs.
Explore Identity & Security