19-ai-gov ? EVA AI Governance Plane

EVA Ecosystem Integration

Tool	Purpose	How to Use
37-data-model	Single source of truth for all project entities	GET https://msub-eva-data-model.victoriousgrass-30debbd3.canadacentral.azurecontainerapps.io/model/projects/19-ai-gov
29-foundry	Agentic capabilities (search, RAG, eval, observability)	C:\eva-foundry\eva-foundation\29-foundry
48-eva-veritas	Trust score and coverage audit	MCP tool: audit_repo / get_trust_score
07-foundation-layer	Copilot instructions primer + governance templates	MCP tool: apply_primer / audit_project

Agent rule: Query the data model API before reading source files.

Invoke-RestMethod "https://msub-eva-data-model.victoriousgrass-30debbd3.canadacentral.azurecontainerapps.io/model/agent-guide"   # complete protocol
Invoke-RestMethod "https://msub-eva-data-model.victoriousgrass-30debbd3.canadacentral.azurecontainerapps.io/model/agent-summary" # all layer counts

---

Status: Design authority complete + kernel-engine runtime active
Owner: AICOE
Last Updated: 2026-03-18
Maturity: active
Current Sprint: API-first pilot-wave rollout active; governance markdown and Copilot memory exceptions retained

---

What This Project Is

19-ai-gov serves two roles:

1. Governance Specification Authority for the EVA AI.Gov platform — governance domain definitions, actor model schemas, decision engine pipeline specification, context envelope contract, and Cosmos container schemas for governance objects.

2. D³PDCA Implementation Authority for the EVA workspace — complete implementation roadmap for deploying Discover-Define-Plan-Do-Check-Act methodology across 6 projects, including 8 new data model layers, 3 Cosmos containers, 40+ UI screens, Control Plane dashboard, APIM gateway, and security integration.

Governance Design Scope

The root of this project remains the governance design authority: governance domain definitions, actor model schemas, decision engine pipeline specification, context envelope contract, Cosmos container schemas for governance objects, and acceptance criteria.

This repository now also contains runnable implementation work under kernel-engine/. That service hosts the workflow orchestration runtime used for the WS-06 workstream and related execution experiments. Treat the root documentation as the policy and design surface, and kernel-engine/ as the executable runtime surface.

Current Runtime Status

The kernel-engine/ service is no longer just planned work. It is a running FastAPI execution surface with repo-native validation restored.

Current verified state as of 2026-03-18:

• Native pytest suite passes at 74 passed, 1 skipped.
• Coverage gate passes at 81.88% after the go-live hardening modules were added.
• POST /workflows/skill-promotion now persists promotion records before emitting orchestration events.
• The Project 19 consumer contract has been aligned to Project 37 generic layer routes.
• The live Project 37 cloud runtime now exposes and accepts skills_operations and orchestration_events through the generated generic layer routes.
• Project 19 live governance records have been refreshed to match the current runtime delivery state.
• The deployed ACA kernel-engine runtime now returns 200 OK for POST /workflows/skill-promotion after promotion of image 20260317-s71-schemafix.
• Focused support-module coverage now fully exercises orchestration_event_schema.py and key_vault.py, closing the previously documented gaps in those modules.
• Kernel runtime settings, workflow persistence, audit access, and GitHub Actions callbacks now share a central runtime contract instead of route-local placeholders.
• JWT validation is now settings-driven for live mode, while mock auth remains limited to development/test mode.
• Signal emission is now wired through the Cosmos wrapper instead of advertising immutable storage while buffering only in memory.
• /ready now reports the actual storage mode and blocks production startup when storage, auth, CORS, or data-model write prerequisites are missing.
• The next active governance step is the Project 19 change-enablement packet executing the approved API-first pilot-wave model.
• The approved operating boundary is API-first and paperless by default, with governance markdown and Copilot memory files retained as disk-authoritative exceptions.
• A nested Veritas audit confirmed that the current active Project 19 rollout intent is already represented in the live data model; remaining WS-06/MVP future concepts in older repo artifacts are historical or deferred residue, not missing active backlog.
• Legacy MVP, Session 70, and sprint-config artifacts have now been explicitly reclassified as historical planning snapshots so they no longer present as active execution packets.
• Lower-priority Session 69, mission-plan, and .eva planning snapshots have also now been marked non-authoritative so the remaining residue is mostly archival rather than operationally confusing.

Local development still permits in-memory storage and mock auth, but those paths are now explicit development-only behavior. Production mode is fail-closed and requires real JWT configuration, non-wildcard CORS, a data-model admin token, and reachable persistent storage.

Scope boundary (as of Feb 23, 2026): The Machine Trust Index (MTI) computation specification ? subscores, formulas, weights, trust bands, allowed-actions matrix, and the Trust Service OpenAPI contract ? has been separated into its own project: 47-eva-mti. The Decision Engine in this project references the Trust Service as a downstream call (step 5: resolve_or_compute_trust ? POST /trust/evaluateTrust). 19-ai-gov governs the policy layer; 47-eva-mti governs the trust computation layer.

This work is grounded in two external references:

1. The Agentic State ? "Rethinking Government for the Era of Agentic AI" (Global Government Technology Centre, Berlin / Tallinn Digital Summit, October 2025).
   Authors: Luukas Ilves, Manuel Kilian. Contributors: 20+ global digital government leaders.
   Core thesis: autonomous AI agents acting on behalf of citizens and public servants must be governed with the same rigour as the humans they represent ? trust must be computed, not assumed.

2. Machine Trust Index White Paper ? NuEnergy.ai / DGC-CGN (2020).
   URL: https://dgc-cgn.org/wp-content/uploads/2020/08/NuEnergy.ai-Machine-Trust-Index-White-Paper.pdf
   Defines the theoretical model for quantifying AI trustworthiness across multiple independent dimensions.

---

Core Concept

Every actor in EVA ? human or AI ? is governed identically.
Trust is not binary. It is computed.
Governance is enforced at runtime through a Decision Engine, not just role checks.

In a system where AI agents can act autonomously on behalf of users, "has this person logged in?" is not a sufficient governance question. The right questions are: What is this actor's current trust level across identity, behaviour, compliance, evidence, security, and reliability? What does the risk profile of this request look like? What controls apply? What decision emerges from that intersection?

This project defines the governance half of that answer. 47-eva-mti defines the trust computation half.

---

Design Scope

The governance design covers five interlocking concerns:

Concern	What is defined
Governance Domains	12 domains with requirements, controls, evidence requirements, and data model impact
Actor Model	Unified principal model (HUMAN / AGENT / SERVICE / SYSTEM) with declared contracts, roles, responsibilities, and assurance profiles
Machine Trust Index (MTI)	6 subscores (ITI, BTI, CTI, ETI, STI, ARI) ? Composite MTI (0?100) ? Trust Band ? Allowed Actions
Decision Engine	9-step runtime pipeline: validate ? catalog ? profiles ? hard-stops ? MTI ? controls ? thresholds ? decision ? audit
API + Data Contracts	Full OpenAPI 3.0 surface for Trust Service (/evaluateTrust, /getDecision, /signal) + Cosmos container schemas

---

Project Scope After MTI Split (Feb 23, 2026)

19-ai-gov covers governance policy design:

Concern	Specs here
Governance objects	EVA-AI-Governance-Plane.md
Unified Actor Model	EVA-Actor-Governance.md
12 Governance Domains	Ai.Gov-governance-domains.md
Decision Engine pipeline (11 steps)	eva-decision-engine-spec.md
Context Envelope schema	eva-decision-engine-spec.md ?Context Envelope
Governance Cosmos containers (11 of 12)	eva-api-n-cosmos-container.md
GC AI policy alignment	EVA-AIatGov.md, EVA-AI-State.md

Trust computation design lives in 47-eva-mti (MTI formulas, subscores, Trust Service API).

---

D³PDCA Implementation Roadmap

New as of March 13, 2026: This project now serves as the implementation authority for deploying D³PDCA (Discover-Define-Plan-Do-Check-Act with continuous Re-Discovery) across the EVA workspace.

Quick Links

Document	Purpose
D³PDCA Master Plan	Complete 7-phase roadmap (25-40 days)
Phase A: New APIs	Register L122-L129 (5-7 days, ready to start)
Phase B: Screens UI	Generate 40 UI components (2-3 days, blocked on A)
Implementation Index	Navigation guide + quick start

Implementation Scope

Phase	What	Projects	Days	Status
A	Register 8 new layers (L122-L129) + API endpoints	37	5-7	✅ Ready
B	Fix screen generator + generate D³PDCA screens	30, 37	2-3	🔒 Blocked
C	Create 2 new Cosmos containers + routing	37, 22	3-5	🔒 Blocked
D	Control Plane dashboard (React UI)	40	5-10	🔒 Blocked
E	APIM deployment in MarcoSub + policies	17, 22	5-7	🔒 Blocked
F	Auth/security integration	17, 28	3-5	🔒 Blocked
G	Documentation refresh across workspace	All	2-3	🔒 Blocked

Total: 25-40 days, $101-178/mo additional Azure cost (ROI: $50K+ compliance value)

---

Specification Index

Governance Specifications

Location: docs/governance-specs/

File	Description	Status
Ai.Gov-governance-domains.md	12 governance domains with requirements, controls, evidence	[DONE]
EVA-Actor-Governance.md	Unified Actor Model (HUMAN/AGENT/SERVICE/SYSTEM)	[DONE]
EVA-AI-Governance-Plane.md	Governance object model (policies, controls, profiles)	[DONE]
eva-governance-domain-catalog.json	Machine-readable domain catalog (JSON)	[DONE]
EVA-Governance-Domain-Catalog.yaml	Machine-readable domain catalog (YAML)	[DONE]

Architecture Specifications

Location: docs/architecture/

File	Description	Status
eva-decision-engine-spec.md	11-step Decision Engine pipeline	[DONE]
eva-api-n-cosmos-container.md	Governance API + Cosmos schemas (11 containers)	[DONE]
EVA-Machine-trust-Index.md	MTI concept and rationale (authoritative in 47-eva-mti)	[DONE]
eva-mti-actions-matrix.md	Trust band → allowed actions matrix	[DONE]
eva-mti-compute-specs.md	MTI computation specs (subscores, weights, decay)	[DONE]
eva-mti-scope.md	ITI/BTI/CTI/ETI/STI/ARI definitions	[DONE]
eva-mti-trust-service-api.md	OpenAPI 3.0 contract for Trust Service	[DONE]

Compliance & Policy

Location: docs/compliance/

File	Description	Status
EVA-AIatGov.md	AI at Gov strategy alignment	[DONE]
EVA-AI-State.md	Summary of The Agentic State paper	[DONE]
EVA-State-Paper.md	Position paper: From RAG to Agentic Government	[DONE]
takeaways_Agentic_State_paper.md	12 functional layers mapped to EVA	[DONE]

Implementation Phases

Location: docs/implementation-phases/

See Implementation Index for complete phase documentation.

---

Specification Index (Legacy — Pre-Reorganization)

File	What it defines
EVA-AI-Governance-Plane.md	Governance objects (policies, controls, assurance profiles, decision gates, exceptions, evidence, audit), context envelope schema, governance catalog relationships
EVA-Actor-Governance.md	Unified Actor Model ? how any principal (human or AI) is represented, governed, and evaluated identically; agent contract model
eva-decision-engine-spec.md	The full 11-step Decision Engine pipeline in YAML spec format ? inputs, processing per step, outputs; calls Trust Service at step 5
eva-api-n-cosmos-container.md	Governance API examples + Cosmos container schema for governance objects (11 containers; actor_trust_scores moves to 47-eva-mti)
Ai.Gov-governance-domains.md	All 12 governance domains with requirements, controls, evidence, and data model impact
EVA-AIatGov.md	AI at Gov strategy alignment ? how this design connects to Government of Canada AI policy
EVA-AI-State.md	Summary of The Agentic State paper ? key findings relevant to EVA
takeaways_Agentic_State_paper.md	12 functional layers from The Agentic State paper mapped to EVA's architecture

MTI / Trust Specifications (moved to 47-eva-mti ? kept here as reference)

These files remain as source material. The authoritative version of each spec is now owned by 47-eva-mti.

File	What it defines	Authoritative in
EVA-Machine-trust-Index.md	MTI concept, 6 subscores, trust bands, graduated autonomy model	47-eva-mti
eva-mti-scope.md	ITI / BTI / CTI / ETI / STI / ARI ? definitions, data sources, formulas	47-eva-mti
eva-mti-actions-matrix.md	Trust band ? allowed action mapping across 9 action categories	47-eva-mti
eva-mti-compute-specs.md	Computation specifications ? inputs, weights, decay, normalization	47-eva-mti
eva-mti-trust-service-api.md	OpenAPI 3.0 contract for Trust Service (/evaluateTrust, /getActorTrust, /getDecision, /signal)	47-eva-mti

Machine-Readable Artifacts

File	Purpose
eva-governance-domain-catalog.json	JSON version of all governance domains ? machine-readable for import and validation
eva-governance-domain-catalog.yaml	YAML version of the same catalog
ado-artifacts.json	ADO work item definitions for import tooling
ado-import.ps1	PowerShell script to import ADO work items from the artifacts file

---

Known Spec Quality Notes (Feb 23, 2026 Assessment)

Issue	File(s)	Impact
YAML blocks use   HTML entities instead of spaces	eva-decision-engine-spec.md, eva-mti-compute-specs.md, eva-mti-trust-service-api.md, eva-api-n-cosmos-container.md	Not parse-ready YAML ? spec is reference only; implementing teams must reformat before use
Backslash-escaped markdown (\*\*text\*\*) throughout source files	EVA-Machine-trust-Index.md, eva-mti-scope.md, Ai.Gov-governance-domains.md, others	Renders correctly in VS Code, may render oddly in other viewers
Pipeline step count: README/PLAN say "9 steps", YAML spec enumerates 11	eva-decision-engine-spec.md	Updated to 11 in all governance docs ? steps are: validate, load_catalog, select_profiles, evaluate_hard_stops, resolve_trust, evaluate_controls, apply_thresholds, aggregate_decision, generate_obligations, emit_audit, return_response
EVA-State-Paper.md contains a scaffolding prompt, not a paper	EVA-State-Paper.md	Incomplete artifact ? paper content was never generated

---

Governance Domain Catalog

The catalog defines all 12 governance domains applicable to EVA. Each domain declares: requirements, controls, evidence, data model impact. Machine-readable versions: eva-governance-domain-catalog.json / .yaml.

#	Domain	Key Controls
1	Privacy & Data Protection	Redaction, PII access logging, purpose limitation
2	Security & Cybersecurity	Threat detection, network zone enforcement, prompt injection
3	Accountability & Audit	Immutable audit events, evidence packs, correlation IDs
4	Fairness & Ethics	Bias monitoring, red team, fairness attestation
5	Transparency	Citations, explainability, system card publication
6	Human Oversight	HITL gates, override logging, escalation paths
7	Data Governance	Classification, retention, lineage
8	Compliance & Legal	ATIP, Treasury Board, Directive on AI
9	FinOps & Sustainability	Cost center attribution, quota enforcement
10	Change Management	Deployment gates, evidence on deploy, rollback
11	Red Team & Adversarial	Attack surface coverage, periodic re-evaluation
12	People & Training	ToU acceptance, training status, role maturity

---

Decision Engine Flow (11 Steps)

DecisionRequest (Context Envelope)
  |
  1.  Validate request (required fields, enum constraints)
  2.  Load Governance Catalog (policies, controls, profiles, hard-stops, gates)
  3.  Select Assurance Profiles (match by surface / env / data / intent)
  4.  Evaluate Hard-Stops (Privacy / Security / Legal -- MTI-independent)
  5.  Resolve or Compute MTI [calls 47-eva-mti Trust Service]
  6.  Evaluate Controls (per applicable assurance profiles)
  7.  Apply Trust Thresholds (Trust Band vs allowed-actions matrix)
  8.  Aggregate Decision: ALLOW | ALLOW_WITH_CONDITIONS | REQUIRE_HUMAN | DENY
  9.  Generate Obligations + Evidence Plan
  10. Emit Audit Events (append-only)
  11. Return DecisionResponse
  |
DecisionResponse { decision, obligations[], evidenceExpected[], appliedPolicies[],
                   appliedControls[], hardStopsTriggered[], reasons[], audit }

Hard-stops (step 4) always fire before MTI. An actor with MTI=100 still receives DENY if a privacy or legal hard-stop triggers.

---

Cosmos Containers (Governance Layer ? 11 of 12)

Container	Purpose	Owner
governance_policies	Versioned policy records	19-ai-gov
governance_controls	Controls with framework refs (ITSG-33, NIST, ATLAS)	19-ai-gov
assurance_profiles	Policy + obligation bundles per surface/env/classification	19-ai-gov
decision_gates	Named gates with trigger selectors and enforcement modes	19-ai-gov
hard_stops	MTI-independent blocking rules	19-ai-gov
exceptions	Time-boxed waivers with approver records	19-ai-gov
actors	Principal registry (HUMAN/AGENT/SERVICE/SYSTEM) with contracts	19-ai-gov
governance_evaluations	Decision records (context ? outcome ? obligations ? evidence refs)	19-ai-gov
obligation_instances	Per-decision obligations with status and dueBy	19-ai-gov
evidence_artifacts	Immutable evidence packs with SHA-256 hash	19-ai-gov
audit_events	Append-only governance event log	19-ai-gov
actor_trust_scores	MTI subscores + composite per actor ? moved to 47-eva-mti	47-eva-mti

---

Related Projects

Project	Governance relationship
47-eva-mti	Trust computation design ? subscores, Trust Service API, actor_trust_scores container
37-data-model	Governance object schemas live in the data model; PUT cycle required for any schema change
33-eva-brain-v2	AGENT actor; must register service principal with declared contract; emits BTI/ARI/ETI signals
29-foundry	Candidate host for Trust Service runtime and Decision Engine runtime
40-eva-control-plane	Evidence spine; obligation fulfillment; governance runbooks; CLI gates
17-apim	Injects governance headers; calls /getDecision before forwarding Protected B+ requests
31-eva-faces	Trust Indicator UI, Governance Panel, RBAC-gated navigation
28-rbac	Role assignments feed ITI subscore

These are cross-references, not assignments. Each project team decides what to implement and when.

• evaluation-report.schema.json ? Evaluation run results
• data-card.schema.json ? Data governance descriptor