A new infrastructure layer for trust, evidence, and ownership.

The slightly deeper version.

The problem. People make agreements. Promises are made. Work is done. Objects change hands. Ownership transfers. But the world does not preserve what actually happened. Documents capture intention; they do not capture the living reality that followed. Courts and auditors spend enormous effort reconstructing what should never have been lost.

The framework. We propose a new primitive: the Verified Event — a structured record with actor, evidence, review, approval, and audit trail. Every other concept in this system is built from this one unit. Agreements become chains of Verified Events. Objects acquire verified histories. Ownership stops being a static declaration and becomes a continuous chain of events.

The platform. EquiWork is the first implementation. It addresses the simplest version of the problem: agreements between two parties about work, payment, and ownership. From this foundation, the same framework extends to other domains. The first canonical agreement record was sealed on 2026-04-21. The CAP predicate vocabulary is frozen. The audit log is append-only by structure. AI suggests; humans approve — enforced at the protocol level.

The first vertical. T&T (Tasting & Toasting) is the first public-facing vertical. It applies the CAP framework to wine: from vineyard to vintage to batch to bottle. Wine is emotionally and structurally perfect as the first vertical — every stage already produces documents, but no continuous chain of verified events. T&T closes that gap. It gives the abstract framework a human face.

Participation. This is not a one-founder system. It requires capital, legal intelligence, engineering depth, domain expertise, audit experience, and partnerships. Investors, engineers, lawyers, partners, auditors, government experts, advisors — different people bring different things. The participation map below shows where each fits.

This project was not born from a desire to build another app. It was born from a repeated observation, watched over years:

• Agreements collapse. Two parties remember the same handshake differently three years later.
• Contributions disappear. The person who built the foundation is forgotten when the building is celebrated.
• Promises become memories. What was said becomes what someone thinks was said.
• Ownership becomes disputed. The certificate is real. The unbroken chain that connects it to today is not.
• Authenticity becomes marketing. Claims of origin, craftsmanship, and provenance outpace the proof.
• Courts reconstruct history after damage is already done. The legal system is asked to do what should have been built in.

EquiWork began as an attempt to protect the truth of contribution. It started with one specific question: when a person contributes to a project, how do we prove that contribution was real, accepted, and valuable?

CAP emerged when the same logic was applied to objects, products, and provenance. A wine bottle, a painting, a luxury item — each has the same underlying problem. Documents claim authenticity; no continuous chain proves it.

T&T became the first living vertical — the first public environment where ordinary people can actually experience verified truth, through wine. A scan of a bottle reveals not a marketing label but a chain of verified events from soil to glass.

From the same root, the framework extends further: luxury, art, IP, registries, family history. Different verticals. Same truth engine.

Seven live portals.
One substrate. Different verticals.

Before the deep dive into the framework, here is the proof of life. Each row below is a working URL — not a mockup, not a screenshot, not a future plan. The framework is not a single product; it is a substrate of capabilities composing into distinct verticals at distinct maturity levels.

The world is not short of documents.
It is short of verified reality.

This problem operates simultaneously at three levels — human, business, and institutional. Each level shows the same gap. Each level pays a different price for it.

The human problem

People trust each other. They make agreements verbally, in messages, in handshakes. Then memory fails — not because people are dishonest, but because human memory is reconstructive, not preservative. What was promised becomes what each side remembers being promised.

• Partners. Two people start something together. Years later, one says, "I was always the operator." The other says, "I was always the lead." Both are sincere. Neither has a record.
• Founders and early contributors. Equity discussions happened in a coffee shop. The cap table never reflected them. The painful conversation arrives during a fundraise.
• Developers and clients. The contract said "build the software." Six months later, the scope is contested. Neither side can produce the evidence of what was agreed.
• Family businesses. Three generations contributed. One generation inherits the name. The others fade from the story.
• Artists and craftsmen. The work is yours. The verification of authorship rests on memory and reputation.

The business problem

Businesses know the human problem and try to solve it with documents. Contracts, certificates, invoices, signatures. The result is a paper trail — but a business does not operate through paper. It operates through events: deliveries, approvals, payments, returns, transfers, changes of state. The paper trail captures intention. The events leave no equivalent trail.

• Contracts. Signed. Then re-interpreted. Then disputed. Then litigated.
• Deliveries. Goods arrived. Or did they? In what condition? Photographed by whom?
• Approvals. Verbally accepted. Confirmed in a meeting. Disputed in writing six months later.
• Payments. Wired. But against which milestone? Against which acceptance?
• Ownership transfers. Title changes hands. The chain back to origin is paperwork-only.
• Compliance. The audit happens annually. The events being audited happen daily.

The institutional problem

Courts, auditors, regulators, and governments inherit the consequences. They are asked to determine truth long after the events. They must reconstruct. They use documents, witnesses, inference. The process is slow, expensive, and structurally biased toward whoever kept better records — not necessarily whoever was right.

• Courts. Reconstruct events through testimony and partial documentation. The legal process is largely the art of rebuilding what should have been preserved.
• Auditors. Sample, verify, attest. Each attestation rests on the underlying records — which were themselves not built for audit.
• Regulators. Investigate after harm. Issue rules. Inspect. The inspection captures a moment; the regulated reality is continuous.
• Governments. Maintain registries — land, vehicles, businesses, marriages. The registry is a snapshot. The path from one snapshot to the next is opaque.

Every level of the problem points to the same gap. The gap is not that we have too few documents. The gap is that documents do not continuously verify reality.

What if it were preserved at the moment it happened? What if every consequential event left a verified trace — actor, evidence, approval, audit trail — that nobody could rewrite later?

That is the question that produced this framework.

They store records.
They do not verify living truth.

This is not a problem of inadequate technology. The world has good tools for storing records. The problem is that storing is not the same as verifying. Every existing system is excellent at one piece of the puzzle. None captures the full chain.

Every existing system is good at one piece — storage, signing, immutability, transaction recording. None of them captures the full chain:

That full chain is what Verified Truth provides. Each link is recorded. Each link is verified. Each link is auditable.

This is not a competitor to contracts, signatures, blockchains, or CRMs. It is the layer that makes them all more useful — because it preserves what happens between them.

A Verified Event is the smallest trustworthy unit of history.

Before introducing platforms, verticals, or products, we introduce the primitive. Everything in the Verified Truth Framework is built from this one unit.

A Verified Event has a precise shape. It cannot be broken down further without losing meaning. It cannot be added to without becoming a different kind of object. Understanding this anatomy is understanding the whole system.

The eight fields of a Verified Event

That is a Verified Event. Not a marketing claim. Not aspirational. A specific event with a specific actor, timestamp, evidence reference, and verifiable status.

Every other concept in this document is built from this primitive. Agreements are chains of Verified Events. Object passports are chains of Verified Events. Ownership transfers are chains of Verified Events. The unit is universal.

The invention is not a feature.
It is a different stance on what truth is.

Many platforms claim to be revolutionary. Most are incremental. This section names what is actually different — not in marketing language, but in structural terms.

Seven structural moves separate this framework from anything that came before it. None of them is a slogan. Each of them is encoded in the system, not asserted on a website.

1. The contract is not the final truth.

Existing systems treat the signed contract as the destination — the proof of what was agreed. Here, the contract is the beginning. The events that follow are the actual truth. The system is built to preserve those events, not just the initial document.

2. Truth is a chain of verified events, not a single declaration.

What is true today is the cumulative result of every verified event that led here. Truth has memory. Truth has structure. Truth can be walked backward to its origin or forward to its current state, and every step is auditable.

3. The system separates declaration, evidence, analysis, verification, approval, and canonical state.

Most platforms blur these. A "signed" document might be checked, accepted, recorded, and verified all in one undifferentiated motion. Here they are explicit, sequential, and separately authoritative. AI can analyze. A peer can verify. Only a qualified human authority can approve. Only a fully-verified chain can become canonical.

4. AI can analyze, but cannot approve.

This is not a runtime policy. It is structural to the protocol. AI-generated attestations are bounded so that they cannot become canonical without explicit human approval. The framework rejects attempts to escalate AI output into authoritative state by design, not by check. confidential detail — exact composition of the predicate vocabulary, validator logic, and schema-level constraints is available to qualified reviewers under invite or NDA.

5. Humans retain final authority.

Every consequential acceptance — approval of a milestone, transfer of ownership, sealing of a canonical record — requires a qualified human authority: a specific, identified, legally accountable person. Automation does not bypass this. The system is built so that the human cannot be removed from the loop.

6. Ownership is not a static claim — it is the result of verified history.

You do not "own" something because a piece of paper says so. You own something because the verified chain of events leads from the origin to your possession, with no broken link. The certificate is one event in the chain. It is not the chain.

7. Products, agreements, and contributions all run on the same truth engine.

The same predicates, the same authority model, the same audit discipline apply to a software contract, a bottle of wine, a contributor's equity, a painting's provenance. Building a new vertical is integration work, not reinvention. That is the leverage of the framework.

What we build on. What others have already done.

The Verified Truth Ecosystem does not claim to invent provenance, formal verification, identity, signatures, blockchain, or AI. Each of these has serious existing work. Our contribution is the architecture that composes them — and a layer of preservation that sits above them.

This section names the public-domain foundations we build on or operate alongside. Each card identifies what the existing system solves well, what it does not address, and what the Verified Truth Framework adds on top. We do not present these as competitors. They are the field.

EquiWork is the first implementation of the Verified Truth Framework.

EquiWork started with one core question — the one that has produced every line of code, every architectural decision, every refusal to compromise:

The naive answer is "use a contract". But contracts are intention, not history. They describe what should happen. They do not capture what did happen.

EquiWork's answer is different: capture the contribution as a chain of verified events, each anchored to evidence, each reviewed by a specific human, each accepted at a specific authority level. The result is not a document — it is a continuous, falsifiable, append-only record of what occurred.

The seven stages of an EquiWork agreement

Every agreement moves through seven states. Each transition is a Verified Event recorded in the immutable audit log. The diagram below is the lifecycle of a real agreement on the platform today.

The full chain in plain words

A founder creates an agreement, specifying scope, milestones, evidence requirements, payment terms, and counterparty. The contributor reviews and either negotiates or accepts. When both confirm, the agreement is frozen — a SHA-256 hash is generated, and the content becomes immutable. Both parties then sign using EIP-712 cryptographic signatures. Two valid signatures plus a valid hash equals a canonical record — verified, sealed, and discoverable.

From this point, execution begins. The contributor delivers work — a commit, a file, a deliverable. Evidence is attached: the commit SHA, the file hash, the artifact reference. The milestone enters review. The founder examines it. The founder issues APPROVES, REJECTS, or requests revision. Approval triggers downstream events: payment release, equity warrant issuance, addition to the contributor's verified history.

Every step produces a Verified Event. Every event is recorded with actor, evidence, approval, timestamp. The cumulative record — the Contract Passport — is the complete history of the engagement. Anyone with access can walk it backward to origin or forward to the current state.

EquiWork is not just escrow

A common misreading: "EquiWork is escrow for contractors." Escrow is one module in the system. It exists. It works. But it is not the invention.

The invention is the loop:

Escrow connects payment to acceptance. But the same framework connects equity to acceptance, reputation to acceptance, intellectual property rights to acceptance. The acceptance event is the hinge. Everything downstream depends on it being verified, not assumed.

Once an acceptance event is canonical, the contributor's verified work history grows by one entry. That entry is not a self-claim — it is a record signed by both parties, with evidence attached, recorded immutably. Over time, this builds a profile that cannot be faked, exaggerated, or rewritten: a verified history of accepted contributions.

Where the platform stands today

Five of the seven lifecycle states are fully implemented and verified. The first canonical record was sealed on 2026-04-21 — a real Verified Event with a falsifiable hash reference. Exact commit and tag references are available to qualified reviewers under invite. reproducible

Two states remain partially implemented: full milestone execution end-to-end is being validated, and agreement completion (the final state with full Contract Passport) is the next major milestone. For the complete inventory of components, status, and source references, see the EquiWork Source Map and Status Matrix companion documents.

The status matrix.

Every claim on this page carries a status. If a component is tagged EXISTS it is implemented in code today. If it is tagged PARTIAL, the gap is documented internally. If it is tagged PILOT, CONCEPT, or ROADMAP, it is clearly identified as such. Nothing on this page is claimed as built when it is not. Detailed source references and exact implementation maps are available to qualified reviewers under invite or NDA.

Status legend: EXISTS implemented in code today · PARTIAL partially implemented, gap documented · PROTOTYPE working dev-environment code · PILOT partner conversation or first deployment underway · ROADMAP specified, not built · CONCEPT vision-document only · RESEARCH HYPOTHESIS structurally plausible, requires validation · EXTERNAL PRECEDENT existing public-domain work we build on · CONFIDENTIAL DETAIL implementation specifics under invite/NDA.

AI suggests. Human approves.

This rule is not enforced by convention. It is structural to the framework. AI-generated attestations are bounded by design so they cannot become canonical without explicit human approval. The mechanism is architectural, not a runtime check that could be bypassed. confidential detail

What AI does

• Reads documents and extracts structure
• Identifies missing evidence or unclear scope
• Prepares record drafts for human review
• Suggests required documents based on agreement type
• Analyzes risk, clarity, and completeness in draft agreements
• Surfaces findings to both parties as analysis, not as approval
• Guides onboarding flow with context-aware suggestions

What AI does not do

• Issue any predicate that carries approval or verification weight
• Sign binding cryptographic payloads on behalf of a party
• Change agreement status or canonical state
• Act as a qualified human authority under any condition
• Auto-accept or auto-reject a milestone
• Transfer ownership of any object
• Make legally consequential decisions

Most platforms claim AI integration as a feature. Some claim AI decision-making as an advantage. Verified Truth takes the opposite position: AI is bounded explicitly, structurally, by the protocol itself. Exact composition of how this bounding is implemented is available to qualified reviewers under invite or NDA.

This is not a limitation. It is a strength. It means humans always retain the authority they bear the legal and ethical weight of. It means the system cannot drift, through software change or business pressure, into a state where AI quietly becomes the source of truth.

The provider abstraction allows the framework to use multiple AI providers — Anthropic, OpenAI, others — without changing the trust model. The choice of underlying model is an implementation detail. The non-negotiable rule is the same regardless.

CAP is not a QR code.
CAP is a general passport architecture for verified provenance.

CAP extends the EquiWork framework from agreements to physical objects. The same predicates, the same authority model, the same audit discipline — applied to anything with provenance.

Where EquiWork verifies relationships and contribution, CAP verifies origin and history of objects. Both share the same protocol layer. Both produce the same kind of artifact: a chain of Verified Events that can be walked from origin to current state.

Why wine first?

Wine is emotionally and structurally perfect as the first vertical. It has every layer the framework needs to demonstrate itself:

• Land. A specific vineyard, on specific soil, with documented climate and ownership.
• Harvest. A dated event with weather conditions, yield, responsible workers.
• Production. Fermentation, aging, bottling — each stage with documented inputs and outputs.
• Documents. Invoices, lab analyses, certifications, classifications.
• Bottle. A specific physical unit with a serial number, label, authentication mark.
• Scan. A consumer holding the bottle can request the verified history.
• Consumer. A human at the end of the chain, asking: "is this real?"

Every existing wine workflow already produces documentation. None of it is connected as a verified chain. That is the gap CAP closes — not by replacing the existing workflow, but by giving it continuous structure.

The layered passport

A CAP passport for wine is built in layers. Each layer is a chain of Verified Events. Each event is anchored to evidence. The passport is not a document — it is the verified history made accessible.

One core. Many object domains.

Wine is the first vertical because it is structurally ideal and emotionally resonant. But CAP is not a wine product. It is a general architecture for verified provenance of any object that has a story worth preserving.

From the same CAP core, the framework extends to multiple object domains. Each domain adds its own evidence types and qualified human authorities. The underlying truth engine — predicates, audit trail, append-only history — does not change.

Other domains the framework already fits

Each is currently CONCEPT — naming them here is honest about what the framework can reach, not promising what is committed.

Why Tasting & Toasting is the first living market.

T&T is not just a wine app. It is the first public environment where ordinary people can actually experience verified truth.

The abstract framework — predicates, audit trails, append-only history — is technically correct but emotionally invisible. People do not feel it. They feel its absence when authenticity is contested, but they do not feel its presence when it works.

Wine changes that. Wine is consumed in a specific human context: a meal, a celebration, a tasting. The moment a person holds a bottle and asks "where did this come from?" — that is the moment verified truth becomes something one can touch.

What T&T does for the consumer

• Scan a bottle. A QR code or NFC mark reveals the chain.
• See its passport. Vineyard, vintage, batch, bottle — all verified.
• Discover winery history. Who made this. Family or company. How long. With what philosophy.
• Join tastings. Curated events at producer locations, verified as authentic.
• Visit producers. Direct connection between consumer and source.
• Connect with authentic places. Not marketing — verified, recorded reality.
• Understand why provenance matters. Through experience, not through doctrine.

What T&T does for the framework

This matters for adoption. An infrastructure layer succeeds when humans interact with its consequences without thinking about its mechanics. T&T is where the framework stops being a whitepaper and becomes a bottle in someone's hand.

The structure

T&T is a separate Delaware Corporation, built on top of the CAP substrate. It is the first paying customer of the verification primitives. The same substrate will power luxury, art, and other future verticals — but T&T proves the model.

The relationship demonstrates that the substrate is real enough to be licensed. That distinction — substrate as licensable infrastructure — is what allows the framework to scale beyond what one company could ever build alone.

Current status: T&T as separate Delaware Corporation EXISTS. CAP substrate licensed to T&T EXISTS. Consumer-facing app CONCEPT. First winery pilot (Stara Winna Góra, Poland) PILOT DISCOVERY.

A digital operating layer for wineries.
Not a CRM. A truth engine.

Winery OS is the producer-side companion to T&T. It is not another wine CRM. It is a digital twin of how a winery actually operates, capturing each stage as a Verified Event.

A winemaker already photographs the harvest. Already keeps fermentation logs. Already files certifications. Already serializes bottles. Winery OS does not change any of this. It captures it. Each existing artifact becomes a Verified Event in the wine's CAP passport.

The full module set

The transformation

A harvest event becomes a Verified Event with photographs, date, vineyard reference, and the person responsible. It is reviewed and accepted by the winery. It is verified by T&T. It becomes part of the Vintage CAP.

The same producer who already takes harvest photos now produces verifiable provenance — without changing their work. The change is not workflow. The change is what their existing work becomes.

The AI Winery Agent

The AI Winery Agent helps the winemaker. It does not replace them. It suggests evidence categories. It flags missing documentation. It drafts CAP entries for human review. It never approves. The winemaker remains the qualified human authority for everything that touches their wine.

The Agent is particularly useful for smaller wineries without dedicated administrative staff. A family winery can produce enterprise-grade provenance without enterprise-grade overhead.

Status: Winery OS as full concept CONCEPT. Module specifications drafted; pilot deployment pending first signed winery partner.

Ownership is not a declaration.
Ownership is a verified history of events.

In the old world, ownership lives in paper. A deed says you own a house. A title says you own a car. A certificate says you own a painting. These documents declare ownership, but they cannot prove the continuous chain of events that led to your current position.

When ownership is disputed — and it is, regularly — the legal system must reconstruct that chain. Documents are gathered. Witnesses are interviewed. Gaps are filled with inference. The process is slow, expensive, and often inconclusive.

Verified Truth treats ownership differently. Ownership is the chain of verified events that led to the current state. Not a single document — a continuous, walkable history.

Where the ownership model applies

How it works

Every ownership transfer is itself a Verified Event. It includes:

• Who transferred. Identified, with their authority to do so verified.
• Who received. Identified, accepting under the chain's rules.
• What was transferred. Linked to the object's CAP record or the equity certificate.
• What evidence supports the transfer. Signed documents, payment records, witnessing.
• Who approved (qualified human authority). The legally accountable confirmer.
• What prior event this supersedes. Linked backward to the previous ownership state.

The SUPERSEDES predicate links new ownership to the prior owner. The chain extends indefinitely backward. To prove current ownership, you do not produce a single certificate — you walk the chain backward until you reach the originating event: the creation of the object, the formation of the company, the recording of the original right.

Current status: protocol-level lineage (SUPERSEDES predicate) EXISTS. Agreement-level ownership EXISTS. Object-level ownership UI PARTIAL.

The same framework. Many domains.

The Verified Truth Framework was developed to solve one specific problem: agreements between contributors and founders. Wine, art, luxury, government — these were not its original targets. But once the framework was built, it became clear that the same primitives apply almost universally.

This section names the verticals being considered. Each is currently CONCEPT — vision-document or pilot-discovery state. Building any of them takes real engineering. Naming them here is honest about what is possible, not promising what is committed.

Every vertical asks the same questions: what exists, who made it, who verified it, who owns it, how did it move. The Verified Truth Framework gives the same answer pattern: predicates, evidence, authority, audit trail.

Building a new vertical is therefore not a research project. It is an integration project. Add evidence types specific to that domain. Identify qualified human authorities. Wire the existing CAP substrate to the new vertical's interface.

This is what makes the framework valuable: it does not need to be reinvented for each new domain. The same investment in protocol layer pays back across all verticals that build on it.

What this is not. What this is.

Honest framing matters. The space around this framework attracts many adjacent expectations. Setting boundaries explicitly protects both reader and project.

Where exactly can you help?

This is not a system that one founder builds alone. It requires capital, legal intelligence, engineering depth, design judgment, domain expertise, audit experience, and partnerships. Different people bring different things. Below: who fits where, and what each gets.

The seven non-negotiable rules.

These principles predate any specific product. They will outlive any specific feature. They are the conditions under which this framework can be trusted at all.

1. No proof claim without evidence

   Every CAP attestation must reference its evidence source. No exceptions. A claim without evidence is not a verified event — it is a statement.

2. No AI final approval

   AI output is structurally bounded to analysis-only attestations. Such attestations cannot become canonical without explicit human approval. This is enforced by framework architecture, not by runtime convention. implementation detail under invite/NDA

3. No ownership transfer without human confirmation

   Predicates that grant or transfer ownership require a qualified human authority. Automated approval paths are forbidden. Every ownership-altering event passes through a human with legal accountability.

4. No silent history rewrites

   Every state change goes through the append-only audit log. Previous state is computed from history, never edited. There is no way to overwrite the record without leaving a trace. implementation detail under invite/NDA

5. No publication without verification

   Public-facing passports require canonical state before they can be shared. Drafts and unverified records remain internal until verified.

6. Every critical event must have an audit trail

   No business-critical operation runs without a recorded entry in the audit log. State transitions, ownership changes, financial events, identity changes — all leave a record by structural requirement.

7. Append-only is structural

   Schema-level constraints enforce append-only history. The protocol enforces it. The application cannot opt out. This is not a coding convention — it is a constraint built into the foundation. implementation detail under invite/NDA

Where we go from here.

Calibrated against current implementation velocity, not against marketing ambition. Major changes will be tracked in updates to this document. Honest dates. Falsifiable milestones.