Governance Kernel Decision Model

1. Purpose

The Governance Kernel Decision Model defines how the UPOS Governance Kernel evaluates governance questions and emits authoritative decision state across the ProductVerse.

The decision model explains:

• what a governance decision is,
• what inputs are required,
• what context must be resolved,
• how policy, entitlement, risk, trust, evidence, and obligation evaluations combine,
• what decision outcomes may be emitted,
• how constraints and explanations are attached,
• how decisions are recorded for audit and assurance,
• how decisions are consumed by PVEP, PDEP, Product Fabric, marketplaces, product graphs, agents, and runtime services.

The decision model exists because ProductVerse governance cannot rely on simple yes/no access checks. A product economy includes many product kinds, actor types, purposes, output ports, jurisdictions, lifecycle states, and product relationships.

Governance decisions must therefore be contextual, explainable, auditable, and machine-actionable.

---

2. Definition

A Governance Decision is an authoritative outcome emitted by the Governance Kernel after evaluating a product-related action, actor, intent, relationship, or lifecycle event against applicable policies, entitlements, risks, trust evidence, obligations, and contextual constraints.

A governance decision answers questions such as:

• Is this action allowed?
• Is this product usable for this purpose?
• Is this subject entitled to this output port?
• Is this product trusted enough for this use?
• Is this product relationship permitted?
• Is this lifecycle transition allowed?
• What obligations or restrictions apply?
• What evidence supports the decision?
• What explanation should be shown to a human or agent?
• What audit record must be retained?

The core decision statement can be expressed as:

Subject S may / may not perform Action A
on Product P
through Output Port O
for Purpose U
in Context C
subject to Constraints K
because of Policies, Entitlements, Risks, Evidence, and Obligations E.

---

3. Governance Decision Scope

The Governance Kernel may make decisions about many ProductVerse events.

3.1 Access Decisions

Access decisions determine whether a subject may access a product or product output port.

Examples:

• user access to a dashboard,
• application access to an API,
• AI agent access to a tool,
• team access to a data product,
• organization access to a marketplace product.

3.2 Usage Decisions

Usage decisions determine whether a product may be used for a declared or inferred purpose.

Examples:

• internal analytics,
• external sharing,
• automated decisioning,
• training an AI model,
• safety-critical operation,
• regulatory reporting,
• commercial redistribution.

3.3 Entitlement Decisions

Entitlement decisions determine whether the subject has a valid right, license, approval, subscription, or mandate to use the product.

Examples:

• active subscription,
• accepted license,
• approved access request,
• delegated authority,
• valid agent scope,
• non-expired entitlement.

3.4 Relationship Decisions

Relationship decisions determine whether a product relationship is permitted or governed.

Examples:

• Product A consumes Product B,
• Product C depends on Product D,
• Product E is composed from Product F,
• Product G exposes an output port to Product H,
• Product I inherits restrictions from Product J.

3.5 Composition Decisions

Composition decisions determine whether selected products may be used together to create a new governed product.

Examples:

• may these data and AI products be combined,
• may this content be included in a bundle,
• may this policy product govern this runtime product,
• may this evidence product support this DPP claim.

3.6 Lifecycle Decisions

Lifecycle decisions determine whether a product may move through lifecycle states.

Examples:

• create,
• validate,
• publish,
• list,
• promote,
• deploy,
• deprecate,
• retire,
• archive,
• restore,
• recertify.

3.7 Trust and Assurance Decisions

Trust and assurance decisions determine whether the product, actor, relationship, or lifecycle event has sufficient evidence and acceptable posture.

Examples:

• DPP valid,
• evidence sufficient,
• quality acceptable,
• maturity sufficient,
• risk tier acceptable,
• certification current,
• unresolved exception exists.

3.8 Exception Decisions

Exception decisions determine whether a deviation from normal policy may be allowed under explicit, time-bound, evidence-backed conditions.

Examples:

• temporary access exception,
• publication exception,
• evidence waiver,
• jurisdiction exception,
• emergency-use exception.

---

4. Decision Context

A governance decision is only meaningful when its context is explicit.

The decision context describes who or what is acting, what they are acting upon, why, where, how, and under what conditions.

4.1 Context Dimensions

Dimension	Description
Subject	Human, organization, team, application, machine agent, AI agent, institutional agent, or product-as-consumer.
Action	Access, use, invoke, compose, publish, share, export, list, retire, approve, delegate, or other action.
Product	Product being accessed, consumed, composed, governed, published, or evaluated.
Product kind	Data, AI, software, physical, creative, governance, evidence, agent, infrastructure, or other product kind.
Product version	Specific product version or lifecycle state involved.
Output port	API, SQL endpoint, dashboard, file, stream, model endpoint, reader, tool, or other port.
Purpose	Declared or inferred reason for the action.
Environment	Runtime, deployment, consumption, marketplace, development, production, sandbox, jurisdiction, or operational context.
Actor authority	Role, mandate, entitlement, license, delegated authority, institutional authority, or agent scope.
Policy context	Applicable rules, controls, obligations, restrictions, and permitted-use conditions.
Trust context	DPP, evidence, quality, maturity, certification, lineage, provenance, and assurance state.
Risk context	Product risk, actor risk, relationship risk, purpose risk, jurisdiction risk, lifecycle risk.
Relationship context	Dependencies, composition, lineage, substitution, complementarity, bundles, product-to-product usage.
Time context	Decision time, entitlement expiry, evidence freshness, policy version, lifecycle timing.

4.2 Context Completeness

The Governance Kernel should avoid making high-impact decisions from incomplete context.

For example, the question:

Can User A access Product B?

may be insufficient.

A more complete question is:

Can User A access Product B
through Output Port C
for Purpose D
in Environment E
under Jurisdiction F
at Time T?

The kernel should either resolve missing context or return a decision requiring clarification.

---

5. Decision Request

A Decision Request is the structured request submitted to the Governance Kernel.

5.1 Minimal Decision Request

A minimal decision request may include:

subject:
  id: subject-123
  type: human-user

action: use

product:
  id: product-456
  version: 2.1

purpose:
  code: internal-analytics

context:
  environment: production
  jurisdiction: EU

5.2 Rich Decision Request

A richer decision request may include:

decisionRequestId: req-001

subject:
  id: user-123
  type: human-user
  organization: org-789
  roles:
    - risk-analyst

action: invoke-output-port

product:
  id: product-456
  kind: data-product
  version: 2.1
  lifecycleState: published

outputPort:
  id: sql-port-01
  type: sql-endpoint

purpose:
  code: regulatory-reporting
  declaredBy: subject
  audience: internal-regulator-facing

context:
  environment: production
  jurisdiction: EU
  time: 2026-05-19T10:00:00Z

relationshipContext:
  downstreamUse:
    - report-product-888

requestedDecision:
  type: access-and-usage

The exact schema may vary by implementation, but the kernel requires enough context to produce meaningful governance state.

---

6. Decision Evaluation Flow

A typical decision flow contains the following stages:

Decision Request
  → Context Resolution
  → Policy Evaluation
  → Entitlement Evaluation
  → Risk Evaluation
  → Trust & Evidence Evaluation
  → Relationship Evaluation
  → Obligation & Constraint Derivation
  → Decision Composition
  → Explanation
  → Audit Record
  → Governance State Emission

6.1 Context Resolution

The kernel enriches the decision request with product metadata, actor context, applicable policies, entitlement state, trust evidence, risk posture, relationships, lifecycle state, and relevant runtime context.

6.2 Policy Evaluation

The kernel evaluates applicable policies, obligations, restrictions, and permitted-use rules.

6.3 Entitlement Evaluation

The kernel checks whether the subject has valid rights, approvals, licenses, subscriptions, or delegated authority.

6.4 Risk Evaluation

The kernel evaluates risk posture across product, subject, purpose, environment, jurisdiction, lifecycle event, and relationship context.

6.5 Trust & Evidence Evaluation

The kernel evaluates DPP state, evidence sufficiency, quality posture, maturity, certification, lineage, provenance, and exception state.

6.6 Relationship Evaluation

The kernel evaluates product-to-product, product-to-agent, product-to-policy, and product-to-output-port relationships where relevant.

6.7 Obligation & Constraint Derivation

The kernel derives restrictions and obligations that apply if the decision is allowed or conditionally allowed.

6.8 Decision Composition

The kernel combines evaluation results into a coherent decision state.

6.9 Explanation

The kernel produces human-readable and/or machine-readable explanations.

6.10 Audit Record

The kernel records the decision request, context, evaluations, decision, constraints, explanation, evidence references, policy versions, and timestamp.

6.11 Governance State Emission

The kernel emits decision state to relevant consumers such as PVEP, PDEP, Product Fabric, marketplaces, agents, runtime enforcement services, or audit systems.

---

7. Decision Outcome Types

Governance decisions should support more than binary allow/deny outcomes.

7.1 Allow

The action is permitted under the evaluated context.

Example:

Allowed: User may view Product A dashboard for internal analytics.

7.2 Deny

The action is not permitted.

Example:

Denied: User may not export Product A outside the approved jurisdiction.

7.3 Conditional Allow

The action is permitted only if constraints are enforced.

Example:

Conditional Allow: User may access Product A if sensitive fields are masked and output is not exported.

7.4 Approval Required

The action may proceed only after an approval workflow.

Example:

Approval Required: Access requires Product Steward approval.

7.5 Exception Required

The action violates standard policy and requires a formal exception.

Example:

Exception Required: Product lacks required evidence for this high-risk use.

7.6 Escalation Required

The action requires escalation due to risk, uncertainty, or authority limits.

Example:

Escalation Required: Institutional approval required for safety-critical use.

7.7 Insufficient Context

The kernel cannot decide because the request lacks required context.

Example:

Insufficient Context: Purpose and jurisdiction are required.

7.8 Not Applicable

The requested policy or governance check does not apply in the given context.

Example:

Not Applicable: External sharing policy does not apply to internal sandbox use.

7.9 Pending

The decision depends on asynchronous checks, evidence refresh, approval, or external verification.

Example:

Pending: DPP evidence validation is in progress.

---

8. Decision Output Structure

A governance decision should be structured.

8.1 Example Decision Output

decisionId: dec-001
decisionRequestId: req-001

outcome: conditional-allow

subject:
  id: user-123
  type: human-user

action: invoke-output-port

product:
  id: product-456
  version: 2.1

outputPort:
  id: sql-port-01

purpose:
  code: regulatory-reporting

constraints:
  - type: no-external-sharing
    severity: mandatory
  - type: audit-logging-required
    severity: mandatory
  - type: row-level-filtering
    severity: mandatory

obligations:
  - type: retain-access-log
    duration: P7Y
  - type: display-dpp-summary
    appliesTo: pvep

explanation:
  summary: >
    Access is allowed for regulatory reporting because the user has a valid entitlement
    and the product is approved for this purpose. External sharing is prohibited.

evidence:
  - dpp: dpp-789
  - policy: policy-123
  - entitlement: ent-456

audit:
  timestamp: 2026-05-19T10:00:00Z
  policyVersion: 4.2
  productVersion: 2.1

8.2 Decision Output Fields

Field	Description
decisionId	Unique identifier for the decision.
decisionRequestId	Identifier of the original request.
outcome	Decision result, such as allow, deny, conditional allow, approval required.
subject	Actor or subject evaluated.
action	Action being evaluated.
product	Product being acted upon.
outputPort	Output port involved, if applicable.
purpose	Declared or inferred purpose.
constraints	Mandatory restrictions that must be enforced.
obligations	Duties that must be fulfilled.
explanation	Human- or machine-readable rationale.
evidence	Evidence, policy, entitlement, risk, or DPP references.
audit	Decision metadata for traceability.
expiry	Optional decision validity period.
reviewRequirement	Optional review, approval, or escalation requirement.

---

9. Decision Composition

Decision composition is the process of combining multiple evaluation results into one coherent governance decision.

For example:

Evaluation	Result
Policy	Allows internal analytics, prohibits external sharing.
Entitlement	Subject has valid access.
Risk	Medium risk, no escalation required.
Trust	DPP valid, evidence current.
Relationship	Downstream report product is permitted.
Jurisdiction	EU use allowed with retention obligation.

Composed decision:

Conditional Allow:
Subject may use the product for internal regulatory reporting in the EU,
with audit logging and no external sharing.

9.1 Combining Rules

A decision model may apply combining rules such as:

• deny overrides,
• prohibit overrides allow,
• highest risk wins,
• missing evidence triggers review,
• expired entitlement denies access,
• active exception may override standard denial,
• purpose-specific policy overrides general policy,
• jurisdiction-specific policy overrides global policy,
• product-kind-specific policy adds obligations,
• output-port-specific policy adds constraints.

These combining rules must be explicit and versioned.

---

10. Constraints and Obligations

Governance decisions often include constraints and obligations.

10.1 Constraints

A constraint restricts what can be done.

Examples:

• no external sharing,
• no export,
• no automated decisioning,
• read-only access,
• masking required,
• row-level filtering required,
• use only approved output port,
• use only in approved environment,
• use only until expiry date,
• use only with human oversight.

10.2 Obligations

An obligation requires something to be done.

Examples:

• audit logging required,
• DPP summary must be displayed,
• attribution required,
• retain evidence for seven years,
• notify steward on use,
• record downstream use,
• submit periodic review,
• obtain human approval,
• refresh evidence before publication.

10.3 Relationship Between Constraints and Obligations

Constraints restrict action. Obligations require action.

Both may appear in a decision.

Example:

Conditional Allow:
Access permitted if data is masked.
Audit logging is required.

The masking requirement is a constraint. The logging requirement is an obligation.

---

11. Explanation Model

Every material governance decision should be explainable.

11.1 Explanation Types

Explanation type	Audience
Consumer explanation	Simple explanation for PVEP users.
Steward explanation	More detailed explanation for product owners or stewards.
Auditor explanation	Traceable rationale with evidence and policy references.
Agent explanation	Machine-readable explanation for automated agents.
Developer explanation	Technical explanation for implementers and runtime systems.

11.2 Explanation Content

An explanation may include:

• decision outcome,
• reason for decision,
• applicable policies,
• entitlement state,
• trust evidence,
• risk factors,
• missing evidence,
• constraints,
• obligations,
• escalation path,
• remediation options,
• appeal or exception path.

11.3 Example Explanation

You may use this product for internal analytics because your team has an active entitlement and the product is approved for internal use. External sharing is not allowed because the product license prohibits redistribution. Audit logging is required under the applicable compliance policy.

---

12. Audit Model

Governance decisions must be auditable.

12.1 Audit Record Contents

An audit record should include:

• decision identifier,
• request identifier,
• actor,
• action,
• product,
• output port,
• purpose,
• environment,
• jurisdiction,
• policies evaluated,
• policy versions,
• entitlement references,
• evidence references,
• DPP references,
• risk evaluation result,
• constraints and obligations,
• decision outcome,
• explanation,
• timestamp,
• decision authority,
• exception state,
• lifecycle state.

12.2 Reproducibility

Where possible, decisions should be reproducible or explainable using:

• product version,
• policy version,
• evidence version,
• entitlement state at decision time,
• actor context at decision time,
• decision logic version.

12.3 Auditability Principle

A governance decision that cannot be explained or audited is not a trustworthy governance decision.

---

13. Decision Validity and Time

Governance decisions may be time-bound.

13.1 Time Factors

Time factors include:

• entitlement expiry,
• license expiry,
• evidence freshness,
• DPP validity,
• policy version,
• lifecycle state,
• exception expiry,
• approval expiry,
• runtime window,
• incident state,
• temporary emergency condition.

13.2 Decision Expiry

A decision may include expiry.

Example:

validity:
  validFrom: 2026-05-19T10:00:00Z
  validUntil: 2026-06-19T10:00:00Z
  reevaluationRequiredOn:
    - entitlement-expiry
    - dpp-expiry
    - policy-change
    - risk-state-change

13.3 Reevaluation Triggers

Decisions should be reevaluated when material context changes.

Triggers may include:

• policy updated,
• entitlement revoked,
• DPP expired,
• evidence invalidated,
• product version changed,
• output port changed,
• lifecycle state changed,
• risk tier changed,
• actor authority changed,
• exception expired,
• jurisdiction changed,
• incident detected.

---

14. Decision Consumers

Different UPOS components consume decisions differently.

Consumer	How it uses decisions
PVEP	Renders access status, trust state, permitted-use explanation, constraints, and next actions.
PDEP	Applies lifecycle gates, composition checks, publication controls, and evidence requirements.
Product Fabric	Enforces access, masking, filtering, routing, runtime constraints, and agent invocation controls.
Marketplace	Displays eligibility, approval requirements, trust status, licensing restrictions, and acquisition constraints.
Product Graph	Shows governance-aware edges, risk overlays, entitlement relationships, and policy relationships.
Agents	Determine whether actions are permitted, constrained, require confirmation, or need escalation.
Runtime services	Enforce output-port access, rate limits, masking, logging, and environment restrictions.
Audit systems	Retain decision records for assurance, compliance, investigation, and reporting.

---

15. Decision Patterns

15.1 Access Decision Pattern

Subject requests access to Product / Output Port
  → Resolve subject, product, purpose, entitlement, policy
  → Evaluate access rules
  → Emit allow / deny / conditional / approval required

15.2 Usage Decision Pattern

Subject declares intended purpose
  → Resolve permitted and prohibited uses
  → Evaluate product-kind and purpose policies
  → Emit usage permission and constraints

15.3 Composition Decision Pattern

PDEP requests composition of Products A, B, and C
  → Resolve product relationships, policies, licenses, risk, evidence
  → Evaluate whether composition is allowed
  → Emit composition decision and required obligations

15.4 Lifecycle Decision Pattern

PDEP requests product publication
  → Resolve lifecycle state, evidence, DPP, ownership, risk, policy
  → Evaluate publication gate
  → Emit publish / block / review / exception required

15.5 Runtime Invocation Decision Pattern

Agent or application invokes output port
  → Resolve actor authority, product, output port, purpose, environment
  → Evaluate runtime policy and entitlement
  → Emit enforceable decision

15.6 Trust Display Decision Pattern

PVEP requests trust state for product
  → Resolve DPP, evidence, quality, risk, maturity, exceptions
  → Emit trust state and explanation

---

16. Decision Semantics

Governance decision semantics should be precise.

16.1 Allow Does Not Mean Unrestricted

An allow decision may still include obligations.

Example:

Allowed, but audit logging required.

16.2 Conditional Allow Requires Enforcement

A conditional allow is only valid if constraints can be enforced.

Example:

Conditional allow with masking required.

If masking cannot be enforced, the decision should not be treated as allow.

16.3 Approval Required Is Not Allow

Approval required means the action cannot proceed until approval is granted.

16.4 Exception Required Is Not Approval Required

Approval required means normal policy allows the action after approval.

Exception required means normal policy is violated and a governed deviation is needed.

16.5 Insufficient Context Is Not Deny

Insufficient context means the kernel cannot decide yet.

It may lead to clarification, enrichment, or review.

16.6 Deny Should Be Explainable

A deny decision should explain which policy, risk, entitlement, or evidence condition caused denial.

---

17. Agent and Product-as-Consumer Decisions

The decision model must support non-human actors.

17.1 Agent Decision Context

For agents, the kernel may evaluate:

• agent identity,
• agent type,
• delegated authority,
• autonomy level,
• supervisor relationship,
• permitted tools,
• allowed products,
• purpose scope,
• execution environment,
• audit requirement,
• human confirmation requirement,
• revocation state.

17.2 AI Agent Considerations

For AI agents, additional considerations may include:

• model risk tier,
• prompt/tool governance,
• hallucination risk,
• autonomy level,
• human-in-the-loop requirement,
• prohibited actions,
• allowed toolset,
• safety constraints,
• evaluation evidence,
• incident history.

17.3 Product-as-Consumer Decisions

A product may consume another product.

The kernel may evaluate:

• whether the consuming product is authorized,
• whether the relationship is registered,
• whether downstream use is permitted,
• whether restrictions propagate,
• whether additional evidence is required,
• whether composition belongs in PDEP.

---

18. Emergency and Exceptional Decisions

Some contexts may require emergency governance handling.

Examples:

• safety-critical operations,
• incident response,
• disaster recovery,
• urgent medical use,
• mission-critical failure,
• emergency habitat support,
• security incident containment.

Emergency decisions should not bypass governance silently.

They should include:

• emergency justification,
• scope limitation,
• time limitation,
• authority validation,
• mandatory audit,
• post-event review,
• explicit exception state,
• revocation condition.

The principle is:

Emergency use may accelerate governance, but it should not erase governance.

---

19. Decision Quality

The Governance Kernel should measure decision quality.

Useful indicators include:

• decision latency,
• decision completeness,
• explanation availability,
• audit record completeness,
• policy coverage,
• false denial rate,
• false allow rate,
• exception rate,
• appeal rate,
• decision reversal rate,
• stale evidence usage,
• stale policy usage,
• human override frequency,
• agent violation rate,
• runtime enforcement success.

Decision quality is part of governance observability.

---

20. Anti-Patterns

20.1 Binary-Only Governance

Treating all decisions as allow or deny ignores conditional use, approvals, obligations, constraints, and exceptions.

20.2 Identity-Only Decisions

A decision based only on who the user is ignores purpose, product kind, output port, environment, jurisdiction, risk, and evidence.

20.3 Context-Free Trust

Trust cannot be evaluated without product, purpose, evidence, and risk context.

20.4 Unexplained Denials

Denying access or usage without explanation damages usability and accountability.

20.5 Conditional Allow Without Enforcement

A conditional allow is invalid if required constraints cannot be enforced.

20.6 Approval and Exception Confusion

Approval is part of normal governance. Exception is a governed deviation from normal governance.

20.7 Static Decisions in Dynamic Contexts

Decisions should be reevaluated when policy, entitlement, evidence, product, risk, or lifecycle state changes.

20.8 Human-Only Decision Model

The decision model must support applications, machine agents, AI agents, institutional agents, and products-as-consumers.

20.9 Unlogged Decisions

Material governance decisions without audit records undermine trust.

---

21. Summary

The Governance Kernel Decision Model defines how UPOS evaluates product-related actions, intents, relationships, and lifecycle events across the ProductVerse.

A governance decision is contextual, not merely binary.

It considers:

• subject,
• action,
• product,
• product kind,
• output port,
• purpose,
• environment,
• jurisdiction,
• entitlement,
• policy,
• risk,
• trust,
• evidence,
• relationship context,
• lifecycle state,
• time.

It may emit outcomes such as:

• allow,
• deny,
• conditional allow,
• approval required,
• exception required,
• escalation required,
• insufficient context,
• pending,
• not applicable.

Each decision should include constraints, obligations, explanations, evidence references, and audit records where needed.

In short:

The Governance Kernel Decision Model turns governance from a static policy statement into a contextual, explainable, auditable, and machine-actionable decision system for the ProductVerse.