Governance Kernel Signals

1. Purpose

The Governance Kernel Signals model defines how the UPOS Governance Kernel emits, receives, interprets, routes, and records governance-relevant signals across the ProductVerse.

Signals are necessary because governance is not only a point-in-time decision. Governance state changes over time.

A product may become untrusted.
A DPP may expire.
A risk tier may change.
An entitlement may be revoked.
A policy may be updated.
A lifecycle gate may fail.
An agent may exceed its authority.
A product dependency may become unsafe.
An evidence record may become stale.
A runtime violation may be detected.

The Governance Kernel Signals model exists to make these changes observable, machine-actionable, auditable, and available to UPOS planes and services.

The key principle is:

Governance signals turn governance state changes into observable, actionable events across the ProductVerse.

2. Definition

A Governance Signal is a structured event, notification, state change, alert, decision emission, or assurance update that communicates a governance-relevant condition about a product, actor, policy, entitlement, risk, trust state, evidence record, DPP, product relationship, lifecycle event, or runtime interaction.

A governance signal may indicate that:

a decision has been made,
a policy has changed,
an entitlement has been granted or revoked,
a trust posture has changed,
a risk tier has changed,
evidence has expired,
a DPP has become invalid,
a lifecycle gate has passed or failed,
a product relationship has become risky,
a runtime policy violation occurred,
an exception was created or expired,
an agent action requires review.

A basic signal statement can be expressed as:

Signal S reports that Governance State G
changed for Object O
because Event E occurred
at Time T
under Authority A
with Severity V
and Recommended Action R.

Example:

DPP_EXPIRED signal reports that Product P version 2.1
no longer has a valid Digital Product Passport
as of 2026-05-19,
requiring trust downgrade, marketplace warning,
and publication review.

3. Why Signals Matter

Governance in the ProductVerse is dynamic.

A static governance model may decide that a product is trusted, entitled, or publishable at one moment. But that decision may become invalid when context changes.

Signals are needed because UPOS must react to governance changes across:

discovery,
acquisition,
consumption,
entitlement,
product composition,
lifecycle management,
runtime enforcement,
marketplace listing,
trust rendering,
audit and assurance,
product graph navigation,
agent-mediated action.

Without governance signals, UPOS components would rely on stale governance state.

The result would be:

expired evidence still displayed as valid,
revoked access still usable,
high-risk products still listed,
retired dependencies still consumed,
expired DPPs still shown as trusted,
runtime violations not reflected in trust or risk posture,
agents acting beyond valid authority.

Signals allow the Governance Kernel to keep the ProductVerse synchronized with current governance reality.

4. Signal as Governance State Change

In UPOS, a governance signal is not just a notification.

It is a representation of governance-relevant state change.

A signal may be:

informational,
advisory,
warning,
blocking,
corrective,
lifecycle-triggering,
audit-triggering,
runtime-enforcing,
escalation-triggering,
marketplace-visible,
PVEP-renderable,
PDEP-actionable,
Product Fabric-enforceable.

The signal itself may not always be the authoritative decision, but it points to or carries governance state that other components must understand.

The principle is:

Signals communicate that governance state has changed, requires attention, or must be enforced.

5. Signal Producers

Governance signals may be produced by multiple UPOS components.

Producer	Example signal
Governance Kernel	Policy decision emitted, trust posture changed, risk tier changed.
Policy Evaluation Engine	Policy violation detected, new obligation derived.
Entitlement Decision Engine	Entitlement granted, revoked, expired, suspended.
Trust & Evidence Engine	Evidence expired, trust downgraded, claim unsupported.
DPP Evaluation Engine	DPP valid, incomplete, expired, superseded.
Risk Evaluation Engine	Risk tier upgraded, escalation required, override expired.
PDEP	Product submitted for publication, lifecycle gate failed, composition blocked.
PVEP	User requested access, DPP viewed, trust explanation requested.
Product Fabric	Runtime policy violation, access denied, masking applied.
Marketplace	Product listed, subscription created, license accepted.
Product Graph	Dependency added, risky relationship detected, downstream impact identified.
Runtime Services	Incident detected, API misuse, quota exceeded, abnormal invocation.
Agents	Delegated action requested, authority boundary reached, recommendation emitted.
Evidence Store	Evidence submitted, approved, expired, revoked.

The Governance Kernel may produce signals directly or consume signals from other systems and convert them into governance state.

6. Signal Consumers

Governance signals may be consumed by many UPOS components.

Consumer	How signals are used
PVEP	Display trust, risk, entitlement, policy, DPP, and lifecycle changes to consumers.
PDEP	Trigger validation gates, block publication, request evidence, require review.
Product Fabric	Enforce access, masking, routing, throttling, logging, or blocking controls.
Marketplace	Update listings, show warnings, suspend acquisition, refresh trust display.
Product Graph	Update policy, trust, entitlement, risk, and dependency edges.
Product Registry	Update product lifecycle, governance, and status metadata.
Evidence Services	Request evidence refresh, mark evidence expired, trigger review.
Agents	Adjust recommendations, stop actions, request confirmation, escalate.
Audit Systems	Record governance state changes and decision traces.
Observability Services	Track governance health, policy drift, trust gaps, risk changes.
Producers and Stewards	Act on evidence gaps, trust downgrades, entitlement issues, lifecycle blockers.

7. Signal Categories

Governance signals can be grouped into categories.

7.1 Decision Signals

Signals emitted when the Governance Kernel makes a decision.

Examples:

governance decision emitted,
access allowed,
access denied,
conditional allow emitted,
approval required,
exception required,
insufficient context,
lifecycle gate passed,
lifecycle gate failed.

7.2 Policy Signals

Signals related to policy state or policy evaluation.

Examples:

policy updated,
policy activated,
policy suspended,
policy retired,
policy conflict detected,
policy violation detected,
new obligation derived,
prohibited use detected,
policy exception requested.

7.3 Entitlement Signals

Signals related to rights, permissions, subscriptions, access grants, and delegated authority.

Examples:

entitlement requested,
entitlement granted,
entitlement denied,
entitlement provisioned,
entitlement expired,
entitlement revoked,
entitlement suspended,
quota exceeded,
delegation granted,
delegation expired,
delegated authority invalid.

7.4 Trust Signals

Signals related to product trust state.

Examples:

trust posture changed,
trust upgraded,
trust downgraded,
trust under review,
product trusted for purpose,
product not trusted for purpose,
evidence gap detected,
certification expired,
quality posture changed.

7.5 Evidence Signals

Signals related to evidence state.

Examples:

evidence submitted,
evidence accepted,
evidence rejected,
evidence expired,
evidence revoked,
evidence superseded,
evidence missing,
evidence insufficient,
evidence review required,
claim unsupported.

7.6 DPP Signals

Signals related to Digital Product Passport state.

Examples:

DPP created,
DPP submitted,
DPP valid,
DPP incomplete,
DPP expired,
DPP revoked,
DPP superseded,
DPP version mismatch,
DPP marketplace-ready,
DPP publication blocked.

7.7 Risk Signals

Signals related to risk state.

Examples:

risk tier changed,
risk upgraded,
risk downgraded,
risk review required,
escalation required,
high-risk use detected,
risk override created,
risk override expired,
residual risk accepted,
relationship risk detected.

7.8 Lifecycle Signals

Signals related to product lifecycle events.

Examples:

product created,
product submitted for validation,
product validation passed,
product validation failed,
product published,
product listing approved,
product listing blocked,
product deprecated,
product retired,
product recertification required.

7.9 Relationship Signals

Signals related to ProductVerse relationships.

Examples:

dependency added,
dependency removed,
relationship approved,
relationship blocked,
product composition requested,
product composition allowed,
product composition denied,
restriction inherited,
downstream impact detected,
chain risk detected.

7.10 Runtime Signals

Signals emitted from runtime systems.

Examples:

runtime access denied,
policy enforcement applied,
masking applied,
prohibited export attempted,
suspicious invocation detected,
agent tool invocation blocked,
quota exceeded,
incident detected,
output port disabled.

7.11 Agent Signals

Signals related to agents and delegated action.

Examples:

agent action requested,
agent authority validated,
agent authority expired,
agent exceeded scope,
AI agent requires human confirmation,
institutional agent escalation required,
tool use blocked,
supervisor review required.

8. Signal Severity

Governance signals should carry severity.

Example severity levels:

Severity	Meaning
Informational	State changed but no immediate action required.
Advisory	Action may be useful but not mandatory.
Warning	Attention required; governance condition may degrade.
Blocking	Action must stop or cannot proceed.
Critical	Immediate escalation required.
Emergency	Exceptional time-sensitive action required under emergency governance.

Severity should not be arbitrary. It should be derived from policy, risk, trust, lifecycle, and operational impact.

9. Signal Structure

A governance signal should be structured and machine-readable.

9.1 Example Signal

signalId: sig-001
signalType: DPP_EXPIRED
severity: blocking

subject:
  type: product
  productId: product-123
  productVersion: 2.1

governanceDomain:
  - dpp
  - trust
  - lifecycle

stateChange:
  previousState: dpp-valid
  newState: dpp-expired

cause:
  event: dpp-validity-expired
  occurredAt: 2026-05-19T10:00:00Z

impact:
  affectedContexts:
    - marketplace-listing
    - external-sharing
    - high-risk-use
  affectedConsumers:
    - marketplace
    - pvep
    - pdep
    - product-fabric

recommendedActions:
  - suspend-marketplace-trust-badge
  - require-dpp-refresh
  - block-new-publication
  - notify-product-steward

evidence:
  references:
    - dpp-789

audit:
  emittedBy: governance-kernel
  emittedAt: 2026-05-19T10:00:01Z
  policyVersion: 4.2

9.2 Core Signal Fields

Field	Description
signalId	Unique signal identifier.
signalType	Type of governance signal.
severity	Informational, warning, blocking, critical, etc.
subject	Product, actor, policy, entitlement, evidence, DPP, relationship, or lifecycle event.
governanceDomain	Policy, entitlement, trust, risk, evidence, DPP, lifecycle, runtime, etc.
stateChange	Previous and new state, where applicable.
cause	Triggering event, decision, expiry, violation, or context change.
impact	Affected products, actors, output ports, relationships, consumers, or lifecycle events.
recommendedActions	Actions that consumers should take.
constraints	Any constraints implied by the signal.
evidence	Evidence, policy, decision, or DPP references.
audit	Emission time, emitter, version references, trace identifiers.
visibility	Who may see this signal or signal summary.
expiry	When the signal becomes stale or must be reevaluated.

10. Signal Lifecycle

A signal may itself have a lifecycle.

Signal Emitted
  → Routed
  → Consumed
  → Acknowledged
  → Acted Upon
  → Resolved / Superseded / Expired
  → Archived

10.1 Emitted

The signal is created by the Governance Kernel or another authorized source.

10.2 Routed

The signal is sent to relevant consumers.

10.3 Consumed

A UPOS component receives and interprets the signal.

10.4 Acknowledged

A human, service, agent, or system acknowledges the signal.

10.5 Acted Upon

The signal triggers enforcement, display, workflow, lifecycle gate, evidence request, or escalation.

10.6 Resolved

The underlying governance condition is addressed.

10.7 Superseded

A newer signal replaces the earlier signal.

10.8 Expired

The signal is no longer valid or relevant.

10.9 Archived

The signal is retained for audit and observability.

11. Signal Routing

Signals should be routed based on governance domain, severity, subject, impact, and consumer type.

11.1 Routing Examples

DPP_EXPIRED
  → Product Steward
  → PVEP
  → Marketplace
  → PDEP
  → Product Fabric

ENTITLEMENT_REVOKED
  → Product Fabric
  → PVEP
  → Runtime Services
  → Audit System

RISK_TIER_UPGRADED_TO_R3
  → PDEP
  → PVEP
  → Product Marketplace
  → Product Steward
  → Governance Review Queue

AGENT_AUTHORITY_EXPIRED
  → Agent Runtime
  → Product Fabric
  → Supervisor
  → Audit System

11.2 Routing Principle

Not every signal should be shown to every consumer. Signals must respect relevance, severity, entitlement, confidentiality, and role.

12. Signal Visibility

Signals may carry sensitive governance information.

Visibility levels may include:

Visibility level	Description
Public	Visible to anyone.
Marketplace summary	Visible in product listings.
Consumer summary	Visible to entitled or prospective consumers.
Steward detail	Visible to product owner or steward.
Governance detail	Visible to governance, risk, compliance, or audit functions.
Runtime only	Used by enforcement systems but not shown directly.
Agent-readable	Available to authorized machine or AI agents.
Restricted	Limited to privileged authority.

Signal visibility must respect:

entitlement,
confidentiality,
privacy,
security,
licensing,
regulatory constraints,
evidence visibility rules,
policy visibility rules.

13. Signal Semantics

Governance signals should have precise semantics.

13.1 Informational Does Not Mean Optional

An informational signal may not require immediate action, but it may still be important for observability or audit.

13.2 Warning Does Not Mean Blocking

A warning indicates concern, but action may still proceed unless policy or risk state says otherwise.

13.3 Blocking Means Enforcement Required

A blocking signal should trigger enforcement or prevent action if the receiving component is responsible for enforcement.

13.4 Critical Requires Escalation

Critical signals should reach accountable authorities quickly.

13.5 Expired Signal Is Not Current State

An expired signal should not be used as current governance state.

13.6 Signal Is Not Always Decision

Some signals report decisions. Others report changes that may trigger new decisions.

14. Signal Patterns

14.1 Decision Emission Pattern

Governance Decision
  → Decision Signal
  → PVEP / PDEP / Product Fabric / Marketplace / Audit

Example:

Access denied because entitlement expired.

14.2 State Change Pattern

Governance State Change
  → Signal Emitted
  → Dependent Systems Update

Example:

Product trust posture changed from trusted to conditionally trusted.

14.3 Expiry Pattern

Evidence / Entitlement / DPP / Exception reaches expiry
  → Expiry Signal
  → Trust / Access / Lifecycle state reevaluated

14.4 Runtime Violation Pattern

Runtime detects prohibited action
  → Violation Signal
  → Enforcement + Audit + Risk Update

14.5 Lifecycle Gate Pattern

PDEP requests lifecycle transition
  → Kernel evaluates
  → Gate Passed / Failed Signal
  → PDEP continues, blocks, or requests remediation

14.6 Relationship Impact Pattern

Product dependency changes
  → Relationship Signal
  → Downstream impact analysis
  → Affected products and consumers notified

14.7 Agent Action Pattern

Agent requests action
  → Authority and entitlement evaluated
  → Agent signal emitted
  → Action allowed, blocked, or escalated

15. Signal Examples

15.1 Entitlement Revoked

signalType: ENTITLEMENT_REVOKED
severity: blocking
subject:
  type: human-user
  id: user-123
object:
  type: product
  id: product-456
impact:
  action: revoke-runtime-access
  consumers:
    - product-fabric
    - pvep
    - runtime-services
recommendedActions:
  - disable-output-port-access
  - notify-user
  - record-audit-event

15.2 Evidence Expired

signalType: EVIDENCE_EXPIRED
severity: warning
subject:
  type: evidence
  id: evidence-789
relatedProduct:
  id: product-456
impact:
  trustState: downgrade-required
  lifecycle: review-required
recommendedActions:
  - request-evidence-refresh
  - notify-steward
  - update-dpp-status

15.3 Policy Violation Detected

signalType: POLICY_VIOLATION_DETECTED
severity: critical
subject:
  type: runtime-action
  id: invocation-001
policy:
  id: policy-no-external-export
violation:
  attemptedAction: external-export
recommendedActions:
  - block-action
  - notify-governance
  - create-audit-record
  - trigger-incident-review

15.4 Risk Tier Changed

signalType: RISK_TIER_CHANGED
severity: warning
product:
  id: product-ai-123
previousRiskTier: R2
newRiskTier: R3
recommendedActions:
  - require-human-review
  - update-marketplace-risk-display
  - reevaluate-agent-entitlements
  - notify-product-steward

15.5 DPP Version Mismatch

signalType: DPP_VERSION_MISMATCH
severity: blocking
product:
  id: product-456
  version: 2.1
dpp:
  id: dpp-789
  productVersion: 2.0
recommendedActions:
  - block-publication
  - require-dpp-update
  - notify-pdep-workflow

16. Signals and PVEP

PVEP consumes governance signals to keep consumer-facing experiences accurate.

PVEP may use signals to:

update trust badges,
update access status,
show DPP warnings,
show risk changes,
disable unavailable actions,
show approval requirements,
display policy explanations,
notify consumers,
refresh product detail pages,
update portfolio views,
update product graph overlays.

Example:

Kernel emits DPP_EXPIRED.
PVEP updates product detail page:
“DPP expired. Trust state under review. External use temporarily unavailable.”

PVEP must not invent signal semantics. It should render kernel-derived signal state appropriately for the audience.

17. Signals and PDEP

PDEP consumes governance signals during product creation and lifecycle control.

PDEP may use signals to:

block publication,
request missing evidence,
refresh DPP,
rerun validation,
reevaluate composition,
stop product promotion,
trigger steward review,
require risk approval,
prevent retirement,
require downstream impact analysis.

Example:

Evidence expired for a product under publication review.
PDEP receives EVIDENCE_EXPIRED signal.
Publication gate fails until evidence is refreshed.

18. Signals and Product Fabric

Product Fabric consumes signals to enforce governance at runtime and across interoperability mechanisms.

Product Fabric may use signals to:

revoke access,
disable output ports,
apply masking,
enforce filtering,
block export,
route to approved environments,
require audit logging,
block agent tool use,
enforce rate limits,
suspend runtime access.

Example:

ENTITLEMENT_REVOKED signal emitted.
Product Fabric revokes API token and disables output-port access.

19. Signals and Marketplace

Marketplaces consume signals to keep product listings accurate.

Marketplace may use signals to:

update listing status,
show trust warnings,
suspend acquisition,
hide restricted products,
display DPP state,
update risk posture,
change availability,
disable purchase or subscription,
trigger provider remediation.

Example:

RISK_TIER_CHANGED to R3.
Marketplace updates product listing to show high-risk posture and approval requirement.

20. Signals and Product Graph

Product Graph consumes signals to update governance-aware relationships and overlays.

Signals may update:

trust edges,
policy edges,
entitlement edges,
evidence edges,
risk overlays,
lifecycle state,
dependency warnings,
downstream impact views,
relationship restrictions.

Example:

Product dependency becomes deprecated.
Product Graph updates downstream impact view and emits affected product relationship signal.

21. Signals and Agents

Agents consume signals to act safely.

Agents may use signals to:

stop a planned action,
request human confirmation,
choose substitute products,
avoid untrusted products,
refresh recommendations,
escalate authority issue,
update product-set selection,
avoid expired DPPs,
prevent prohibited tool invocation.

Example:

AI procurement agent receives DPP_EXPIRED for recommended product.
Agent removes product from recommendation set or marks it as requiring review.

Agent-facing signals should be machine-readable and scoped to the agent’s authority.

22. Signals and Audit

Signals should be auditable.

A signal record should show:

what was emitted,
why it was emitted,
what object it applies to,
who or what emitted it,
who received it,
whether it was acknowledged,
what action was taken,
when it was resolved,
what evidence or decision supports it.

Signals are part of the governance evidence trail.

The principle is:

A material governance signal should leave an audit trail.

23. Signal Reliability

Governance signals must be reliable.

Important properties include:

delivery assurance,
ordering where needed,
idempotency,
deduplication,
replayability,
integrity,
authenticity,
traceability,
expiry handling,
consumer acknowledgement,
failure handling,
dead-letter handling,
monitoring.

A missed governance signal may cause unsafe or non-compliant behavior.

24. Synchronous vs Asynchronous Signals

Signals may be emitted synchronously or asynchronously.

24.1 Synchronous Signals

Used when immediate response is needed.

Examples:

access denied,
policy violation,
runtime block,
lifecycle gate failed.

24.2 Asynchronous Signals

Used when governance state changes over time.

Examples:

evidence expired,
DPP review required,
trust downgraded,
risk review due,
entitlement nearing expiry.

Both patterns are necessary.

25. Signal Retention

Signals should be retained according to governance requirements.

Retention may depend on:

signal type,
severity,
policy,
jurisdiction,
audit requirement,
product kind,
risk tier,
lifecycle relevance,
regulatory obligation.

High-impact signals should be retained longer than low-impact informational signals.

26. Signal Observability

Signal operations should be observable.

Useful metrics include:

signals emitted by type,
signals emitted by severity,
signal delivery success,
signal delivery latency,
unacknowledged signals,
unresolved blocking signals,
expired signals,
duplicate signals,
failed signal routing,
signal consumer failures,
signal-triggered enforcement actions,
signal-triggered lifecycle blocks,
signal-triggered marketplace updates,
signal-triggered trust downgrades.

Signal observability helps determine whether governance state is actually flowing through UPOS.

27. Security and Control Considerations

Governance signals are control-sensitive.

Important considerations include:

signal authenticity,
signal integrity,
producer authorization,
consumer authorization,
secure routing,
confidentiality,
replay protection,
tamper resistance,
audit logging,
signal visibility controls,
prevention of false signals,
prevention of signal suppression,
incident handling for signal failures.

A false signal may wrongly block or permit action. A suppressed signal may allow unsafe action to continue.

28. Design Guidance

28.1 Structure Signals

Signals should be typed, versioned, and machine-readable.

28.2 Preserve Semantics

A warning, block, decision, alert, and state change should not be treated as the same thing.

28.3 Route by Relevance

Signals should reach the components and actors that need them, not everyone.

28.4 Make Severity Explicit

Severity should be part of signal structure and should drive behavior.

28.5 Make Signals Auditable

Material governance signals should be retained and traceable.

28.6 Support Human and Agent Consumers

PVEP may need human-readable signal explanations. Agents need machine-readable signal payloads.

28.7 Connect Signals to Action

Signals should carry recommended actions or required actions where possible.

28.8 Prevent Signal Abuse

Signals should be protected from forgery, manipulation, replay, and suppression.

28.9 Avoid Stale Signals

Signals should include timestamps, expiry, supersession, or reevaluation semantics.

29. Anti-Patterns

29.1 Signals as Logs Only

A log records that something happened. A governance signal communicates actionable governance state.

29.2 Untyped Signals

Generic events without clear signal type or semantics are hard to act on.

29.3 No Severity

Without severity, consumers cannot know whether to inform, warn, block, or escalate.

29.4 Signal Flooding

Too many low-value signals can cause consumers to ignore important ones.

29.5 No Visibility Controls

Governance signals may reveal sensitive policy, risk, entitlement, or evidence information.

29.6 No Audit Trail

Material signals without traceability weaken governance assurance.

29.7 Stale Signals

Old signals should not be treated as current governance state.

29.8 Signals Without Action

Signals that do not identify impact or recommended action may create noise.

29.9 Suppressed Signals

Governance-critical signals must not be silently dropped or ignored.

30. Summary

The Governance Kernel Signals model defines how governance state changes are emitted, routed, consumed, acted upon, and audited across the ProductVerse.

Governance signals communicate changes or conditions related to:

decisions,
policies,
entitlements,
trust,
evidence,
DPPs,
risk,
lifecycle events,
product relationships,
runtime enforcement,
agents.

Signals are consumed by PVEP, PDEP, Product Fabric, marketplaces, Product Graph, registries, agents, runtime services, producers, stewards, and audit systems.

They must be structured, typed, severity-aware, context-aware, visibility-controlled, auditable, reliable, and actionable.

In short:

Governance Kernel Signals keep the ProductVerse synchronized with current governance reality.

1. Purpose​

2. Definition​

3. Why Signals Matter​

4. Signal as Governance State Change​

5. Signal Producers​

6. Signal Consumers​

7. Signal Categories​

7.1 Decision Signals​

7.2 Policy Signals​

7.3 Entitlement Signals​

7.4 Trust Signals​

7.5 Evidence Signals​

7.6 DPP Signals​

7.7 Risk Signals​

7.8 Lifecycle Signals​

7.9 Relationship Signals​

7.10 Runtime Signals​

7.11 Agent Signals​

8. Signal Severity​

9. Signal Structure​

9.1 Example Signal​

9.2 Core Signal Fields​

10. Signal Lifecycle​

10.1 Emitted​

10.2 Routed​

10.3 Consumed​

10.4 Acknowledged​

10.5 Acted Upon​

10.6 Resolved​

10.7 Superseded​

10.8 Expired​

10.9 Archived​

11. Signal Routing​

11.1 Routing Examples​

11.2 Routing Principle​

12. Signal Visibility​

13. Signal Semantics​

13.1 Informational Does Not Mean Optional​

13.2 Warning Does Not Mean Blocking​

13.3 Blocking Means Enforcement Required​

13.4 Critical Requires Escalation​

13.5 Expired Signal Is Not Current State​

13.6 Signal Is Not Always Decision​

14. Signal Patterns​

14.1 Decision Emission Pattern​

14.2 State Change Pattern​

14.3 Expiry Pattern​

14.4 Runtime Violation Pattern​

14.5 Lifecycle Gate Pattern​

14.6 Relationship Impact Pattern​

14.7 Agent Action Pattern​

15. Signal Examples​

15.1 Entitlement Revoked​

15.2 Evidence Expired​

15.3 Policy Violation Detected​

15.4 Risk Tier Changed​

15.5 DPP Version Mismatch​

16. Signals and PVEP​

17. Signals and PDEP​

18. Signals and Product Fabric​

19. Signals and Marketplace​

20. Signals and Product Graph​

21. Signals and Agents​

22. Signals and Audit​

23. Signal Reliability​

24. Synchronous vs Asynchronous Signals​

24.1 Synchronous Signals​

24.2 Asynchronous Signals​

25. Signal Retention​

26. Signal Observability​

27. Security and Control Considerations​

28. Design Guidance​

28.1 Structure Signals​

28.2 Preserve Semantics​

28.3 Route by Relevance​

28.4 Make Severity Explicit​

28.5 Make Signals Auditable​

28.6 Support Human and Agent Consumers​

28.7 Connect Signals to Action​

28.8 Prevent Signal Abuse​

1. Purpose

2. Definition

3. Why Signals Matter

4. Signal as Governance State Change

5. Signal Producers

6. Signal Consumers

7. Signal Categories

7.1 Decision Signals

7.2 Policy Signals

7.3 Entitlement Signals

7.4 Trust Signals

7.5 Evidence Signals

7.6 DPP Signals

7.7 Risk Signals

7.8 Lifecycle Signals

7.9 Relationship Signals

7.10 Runtime Signals

7.11 Agent Signals

8. Signal Severity

9. Signal Structure

9.1 Example Signal

9.2 Core Signal Fields

10. Signal Lifecycle

10.1 Emitted

10.2 Routed

10.3 Consumed

10.4 Acknowledged

10.5 Acted Upon

10.6 Resolved

10.7 Superseded

10.8 Expired

10.9 Archived

11. Signal Routing

11.1 Routing Examples

11.2 Routing Principle

12. Signal Visibility

13. Signal Semantics

13.1 Informational Does Not Mean Optional

13.2 Warning Does Not Mean Blocking

13.3 Blocking Means Enforcement Required

13.4 Critical Requires Escalation

13.5 Expired Signal Is Not Current State

13.6 Signal Is Not Always Decision

14. Signal Patterns

14.1 Decision Emission Pattern

14.2 State Change Pattern

14.3 Expiry Pattern

14.4 Runtime Violation Pattern

14.5 Lifecycle Gate Pattern

14.6 Relationship Impact Pattern

14.7 Agent Action Pattern

15. Signal Examples

15.1 Entitlement Revoked

15.2 Evidence Expired

15.3 Policy Violation Detected

15.4 Risk Tier Changed

15.5 DPP Version Mismatch

16. Signals and PVEP

17. Signals and PDEP

18. Signals and Product Fabric

19. Signals and Marketplace

20. Signals and Product Graph

21. Signals and Agents

22. Signals and Audit

23. Signal Reliability

24. Synchronous vs Asynchronous Signals

24.1 Synchronous Signals

24.2 Asynchronous Signals

25. Signal Retention

26. Signal Observability

27. Security and Control Considerations

28. Design Guidance

28.1 Structure Signals

28.2 Preserve Semantics

28.3 Route by Relevance

28.4 Make Severity Explicit

28.5 Make Signals Auditable

28.6 Support Human and Agent Consumers

28.7 Connect Signals to Action

28.8 Prevent Signal Abuse