Reference architecture: Current capabilities and planned integrations are qualified by maturity and boundary. Request a walkthrough
Public reference architecture — version 0.1

From enterprise evidence to verifiable assurance

DigiTrust is verifiable trust infrastructure for the AI era.

This public architecture explains how the reference implementation preserves evidence identity and provenance, verifies quality and claim support deterministically, governs agent authority, and binds trust decisions to signed assurance outputs.

Request an architecture walkthrough Return to platform overview

Reference implementation, design-partner stage, limited onboarding, and production hardening in progress. This page does not claim general availability or independent certification.

Trust chain

Evidence → Provenance → Verification → Trust Decision → Assurance Output

Each stage preserves enough identity and context for a reviewer to understand what was evaluated, which rules applied, what failed, and which limitations remain.

01EvidenceAuthorized source records, context, identity, classification, and integrity metadata.
02ProvenanceCase-scoped lineage, Evidence Events, Tool Invocations, lifecycle, and chain of custody.
03VerificationDeterministic policy, claim support, quality dimensions, authority, and separation of duties.
04Trust decisionSupported or unsupported claims, hard failures, findings, scores, and remediation guidance.
05Assurance outputSigned reference reports, audit exports, summaries, and governed Evidence Packets.
Platform layers

Three layers, one inspectable trust boundary

Evidence Packets remain an important outcome, while the platform boundary extends from durable evidence through deterministic verification to multiple assurance outputs.

Evidence Fabric

Tenant- and case-scoped services register immutable artifact metadata, link collection events and governed tool invocations, derive supersession and revocation state, project minimized provenance, and produce signed audit exports. Raw secrets, credentials, tool parameters, and customer evidence bytes stay outside public outputs.

Verification Engine

Strict policy, claim, and plan contracts bind exact identities and input snapshots. Deterministic rules assess eight evidence-quality dimensions, claim support, verifier authority, separation of duties, stale or revoked evidence, and signed-report integrity without LLM calls or fuzzy semantic inference.

Assurance Outputs

Verification reports, audit exports, findings, remediation guidance, buyer-facing summaries, and Evidence Packets expose the basis, identity, evaluated inputs, decision effects, and current limitations of the assurance provided.

Trust principles

Architecture that fails visibly

DigiTrust is designed so critical trust outcomes remain explicit, attributable, and resistant to silent normalization.

Identity before interpretationTenant, case, artifact, actor, policy, plan, and output identities must agree before a trust decision is accepted.
Provenance over presenceA document's existence is insufficient; its source context, lineage, event path, and collection authority matter.
Hard failures stay hardRevocation, invalid authority, required separation-of-duties violations, snapshot drift, and unverifiable integrity cannot be downgraded by severity configuration.
Minimize disclosureAssurance outputs preserve useful evidence identity and findings without exposing raw secrets, credentials, or unnecessary customer data.
Deterministic firstExplicit metadata, evidence types, sources, control mappings, and claim criteria drive current verification decisions.
Separation of dutiesExact versioned actor identities distinguish drafting, evidence collection, verification, and approval responsibilities.
Explain every outcomeReports retain findings, remediation, formula inputs, confidence limits, and the reason a claim passed or failed.
Qualify maturityReference controls and planned integrations are described as such rather than presented as production certification.
Responsibility boundary

Deterministic verification and bounded AI assistance

Current trust outcomes do not depend on an LLM deciding whether evidence is true or semantically sufficient.

Deterministic responsibilities

  • Canonical identity, hash, signature, and chain checks
  • Artifact lifecycle and terminal replacement resolution
  • Exact provenance paths and semantic link requirements
  • Declared evidence-type, source, control, and mapping criteria
  • Freshness thresholds, evidence minimums, and scoring formulas
  • Agent authority, delegation, and separation-of-duties checks
  • Non-downgradable hard trust outcomes

Bounded AI-assisted responsibilities

  • Guide a user through approved evidence and review workflows
  • Summarize already-verified findings for a defined audience
  • Help explain remediation without changing the underlying decision
  • Operate only through governed tools and delegated authority
  • Keep public demonstrations synthetic and read-only

Future semantic analysis, if introduced, must remain separately bounded and cannot override deterministic hard failures.

Evidence quality

Eight dimensions make support inspectable

DigiTrust verifies the quality of evidence, not merely whether a document exists. Current checks use declared metadata and policy, not semantic truth inference or content-level contradiction analysis.

IntegrityAre record identity, structure, hashes, signatures, and linked histories intact?
AuthorityDid an allowed source and exact authorized verifier act within approved scope?
ProvenanceDoes a complete case-scoped path connect the artifact, declared event or invocation, and trust context?
FreshnessIs the signed collection time within the explicit threshold for its type and classification?
LifecycleIs the evidence active, stale, superseded, revoked, or replaced by a verified active terminal?
RelevanceDo declared types, sources, media, controls, and mappings match the claim's explicit criteria?
CompletenessAre required metadata fields and the minimum number of usable evidence items present?
IndependenceAre drafting and verification duties assigned to distinct, exact actor identities when required?
Security and privacy boundaries

Bind what matters. Expose only what is needed.

Reference controls demonstrate the architecture without claiming production key management, certification, or deployment maturity.

Current reference safeguards

  • Tenant- and case-scoped durable records
  • Append-only histories and canonical SHA-256 hashes
  • Demo HMAC signatures over bound identities and inputs
  • Governed tool authorization and explicit delegation scope
  • Minimized provenance and customer-safe output patterns
  • Synthetic, read-only public ChatGPT demonstration

Explicit exclusions

  • No production KMS or hardware-backed signing claim
  • No independent certification or audit opinion
  • No general production availability claim
  • No production customer evidence in the public demo
  • No guarantee that an assurance output replaces legal, audit, compliance, or procurement judgment
  • No current semantic truth or contradiction inference claim
Current maturity

Reference implementation with limited onboarding

DigiTrust currently demonstrates immutable artifact integrity, lifecycle lineage, minimized provenance, signed audit exports, governed agent and delegation checks, deterministic evidence-quality verification, and signed verification reports.

Commercial work is in design-partner and soft-launch stages. Production hardening, customer-specific integrations, operating controls, retention, and production key management require scoped validation.

Known limitations

  1. 1
    Reference persistenceSQLite demonstrates durable behavior but is not the target production data architecture.
  2. 2
    Reference signingDemo HMAC validates binding logic but is not production KMS signing or non-repudiation.
  3. 3
    Metadata verificationCurrent relevance checks explicit metadata and criteria rather than inferred semantic truth.
  4. 4
    Planned integrationsCloud reference patterns and production connectors remain subject to design and validation.
Planned reference integration

AWS Trust Verification Reference Pattern

AWS is the first planned flagship cloud reference integration. Candidate AWS evidence sources may include authorized configuration, identity, security, logging, and control-assessment records selected for a defined trust use case.

Qualification: the pattern is being prepared and is to be validated through an upcoming AWS engagement. It does not represent AWS endorsement, AWS Marketplace availability, partnership status, certification, or a production integration.

Intended validation path

  1. 1
    Collect authorized AWS evidenceDefine approved accounts, regions, services, sources, and collection authority.
  2. 2
    Preserve provenanceBind evidence to source context, collection events, governed invocations, and lifecycle.
  3. 3
    Verify quality and claim supportApply explicit policy, control mappings, evidence criteria, and hard trust outcomes.
  4. 4
    Generate signed assurance outputsProduce audience-appropriate findings and trust decisions bound to evaluated inputs.

Review the architecture against one real trust decision

Choose a workflow, evidence source, or planned cloud pattern and request a scoped walkthrough with DigiTrans.

Request a walkthrough Review pricing