Governance Kernel Interfaces

1. Purpose

The Governance Kernel Interfaces model defines how UPOS components, products, actors, agents, registries, runtimes, marketplaces, and experience planes interact with the Governance Kernel.

The Governance Kernel is the computational governance core of UPOS, but it cannot operate in isolation. It must expose clear interfaces so that other ProductVerse capabilities can request decisions, retrieve governance state, submit evidence, receive signals, inspect policies, validate entitlements, check DPP status, evaluate risk, and enforce constraints.

This document explains:

• what kinds of interfaces the Governance Kernel exposes,
• what systems and actors consume those interfaces,
• what requests and responses look like conceptually,
• how interfaces support PVEP, PDEP, Product Fabric, marketplaces, Product Graph, agents, products-as-consumers, registries, and audit systems,
• how interfaces differ from implementation APIs,
• how interface design should remain product-kind-agnostic while supporting product-kind-specific governance.

The key principle is:

The Governance Kernel computes and emits governance state through structured interfaces so that governance can be rendered, applied, enforced, audited, and automated consistently across the ProductVerse.

---

2. Definition

A Governance Kernel Interface is a structured interaction boundary through which another UPOS component, product, actor, agent, or system submits governance context to the Governance Kernel or receives governance state from it.

A Governance Kernel interface may support:

• decision requests,
• entitlement checks,
• policy evaluation,
• trust state retrieval,
• evidence submission,
• DPP validation,
• risk evaluation,
• lifecycle gate checks,
• relationship governance checks,
• exception handling,
• signal subscription,
• audit queries,
• explanation retrieval.

These interfaces may be implemented as APIs, event topics, message queues, SDKs, policy-as-code adapters, registry integrations, graph queries, or human-facing governance consoles.

The interface model is conceptual. It defines the types of interaction UPOS needs. It does not prescribe a single implementation technology.

---

3. Interface Design Principles

3.1 Context-Rich

Governance interfaces should accept enough context to support meaningful decisions.

A weak request is:

Can User A access Product B?

A stronger request is:

Can Subject S invoke Output Port O of Product P version V
for Purpose U
in Environment E
under Jurisdiction J
at Time T?

3.2 Structured

Interfaces should use structured inputs and outputs so they can be consumed by humans, systems, and agents.

3.3 Explainable

Interfaces should return decision rationale, constraints, obligations, and evidence references where appropriate.

3.4 Product-Kind Agnostic

Interfaces should support many product kinds without being designed only for data, AI, software, physical, or creative products.

3.5 Product-Kind Aware

While product-kind agnostic, the interfaces must allow product-kind-specific fields, rules, evidence, and risk models.

3.6 Actor- and Agent-Aware

Interfaces should distinguish human users, organizations, applications, machine agents, AI agents, institutional agents, and products-as-consumers.

3.7 Auditable

Material interface calls should be traceable where they affect governance decisions, lifecycle gates, access, trust, or risk.

3.8 Secure

Governance interfaces expose sensitive decision and policy information. They must enforce authentication, authorization, least privilege, and visibility controls.

3.9 Versioned

Interface contracts, decision schemas, policies, and response formats should be versioned.

3.10 Machine-Readable and Human-Renderable

Responses should support machine action while enabling PVEP and other experiences to present understandable explanations.

---

4. Interface Consumers

Governance Kernel interfaces are consumed by many UPOS components.

Consumer	Interface needs
PVEP	Render access, trust, risk, DPP, policy, entitlement, evidence, and permitted-use state.
PDEP	Validate product creation, composition, lifecycle gates, publication readiness, DPP completeness, and evidence sufficiency.
Product Fabric	Enforce access, runtime policies, masking, routing, filtering, logging, environment controls, and agent invocation controls.
Marketplace	Display eligibility, subscription status, licensing constraints, DPP summaries, trust posture, risk state, and acquisition pathways.
Product Graph	Show policy, entitlement, trust, evidence, risk, DPP, and governance relationships.
Product Registry	Provide product metadata and consume governance status updates.
Evidence Services	Submit, update, validate, and retrieve evidence state.
DPP Services	Submit DPPs, validate DPPs, retrieve DPP status, and publish DPP summaries.
Runtime Services	Check access, enforce constraints, report violations, and emit runtime evidence.
Agents	Request decisions, inspect permitted actions, evaluate product suitability, and receive machine-readable governance state.
Audit Systems	Retrieve decision records, evidence references, policy versions, and governance traces.
Governance Actors	Review exceptions, approve policies, inspect risk, and investigate decisions.

---

5. Interface Categories

The Governance Kernel may expose several interface categories.

Governance Kernel Interfaces
├─ Decision Interfaces
├─ Policy Interfaces
├─ Entitlement Interfaces
├─ Trust Interfaces
├─ Evidence Interfaces
├─ Risk Interfaces
├─ DPP Interfaces
├─ Lifecycle Gate Interfaces
├─ Relationship Governance Interfaces
├─ Exception Interfaces
├─ Signal Interfaces
├─ Explanation Interfaces
└─ Audit Interfaces

Each category serves a different governance need, but they should share common concepts such as subject, action, product, purpose, context, evidence, policy, risk, trust, decision, explanation, and audit trace.

---

6. Decision Interfaces

6.1 Purpose

Decision interfaces allow UPOS components to request authoritative governance decisions.

They are used when a system needs to know whether an action is allowed, denied, conditional, pending, requires approval, requires exception, or lacks sufficient context.

6.2 Typical Consumers

• PVEP,
• PDEP,
• Product Fabric,
• marketplace services,
• runtime services,
• agents,
• applications,
• products-as-consumers.

6.3 Example Request

decisionRequest:
  requestId: req-001

  subject:
    id: user-123
    type: human-user
    organization: org-456
    roles:
      - product-consumer

  action: invoke-output-port

  product:
    id: product-789
    kind: data-product
    version: 2.1

  outputPort:
    id: api-port-01
    type: api

  purpose:
    code: internal-analytics
    declaredBy: subject

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

6.4 Example Response

decision:
  decisionId: dec-001
  outcome: conditional-allow

  constraints:
    - no-external-sharing
    - audit-logging-required

  obligations:
    - display-dpp-summary
    - retain-access-log

  explanation:
    summary: >
      Use is allowed for internal analytics because the subject has valid entitlement.
      External sharing is not allowed under the applicable policy.

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

  audit:
    traceId: trace-001
    evaluatedAt: 2026-05-19T10:00:01Z

6.5 Design Notes

Decision interfaces should support both synchronous and asynchronous patterns.

Synchronous decisioning is useful for runtime enforcement. Asynchronous decisioning is useful for evidence review, lifecycle gates, and complex assurance workflows.

---

7. Policy Interfaces

7.1 Purpose

Policy interfaces allow systems to evaluate, inspect, retrieve, explain, and simulate policies.

They should support both human-readable and machine-readable policy interactions.

7.2 Capabilities

Policy interfaces may support:

• retrieve applicable policies,
• evaluate policy against context,
• explain policy decision,
• simulate policy impact,
• validate policy syntax,
• detect policy conflicts,
• retrieve policy obligations,
• retrieve permitted and prohibited uses,
• inspect policy hierarchy,
• submit policy update,
• retrieve policy version.

7.3 Example Request

policyEvaluationRequest:
  product:
    id: product-789
    kind: ai-product
    version: 1.4

  action: automated-decisioning

  purpose:
    code: customer-eligibility

  context:
    jurisdiction: EU
    environment: production

7.4 Example Response

policyEvaluation:
  applicablePolicies:
    - policy-ai-high-impact-use
    - policy-eu-customer-decisioning

  outcome: require-approval

  obligations:
    - human-review-required
    - audit-logging-required
    - model-evaluation-required

  prohibitedUses:
    - fully-autonomous-decisioning-without-review

  explanation:
    summary: >
      Automated customer eligibility use requires human review and current model evaluation evidence.

---

8. Entitlement Interfaces

8.1 Purpose

Entitlement interfaces allow systems to evaluate whether a subject has valid rights to access, use, invoke, acquire, subscribe to, compose with, or act upon a product.

8.2 Capabilities

Entitlement interfaces may support:

• check entitlement,
• retrieve entitlement state,
• request access,
• approve or deny access,
• revoke entitlement,
• suspend entitlement,
• renew entitlement,
• check output-port entitlement,
• check purpose-specific entitlement,
• check delegated authority,
• check product-to-product entitlement,
• retrieve entitlement explanation.

8.3 Example Request

entitlementCheck:
  subject:
    id: agent-123
    type: ai-agent

  delegatedAuthority:
    delegator: org-456
    mandate: procurement-recommendation
    scope:
      productKinds:
        - data-product
        - ai-product

  action: recommend

  product:
    id: product-789
    version: 2.1

  purpose:
    code: product-discovery

8.4 Example Response

entitlementState:
  outcome: conditionally-entitled

  constraints:
    - recommendation-only
    - no-acquisition-without-human-confirmation
    - audit-logging-required

  explanation:
    summary: >
      The AI agent may recommend this product under delegated authority,
      but may not acquire or subscribe without human confirmation.

---

9. Trust Interfaces

9.1 Purpose

Trust interfaces expose evaluated trust state for products, claims, output ports, relationships, DPPs, agents, and lifecycle events.

9.2 Capabilities

Trust interfaces may support:

• get trust posture,
• evaluate trust for purpose,
• retrieve trust explanation,
• retrieve trust evidence references,
• compare trust across products,
• retrieve trust constraints,
• subscribe to trust changes,
• retrieve trust history.

9.3 Example Request

trustRequest:
  product:
    id: product-789
    version: 2.1

  purpose:
    code: regulatory-reporting

  outputPort:
    id: sql-port-01

  context:
    jurisdiction: EU

9.4 Example Response

trustState:
  posture: conditionally-trusted

  reasons:
    - dpp-valid
    - quality-checks-current
    - lineage-complete

  constraints:
    - internal-use-only
    - audit-logging-required

  evidence:
    - dpp-789
    - quality-report-456
    - lineage-record-123

  explanation:
    summary: >
      The product is trusted for regulatory reporting through the SQL output port,
      provided audit logging is enabled and outputs remain internal.

---

10. Evidence Interfaces

10.1 Purpose

Evidence interfaces allow systems to submit, retrieve, evaluate, link, validate, and inspect evidence.

10.2 Capabilities

Evidence interfaces may support:

• submit evidence,
• update evidence,
• validate evidence,
• retrieve evidence state,
• link evidence to claim,
• retrieve evidence for DPP,
• check evidence sufficiency,
• check evidence freshness,
• report evidence gap,
• restrict evidence visibility,
• retrieve evidence audit trail.

10.3 Example Request

evidenceSufficiencyRequest:
  product:
    id: product-ai-123
    version: 1.4

  claim:
    id: claim-approved-for-advisory-use

  purpose:
    code: advisory-use

  requiredEvidence:
    - model-evaluation-report
    - risk-review
    - human-oversight-design

10.4 Example Response

evidenceState:
  outcome: partially-sufficient

  present:
    - model-evaluation-report
    - risk-review

  missing:
    - human-oversight-design

  impact:
    trustPosture: conditionally-trusted
    lifecycleGate: publication-review-required

  explanation:
    summary: >
      Evidence is partially sufficient. Human oversight design evidence is missing.

---

11. Risk Interfaces

11.1 Purpose

Risk interfaces expose risk evaluation capabilities for product contexts, purposes, relationships, agents, lifecycle events, and runtime interactions.

11.2 Capabilities

Risk interfaces may support:

• evaluate risk,
• retrieve risk tier,
• retrieve structured risk state,
• retrieve required controls,
• submit risk assessment,
• request risk review,
• approve risk treatment,
• retrieve risk explanation,
• subscribe to risk changes,
• inspect risk propagation.

11.3 Example Request

riskEvaluationRequest:
  product:
    id: product-ai-123
    kind: ai-product
    version: 1.4

  action: invoke-output-port

  outputPort:
    id: inference-api

  purpose:
    code: automated-decision-support

  subject:
    id: application-456
    type: application

  context:
    environment: production

11.4 Example Response

riskState:
  tier: R3
  categories:
    - automated-decision-risk
    - customer-impact-risk

  requiredControls:
    - human-review-required
    - audit-logging-required
    - drift-monitoring-required

  explanation:
    summary: >
      This use is high risk because model output may materially influence customer decisions.

---

12. DPP Interfaces

12.1 Purpose

DPP interfaces allow systems to submit, validate, retrieve, inspect, publish, and evaluate Digital Product Passport state.

12.2 Capabilities

DPP interfaces may support:

• retrieve DPP summary,
• retrieve DPP detail,
• validate DPP,
• check DPP completeness,
• check DPP version alignment,
• check claim-evidence bindings,
• publish DPP,
• revoke DPP,
• supersede DPP,
• retrieve DPP visibility view,
• evaluate DPP for purpose,
• retrieve DPP-derived trust state.

12.3 Example Request

dppValidationRequest:
  dpp:
    id: dpp-789

  product:
    id: product-456
    version: 2.1

  requestedUse:
    purpose: external-sharing
    context:
      marketplace: public

12.4 Example Response

dppEvaluation:
  outcome: invalid-for-purpose

  reasons:
    - rights-evidence-missing
    - external-sharing-not-supported
    - product-version-aligned

  recommendedActions:
    - add-rights-evidence
    - restrict-marketplace-listing
    - show-consumer-warning

  explanation:
    summary: >
      The DPP is valid for internal use but not for external sharing because rights evidence is missing.

---

13. Lifecycle Gate Interfaces

13.1 Purpose

Lifecycle gate interfaces allow PDEP and related systems to validate whether a product can move through lifecycle transitions.

13.2 Capabilities

Lifecycle gate interfaces may support:

• validate creation readiness,
• validate composition,
• validate output port activation,
• validate publication,
• validate marketplace listing,
• validate promotion,
• validate deprecation,
• validate retirement,
• validate recertification,
• retrieve missing requirements,
• retrieve gate explanation.

13.3 Example Request

lifecycleGateRequest:
  lifecycleAction: publish

  product:
    id: product-789
    kind: ai-product
    version: 1.0

  submittedBy:
    id: user-123
    type: human-user

  context:
    targetMarketplace: enterprise-marketplace

13.4 Example Response

lifecycleGateDecision:
  outcome: blocked

  missingRequirements:
    - dpp-complete
    - model-evaluation-current
    - owner-approval

  requiredActions:
    - complete-dpp
    - attach-model-evaluation-report
    - obtain-owner-approval

  explanation:
    summary: >
      Publication is blocked until DPP, evaluation evidence, and owner approval are complete.

---

14. Relationship Governance Interfaces

14.1 Purpose

Relationship governance interfaces evaluate whether product relationships are allowed, trusted, entitled, risky, or require restrictions.

14.2 Capabilities

These interfaces may support:

• check product-to-product consumption,
• validate dependency,
• validate composition,
• evaluate relationship risk,
• evaluate inherited restrictions,
• evaluate relationship trust,
• check product-to-agent relationship,
• validate bundle membership,
• validate product chain,
• retrieve relationship explanation.

14.3 Example Request

relationshipGovernanceRequest:
  relationshipType: composed-from

  targetProduct:
    id: product-new-001
    kind: evidence-product

  sourceProducts:
    - id: data-product-123
      version: 2.1
    - id: ai-product-456
      version: 1.4

  purpose:
    code: regulatory-evidence-generation

14.4 Example Response

relationshipGovernanceDecision:
  outcome: conditional-allow

  inheritedConstraints:
    - no-external-sharing
    - audit-logging-required

  requiredEvidence:
    - lineage-record
    - model-evaluation-report
    - composition-approval

  explanation:
    summary: >
      Composition is allowed for regulatory evidence generation if inherited restrictions are preserved
      and required lineage and model evaluation evidence are attached.

---

15. Exception Interfaces

15.1 Purpose

Exception interfaces support governed deviations from standard policy, trust, risk, entitlement, evidence, or lifecycle requirements.

15.2 Capabilities

Exception interfaces may support:

• request exception,
• evaluate exception request,
• approve exception,
• deny exception,
• revoke exception,
• renew exception,
• retrieve exception state,
• retrieve exception expiry,
• record mitigation controls,
• retrieve exception audit trail.

15.3 Example Request

exceptionRequest:
  requester:
    id: user-123
    type: human-user

  policy:
    id: policy-no-external-sharing

  requestedDeviation:
    action: external-share
    product:
      id: product-456
      version: 2.1

  justification:
    code: emergency-response

  requestedDuration: P72H

  proposedControls:
    - audit-logging-required
    - post-event-review-required

15.4 Example Response

exceptionDecision:
  outcome: approved

  validUntil: 2026-05-22T10:00:00Z

  constraints:
    - emergency-use-only
    - audit-logging-required
    - post-event-review-required

  explanation:
    summary: >
      Temporary external sharing is approved for emergency response only and expires in 72 hours.

---

16. Signal Interfaces

16.1 Purpose

Signal interfaces allow systems to emit, subscribe to, retrieve, acknowledge, and act on governance signals.

16.2 Capabilities

Signal interfaces may support:

• emit signal,
• subscribe to signals,
• retrieve signal,
• acknowledge signal,
• resolve signal,
• query signals by product,
• query signals by severity,
• query signals by governance domain,
• replay signals,
• retrieve signal audit trail.

16.3 Example Signal Subscription

signalSubscription:
  subscriber:
    id: pvep-service
    type: system

  filters:
    governanceDomains:
      - trust
      - dpp
      - entitlement
    severities:
      - warning
      - blocking
      - critical
    productKinds:
      - data-product
      - ai-product

16.4 Example Signal

signal:
  signalType: DPP_EXPIRED
  severity: blocking
  product:
    id: product-456
    version: 2.1
  recommendedActions:
    - update-product-detail-warning
    - block-external-use
    - notify-steward

---

17. Explanation Interfaces

17.1 Purpose

Explanation interfaces provide human- and machine-readable rationale for governance decisions, trust states, entitlement states, policy outcomes, risk evaluations, DPP evaluations, and lifecycle gates.

17.2 Capabilities

Explanation interfaces may support:

• retrieve decision explanation,
• retrieve policy explanation,
• retrieve entitlement explanation,
• retrieve trust explanation,
• retrieve risk explanation,
• retrieve lifecycle gate explanation,
• retrieve consumer-friendly summary,
• retrieve auditor-level trace,
• retrieve agent-readable reason codes,
• retrieve remediation guidance.

17.3 Example Request

explanationRequest:
  target:
    type: decision
    id: dec-001

  audience: consumer
  language: en

17.4 Example Response

explanation:
  summary: >
    You can use this product for internal analytics, but you cannot export it externally.
    External sharing is restricted by policy and license.
  nextActions:
    - request-external-sharing-approval
    - view-policy-summary
    - open-dpp-summary

---

18. Audit Interfaces

18.1 Purpose

Audit interfaces provide access to governance decision records, signal traces, evidence references, policy versions, and lifecycle gate history.

18.2 Capabilities

Audit interfaces may support:

• retrieve decision audit record,
• retrieve policy evaluation trace,
• retrieve entitlement audit trail,
• retrieve DPP evaluation history,
• retrieve evidence review history,
• retrieve risk decision trace,
• retrieve lifecycle gate history,
• retrieve exception history,
• retrieve signal delivery trace,
• export audit package.

18.3 Example Request

auditQuery:
  product:
    id: product-456
    version: 2.1

  timeRange:
    from: 2026-01-01T00:00:00Z
    to: 2026-05-19T23:59:59Z

  include:
    - decisions
    - evidence
    - dpp-evaluations
    - policy-versions
    - signals

18.4 Example Response

auditPackage:
  product:
    id: product-456
    version: 2.1

  records:
    decisions:
      count: 128
    evidence:
      count: 14
    dppEvaluations:
      count: 6
    signals:
      count: 9

  export:
    format: governance-audit-package
    generatedAt: 2026-05-19T10:00:00Z

---

19. Interface Modes

Governance Kernel interfaces may be exposed through several modes.

19.1 Synchronous APIs

Used for immediate decisioning.

Examples:

• runtime access check,
• entitlement check,
• output port invocation,
• marketplace eligibility check.

19.2 Asynchronous Events

Used for governance state changes.

Examples:

• DPP expired,
• trust downgraded,
• entitlement revoked,
• risk tier changed,
• evidence missing.

19.3 Batch Interfaces

Used for periodic governance evaluation.

Examples:

• nightly entitlement review,
• evidence freshness scan,
• DPP completeness scan,
• risk posture recalculation.

19.4 Graph Interfaces

Used to expose governance relationships.

Examples:

• product governed by policy,
• product evidenced by DPP,
• actor entitled to product,
• product inherits restriction from input product.

19.5 Human Review Interfaces

Used when decisions require human judgment.

Examples:

• exception review,
• policy approval,
• risk override,
• evidence review,
• lifecycle approval.

19.6 Agent Interfaces

Used by machine and AI agents.

Examples:

• permitted action check,
• product suitability evaluation,
• DPP summary retrieval,
• machine-readable constraints,
• authority validation.

---

20. Common Request Context

Most Governance Kernel interfaces should share a common request context where relevant.

commonContext:
  subject:
    id: subject-id
    type: human-user | organization | application | machine-agent | ai-agent | institutional-agent | product

  action: action-code

  product:
    id: product-id
    kind: product-kind
    version: product-version

  outputPort:
    id: output-port-id
    type: output-port-type

  purpose:
    code: purpose-code
    declaredBy: subject | system | inferred

  environment:
    name: production | sandbox | marketplace | external | mission-critical

  jurisdiction:
    code: jurisdiction-code

  time:
    requestedAt: timestamp

  relationshipContext:
    relationshipType: relationship-type
    downstreamUse: downstream-use

Not every interface requires every field, but high-impact decisions should prefer richer context.

---

21. Common Response Structure

Most Governance Kernel interfaces should return structured governance state.

governanceResponse:
  outcome: allow | deny | conditional-allow | approval-required | exception-required | insufficient-context | pending

  state:
    policyState: ...
    entitlementState: ...
    trustState: ...
    riskState: ...
    evidenceState: ...
    dppState: ...

  constraints:
    - constraint-code

  obligations:
    - obligation-code

  explanation:
    summary: human-readable text
    reasonCodes:
      - REASON_CODE

  evidence:
    references:
      - evidence-id

  audit:
    traceId: trace-id
    evaluatedAt: timestamp
    evaluator: governance-kernel

The exact response depends on the interface category.

---

22. Interface Security

Governance Kernel interfaces are sensitive and must be secured.

Important controls include:

• authentication,
• authorization,
• least privilege,
• mTLS or secure service identity where applicable,
• scoped API tokens,
• agent authority checks,
• product-to-product access controls,
• policy visibility controls,
• evidence visibility controls,
• audit logging,
• rate limiting,
• tamper resistance,
• replay protection,
• data minimization,
• secure error handling.

The interface should not leak restricted product, policy, entitlement, risk, or evidence information through error messages or metadata.

---

23. Interface Versioning

Governance interfaces should be versioned.

Versioning applies to:

• API contracts,
• event schemas,
• decision schemas,
• signal schemas,
• policy schema,
• entitlement schema,
• risk schema,
• trust schema,
• DPP schema,
• evidence schema,
• explanation schema.

Versioning is necessary because governance decisions may need to be explained later using the interface and schema version in force at the time.

---

24. Interface Observability

Governance Kernel interfaces should be observable.

Useful metrics include:

• request volume by interface,
• decision latency,
• error rate,
• denied request rate,
• insufficient-context rate,
• policy evaluation failures,
• entitlement check failures,
• evidence submission failures,
• DPP validation failures,
• signal delivery failures,
• audit query volume,
• agent interface usage,
• runtime enforcement calls,
• stale response usage,
• interface version adoption,
• unauthorized call attempts.

Interface observability helps determine whether governance is operationally healthy.

---

25. Interface Reliability

Governance Kernel interfaces should be reliable.

Important properties include:

• availability,
• resilience,
• timeout behavior,
• retry semantics,
• idempotency,
• event replay,
• cache invalidation,
• decision freshness,
• degraded-mode behavior,
• fallback rules,
• circuit breaking,
• consistency between decision and enforcement.

Some runtime decisions may require low latency. Some assurance decisions may tolerate asynchronous processing.

Interface design should distinguish these needs.

---

26. Interface and Caching

Some governance state may be cached, but caching must be careful.

Examples of cacheable state:

• product trust summary,
• DPP summary,
• marketplace eligibility summary,
• policy metadata,
• static product constraints.

Examples of state requiring caution:

• entitlements,
• revocations,
• agent authority,
• risk changes,
• policy violations,
• runtime decisions,
• emergency restrictions.

Caching rules should include:

• time-to-live,
• invalidation triggers,
• signal-driven refresh,
• policy-change invalidation,
• entitlement-revocation invalidation,
• DPP-expiry invalidation,
• risk-change invalidation.

The principle is:

Cached governance state must not outlive the context that made it valid.

---

27. Interface Anti-Patterns

27.1 Context-Free Interfaces

A simple canAccess(productId, userId) interface is insufficient for many ProductVerse decisions.

27.2 UI-Specific Governance Logic

PVEP should not implement governance logic that belongs in the kernel.

27.3 Runtime Bypass

Runtime services should not bypass entitlement, policy, trust, or risk checks where governance requires them.

27.4 Human-Only Interfaces

Governance interfaces must support machine agents, AI agents, institutional agents, and products-as-consumers.

27.5 Unversioned Contracts

Unversioned interfaces make audit and reproducibility weak.

27.6 No Explanation Path

A decision API that returns only true or false is too weak for governed product economies.

27.7 No Signal Subscription

Without signal interfaces, consumers rely on stale governance state.

27.8 Overexposed Evidence Interfaces

Evidence details should not be exposed without visibility control.

27.9 Caching Without Invalidation

Cached governance state without invalidation can lead to unsafe or non-compliant actions.

---

28. Summary

The Governance Kernel Interfaces model defines how UPOS components interact with the Governance Kernel.

The Governance Kernel exposes interfaces for:

• decisions,
• policies,
• entitlements,
• trust,
• evidence,
• risk,
• DPPs,
• lifecycle gates,
• relationship governance,
• exceptions,
• signals,
• explanations,
• audit.

These interfaces allow PVEP to render governance state, PDEP to validate product lifecycle gates, Product Fabric to enforce governance at runtime, marketplaces to display eligibility and trust, Product Graph to expose governance relationships, agents to act safely, and audit systems to retain traceability.

Governance Kernel interfaces should be contextual, structured, secure, versioned, explainable, auditable, product-kind-aware, actor-aware, agent-aware, and machine-readable.

In short:

Governance Kernel Interfaces make governance computable, consumable, enforceable, explainable, and auditable across the ProductVerse.