EXECUTIVE SUMMARY
Most of what an enterprise knows lives in documents, not databases. Contracts, policies, statements, filings and lease files carry the ground truth for legal, accounting, insurance, logistics and private markets. None of it was built to be queried. That is why AI keeps stalling on document-heavy work. The failure is rarely the model’s ability to reason. It is that the data feeding the model cannot be trusted, versioned, permissioned, or checked.
Inveniam's answer is a three-layer stack. Open DGML turns document content into named, typed, source-linked elements instead of prose a model has to re-parse. Inveniam IO governs that structure as a living corpus: which version is authoritative, who may see each piece of it, what changed and when.
NVNM Chain anchors proof of origin and state so a counterparty can verify an answer without ever receiving the underlying file. Source data stays in the owner's environment throughout. Nothing moves, nothing gets copied, and nothing has to be handed to a model vendor to get value from it.
The three layers—DGML, Inveniam.io, and NVNM Chain—can be adopted independently. DGML spreads as an open format, and NVNM Chain verifies autonomously. What actually requires a commercial engagement is Inveniam.io in the middle, because governing an evolving corpus is an ongoing operational problem, not something you solve once and walk away from.
"[Information] is unverified: offering no standard framework to prove its origin, process, or state."
A document is a high-inertia artifact. Modifying it, moving it, contextualizing it, or verifying it requires deliberate effort. That friction is precisely why authoritative facts live inside documents across regulated industries—and why unstructured files remain the final class of enterprise data AI cannot yet reliably transact on.
Five properties compound the problem, and they compound each other:
It is unstructured: Sitting in PDFs rather than accessible databases.
It is stale by design: Updating only on episodic reporting cycles instead of continuously.
It is siloed: Fragmented across departments, advisers, and counterparties, each holding a different piece of the same picture.
It is unverified: Offering no standard framework to prove its origin, process, or state.
It is opaque: Decisions built on top of it cannot be reliably reconstructed later for a regulator or a court.
The core problem is universal, even if each industry phrases it differently. Legal asks which clause governs in an executed agreement. Audit asks which figure was tested against primary evidence. Insurance asks what is covered after successive policy endorsements. Private markets ask what an asset is worth and whether the valuation holds under scrutiny. Every document-heavy sector pays the same tax: manual verification, with costs scaled to the opacity of the underlying data. That is fundamentally a data-conditions problem. No level of raw model intelligence can solve it from the top down.
Documents are the hard part, not the whole problem
Most of what an institution knows already sits in systems it runs today: a warehouse, a ledger, a servicing platform, a mainframe nobody wants to touch. Legacy systems of record such as mainframes, AS/400s, on-premise SQL and file shares are authoritative and rarely going anywhere. ERP, CRM and servicing platforms, along with warehouses like Snowflake, Databricks, Redshift, Azure and Oracle, hold the structured operational half of the picture. Newer streaming pipelines, vector stores and agent memory move faster than the governance built around them. Document data, the contracts, policies, statements and filings that no query language reaches, is where Inveniam started. It is not where a real answer stops.
Inveniam IO gives a single permissioned, AI-ready view across all of it. Structured sources are connected and governed where they already sit. Document data is structured through Open DGML first. Neither one gets copied out of the systems that already hold it, because clients rarely have a pure document problem or a pure database problem. They have questions that need both answered together.
Through its products — Open DGML, Inveniam IO, and NVNM Chain — Inveniam takes documents where they already sit, turns them into source-linked, governed elements, and serves only the smallest permissioned slice of verified intelligence to externals — without ever relinquishing source custody.
Comparing the alternatives
Every route to putting AI on top of enterprise documents trades some sovereignty for speed. Before choosing one, ask whether the trade sits in the architecture, where you can inspect it, or in a contract, where you can’t.
Frontier model provider, enterprise tier. This is the fastest path to a working demo, with the strongest raw model capability behind it. The cost arrives later. The provider’s retention posture is a contractual promise no one can independently verify, and your corpus effectively becomes context inside a vendor you don’t run.
Hyperscaler AI stack. Identity and networking are already solved, and it runs inside your own cloud account with mature tooling. But the document layer is still yours to build, provenance is not a native primitive, and the architecture keeps pulling everything toward a single cloud provider.
Closed document-AI SaaS for contracts or claims. It reaches value quickly and is opinionated in genuinely useful ways. The extracted structure lives permanently in the vendor’s schema, inside their tenant, so leaving means re-extracting from scratch, and a counterparty can verify nothing without going through the vendor.
RAG over your own data lake. This is the only option with no vendor in the path, and every component is swappable. It also means you own chunking, freshness, permissions, supersession, and audit outright. That is years of engineering work, and in practice it is the actual job.
Inveniam's position sits differently: an open format, a governed control plane, an independent proof layer, and source data that stays in the client's own custody the entire time. Structure is portable under Apache 2.0. Verification runs against a public chain. Neither an eventual exit nor a counterparty's verification has to route through Inveniam at all. The first four paths above are all reasonable choices depending on what a client is optimizing for. None of them lets a counterparty check an answer without also trusting the vendor that produced it.
"Zero data retention sounds like a solution, but it is an assurance nobody can independently verify."
A closed system asks a client to trust an assurance. An open one lets a client check a fact. This difference is an important distinction in regulated work.
The closed-system failure mode has a consistent shape. A client's corpus becomes someone else's advantage, because the most valuable thing an institution owns is often the very thing it has to hand over just to get started with an AI vendor. Zero data retention sounds like a solution, but it is an assurance nobody can independently verify. There is no test that tells a kept promise apart from a broken one after the fact. A vendor's extraction schema quietly becomes the client's own schema, so leaving is never a clean migration. It is a full re-extraction, and that cost effectively prices the client's renewal before the negotiation even starts. And any counterparty receiving an answer has to trust the vendor behind it too, since accepting the number means accepting a system it never chose to rely on.
Architectural sovereignty means something more specific than a policy page. Source files never move, and only proofs traverse the network, with indexing and embedding running at the edge inside the client's own environment. Only hashes get anchored; source bytes are never written on chain, which holds checksums and evidence URIs instead. The format itself is Apache 2.0, so structure stays portable without a license negotiation, including a client's ability to walk away from Inveniam entirely. And verification does not route through Inveniam at all. A counterparty checks a public chain directly, not a vendor API and not anyone's goodwill.
Venture investor Chamath Palihapitiya made roughly this point on the All-In podcast, discussing whether the AI industry can regulate itself: flipping a zero-data-retention switch is treated across the industry as the term that is supposed to make everything fine, when there is no way to actually guarantee any of it. Trust that has to be promised is a policy. Trust that can be checked is architecture.
From source to consumption:
five stages, nothing copied
Five stages carry a document from wherever it already lives to data an agent can act on and a counterparty can check. Structured sources join in at the third stage, under the same permission model as everything else. The constant across all five is that the source itself never moves.
Source
It starts with source: documents stay in the document and contract management systems, matter files and policy files they already live in, alongside the warehouses and ledgers holding the structured half of the picture.
Structure
Next comes structure, where Open DGML turns document concepts into named, typed, source-linked elements, each carrying a pixel-precise origin back to the page it came from.
Govern
Then govern, where Inveniam IO tracks which version currently controls, what superseded what, what changed upstream, and who is allowed to see each element.
Prove
Then prove, where evidence of origin, process and state gets produced for every element and the resulting hashes get anchored on chain, with NVNM Chain purpose-built for that role and other chains supported alongside it.
Consume
Finally, consume: only the smallest permissioned slice that a given agent, application, analyst or counterparty is entitled to see actually reaches them.
The control-plane
A continuous obligation, not a one-time pipeline
Pulling values out of a file once is straightforward, and it is deliberately not what Inveniam does. Making that data usable for AI inference at institutional scale is an ongoing obligation. That ongoing obligation is what the control plane actually is.
It detects change, so a new or amended document triggers reprocessing and downstream outputs refresh rather than silently drifting out of date. It resolves authority: which document, at which version, governs an obligation as it stands today. Permission gets enforced at the level of an individual element, raw, structured or embedded, and that permission is revocable by party. Custody gets preserved because indexing and embedding run at the edge, inside the owner's own environment, and source files never move. And proof gets distributed, so verified values reach only the authorized tools, each carrying an anchor a third party can independently check.
What that unlocks in practice is worth naming directly. Verification gets cheaper, often by an order of magnitude, because a mark traces to a clause, a coverage traces to an endorsement, a figure traces to its evidence. Reporting cycles give way to continuous monitoring, so covenant drift, policy amendments and control failures surface as they happen instead of at the next quarterly close. Auditors, regulators and counterparties can check a claim without receiving the underlying files at all. Work that used to stall waiting for a person to read a document now completes on evidence instead. And an entire category of products, collateral structures, tokenization, pricing, services, becomes possible once the inputs feeding them can actually be trusted. None of this replaces certified appraisers, auditors, adjusters or counsel. It industrializes the information flow that runs around them.
Inveniam IO detects changes as they happen and resolves authority: which document, at which version, governs an obligation as it stands today. Nothing waits for a person to notice a change.
Permissions and workflows
Where the platform earns its keep
Preparing data for inference is not only a structuring problem. It is a question of who, and what, may see each individual piece of a corpus, and keeping that answer true as the corpus keeps changing underneath it.
Permission resolves at the element, not the file, so a single figure can be released without granting access to the document that contains it. Access takes one of three shapes, raw, structured or embedded, so a model can be entitled to a value without ever being entitled to the page it sits on. A role hierarchy resolves permission at the record level first, then the registry, then globally, with the most specific grant always winning. Access given to a counterparty can be withdrawn without renegotiating the underlying relationship. Agents get treated as principals in their own right, acting under a signed identity, so their entitlements belong to them rather than being borrowed from whoever deployed them.
Workflows follow the same logic. A new or amended source starts the work automatically, so nothing waits for a person to notice a change. Human checkpoints sit where the process genuinely needs one, and automation covers everywhere else. Covenant, term and threshold surveillance runs continuously across the corpus, not just at a reporting date. Outputs refresh as the underlying data changes instead of aging until the next cycle. Every step is attributable to who or what acted, when, and on which version, anchored so it can be proven later. Structuring the data turns out to be the easier half of the job. Governing who may use it, and keeping that governance true over time, is the platform.
"The failure modes seen in enterprise document AI today are rarely failures of model capability. They are context failures."
The failure modes seen in enterprise document AI today are rarely failures of model capability. They are context failures. The wrong version gets used. A permission goes unchecked. An answer arrives with nothing to cite. Cost scales with page count regardless of what the question actually needed.
Structure that arrives preresolved means a model receives named concepts instead of raw layout noise, so it stops rebuilding document structure on every call. Retrieval built around a concept rather than a text string means an agent that correctly reads one contract's liability cap reads all ten thousand others the same way, with no per-document prompting. Sending a subtree instead of a full document changes token economics directly. Typed values and named concepts remove the step where a model guesses what a number means or where it belongs, which is one of the more common sources of hallucination in the first place. And because every answer resolves to a pixel box on a signed page and a hash a third party can check, auditability stops being a separate exercise bolted on afterward.
Inveniam is deliberately not a model. It does not train or fine-tune one, and it does not sell one. No corpus ever leaves an owner's custody to become weights, Inveniam's or anyone else's. It is also not a rip-and-replace of a client's existing AI stack. It sits underneath the stack a client already runs and feeds it better inputs. The model is increasingly the commodity in this picture. The data conditions around it are what actually differentiate one deployment from another.
Inveniam supplies the harness. The client supplies the intelligence. Nothing in the platform assumes a particular model vendor, a particular agent framework, or that inference happens anywhere other than an environment the client controls.
A client can bring its own model, since routing is provider-agnostic: point the harness at a commercial API, an open-weights model, or a self-hosted model, and switch between them without touching the underlying data layer. That routing lives in the AI service, not in application code. A client can bring its own agent too, connecting an orchestrator over the Model Context Protocol to a typed tool surface, keeping its own identity, its own keys and its own control flow rather than reverse-engineering a prompt-shaped API. And the harness itself can run inside the client's own VPC, with indexing and embedding running at the edge so permissioned snippets never cross a boundary the client does not own. Zero data retention stops being a policy someone has to trust and becomes a structural fact of the architecture instead.
What the harness supplies is model routing with fallback across providers, permissioned context assembly built from the document graph, provenance on every element it returns, and the MCP tool surface and anchoring hooks that make verification possible. What the client supplies is the model itself and what it pays for it, the agent and its evaluation, its own key infrastructure and signing, and the policy governing what each role is allowed to see. The platform's value does not depend on which model a client happens to be running this quarter.
Inveniam supplies the harness. The client supplies the intelligence. Nothing in the platform assumes that inference happens anywhere other than in an environment the client controls.
Beyond chunk-and-embed retrieval
Conventional retrieval-augmented generation and Inveniam's approach run the same vector search underneath. What changes is the unit that comes back, and what can be said about it afterward.
Chunk-and-embed retrieval splits content on length, so a clause can straddle two chunks and belong fully to neither. The chunk is a passage of prose, so the model has to re-derive the fact it needs from that prose on every call, paying token cost for the surrounding text along the way. Citation, when it exists at all, is typically a filename and maybe a page number, resolving to nothing more specific than that. Freshness reflects whatever the last index run happened to capture, with no signal telling an agent whether the source has moved since. Permission gets granted per document if it gets enforced at all, so releasing one figure often means granting an entire file. And supersession is invisible: an amended clause and the clause it replaced look identical to the retriever.
A graph slice with provenance behaves differently at every one of those points. Content is chunked on meaning, with the unit defined as a named, typed element from the docset vocabulary rather than an arbitrary span of text. The element carries the fact itself, since a reserved value attribute holds the canonical figure, so the model reads it directly instead of parsing for it inside prose. Citation resolves to an actual pixel box on a page image a reader can be shown. Freshness becomes a property of the platform, which knows whether anything upstream has changed since an answer was produced. Permission resolves at the individual element and is revocable by party. Supersession is tracked explicitly, so what gets returned is what currently governs, not whatever happened to be indexed last. An answer an agent can act on turns out to be the same thing as an answer a human can check.
Three layers adopted independently
Each layer solves a distinct problem and has its own reason to exist on its own. Most clients start with one, not all three, and the technical appendix carries the full specification for each. What follows is when to reach for which one.
Where the platform stands today
An open standard that overstates its own maturity rarely survives contact with the developers trying to build on it, so it is worth being direct about the gap between what ships today and what is still coming. The specification, the Python reference implementation, the NVNM mainnet and its anchoring module, and the 21-tool MCP server are live and public now. A developer beta, public RPC access, a published tool reference and a network participation token targeted for the fourth quarter of 2026 are announced but not yet generally available. A formal query language, an Inveniam IO API, a Know-Your-Agent identity module and any tokenomics remain unbuilt. The full breakdown is in the appendix. Publishing the gaps is a deliberate choice: developers tend to find them within an afternoon regardless, and an ecosystem gets built on what actually works, not on what a deck claims works.
