The problem
Static files, fragmented AI features, ambiguous revisions and difficult verification force people to reconstruct context around every document.
Universal Document for organizations
A document can tell you what it means and prove what it is.
Universal Document is a portable document architecture for structured meaning, explicit revision history, local document intelligence and independently checkable integrity. Start with one document family—not an estate-wide replacement.
The executive brief
The idea
UD places intelligence-ready structure, policies, provenance and integrity evidence in the portable document architecture—not only in the application opening it.
The two states
UDR remembers change. It is living and revisable. UDS preserves finality. It is a sealed selected state that is amended through a new UDR.
BrowserCarrier
A `.udr.html` or `.uds.html` opens in an ordinary browser with zero installation. Its presentation is separate from the embedded canonical UD bytes.
Why now
AI can make an application smarter. UD is designed so compatible Readers can use portable structure and policy carried by the document itself.
How to start
One team. One document family. One measurable problem. Fourteen days, followed by an explicit expand or stop recommendation.
What an organization can use today
Create living UDR documents with explicit revision policy and history.
Share self-contained BrowserCarriers that open without installation and make zero automatic network requests.
Use document-bound Talk with citations and off-document refusal on supported local Reader paths.
Verify canonical integrity locally and report trust states separately.
Run bounded conversion, authenticity-review and evidence-room professional services within their published scope.
What is not generally available
Protected organization signing and managed signing keys — Early Access until protected custody and authorization are provisioned.
Verified organization identity — Early Access and never marked verified before an actual procedure.
Trusted timestamps and independent-node validation — Planned; waitlist only.
Hosted enterprise storage, legal hold and regulated-industry compliance — not implied by the document format.
Technical architecture
Canonical forms
UDR and UDS use the existing canonical schema and emitter. Structured blocks carry content; policies use the existing extension mechanism.
Revision and sealing
UDR revisions append hash-linked history. UDS uses canonical serialization, SHA-256 integrity and the existing Ed25519 sealing architecture where an authorized protected signer is actually available.
Portable presentation
BrowserCarrier embeds exact original bytes, uses a restrictive CSP and remains script-free. Core verification remains offline-capable.
Applications
Creator authors UDR. Reader opens, talks, revises or starts amendments. Validator reports integrity and every available trust state separately. Trust Registry publishes key and identity records.
Policies
Conversation Policy controls knowledge, citations and external-AI permission. Editing Policy controls open revision, named editors, suggestions, comments or read-only behavior.
Conversion and APIs
Representative conversion pilots are operational within published limits. Production-scale credentials, throughput and integration require a provisioned written scope.
Security and trust: seven different questions
Integrity
Do protected canonical content and its recorded hash agree?
Signature validity
Does the cryptographic signature verify with the presented public key?
Key trust
Is that signing key trusted under the applicable policy?
Identity
Has the real person or organization actually completed an identity procedure?
Time
Is the time local metadata or independently evidenced?
Current status
Has the document or key been revoked or superseded?
Transparency
Is a receipt or inclusion proof present and verified?
UD is cryptographically tamper-evident where the required evidence exists. It is not described as tamper-proof, automatically legally binding, or automatically compliant with any signature or regulated-industry regime.
Privacy and data flow
Inside the file
Content, structure, policies, provenance and available integrity evidence travel in the UD. BrowserCarrier presentation is separate from canonical identity.
Local paths
BrowserCarrier makes zero automatic network requests. Supported Reader Talk and core verification can remain local; “Nothing uploaded” appears only on a path where every stage is actually local.
Deliberate online paths
Registry lookups, hosted conversion, organizational workflows and lead intake occur only after a deliberate online action and their data boundary must be disclosed.
Analytics boundary
No document text, question text, filename, title, email, PHI or sensitive document metadata is sent to product analytics.
Hosting options
BrowserCarrier and local Reader provide a local-first base. Organization-managed or hosted deployments require an explicit architecture, residency, access and support scope.
Compliance boundary
Local processing alone does not establish HIPAA or another compliance status. Regulated deployment requires its own controls, agreements and validation.
How UD differs
| Format or product | Primary strength | UD distinction |
|---|---|---|
| Standardized fixed-page presentation | UD adds portable structured meaning, policies, revision lineage and canonical integrity evidence. | |
| DOCX | Standardized office authoring and editing | UD explicitly models living revision policy and sealed final state. |
| Adobe Acrobat AI | AI assistance around PDF | UD is designed so intelligence-ready structure belongs to the portable document architecture. |
| Word/Copilot | AI inside Microsoft authoring workflows | UD behavior and policy can travel beyond one vendor application. |
| Google Docs/Gemini | Hosted collaboration with AI assistance | UD is portable and can remain useful without one hosted account. |
A staged migration—not “replace every PDF”
Stage 1
Begin suitable new documents as UDR and deliberately select any final UDS.
Stage 2
Convert one high-value legacy document family with explicit mapping, exceptions and source preservation.
Stage 3
Integrate relevant source systems and policies after the acceptance batch works.
Stage 4
Expand only if measured recipient, workflow and operational value justifies it. Keep PDF compatibility exports where needed.
The 30-minute demonstration
- 0–3: frame the document problem and UDR/UDS lifecycle.
- 3–7: open a BrowserCarrier with zero installation.
- 7–12: Talk with citations.
- 12–16: ask an off-document question and show refusal.
- 16–20: edit UDR, create V2, inspect History and Compare.
- 20–24: verify UDS, tamper with a copy and show safe failure.
- 24–27: create an amendment rather than edit the UDS.
- 27–30: agree whether a bounded pilot is appropriate.
The 14-day bounded pilot
One team. One document family. One measurable problem. Fourteen days.
Day 0
Scope, owner, exclusions, data boundary and success criteria.
Days 1–2
Map the representative source workflow.
Days 3–5
Configure or convert a small acceptance set.
Days 6–10
Controlled use with the agreed team and recipients.
Days 11–12
Measure creation time, revision clarity, comprehension, verification, friction and operational effort.
Days 13–14
Deliver results and an explicit expansion or no-expansion recommendation. No improvement is guaranteed in advance.
Pilot qualification
A good pilot
Repeatable document family, meaningful recipient group, clear pain, bounded scope, internal owner and measurable current workflow.
A poor pilot
Estate-wide replacement, undefined objective, speculative use, or dependence on unfinished signing, identity, timestamp or node infrastructure.
Procurement FAQ
Is UD proprietary?
The current implementation is an open document-standard adoption layer. Portable raw UDR/UDS files and BrowserCarriers are designed not to require one hosted account.
What if Universal Document disappears?
A BrowserCarrier remains locally readable and can return its embedded original. Core integrity verification is designed to remain offline-capable in compatible implementations. Optional online status services may no longer update.
Do recipients need software?
No for .udr.html and .uds.html BrowserCarriers. Raw-file Desktop integration is optional.
Does it work offline?
BrowserCarrier presentation and core integrity verification can. Registry, revocation, timestamp or transparency status may require an explicit online check.
Can we still make PDFs?
Yes. PDF remains a compatibility derivative or conversion input; it is not silently treated as canonical UD identity.
How does identity work?
Signature validity, trusted-key status and verified real-world identity are separate. Identity is not marked verified until a real procedure occurs.
Where is data processed?
BrowserCarrier makes no automatic request. Supported local Reader paths process the document locally. Hosted conversion or organization services are invoked deliberately and require a written data boundary.
What analytics are collected?
Allowlisted product events only. Document text, question text, filenames, titles, emails, PHI and sensitive document metadata are excluded.
Can we pilot first?
Yes: one team, one document family, one measurable problem, fourteen days.
Can existing systems stay?
Yes. Start with a bounded document family and integrate source systems only after measured value justifies it.
Who supports deployment?
A qualified inquiry is assigned an owner. Immediate persistence and acknowledgement are followed within one business day by qualification; qualified teams receive a 30-minute demo and, where appropriate, a written bounded-pilot proposal. No 24/7 support promise is implied.
Structured organizational intake
Discuss an organizational pilot
Describe the workflow and approximate scale—not confidential documents, case facts, PHI, credentials or source files. The system persists the request, creates an enterprise qualification state and suggests existing product routes for review.
Existing commercial routes
Migration and API needs route to Bulk Document Conversion or Enterprise. Schema needs route to Schema Engineering. Legal and audit needs route to their existing specialist pages. Company signing remains Early Access. Trusted timestamps remain Planned.