Give your AI an
accountable starting point.

DFD is building an enterprise AI data-assurance gateway. Inspect documents before indexing, record policy decisions as verifiable evidence, and check eligibility when your AI retrieves them.

Discuss a pilot Explore the approach

Customer-operated architecture
Explicit inspection coverage
Post-quantum evidence design

ILLUSTRATIVE WORKFLOW

From source to accountable use.

DOCUMENT SOURCES

PDF

policy-2026.pdfversion 8

PDF

inv-88213.pdfversion 2

DOCX

vendor-terms.docxversion 3

Immutable source versions

INSPECTION + POLICY

DFD gatewayFindings → policy → evidence

POLICY OUTCOMES

allowpolicy-2026.pdf

coverage: configured checks complete
findings: no blocking findings
evidence: source + transforms + chunks

denyvendor-terms.docx

finding: instruction-like hidden text
reason: INJ-HIDDEN-TEXT
policy: configured to block this finding

Proposed behavior · synthetic examples · not a live scan

allowreviewdenyabstain

A finding becomes a decision under your policy. A signature records that decision; it does not prove a document is true.

CONTROL THE INPUT. KEEP THE EVIDENCE.

WITHIN YOUR EXISTING DATA FLOW

Your sources. Your stack. A deliberate control boundary.

The first pilot connects one intake path, one controlled index and your source-authorization resolver. Start with customer-pushed files or versioned S3 objects; expand from measured needs.

Your sources
DFD gateway
Your index
Eligibility check
Your AI application

A shared architecture for platform, security and data teams across industries.

01 / THE INSPECTION MODEL

Four layers of evidence. Coverage you can see.

Configured checks produce findings. Your policy determines what proceeds. Skipped, unsupported and incomplete checks stay visible.

WHERE DID THIS COME FROM?

Provenance & source identity

Bind the assessment to a source and version. Validate supported signatures where available; keep missing, invalid and indeterminate provenance distinct.

WHAT IS ACTUALLY IN THE FILE?

Document structure

Surface hidden content, extraction discrepancies and suspicious container features within supported formats. Record where inspection was incomplete.

WHAT IS THE CONTENT ASKING?

Content & injection risk

Screen for instruction-like content and configured risk patterns. Route uncertainty to review or abstention; an uncompleted scan is never a pass.

DOES THE RECORD AGREE?

Reference consistency

Compare selected business fields with customer-approved records. Differences become findings for review; reference data can still be incomplete or wrong.

02 / BEYOND THE SCAN

Record the decision. Keep control after indexing.

The useful question is more than “did this file pass?” It is “can this person use this exact content, for this purpose, now?”

Explicit outcomes. Visible reasons.

Allow, review, deny or abstain—with reason codes and inspection coverage. Critical conditions are evaluated by policy, not averaged into a trust score.

Evidence bound to the content.

The proposed signed assessment binds source version, processing steps, policy and chunk manifest. Export and independent verification are part of the planned contract.

Eligibility at the point of use.

Check authenticated identity, source permissions, accepted evidence and lifecycle state under an agreed freshness policy. Measure revocation response in the pilot.

assessment.json

PROPOSED EVIDENCE MODEL

01{
02  "subject": "policy-2026.pdf",
03  "source_version": "8",
04  "coverage": "configured checks complete",
05  "policy": "v3.2",
06  "decision": "allow",
07  "reason_codes": [],
08  "transforms": ["extract", "chunk"],
09  "manifest_digest": "sha384:…",
10  "profile": "dual-evidence-v1",
11  "signatures": [
12    "ECDSA P-256",
13    "ML-DSA-65"
14  ]
15}

DATA FLOW DEFENSE

Abbreviated illustration. Signature verification alone does not establish current access or key trust.

Evidence describes origin, checks and decisions. It does not establish that every source claim is true.

03 / THE INTEGRATION

Make the control boundary explicit.

Connect inspection, controlled publication and retrieval checks around one real document workflow. Agree supported data, authorization and failure behavior before enforcement.

01Inspect source version
02Record findings + decision
03Publish bound content
04Recheck before use

workflow.pyCONCEPTUAL PSEUDOCODE

1# Proposed workflow — pseudocode, not a released SDK
2
3assessment = inspect(immutable_source_version)
4record(assessment.coverage, assessment.findings)
5
6if policy_accepts(assessment):
7    publish(assessment, bound_chunk_manifest)
8
9principal = authenticate(request)
10candidates = index.retrieve(question)
11
12# The trusted adapter checks the exact content it releases.
13with trusted_adapter(principal, purpose) as adapter:
14    eligible = adapter.recheck(candidates)
15    adapter.release_verified_bytes(eligible)

Proposed API flow. APIs and SDKs are in development; this example is not executable.

One intake pathOne controlled indexExact-byte binding

04 / SECURITY BY EXPLICIT CONTRACT

Designed for scrutiny. Including the cryptography.

Post-quantum protection belongs to specific assets and paths. It is not a substitute for access control or content inspection.

EVIDENCE INTEGRITY

Post-quantum evidence

Proposed ML-DSA-65 and ECDSA P-256 signatures over the same payload. Interoperability and independent cryptographic review are pilot gates.

CONFIDENTIALITY IN TRANSIT

Protected transport

Hybrid ML-KEM TLS is planned for supported, controlled connections. Coverage and actual negotiation are verified per hop.

OPERATIONAL CONTROL

Your environment

A customer-operated data plane, scoped support access and agreed retention. The deployment contract defines the boundary.

INDEPENDENT REVIEW

Exportable records

Reason codes, policy versions and evidence available for authorized review. Retention and deletion are agreed for each deployment.

05 / BUILD WITH US

One real workflow. A measurable next step.

Scope a six-to-eight-week design-partner engagement around a document-based AI assistant, starting after access, procurement and customer staffing are agreed.

FROM THREAT MODEL TO GO / NO-GO

The design-partner pilot

For enterprise platform, security and data teams across industries. Scope, deployment and commercial terms are agreed together.

Discuss your workflow

01Workflow & threat model
02Shadow assessment
03Evidence export
04Measured integration
05Go / no-go review

PROPOSED PACKAGING · SHAPED BY PILOT NEEDS

Sandbox

Planned evaluation

Public and synthetic fixtures, bounded inspection and local evidence verification. Not yet publicly available.

Team

One deployment

A defined set of pipelines, inspection capacity, evidence retention and standard support.

Enterprise

Broader control

Multiple pipelines, organization-level policies, residency requirements and negotiated deployment support.

Packaging is proposed. Availability and commercial terms will follow validated pilot needs.

LET’S DEFINE THE FIRST WORKFLOW

Bring us the data flow your team needs to trust.

Where do documents enter your AI system? Who owns access? What does your security review need to prove?

Or email the DFD team directlyinfo@dfd.io

Give your AI anaccountable starting point.