Governance Runtime Epic

User Journey

The Governance Runtime bounded context enforces governance policies at runtime through evidence collection, risk evaluation, and continuous compliance monitoring. It maintains risk registers, executes policy validations, and provides real-time governance decisions across all bounded contexts in the SEA™ platform.

Jobs to be Done & EARS Requirements

Job: Collect Evidence for Governance Checks

User Story: As a governance system, I want to collect evidence from all contexts for governance validation, so that I can verify compliance with enterprise policies.

EARS Requirement:

• While the system is operational, when a CollectEvidence command is received with context identifier and policy scope, the governance-runtime context shall:
  1. Identify Evidence Requirements:
     • Parse policy definitions to determine required evidence types
     • Identify source contexts for each evidence type
     • Define evidence collection scope (time range, entities, operations)
  2. Gather Artifacts:
     • Collect from semantic-core: DSL specifications and validation results
     • Collect from architectural-governance: compliance reports and violations
     • Collect from query: access logs and governance decisions
     • Collect from ingest: policy ingestion records and changes
     • Collect from all contexts: domain events and state changes
     • Classify and redact sensitive fields (PII/secrets) before storage
  3. Hash Evidence for Integrity:
     • Calculate SHA256 hash for each evidence artifact
     • Store hash alongside evidence for tamper detection
     • Maintain hash chain for evidence provenance
  4. Store Evidence Record:
     • Create evidence aggregate with:
       • Evidence ID and timestamp
       • Source context and artifact type
       • SHA256 hash and content reference
       • Collection metadata (collector, scope, purpose)
     • Persist evidence in immutable storage
  5. Return Evidence Summary:
     • List collected artifacts with hashes
     • Provide evidence references for validation
     • Flag any collection failures or missing evidence

Job: Evaluate Risks for Context

User Story: As a risk manager, I want to evaluate risks across contexts based on evidence and policies, so that I can identify and mitigate compliance issues.

EARS Requirement: While the system is operational, when an EvaluateRisks command is received with context identifier and evaluation criteria, the governance-runtime context shall:

1. Load Governance Policies:
   • Retrieve policy rules from semantic-core
   • Load risk models and scoring criteria
   • Identify applicable controls and thresholds
2. Analyze Evidence:
   • Retrieve collected evidence for context
   • Verify evidence integrity via SHA256 hashes
   • Compare evidence against policy requirements
3. Calculate Risk Scores:
   • Assess likelihood: probability of policy violation
   • Assess impact: severity of violation consequences
   • Calculate overall risk score: likelihood × impact
   • Determine risk level: Critical, High, Medium, Low
4. Identify Violations:
   • Detect policy breaches from evidence analysis
   • Classify violations by severity and category
   • Root cause analysis for identified issues
5. Update Risk Register:
   • Create or update risk entries with:
     • Risk ID and context identifier
     • Risk level and score
     • Contributing factors and evidence
     • Mitigation recommendations
   • Track risk trends over time
6. Trigger Actions:
   • Alert on critical and high risks
   • Block operations when policy violations detected:
     • Scope: incoming API requests, new deployments, and state-changing transactions
     • Mechanisms: API gateway reject, sidecar/interceptor abort, admission controller
     • Duration: until remediation or timed quarantine with backoff
     • Emergency override: approverRoles with auditable, time-limited bypass (SDS-031 authority boundaries: RBAC + permission-scope checks, audited break-glass, and time-bound approvals; see SDS-031)
   • Suggest remediation steps for identified issues
   • Emit risk-evaluation-completed event

Job: Query Current Risk Score

User Story: As a dashboard or monitoring system, I want to retrieve current risk scores and registers, so that I can display governance health status.

EARS Requirement:

• While the system is operational, when a GetRiskScore query is received with context identifier or “all” qualifier, the governance-runtime context shall:
  1. Retrieve RiskRegister aggregate for specified context
  2. If “all” requested, aggregate risk scores across all contexts
  3. Return risk information including:
     • Overall risk score and level (Critical/High/Medium/Low)
     • Individual risk entries with:
       • Risk ID and description
       • Likelihood and impact ratings
       • Contributing violations and evidence
       • Mitigation status and recommendations
     • Risk trend history showing changes over time
     • Last evaluation timestamp
  4. Include context-specific filtering options:
     • Risk level filters (show only Critical/High)
     • Category filters (compliance, security, architectural)
     • Time range filters (recent changes only)

Job: Enforce Policies at Runtime

User Story: As a policy enforcement point, I want to validate operations against governance policies before execution, so that I can prevent non-compliant actions.

EARS Requirement:

• While processing operations, when a runtime check is triggered by EnforcePolicy command, the governance-runtime context shall:
  1. Identify Applicable Policies:
     • Parse operation type and context
     • Retrieve relevant governance policies
     • Load policy rules and constraints
  2. Evaluate Against Evidence:
     • Collect current state evidence
     • Compare operation against policy requirements
     • Check for potential violations
  3. Make Governance Decision:
     • Allow: Operation complies with all policies
     • Deny: Operation violates policy (return 403)
     • Allow with Warning: Operation compliant but risky
     • Require Approval: Operation needs elevated permissions
       • approvalWorkflow:
         • approverRoles (admin/owner/policy-reviewer)

         • mode: “sync”

           “async”

         • approvalTimeoutSeconds

         • onTimeout: “deny”

           “escalate”

         • pendingBehavior: “block”

           “queue”

           “continue”

       • enforce SDS-031 authority boundaries (RBAC + permission-scope enforcement with auditable approvals and time limits) for approvals and overrides
  4. Record Decision:
     • Log governance decision with:
       • Operation type and context
       • Decision (allow/deny/warning/approval)
       • Applicable policies and evidence
       • Timestamp and decision maker (human/system)
  5. Return Decision:
     • Provide allow/deny result to calling context
     • Include rationale and policy references
     • For async approval, return 202 with approvalId and callback/webhook details
     • Emit policy-enforcement event for observability

Domain Entities Summary

Root Aggregates

• Evidence: Represents governance evidence with artifact hash, content reference, source context, and collection metadata
• RiskRegister: Aggregates risk assessments with risk entries, scores, trends, and mitigation recommendations
• GovernanceDecision: Records policy enforcement decisions with operation, outcome, rationale, and timestamp

Value Objects

• RiskScore: Numerical and categorical risk assessment (0-100, Critical/High/Medium/Low)
• EvidenceHash: SHA256 hash for evidence integrity verification
• PolicyViolation: Identified breach with type, severity, evidence references, and remediation steps
• RiskEntry: Individual risk with ID, description, likelihood, impact, and mitigation status

Policy Rules

• PolicyConfigRequired: Governance policies must define rules for evaluation
• EvidenceIntegrity: All evidence must be SHA256 hashed for tamper detection
• SidecarEnforcement: Policy validation uses sidecar pattern to prevent inference modification
• ImmutableEvidence: Collected evidence must be stored immutably for audit trails

Integration Points

• All Bounded Contexts: Collects evidence from and enforces policies across all contexts
• Semantic Core Context: Retrieves policy definitions and validation rules
• Architectural Governance Context: Receives architectural compliance data for risk assessment
• Query Context: Validates access requests and enforces query governance
• Ingest Context: Monitors policy ingestion for compliance tracking
• Monitoring Systems: Emits alerts for critical risks and violations

References

• SDS-031 — Authority Boundaries: Defines RBAC/permission-scope enforcement, audit requirements, and time-limited approvals for break-glass and override flows. See docs/specs/shared/sds/031-authority-ownership-boundaries.md.