Public-release candidate, Bundle 1.0-rc.4, Independent review pending

AI Trust Graph

An open methodology for assessing AI systems using graph-based trust, authority, evidence, controls, paths, governance, and security validation.

Read the canonical methodology on GitHub See how it reasons

Synthetic Illustrative only. Graph topology alone does not prove authority, invocation, reachability or exploitability.

The problem

AI systems are no longer isolated models.

The methodology treats enterprise AI risk as a property of interconnected authority, influence and dependency.

Illustrative

Identities
Agents
Tools
Data
Models
Providers
Business actions

A topological connection is not automatically an exploitable path. Required permissions, protocols, state and preconditions must be evidenced or explicitly marked Unknown.

Source: Artifact #1 — Manifesto §2.2 (thesis), §4 (invariant); terms from its core proposition.

The reasoning chain

From what exists to what can be defended.

The Core Conceptual Model calls this chain the intellectual spine of the methodology.

Objects
Relationships
Conditions
Paths
Authority and Influence
Consequence
Controls
Evidence
Decision

Canonical reasoning questions

Theory map, Artifact #2 §0.10
Question	Concept
What exists?	Objects and system boundary.
How is it connected?	Typed directional relationships.
What must be true?	Preconditions and state.
What can happen next?	Reachability and path analysis.
Who or what can cause it?	Authority, influence and actionability.
Why does it matter?	Target criticality and consequence.
What interrupts it?	Control breakpoint and resilience.
What can we defend?	Evidence, confidence and accountable decision.

Source: stage names and order from the reasoning chain in Artifact #2 — Core Conceptual Model §0.10; questions and concepts are the same section’s theory-map table, verbatim.

Six domains

Six coordinated lenses over one graph.

The domains are coordinated assessment lenses over one graph. They are not separate products and should not maintain incompatible definitions, evidence grades or scoring assumptions. Each has twelve canonical controls and six maturity capabilities.

D1ATG-DIS-001…012
Discovery and AIBOM
Establish measurable estate, ownership, dependencies and shadow AI.
Maturity capabilities for D1 Discovery and AIBOM
1. D1.1 Discovery scope and source coverage
2. D1.2 Canonical inventory and ownership
3. D1.3 Shadow AI and unmanaged use
4. D1.4 AIBOM and dependency lineage
5. D1.5 Unknown, orphan and lifecycle management
6. D1.6 Discovery evidence and assurance
D2ATG-TRU-001…012
Trust and Privilege Paths
Model cloud and AI trust, identity inheritance and attacker-relevant paths.
Maturity capabilities for D2 Trust and Privilege Paths
1. D2.1 Trust relationship representation
2. D2.2 Identity and privilege path analysis
3. D2.3 Boundary and provider trust
4. D2.4 Path identification and prioritization
5. D2.5 Control breakpoint analysis
6. D2.6 Trust graph quality and governance
D3ATG-AUT-001…012
Authority Governance
Define and review effective access, inference, approval and action.
Maturity capabilities for D3 Authority Governance
1. D3.1 Authority inventory and taxonomy
2. D3.2 Delegation and identity context
3. D3.3 Human approval and oversight
4. D3.4 Authority amplification control
5. D3.5 Revocation and containment
6. D3.6 Authority decision governance
D4ATG-VAL-001…012
AI Security Validation
Test architecture and controls against realistic scenarios.
Maturity capabilities for D4 AI Security Validation
1. D4.1 Validation strategy and scope
2. D4.2 Threat modeling and path hypotheses
3. D4.3 Rules of engagement and safety
4. D4.4 Control effectiveness testing
5. D4.5 Finding quality and closure
6. D4.6 Validation assurance and independence
D5ATG-GOV-001…012
AI Governance and Assurance
Connect ownership, risk tier, policy, obligations and evidence.
Maturity capabilities for D5 AI Governance and Assurance
1. D5.1 Strategy, policy and risk appetite
2. D5.2 Use-case intake and tiering
3. D5.3 Decision rights and accountability
4. D5.4 Applicability and obligations
5. D5.5 Exceptions and risk acceptance
6. D5.6 Assurance, reporting and literacy
D6ATG-RES-001…012
Operational Resilience
Prepare for failure, compromise, containment and recovery.
Maturity capabilities for D6 Operational Resilience
1. D6.1 Observability and attribution
2. D6.2 Detection and triage
3. D6.3 Containment and kill mechanisms
4. D6.4 Recovery, rollback and compensation
5. D6.5 Incident reconstruction and evidence
6. D6.6 Exercises, learning and resilience governance

Source: purposes from Artifact #2 §8.1; capabilities from Artifact #3 — Maturity Model; control IDs from Artifact #5 — Master Control Library.

Authority

Access is not authority.

Each of these is a separate claim. Each needs its own evidence, and none is silently inferred from another.

Can connect
Can authenticate
Can access
Can invoke
Can modify
Can transact

Illustration of distinct assertions only — not a canonical sequence, ladder or state machine.

The capability definition, its network reachability, granted authority and actual invocation are different concepts and require different relationships.
Separation rule — Artifact #2 §3.6

Canonical authority classes

Observe
Read
Retrieve
Infer
Recommend
Approve
Execute
Modify
Delete
Disclose
Transact

Authority classes describe the kind of consequence an entity can cause. They are not maturity levels and should not be ranked without considering target, scope, conditions and criticality.

Source: Artifact #2 §5.2

Evidence-bounded conclusions

UNKNOWN stays UNKNOWN.

Insufficient evidence does not silently become a favourable — or an adverse — conclusion. UNKNOWN remains visible until sufficient evidence and accountable review resolve the material assertion.

UNKNOWNis notSafe
UNKNOWNis notFailed
UNKNOWNis notZero risk
UNKNOWNis notN/A

UNKNOWN is not Not Tested.

They are distinct non-numeric result states with different meanings.

UNKNOWN: The material state remains unresolved because evidence is absent, insufficient or materially conflicting.
Numeric treatment No numeric value.
Reporting treatment Included in uncertainty and evidence-gap counts.
Not Tested: Testing required for a stronger conclusion was not performed.
Numeric treatment No numeric value for effectiveness.
Reporting treatment May retain a design score if separately supported.

Neither may be silently converted into a fabricated effectiveness result. Evidence grade E0 (no evidence) can support either, according to context: The only defensible conclusion is UNKNOWN or Not Tested.

Source: meanings from Artifact #6 — Evidence Model §0.5, §1.1; numeric and reporting treatment from Artifact #4 — Scoring Framework §0.5.

UNKNOWN is not zero, weak, safe or effective.
Invariant SC-INV-01 — Artifact #4 — Scoring Framework

Distinct non-numeric result states

Not Assessed
UNKNOWN
Inconclusive
Not Tested
Not Applicable

Each state has its own numeric and reporting treatment. They must never be silently collapsed into one another, into a score, or into a pass/fail. AI Trust Graph deliberately produces no single overall trust score.

Source: Artifact #4 §0.5

Control breakpoints

Where can a material path be interrupted?

A control breakpoint is a node, relationship or boundary where an effective control can materially stop, constrain, detect or contain a path. Alternate and residual paths must still be checked.

Illustrate an effective control that can…StopConstrainDetectContain

Human
Agent
Identity
Tool (control breakpoint between Tool and API)
API
Sensitive action

Stop. Progression past the breakpoint is blocked.

Constrain. Progression continues only within narrower scope or conditions.

Detect. Progression is observed and raises a signal for response.

Contain. Downstream effect is isolated or limited.

Synthetic Plain-language illustration of where an effective control can stop, constrain, detect or contain progression. It is not a real system, and it does not show that any step is authorized, invoked, reachable or exploitable.

Path validation state

Candidate
Topological
Plausible
Validated
Exploitable
Controlled
Invalidated

Path role

Primary
Alternate
Residual

Validation state and role are orthogonal dimensions and are not collapsed into one state machine.

Source: Artifact #2 §1.8, §6.3, §6.6

Evidence model

Six grades of evidentiary support.

Grade measures evidentiary support, not desirability, safety or compliance.

E0 — No evidence
Meaning
No source is available or the supplied item cannot be linked to the assertion.
What it can support
The only defensible conclusion is UNKNOWN or Not Tested. E0 is not evidence that the control is absent.
E1 — Inference or uncorroborated signal
Meaning
A hypothesis is derived from incomplete, indirect, automated or unverified information.
What it can support
E1 can prioritize investigation and create candidate graph assertions, but cannot establish implementation or operating effectiveness.
E2 — Attestation
Meaning
An accountable person states that a condition or practice exists.
What it can support
E2 supports claimed practice and context. It is vulnerable to memory, interpretation, incentives and incomplete visibility and therefore needs corroboration for material technical claims.
E3 — Approved documentary evidence
Meaning
A governed document records approved design, policy, architecture, procedure, contract or decision.
What it can support
E3 can support design intent and governance state. It does not alone prove actual configuration, runtime behavior or sustained operation.
E4 — Corroborated technical evidence
Meaning
Technical evidence from authoritative sources is supported by an independent source, consistent observation or reproducible inspection.
What it can support
E4 can support implementation or operation within observed scope when current, relevant and representative.
E5 — Direct technical and representative evidence
Meaning
Current direct technical evidence is combined with a representative test or operating record that demonstrates the claimed behavior under stated conditions.
What it can support
E5 may support verified effectiveness or adaptive operation, but only for the tested scope, period and conditions.

Grade is not sufficiency. Meeting the grade minimum is necessary but not sufficient; relevance, scope, currentness, representativeness, conflict status and an approved reviewer decision still govern.
A high grade can confirm an adverse state. A low grade can weakly suggest a favorable state.
Grade is its own quantity. Never add evidence grade to control effectiveness, severity, maturity or risk as if they were the same quantity.

Source: grade names, meanings and supported claims quoted from Artifact #6 — Evidence Model §1.1–§1.8; the full sufficiency rules are deliberately not summarized here.

Assessment lifecycle

Thirteen controlled phases.

Separate from the reasoning chain: Artifact #7 governs the controlled fieldwork lifecycle and gates without redefining upstream semantics.

The lifecycle contains thirteen controlled phases. Phases may iterate, but required gates cannot be skipped merely because information was available earlier.

Phase 1 Initiate
Phase 2 Scope
Phase 3 Discover
Phase 4 Model
Phase 5 Evidence
Phase 6 Controls
Phase 7 Paths
Phase 8 Maturity
Phase 9 Scoring
Phase 10 Findings
Phase 11 Decisions
Phase 12 Report
Phase 13 Reassess

Phase outcomes and gates

Primary outcome of each phase (§0.11)
Phase	Primary outcome
1 Initiate	Approved charter and decision purpose.
2 Scope	Versioned boundary and population.
3 Discover	Measured estate and blind spots.
4 Model	Reviewed graph snapshot.
5 Evidence	Graded and traceable evidence set.
6 Controls	Applicability and control results.
7 Paths	Validated material path portfolio.
8 Maturity	Six-domain capability profile.
9 Scoring	Transparent scorecards and coverage.
10 Findings	Evidence-linked gaps and remediation objectives.
11 Decisions	Approved gates, exceptions and dispositions.
12 Report	Quality-reviewed decision package.
13 Reassess	Trigger-based new or updated run.

Each phase has entry conditions, mandatory activities, outputs, decision gates and quality checks. An incomplete phase may proceed only under an approved limitation that does not invalidate downstream work.

Gate tests (§0.12)
Gate test	Rule
Completeness	Mandatory outputs exist or limitations are explicitly approved.
Evidence	Assertions meet artifact-specific sufficiency.
Safety	Collection and testing remained within authorization.
Traceability	Inputs and decisions can be reconstructed.
Critical gates	Open conditions are applied before progression.
Quality	Required reviewer has challenged the work.
Decision	Named authority accepts the next phase or bounded limitation.

Assessment types

Listed in Artifact #7 order; the order implies no priority.

Baseline assessment
Periodic reassessment
Material-change assessment
High-impact deep dive
Incident-driven assessment
Third-party and provider assessment
Portfolio assessment
Pre-deployment readiness assessment
Continuous or event-driven assessment
Regulatory or obligation-focused assessment

Assessment type definitions

Baseline assessment: Establish the first defensible view of scope, graph, controls, evidence, maturity and material paths.
Periodic reassessment: Re-evaluate a stable scope at an approved cadence while preserving comparable prior results.
Material-change assessment: Assess the consequences of model, prompt, data, tool, identity, provider, autonomy, geography, purpose or architecture change.
High-impact deep dive: Increase evidence, testing, independence and path analysis for systems with significant consequence or authority.
Incident-driven assessment: Reconstruct changed facts, affected paths, control failures and recovery evidence after an event.
Third-party and provider assessment: Examine service-specific responsibility, configuration, evidence access, data handling, resilience and concentration.
Portfolio assessment: Profile multiple use cases or systems while preserving materially different populations and avoiding misleading averages.
Pre-deployment readiness assessment: Determine whether evidence, controls, testing, approvals and containment are sufficient for the requested release.
Continuous or event-driven assessment: Use approved automated signals and triggers to refresh evidence and initiate human review of material change.
Regulatory or obligation-focused assessment: Evaluate fact-specific obligations and related controls without representing framework mapping as compliance proof.

Source: phases, outcomes and iteration rule from Artifact #7 — Assessment Methodology §0.11; gate tests from §0.12; assessment types from §1.1–§1.10; the role of Artifact #7 from METHODOLOGY_MANIFEST §1.

The structure that carries the model

Domains: 6
Canonical controls: 72
Maturity capabilities: 36
Maturity levels: M1–M5
Evidence grades: E0–E5

Maturity is cumulative, evidence-gated and not an average of control scores.

Canonical source

Read the methodology itself.

This website explains; the artifacts on GitHub decide. Listed in the recommended reading order from the Methodology Manifest.

Artifact #13 · Phase 2 companionNon-normativeReference Graph Schema and Illustrative Query LibraryIllustrative property-graph schema and GQL-style query patterns. Informative only; carries no conformance weight.

Public review

This methodology is meant to be challenged.

Challenge the assumptions.
Examine the graph semantics.
Inspect the evidence rules.
Report inconsistencies.
Contribute through GitHub.

Submit a finding Repository