Dashboard / AI Governance

Forge Comply · ForgeComply360

AI Governance & Continuous Assurance

In progress · Days 1–2 merged · Day 3 next

A native operating capability inside Forge Comply. It governs AI systems from inventory through continuous assurance by extending the existing platform, not by standing up a separate GRC stack.

/projects/ai-governance/

Program snapshot

Plan of record dated October 6, 2026. The live ForgeComply360 repository remains authoritative for migrations, APIs, feature flags, and security behavior. This page records the program model and release criteria.

Core question
Can this AI system operate within the authority, controls, and boundaries established for it, and can Forge continuously prove that those conditions remain true?
Sprint shape
Days 1–5 establish feature completeness. Day 6 joins the existing Beta program. Day 7 is release certification, security regression, demo readiness, and final GO / NO-GO.
Repository
Bjay0727-jay/ForgeComply360
Feature flag
aiGovernance is off by default and is enabled deliberately for a Beta tenant.
Recorded main
6e29cbe8f360b296a00488e4628458cec7689832 at the October 6 snapshot.

Working authority. Do not treat this portal as a substitute for the repository. Rebaseline each day from current main.

Seven-day sprint

Each day has an implementation gate and a merge gate. The next day starts from clean current main, never from the previous feature branch.

Status labels are from the October 6, 2026 plan snapshot.
Day Status Title Exit condition
1 Merged Architecture freeze + Forge Trust Graph Context and dependency foundation merged. PR #1250. Migration migrate-252-ai-trust-graph.
2 Merged Classification + Governance Profile + Control Envelope Deterministic governance treatment and boundaries merged. PR #1252. Migration migrate-253-ai-governance-classification-envelope. Classifier ai-gov-classify-v1.
3 Next Assurance lifecycle + GRC integration + validation ASSURE stage works using real Forge GRC records. No AI-specific shadow engines.
4 Planned Operational authorization + material change + continuous assurance Human authorization and the continuous reassessment loop work.
5 Planned Trust Posture + Command Center + reports Feature complete.
6 Planned Beta integration + golden customer simulation Beta integrated through the BETA-AI-001 journey.
7 Planned Beta certification + demo + release Beta certified. Final GO / NO-GO issued.

Definition of done

Feature complete

End of Day 5. Register, contextualize, classify, bound, assure, authorize, monitor change, explain posture, and report — using existing Forge records.

Beta ready

End of Day 7. Golden scenario, tenant and business-unit isolation, RBAC, separation of duties, feedback instruments, security regression, and a demo package.

Day 3 focus

Lifecycle through ASSURE and AUTHORIZATION_REQUIRED. Link real risks, controls, evidence, findings, and POA&M. Ready for authorization review is a readiness state only.

Lifecycle and gates

Selective operating model: one reusable assurance pattern. AI Governance is its first explicit application.

Stages and where the plan says they are built.
Stage Purpose Built in
Register Know what AI exists and who owns it. Existing AI Registry
Contextualize Understand dependencies, data, people, and environment. Day 1 · merged
Classify Determine governance treatment. Day 2 · merged
Bound Define the maximum acceptable operating boundary. Day 2 · merged
Assure Prove required controls and validations. Day 3 · next
Authorize Human decision to permit operation. Day 4
Operate Run only inside approved runtime boundaries. Existing runtime safety
Observe Collect operating facts. Day 4
Adapt Evaluate material change and reassessment. Day 4
Improve / Retire Remediate or responsibly retire. Days 3–4

Five continuous governance gates

  • Registration. Identity, purpose, owner, and dependencies are known. Otherwise do not advance.
  • Governance. The system is contextualized, classified, and bounded. Otherwise do not complete assurance.
  • Assurance. Controls, evidence, and validations support operation. Otherwise do not present it as ready.
  • Authorization. An authorized human has made the operational decision. Otherwise there is no operating authority.
  • Continuous. Material facts since the authorization basis are reviewed. Otherwise reassess, revalidate, reauthorize, suspend, or retire.

Hard-gate principle. Hard governance gates override aggregate percentages and maturity scores. A failed human-oversight or prohibited-autonomy condition cannot be offset by other high indicators.

Product and runtime boundaries

Forge Comply

System of record for inventory, Trust Graph, profiles, envelopes, risk, evidence, findings, authorization, material change, and reports.

AI Center of Excellence

Standards, methods, training, and reference patterns. It must not overwrite customer governance state, grant runtime authority, accept risk, or authorize an AI system.

Framework mapping

ITIL AI Governance, NIST AI RMF, EU AI Act, 800-53, and ISO mappings are inputs. No mapping grants operational authority or marks compliance by itself.

Control Envelope

The envelope can only maintain or lower authority. It cannot increase autonomy, add tool scopes, activate capability packs, bypass MCP controls, or authorize operation. Enforcement is deny-only and off unless AI_CONTROL_ENVELOPE_ENFORCEMENT is enabled. Agent autonomy maximum remains 2. Level 5 autonomy stays banned.

Envelope facets recorded on October 6: identity verified in preflight; action/autonomy deny-only when the flag is on; termination partial by reference to existing switches; data, knowledge, model, tool, financial, human approval, time, and escalation still declared only.

Release acceptance and non-negotiables

All twelve categories must pass for a GO decision on Day 7.

  • Functional lifecycle through supported UI and API.
  • Human accountability, deterministic classification, hard gates, and versioned history.
  • Real controls, risk, evidence, findings, POA&M, and validation.
  • Human-only operating decision tied to a defined assurance basis.
  • Material change can require revalidation, reauthorization, suspension, or retirement.
  • Tenant, business-unit, RBAC, separation-of-duties, and autonomy protections.
  • Auditable authoritative changes and denials.
  • Beta customer completes the workflow without database edits.
  • Required Beta reports, green platform regression, controlled migrations and flags, and a formal GO / NO-GO.

Golden scenario

BETA-AI-001, Enterprise / Healthcare AI Assistant, exercises the full Forge lifecycle without a real customer environment. Most validations pass. A tool-permission validation fails and becomes a real finding. Authorization is Authorized With Conditions or Limited Pilot. A later model or tool change triggers impact analysis and revalidation.

Security rule. No agent, model, or service actor can issue authoritative operational authorization. Trust Graph relationships are descriptive facts and never runtime permission.

CanaPoint AI Assurance runbook

Companion architecture and implementation runbook prepared October 6, 2026 for a native CanaPoint AI Assurance layer in the existing ForgeComply360 / CanaPoint application. It is a separate phase sequence from the seven-day governance sprint above. AI may analyze, recommend, draft, and explain. Authoritative state changes stay with deterministic CanaPoint services and authorized humans.

Four capabilities

  • Compliance evidence analysis. Type, freshness, control relevance, support level, gaps, and follow-up.
  • Control assessment assistance. Advisory determination with reasons and citations for assessor review.
  • Report generation. Deterministic metrics remain the facts. AI drafts narrative only.
  • Risk analysis. Scores stay deterministic. AI explains contributors and suggests treatment.

Boundaries that do not move

  • AI does not finally mark a control implemented or effective outside the authorized workflow.
  • AI does not accept risk, close POA&M items, or issue an authorization.
  • AI does not bypass RBAC, organization scope, system assignment, or dataset permissions.
  • Retrieval happens only after authorization filtering. Retrieved text is untrusted.
  • Report metrics are never invented. Material inferences get a provenance record.

AI-ASSURE phases

AI-ASSURE-0

Architecture freeze and threat model. Docs only. No runtime code, migration, or new Cloudflare resources. This is the required starting point.

AI-ASSURE-1

AI Gateway, model broker, fail-closed policy, and provenance tables. No business use cases yet.

AI-ASSURE-2

Authorized retrieval. Organization and system scope come from the session. Cross-tenant retrieval must fail.

AI-ASSURE-3

Evidence Intelligence. Structured, cited, reviewable analysis. No control-status writes.

AI-ASSURE-4

Control Assessment Assistant. Reviewer acceptance uses the existing authorized write path.

AI-ASSURE-5

Risk Intelligence. Official scores stay deterministic. Accept Risk remains a human action.

AI-ASSURE-6

Governed report narratives over verified facts and snapshots. No raw query authority for the model.

AI-ASSURE-7

Evaluation, adversarial tests, and beta certification on an exact SHA. Any failed P0 tenant, authorization, provenance, citation, or mutation case blocks beta.

Federal path. Keep a provider abstraction for a later GovCloud runtime. Do not provision that path as part of this portal or as unpaid preparation. A federal profile must fail closed if a commercial AI endpoint is configured.

Commercial platform named in the runbook: Cloudflare Workers, D1, R2, KV, Workers AI, AI Gateway, and Vectorize. Resource creation stays inside the product repository’s phase gates. This portal does not create those resources.

Back to dashboard ForgeScan Phase 1