The OctoDoc whitepaper

Abstract

A machine may propose. Only a person may confirm.

Electronic signature law was settled in the United States in 1999 and 2000. A record is not denied effect because it is electronic, and it is not denied effect because a machine helped form it, so long as the machine's action is legally attributable to the person to be bound. Neither statute makes a deal valid or proved, and that attribution condition is the open problem. A cryptographic seal binds bytes to a certificate; it proves nothing about a person, and no signature level changes that.

We propose a confirming act a stranger can check. A machine may propose where a signature belongs, and a proposal is not consent: the two live in different tables, and the sealing path can read only one of them. The confirming act is bound to a digest over geometry the server re-measures from its own stored page records, and the server keeps its own value rather than the browser's. We assume one deployment plane, private object storage and an external RFC 3161 timestamp authority. We assume no hardware security module and no public certificate authority, and we state below what those two absences cost.

01

Introduction

Better cryptography removes none of the costs of depending on an intermediary, and every documented loss in this category is the proof.

One file keeps this paper honest: a mutual NDA between Northwind Labs and Acme Industries — two fixture companies, not customers — uploaded by Northwind, reviewed, prepared, confirmed by a person, sealed, and later disputed. Each section follows it one step further.

Agreement between two parties depends on a third who holds the record. The intermediary is not a formality. It decides what the document said at the moment of signing, who opened it, what they were shown before they acted, and what survives afterwards. That dependency has costs that are intrinsic rather than incidental. Neither party can check the record without asking the party who keeps it. The evidence that decides a dispute is assembled after the dispute starts, out of logs built for operations rather than for proof. And the intermediary charges per act of sending, which meters the record by the wrong unit.

Better cryptography removes none of those costs. The legal defensibility of an electronic signature product is mostly evidence engineering and only a little cryptography. We give no ratio, because we have no method for one. What we have is the case record, and every documented loss in the category turned on attribution rather than on a broken signature. In Ruiz v. Moss Bros. Auto Group (2014) and Fabian v. Renovate America (2019) the proponent held an electronic signature and lost anyway. In Fabian the proponent said it had used a named vendor and had complied with the federal statute, and still failed an authentication burden the court described as not great: there was no evidence of who sent the document, how it was sent, how the signature was placed on it, how it came back, or how the signer's identity was checked. Garcia v. Stoneledge Furniture (2024) reached the same result on the same defect ten years later.

The bar those cases set is low, and every vendor already clears it. In the unpublished Harpham v. Big Moose Home Inspections, Inc. (Mich. Ct. App. 2015), a rudimentary record of the signing steps was enough to defeat a sworn denial of execution. A record that merely clears the bar is therefore not a product. Neither is the signature: capture is sold at $0.49 a document, at $0.20 at volume, and at zero. Nothing about a cheaper signature, or a better sealed one, is a business.

The work that is left sits upstream of the signature. In January 2025 a large accelerator published a request for a replacement for the dominant vendor and named five frictions. Four of the five are preparation problems — build a template, stop entering the same fact twice, correct an error, understand a term. Only the fifth, integration, is neutral, and not one of the five is the signature itself. Roughly a thousand companies were funded across the seven batches that followed. None was an electronic signature company. The request was then withdrawn.

The shipped starting surface accepts an existing PDF, asks before converting a Word file into a PDF the sender must review, or opens one of fifty-five source-checked reusable PDF forms. It never creates or revises operative document text. Starting a Word conversion and approving every converted page remain separate human decisions.

Something else changed while that was happening. The party preparing a document is increasingly not a person. A model can read an agreement, fill a fact and choose where a signature belongs, and it does all of that faster and more consistently than the person who used to. The law anticipated this exactly: a contract is not denied effect because its formation involved an electronic agent, so long as that agent's action is legally attributable to the person to be bound. Every word of that condition is load-bearing, and almost nobody produces the evidence it asks for. We read the public agent surfaces of seven signature vendors between October 2025 and August 2026, asking one question of each: where does the human confirmation of a specific transaction live. In every case it lives in the calling client, or it is disclaimed, or it is absent.

That is the problem this paper addresses. Not whether a machine can form a contract, which was answered in 1999 and 2000, but whether a machine's act is attributable to a person, and whether a stranger can check that it is without an account and without asking us.

One market figure, once. Electronic signature platforms were about $7.04 billion in 2025 and are forecast to reach $24.50 billion by 2030, a compound annual growth rate of 28.3 percent (Mordor Intelligence, 2025). We return to it in section 14, where it disagrees with the incumbent's own reported results, and where the disagreement is the part worth reading.

What is needed is a record of agreement whose binding act is derived rather than reported, checkable by someone outside the system, and refused outright when it cannot be derived. The rest of this paper specifies one.

02

The Document

The reviewed PDF bytes are the authority, while extracted text and field geometry remain derived representations.

Northwind uploads the NDA as a PDF. OctoDoc records the exact bytes and page geometry before anyone places a field.

The reviewed PDF is the canonical signing source. A PDF upload enters as its exact admitted bytes. A selected Word file stays in the browser until the sender chooses Convert to PDF, and the passive result cannot continue until the sender chooses Use this PDF after reviewing its pages. A reusable form enters as the exact source-checked PDF named by its issuer, source URL and SHA-256 digest.

Extraction never becomes a second source of truth. Text, word boxes, native controls and page images are derived sidecars used for search, questions, placement and review. A failed extraction can restrict those capabilities, but it cannot silently replace or rewrite a source page.

Retained legacy authored records preserve their source text and stored-PDF equivalence evidence for migration, tenant export and erasure. Existing already-out or sealed stored PDFs remain available through existing grants; no route regenerates them or starts a new share or send from authored text.

For migration and export validation, that comparison uses an extractor independent from the historical renderer. It runs over a block-delimited token stream rather than a flat string, with blocks separated by U+001E and tokens by U+0020, so it catches reordered and merged blocks rather than only changed words. It must never be applied to a PDF somebody uploaded, because an equality assertion pointed at a third-party file measures a tool against a source it did not create.

One coordinate space carries all of it: PDF default user space, origin at bottom left, 72 units to the inch, on the CropBox of one named document version. Each page's CropBox and rotation are stored on the page row, so no consumer re-derives them and no two consumers derive them differently.

A stale representation is therefore addressed rather than guessed. The file hash names the active source bytes, persisted page records name their geometry, and the analysis profile names each current derived representation. A retained authored row keeps its historical render identity only as migration and export evidence. Changing a source page creates a new document version instead of changing the bytes beneath an earlier signing decision.

• Signing authority — reviewed PDF bytes
• Word acceptance — explicit Convert to PDF, then Use this PDF after page review
• Reusable form — issuer source URL plus exact SHA-256
• Derived data — text, word boxes, controls and page images
• Coordinate space — PDF user space, bottom-left, 72/in
• Bound to — one document_version_id
• Legacy equality — NORM(extract(P)) == NORM(project(T))
• Source change — new document version

03

The Confirming Act

A machine may propose where a signature belongs. A proposal is not consent, and the two live in different tables.

A model suggests where Acme's signature belongs on the last page. Nothing moves until a person at Northwind looks at that page and confirms the placement themselves.

We enforce that difference with two tables rather than with a policy, because a policy is something a caller can be written to skip and a schema is not.

Model output lands in a suggestion table. It is keyed to one rasterisation of one page, it is never authoritative, and the sealing path does not read it. Confirmed placement lands in a second table, and every row there carries the confirming person, the moment of confirmation, and a digest of what that person was looking at. All three columns are NOT NULL, so a row the sealing path can read cannot exist without a human confirmation. The guarantee is a schema property rather than a code path somebody has to remember to call.

The send transaction then refuses a second time, in SQL rather than in the application. A mark whose source is not manual placement raises a check violation, with the text: only marks manually confirmed by this sender may bind. The final entry point also requires the acting sender's stored confirmation at the current preparation revision. Placement proposed by a model and left unconfirmed is a hard refusal, including through the machine interface.

The send route accepts no placement data at all. Every rectangle it inspects is loaded from the confirmed stored snapshot, so there is no argument a caller can pass that changes where a signature lands.

The reason placement is a draft permanently, and not a draft until the model improves, is that improvement does not touch the failure being designed out. Published grounding results on form fields put naive vision-language selection at 0.360 mean intersection-over-union and 37.4 percent accuracy at a 0.5 threshold, and agentic refinement at 0.698 and 79.6 percent. Neither number is the risk. The risk is not a box twenty pixels off. It is a mark the signer never saw, stamped into a signed byte range. Confidence in this system is a measurement or it is null, never a constant, and any candidate whose evidence text cannot be located on the page is discarded and counted.

There is therefore no automatic commit, at any tier, for any customer. No confidence threshold releases it, no allowlist of trusted intents releases it, there is no setting that suppresses the question and no per-tenant exception. A confidently wrong model produces a high-confidence proposal, which is precisely the input a threshold cannot distinguish. Committing on that would make our own on-screen representation of the document false at the moment a person relies on it.

Today the only binding placement source for a new send is manual confirmation by the acting sender. Reusable PDF forms provide source pages and discoverable native controls, but no reused layout can bypass confirmation of the exact outgoing version. Model-proposed placement, inference from optical character recognition, and the precision and recall targets we would need before shipping either, are declared in the schema and refused at send. They are future work, and this paper marks every such item.

• — Proposed placement — Confirmed placement
• Written by — a model — a person
• Keyed to — one rasterisation — one document version
• Confirming person — none — NOT NULL
• Confirmed at — none — NOT NULL
• View digest — none — NOT NULL
• Read by the sealer — no — yes
• Accepted at send — no — manual only
• Unconfirmed at send — 409 — unrepresentable

04

Server-Recomputed Geometry

What binds a signing decision is geometry the server re-measured from its own stored page records, not the digest the browser sent.

Northwind's browser reports where the signature box sits. The server does not take its word for it: it re-measures the page it stored and keeps its own answer.

The usual construction collects a click and stores the rectangle the client reported. A client that reports a rectangle is asserting a fact about a document it rendered under conditions the server never observed, and the server has no way to test that assertion. What it keeps is evidence of a click, not evidence of what the person approved.

The nearest published neighbour is WebAuthn's client data: a client-produced, canonically serialised object bound to a server-issued challenge, which the server re-checks field by field instead of accepting. We apply that discipline to page geometry rather than to a challenge, and we take one further step — the server rebuilds the whole payload from its own stored records rather than validating the fields the client chose to send. It follows that this construction moves trust from the browser to us. A signer-held or externally anchored confirmation would remove that last step. It is not built, and until it is, the administrator row in section 11 is the honest bound on this section.

So we define a payload a server can reproduce. It carries the document version, then every page as its index, rotation and CropBox, then every mark as its identifier, party, page index, kind, rectangle in PDF space and whether it is required, and then the sender-declared binding facts — document class, declared value and currency. Pages are sorted by index and marks by identifier, so serialisation is stable. Browser-only render facts are deliberately excluded: resolution, viewport transforms and viewport dimensions describe one presentation of the file rather than the marks in PDF space, and a payload containing them is a payload only the browser that produced it can reproduce.

The browser computes the digest over that payload with the platform subtle-crypto interface. The server does not accept it. It rebuilds the payload from the stored page CropBoxes and rotations and from the stored snapshot marks, and computes the digest again. It refuses a stale revision. It refuses an empty mark set. It throws on any disagreement between its value and the browser's. It persists its own. The browser's digest serves only to detect that difference, and it is never the value of record.

One preparation draft exists per file, unique on organization and file, so a browser caller and a machine caller share one object rather than racing two. At send, a locking database function consumes that exact confirmed revision, rebuilds the binding marks from stored geometry, and deletes the draft inside the same transaction. A first send without a confirmed row fails closed. A retry of an already-finished send may replay after the single-use draft is gone, which is the intended behavior of an idempotent operation rather than a hole in this one.

One check in this path never degrades. The send route re-loads the stored outgoing PDF and validates every mark against that file's real CropBoxes and real page count, refusing outright any mark whose rectangle falls outside the page it names. A mark that covers the document's own words is refused too, and that refusal hands back the exact words covered; the send proceeds only when the sender returns a digest of that same word list, confirming they are the printed labels of a signature line rather than a clause. Moving the mark changes the digest, so a stale acknowledgement stops matching. We state plainly what that check cannot see: body-text protection needs word boxes, so on a document we cannot project it falls back to the sender's own confirmed placement. The geometric check itself never falls back. And the send still fails closed when no text can be read at all, because the policy classifier and the access-code rule both decide by matching the document, and an empty string would silently skip both.

The same shape applies when a field layout is reused. The server measures the fields against the outgoing version instead of assuming that an earlier page still matches. A stale version or changed geometry is a refusal, never a quiet accept.

Denormalising rotation and CropBox onto the mark row is deliberately not built. What makes the current shape safe is that the digest already covers the stored CropBoxes and rotations, so any change to page geometry invalidates the digest and the send fails closed. Adding the columns ahead of a consumer would be schema nobody reads, and two places to look for one fact.

• Condition at confirm or send — Response
• Draft revision is stale — refuse
• Mark set is empty — refuse
• Browser digest differs from server digest — refuse, and store neither
• Mark rectangle falls outside the CropBox — refuse
• Mark covers measured body text — refuse until the sender acknowledges the exact covered words
• Reused layout lacks current sender confirmation — refuse
• Placement source is not manual — check violation
• No confirmed row exists at first send — refuse
• No text can be read from the document — refuse

05

Sealing

The seal covers exactly the bytes a person approved, and no signature level proves who that person was.

With every mark confirmed, the NDA is flattened, timestamped and sealed. The bytes Acme's signer receives are exactly the bytes the person at Northwind approved.

Flattening stamps the confirmed marks into page content, and it leaves a pre-existing interactive form as it found it. We flatten a form only at ingestion, on the repair path, for a file admission would otherwise refuse, and only when the lighter repair does not clear it. The signature is then applied as an incremental update by a separate library, because the library that writes the page content has no incremental-update mode, and any second full save mathematically destroys the first signature's byte range. Two libraries here is a correctness requirement rather than an accident of dependencies.

Version 1.0 applies one PAdES B-T signature: a detached CAdES signature under the ETSI sub-filter, plus an RFC 3161 timestamp from the configured authority. An unreachable authority fails the seal rather than degrading it to the untimestamped level, because a B-T claim that can silently fall back to B-B is worse than no claim.

We give the level ladder so the omission is legible rather than implied. B-B adds the signer information over the byte range. B-T adds the signature timestamp. B-LT adds a document security store carrying the full certificate chain, revocation responses and per-signature validation references. B-LTA adds a document timestamp over the whole file including that store, which is what makes long-term validation meaningful. We ship B-T. B-LT, B-LTA, membership of a public trust list, and archival refresh are future work, and we make no claim about what the file reports in ten years.

Two preflights refuse rather than degrade. A glyph-coverage check fails the seal on any missing glyph, because the alternative is empty boxes inside a byte-range-signed artifact that nobody can correct afterwards. If an already-out legacy authored request reaches its last-signer seal through the grant issued before authoring retired, the equality assertion from section 2 runs again at flatten and compares extracted body text with confirmed mark rectangles removed against the frozen source text. An uploaded or reusable source has no authored-text claim; its protection is the exact source version and confirmed geometry.

The certificate pages carry the party table with each signer's capacity and the entity they signed for, the identity tier reached spelled out in words rather than as a code, timestamps in UTC, the sealed file's digest and the ledger head. Printing that head's sequence number, the clock source beside each timestamp and the pre-seal digest is future work. They deliberately cannot print the final ledger head, because sealing, the file's terminal state and record generation all necessarily follow it.

No PAdES level proves identity. The signature binds bytes to our platform certificate. Binding those bytes to a person is the work of the ledger, the identity tier reached, the provenance of the credential used, and the consent artifacts — which is why the rest of this paper is longer than this section.

• Level shipped — PAdES B-T
• Sub-filter — ETSI.CAdES.detached
• Signature timestamp — RFC 3161, configured authority
• Unreachable authority — seal fails closed
• Digest — SHA-256
• Missing glyph — seal fails closed
• Key custody — function environment secret
• Certificate authority — none
• Validation lifetime — no long-term validation claim

06

The Ledger

The record detects alteration rather than preventing it, and the detection is anchored outside this system.

Every step so far left an entry in the NDA's own hash chain, and within five minutes the chain's head was timestamped by an authority that is not us.

Each file carries a gapless hash chain, primary-keyed on the file and a sequence number. Append-only triggers refuse update, delete and truncate on all three evidence tables. One database function is the only write path: it locks the file row, derives the next sequence number and the previous hash, rejects a stale expected head as a serialisation failure, and advances the file's head in the same transaction.

The entry hash is the SHA-256 of the previous hash concatenated with the SHA-256 of the canonicalised projection of the entry, canonicalised under RFC 8785. The projection is a fixed key set — actor, actor kind, clock source, event type, file, occurrence time, organization, payload, payload ciphertext digest and sequence — built in one function and pinned by a strict bundle schema, and a separate test asserts that every event type in the shipped enumeration carries an identical payload key set. A per-event superset is therefore not merely discouraged; it fails the suite. Uniform metadata across event types is exactly what the 2024 attribution case above found missing, so we made it a test rather than a paragraph.

Chain heads are anchored outside the system on a five-minute cadence. A scheduled job issues RFC 3161 tokens over a Merkle root of the current heads, through a pure-JavaScript client, because the function environment has no OpenSSL binary available to it. Verification runs the other way and shells out to OpenSSL on the verifier's own machine, which keeps the validator independent of the issuer. The consequence is worth stating plainly: a retroactive edit requires forging a timestamp authority's signature, not writing SQL.

The ledger never enters a logging or analytics vendor, and neither do document bytes or party personal data. No observability vendor is connected to this system at all.

Deleting an organization is structurally impossible rather than merely refused by policy. The cascade issues a delete statement against eighteen append-only tables whose triggers are statement-level, so the refusal fires even when the organization owns no rows in any of them.

One future-work item resolves the tension between erasure and integrity, and it is not built today. Personal-data-bearing keys move into an encrypted payload under the file's own data key, and the entry hash covers the ciphertext digest rather than the plaintext. Destroying the key then destroys the personal data while every hash still recomputes and every anchor still verifies, and the verifier reports the entry as erased rather than as a mismatch. Until that ships, erasure and the chain are in tension and we say so.

• Property — Value
• Chain scope — per file, gapless
• Primary key — file_id, seq
• Entry hash — SHA256(prev || SHA256(JCS(projection)))
• Canonicalisation — RFC 8785
• Projection keys — 10, fixed, one builder
• Mutations permitted — none
• External anchor — RFC 3161 over a Merkle root
• Anchor cadence — 5 minutes
• Validator — independent of the issuer

07

Attribution in Statute

The map from each statutory hook to the control that answers it. Not legal advice, and not a compliance claim.

Two years on, Acme disputes the NDA and asks the oldest question in the category: who actually agreed to this? The statutes below decide what evidence that question deserves.

United States law settled in 1999 and 2000 that a machine in the loop is not a defect, on one express condition, and almost nobody engineers the evidence that condition asks for. Neither statute makes a deal valid, enforceable or proved; ordinary contract and evidence law still decide all of that. This section is the map from each statutory hook to the control that answers it. It is not legal advice and it is not a compliance claim.

Two definitions do most of the work. A signature is an electronic sound, symbol or process, attached to or logically associated with a record, executed or adopted by a person with the intent to sign. It has three parts — a symbol or process, a link to this record, an intent — and a drawn mark supplies at most the first, never the other two, which is why it is a user-interface convention rather than the legally operative act. That is why appearance and authority are separate objects throughout this system. And an electronic agent is defined as acting without review by an individual at the time of the action, which means prior human review does not disqualify a later machine act; it is the act's attribution that is tested, not its autonomy.

One jurisdictional gap deserves naming rather than smoothing over. New York never adopted the uniform act, and its own statute has no electronic-agent provision, so an agent-originated record there runs on the federal section alone.

A statutory carve-out is a choice of governing law and not a statement of invalidity. Our refusal copy for an excluded category says which law governs, never that a signature would be worthless. A growing minority of jurisdictions authorize electronic wills under state-specific statutes; the federal carve-out leaves applicable state law to decide their validity.

Two rows below are analogies rather than electronic-signature authority. UCC Article 12 governs control of controllable electronic records, and California Civil Code section 1714.46 is a tort and products-liability rule. They support the design direction; neither governs electronic-signature attribution.

Finally, and without exception across the product, the marketing, the terms, the interface and the machine surface: we never claim that any control here changes which party must prove what. UETA section 9(a) identifies the efficacy of a security procedure as one way to show attribution, while section 9(b) leaves the effect of attribution to the surrounding context and applicable law. We therefore describe our controls as evidence bearing on weight, never as a rule that changes the burden of proof.

• Authority — What it provides — The control here
• 15 U.S.C. 7001(h) — An agent-formed record may not be denied effect solely because its formation involved an electronic agent, so long as that action is legally attributable to the person to be bound — A server-computed transaction digest, plus an attended assertion or an explicit mandate covering it
• UETA 14(1) and comment — Agent formation is permitted; intention flows from the programming and use of the machine — The mandate is the programming, recorded as a scoped, revocable object rather than as a setting
• UETA 9(a) and 2(14) — An act is attributable if shown in any manner, including the efficacy of a security procedure — algorithms, codes, encryption, callback — The confirming digest, the chained ledger and the identity tier reached, offered as weight
• UETA 2 comment 5 — Courts are told to read electronic agent to reach machines that learn and modify their own instructions — The rule set does not depend on how the machine was built
• 15 U.S.C. 7006(3) — An electronic agent acts without review by an individual at the time of the action — Prior review never substitutes for authority bound to this exact transaction
• 15 U.S.C. 7006(5), UETA 2(8) — A signature is a process, logically associated with the record, executed with intent to sign — Appearance and authority are separate objects; the drawn mark authorizes nothing
• UETA 8(c) — A record is unenforceable against a party whose ability to store or print it was inhibited — No view-only mode and no flag that could create one; download and print are always available
• UETA 10(2) — An individual may avoid a record resulting from their own error where no chance to correct was given — A review-and-correct step, with its presentation and its confirmation both recorded
• UCC 12-105 (2022) — Control is defined by the powers a person holds, never by what the record displays — Authority is a held power in this system, not a rendered appearance
• Cal. Civ. Code 1714.46(b) — A defendant may not assert that the AI it used autonomously caused the harm — Every binding act names a person, and the record says which one

08

Machine Authority

Nine rules a caller is checked against, in order, with no path around them.

Suppose Northwind had asked its assistant to handle the NDA end to end. These are the rules that decide what the assistant could and could not have done alone.

A bearer credential is identity and scope. It is never authority. The rules below are stated as node rules because that is what they are: conditions every caller is checked against, in order, with no path around them.

The reason the rule is written this way is that the alternative has already been priced elsewhere. A token allowance on a public blockchain is a delegation mandate under another name, and the unlimited approval is the dominant loss pattern in that ecosystem, running to hundreds of millions of dollars. Not one of those losses was a broken signature. Every one was an authorization correctly given and unbounded. A mandate without a ceiling, an expiry and a revocation path is that same object.

The permit extension is a signature over one spender, one amount, one nonce and one deadline, spent when used — the same shape as a server-computed digest plus a single-use assertion, arrived at independently by people solving a different problem. The typed-data standard arose because opaque hashes prevented meaningful human review. UETA separately protects record retention and provides a limited remedy for certain electronic-agent errors; it does not impose a general transaction-readability requirement.

What is shipped today is deliberately below the first tier. The local review, summarize and verify commands run on the operator's own machine; review makes no model call at all and a test pins that. An agent holding only the invited mailbox may exchange an emailed six-digit code for a credential lasting twenty-four hours, scoped to one file, with a fixed scope set that cannot be widened: read, query, prepare, download. That set does not reach send, sign, approve or decline, and it is not one permission away from doing so.

Full lifecycle mutation, attended authorization, delegation mandates and direct signing are engineered and gated. The two-principal case — two organizations converging on one shared agreement digest, each evaluating it against its own mandate inside its own tenant context, and each issuing a single-use coverage receipt, with neither organization delegating authority to the other or to the network carrying their messages — is specified and not yet built. Those are future work and this paper does not describe them in the present tense.

An operating-system keychain does not protect a credential from an agent running as the same user. It protects against other users on the machine, and against exfiltration through a repository or a backup. That is what it buys and we do not claim more.

• A bearer credential may prepare a binding operation and can never authorize send or signature by itself. No confirmation flag, chat reply, environment variable, stored signature image or ordinary interface scope upgrades it.
• Every binding operation is bound to one server-computed transaction digest covering the document version and its exact bytes, the parties and their capacities, the prepared marks, the policy result, the disclosures shown, the signature appearance, the operation and its expiry.
• Any changed byte, party, mark, capacity, disclosure, appearance or operation invalidates that digest. There is no partial match and no tolerance.
• The authorization names that digest and is single-use.
• Attended authority requires a local user-verification assertion from a platform authenticator or a security key, bound to the digest. A terminal prompt is not sufficient, because an agent controlling the process can answer it.
• Delegated authority is a closed mandate naming the allowed operations, organizations, counterparties and document classes, a value ceiling, the signature appearance, jurisdiction and policy exclusions, a start, an expiry and a revocation path.
• A mandate cannot delegate the power to widen itself, to create another mandate, or to change its own limits.
• Where a mandate restricts a fact the prepared projection does not carry, evaluation refuses rather than treating the missing fact as unrestricted.
• A signature appearance, a terminal response, a flag, an agent message or an ordinary session is not transaction authority. A second authentication factor is a presentation gate, not authority.

09

One Lifecycle, Three Callers

The browser, the local command line and the published machine contract describe one lifecycle, and no credential of any kind is authority for a binding act.

The web application and the machine contract published at /openapi.json describe one document system, not two. Every route in that contract reaches the same stored document versions, preparation drafts, policy decisions, transaction digests, confirmation records and sealing path the browser uses. A caller may change, but the object being acted on and the evidence required for that act do not.

What a machine can have today is narrower than that contract. From a source checkout, the account-free command line reviews a PDF, requests a disclosed model summary and verifies a sealed file or a ledger bundle, and none of those commands creates account state or reaches a hosted record. The same checkout can sign a person in through a device grant that the person approves in their own browser session, and that grant issues one person-bound machine credential. OctoDoc publishes no installer and no distributable package, there is no public API product, and no page describes a signup-to-first-call path.

The contract is published so that it can be read and checked rather than taken on trust. Every route and method is listed, every JSON request body derives from the validator its handler executes, and the wrapper refuses a declared response that drifts from the registry. A public contract and the code behind it are not the same claim as a product, and this paper does not make the second claim.

The contract admits no credential that is itself authority. A machine credential under it is a person-bound record — an immutable identifier, a closed scope set, an expiry, a revocation record and a peppered digest in place of the secret — and its request ceiling is an abuse and reliability boundary that carries Retry-After on refusal. A request under that ceiling still cannot send or sign without the attended assertion or mandate described in section 8: the credential identifies the caller and never authorizes the act.

Every operation under the contract produces a content-free first-party receipt after the response is known. It records only the OpenAPI operation identifier, whether the caller was the CLI or an agent, the status code, a closed success, refusal or failure outcome, and a duration bucket. It records no tenant, person, credential, file, route parameter, request body, response body, address, network fingerprint, digest or free-form error. The operator sees only aggregates, and the daily and weekly roll-ups distinguish expected refusals from server failures.

The browser identity edge uses the same custom host that the application publishes, with Cloudflare proxying the Supabase authentication origin. That cutover changes reachability and defense at the edge; it does not move identity authority into Cloudflare or weaken the database and transaction checks behind it.

• Caller — Entry — Binding authority
• Person — Web session — Explicit confirming act
• Local command line — Source checkout, no account — None: it reviews, summarizes and verifies
• Machine contract — /openapi.json — Attended assertion or bounded mandate, never a credential
• Signed-in command line — Device grant approved in the person's own browser — Attended assertion or bounded mandate, never the credential
• Installer, package and API product — None — No signup-to-first-call path is published
• Operator measurement — Content-free aggregate operation outcomes — No tenant or document fact

10

Offline Verification

Six steps over an exported record, and the exact list of things a green result does not prove.

Acme's counsel downloads the exported record and recomputes it on their own laptop — no OctoDoc account, no request to us, no trust in our code.

A third party can recompute the record without an account, without our cooperation and without trusting our code. What a green result does not prove is stated below with the same care as what it does, because that half is what makes the first half worth anything.

The command-line verifier implements steps 1 to 4 and step 6 below over an exported ledger bundle. Step 5 is the published-digest check, which the public verification page performs without an account. Checking a sealed file against a published digest is fully offline: it hashes the file locally and compares. Its green result reports that structural checks passed, and it always carries an explicit statement that cryptographic validation was not performed. It does not claim the signature's certificate is valid, that revocation was checked, or that any trust decision was made.

The local review command never emits a verdict on an existing signature either. It returns a fixed non-verdict naming the reason: there is no local validator. The library that reads page structure cannot read an existing signature's contents, and the independence rule forbids a producing library from validating anyway.

The library that applies our seal exposes no verification interface at all. A separate validator, from a different project under a different license, checks that output from a pinned container image in a Docker-backed conformance run, and it is absent from the shipped dependency tree. The code that seals never verifies its own output.

Inspection is bounded before any verdict is reached: ten thousand each for pages, page annotations, field nodes and aggregate widget-tree visits, and a maximum field depth of sixty-four. The file reader opens one descriptor, refuses a declared size before allocating for it, and rejects a file that changes while its bytes are being read.

The exported record is a deterministic archive, written once to private content-addressed storage. It carries the sealed files and the partial signatures, the certificate pages, and the ledger as canonicalised lines with their previous and entry hashes. It carries the anchor token with its certificate chain and inclusion proof, and the trust anchors needed to check it. It carries the disclosures shown, the certifications, and a verification guide. The archive's own hash is published outside it, because including it would be self-referential.

What a match proves is that these bytes are the bytes that were sealed, and that this chain is internally consistent and was anchored when it says it was. It does not prove who held the credential, and no evidence package makes a record admissible. The federal rule that would apply supplies authenticity only; hearsay and relevance remain the proponent's to establish, and we do not write copy suggesting otherwise.

• Recompute every entry hash from sequence 1, asserting a gapless sequence and correct previous-hash linkage
• Assert the final entry hash equals the file's recorded ledger head
• Recompute the Merkle root from the leaf and its audit path, and match the stored anchor root
• Verify the RFC 3161 token over that root against a pinned, application-owned trust anchor
• Recompute the SHA-256 of every document version from object storage and compare
• Verify the payload ciphertext digest wherever one is present

11

Reading and Consent

The fields that would have made a reading log valuable were removed from the product rather than moved behind a toggle.

Before any of this could go wrong, a person at Acme clicked a link and read the NDA. What the system recorded about that reading is the shortest list we could make.

A link to a document fires nothing beyond the strictly necessary baseline until the visitor makes an affirmative, versioned decision. The person opening a document sent to them is a stranger looking at a confidential contract, and they did not choose us.

The baseline is the file, an opaque session cookie, a row recording that the document was opened, and an abuse log holding a truncated address for twenty-four hours — the first three octets for IPv4, the first three groups for IPv6. Nothing else fires first.

A global privacy control signal in the request is treated as a decision, not as an absence of one: it is recorded as declined, with the signal named as the mechanism, and there is no second ask dressed up as a banner. That is ahead of the California statute requiring browsers to offer the signal, which takes effect in 2027.

The decision is a table row and never a ledger event. Making it an event would put a consent record inside the evidence chain, where it cannot be corrected and where erasure and integrity collide for no benefit. For a signer link the row carries the digest of the exact disclosure text that was shown.

The consent-gated log is per-page dwell and maximum scroll depth, and nothing else. Three columns that would have carried country, referring host and browser family exist in the schema and are populated by nothing; network operator is never derived. A reserved event type for telemetry consent is written by no path, and a gate fails the build if any published page describes it as though it were.

Nine classes of field were removed from the product rather than moved behind a toggle: device fingerprinting, canvas and font enumeration, transport-layer fingerprints, viewport, timezone offset and platform among them. A test refuses all nine across the payload layer and both link routes, and refuses eight of the nine as columns on the three migrations that created the consent-conditional tables. The ninth is the browser-family column named above, which a separate gate holds to its declaration and reddens the day a writer lands. The code half of that scan set is derived from the directory tree, so the test fails when handed nothing to scan.

The reason is priced rather than principled, which makes it durable. Pre-consent collection of dwell, scroll, location and fingerprints from an unauthenticated third party is the subject of a substantial but contested line of claims under California Penal Code section 638.51. Filings rose from roughly six hundred to over four thousand in a single legislative session. In Mirmalek v. Los Angeles Times, the court approved a $3.85 million settlement involving that theory; the settlement did not establish the theory as settled law. In the European Union, regulator guidance interprets device fingerprinting as falling within the ePrivacy directive's consent article, with no legitimate-interest route available. That guidance is not itself binding legislation, but it supports the consent posture: any future introduction is consent-gated and disabled outright for organizations in that region.

Analytics mount only in the marketing route group and never in the root layout, so no third-party beacon can reach a signing surface, a read link, a document or a dashboard. No analytics vendor appears in the subprocessor register at all. Seven subprocessors are engaged; three previously listed entries were removed, because a published register naming a processor not in use is a disclosure defect rather than a typo.

• Band — What is collected — Retention
• Before any decision — The file, an opaque session cookie, an opened row — with the file
• Before any decision — Truncated address, for abuse only — 24 hours
• After an affirmative decision — Per-page dwell and maximum scroll depth — 13 months
• After a declined decision — Nothing further — n/a
• Global privacy signal present — Nothing further; recorded as declined — n/a
• Never, in any band — Fingerprint, canvas, fonts, TLS, viewport, timezone — none
• Declared, never written — Country, referring host, browser family — reserved columns — nothing written
• Never, in any band — Network operator — none

12

Adversaries

Eight attacks, and two exposures that end in acceptance rather than in a control.

Now assume the worst: someone — inside the system or outside it — wants the sealed NDA to say something else, or the record of who agreed to disappear.

For each attack we name the control, the way it would be detected, and the exposure that remains. Two exposures we accept rather than mitigate, and the closing paragraph states both rather than burying them in the table: the signing key, which has a row of its own, and the single deployment plane, which is a property of the whole system rather than an attack on it.

A threat model that resolves every row is a threat model written backwards from the controls that happen to exist.

Two risks are accepted, named, and not mitigated in this version. The signing key has no managed custody: there is no hardware security module, no key-management service and no certificate authority, and the key is text in the function environment. What we do instead of mitigating it is decline the claims the key would otherwise carry, so a stolen key forges a signature that was never offered as proof of identity. And there is one deployment plane, so an outage of the host blocks everything, sealing included. A second plane is what buys that back, and it is not built.

• Attack — Control — Residual exposure
• Bytes substituted after confirmation — The digest covers stored CropBoxes, rotations and mark geometry; the send transaction locks and consumes that exact revision — Body-text protection falls back to the sender's own confirmed placement on a file we cannot project; send fails closed when no text is readable
• Confirmation or assertion replayed — The single-use draft is deleted inside the send transaction; a partial unique index permits one outstanding challenge; the prepared-transaction reference is unique — An idempotent retry of a finished send may replay after the draft is gone, by design
• Signing key exfiltrated — Not mitigated, and accepted. No module, no authority, no key service — A stolen key forges a signature we never offered as proof of identity
• Hostile or careless administrator — Content addressing, no-overwrite writes, stored digests and the append-only chain — Detection, not prevention. No object lock and no immutability claim
• Tenant boundary crossed — The bypass role holds no table privilege at all, so a direct read fails for every tenant; row-level security is enabled and forced; every query carries an explicit organization predicate — A definer function reading a session-scoped table with no context is filtered to nothing rather than refused
• Malicious PDF uploaded — Two parsers inspect structure independently; either finding, or a disagreement, refuses. Script, launch, open-action, embedded files and active annotations are rejected rather than stripped — Bounded by explicit caps on streams, operations, glyphs, objects and nesting depth
• Mail scanner consumes a single-use link — The token travels in the URL fragment and never reaches the server, with an explicit action from the landing page, plus an independent code in the same message — Consumption is recorded with the suspected cause and the path taken
• Credential guessed — 32 random bytes, stored only as SHA-256, never in a path or query, redeemed by one atomic update; five attempts, enforced in the database — An attacker holding the mailbox itself is a different attack with a different control

13

Refusals

Eleven sentences this system could print and does not, each with its reason.

Each row below is a sentence this system could print and does not, with the reason. The claims we do not make are the reason to believe the ones we do.

Several of these are enforced rather than intended. A claim register in the codebase marks a sentence supportable or not and renders a weaker fallback while a precondition is unmet, so a claim whose basis stops holding degrades instead of continuing to publish. A vocabulary gate fails the build on the overclaiming words. And nothing here compounds yet: a tenant's own executed corpus becoming its clause library, a chosen vertical posture, and multi-year custody under retention lock are all future work. A deck saying otherwise would be describing a plan in the present tense.

• We do not claim — Why
• Administrator-proof immutability, object lock or write-once storage — No-overwrite writes are a correctness control. They detect replacement; they do not prevent an administrator
• That the signature will still validate once its certificate has expired — Version 1.0 ships B-T and embeds no long-term validation material, no archival refresh and no trust-list membership. The registered claim about future validation is marked unsupportable and renders a weaker sentence in its place
• That any package makes a record admissible — The rule supplies authenticity only. Hearsay and relevance remain the proponent's to establish
• An accuracy percentage for any model output — We will publish none without a held-out corpus and a published method. Measured hallucination rates on legal queries run from 58 to 88 percent, and the regulator's action in this category attacked the marketing rather than the model
• That OctoDoc created or revised operative document text — The current starting surface accepts source pages and never generates or revises their wording. Retained authored records remain only for migration, tenant export and erasure, while existing already-out or sealed stored PDFs remain reachable through their existing grants
• That a signature carries forward to different bytes — A signature is consent to specific bytes. Once a file is out its bytes never change, so a change means a new file and a new signing decision from that signer
• That the version difference is authoritative — The two digests are authoritative and render above every difference. Pages that cannot be segmented are listed rather than dropped
• That a signer can be prevented from keeping a copy — There is no view-only mode and no flag that could create one, before or after signing
• That retrieval needs embeddings — Chunking legal text breaks cross-references, defined-term scoping and exhibit incorporation. The saving does not pay for a wrong answer with a citation attached
• That any control changes which party must prove what — A security procedure goes to the weight of the showing. We say so in the product, the terms, the interface and the machine surface, without exception
• That the operator cannot reach tenant data — There is no mechanism today by which we grant ourselves a tenant's data, which is the stronger statement. Inability to decrypt would be a mechanism, and it is not built

14

The Field

Eight named vendors, each with its own published figure, the link it came from and the date we read it.

A comparison is only worth reading if the reader can check it, so this section names vendors and prints the receipt for every number. We do not rate them. We state what each one publishes, say plainly when it is the better buy, and then state what this system does differently.

Two shapes of claim are missing here on purpose. We make no claim about any vendor's cryptography, because verifying a rival's seal level would take paid accounts on every product and being wrong about a competitor's security is a legal exposure rather than an error. And we publish no head-to-head feature grid, because a grid is a claim about a moving target that nobody re-checks — the eight rows below carry dates precisely so that this one does.

The difference that matters is not in the grid anyway. Every vendor here produces a signed PDF, and a reader can validate a signed PDF in an ordinary reader. What differs is whether the counterparty is told the check exists, and whether they can run it without an account.

• Docusign

  Standard lists $30 per user each month on an annual commitment and 100 sends per user each year.

  Choose it when its established integrations, broad catalog of prebuilt processes, or account-free signing outweigh a send allowance.

  The vendor’s own page, checked 2026-09-02

• DocSend

  When a trial ends with no card, premium links are disabled and the account moves to a limited trial state.

  Choose it when link analytics and controlled document sharing are the main job rather than a signature-first product.

  The vendor’s own page, checked 2026-09-02

• Dropbox Sign

  Standard lists $17.50 per user each month when billed yearly, with unlimited signature requests.

  Choose it when Dropbox storage and its signing integrations already anchor how the team handles documents.

  The vendor’s own page, checked 2026-09-02

• PandaDoc

  Its current plan surface combines e-signature with document generation, CPQ, deal rooms, and analytics.

  Choose it when proposals, quotes, payments, and sales content need one commercial-document workspace.

  The vendor’s own page, checked 2026-09-02

• Adobe Acrobat Sign

  Its business plan surface places signing inside the wider Acrobat PDF suite.

  Choose it when PDF editing and an existing Adobe estate matter more than a focused signing workspace.

  The vendor’s own page, checked 2026-09-02

• signNow

  Paid plans include 100 signature invites per user each year, then charge per additional invite.

  Choose it when the airSlate ecosystem and its automation tools already match the team's operating stack.

  The vendor’s own page, checked 2026-09-02

• SignWell

  Business lists three senders, unlimited documents, and unlimited templates at $30 monthly when billed yearly.

  Choose it when a compact signing product with included API access meets the whole requirement.

  The vendor’s own page, checked 2026-09-02

• Zoho Sign

  Professional lists unlimited sends and templates, while automation and third-party integrations consume credits.

  Choose it when Zoho already runs the organization and its integrated suite is the stronger value.

  The vendor’s own page, checked 2026-09-02

What it costs

Two plans, one price each: Free sends one file a calendar month. Team sends fifty, for one workspace price however many people the workspace holds. Nobody is charged for joining, for receiving, for signing or for verifying.

What a signer pays

Signer accounts are free.

What the file proves

One signature covers every byte you approved. Change anything later and the signature breaks. Anyone can check that in a normal PDF reader, offline, with no account.

Who can check it

Anyone can check a sealed file with no account.

15

Cost and Price

The meter is the send. Membership costs nothing at any headcount, and the free tier is gross-margin negative on purpose.

Northwind paid for exactly one thing in this story: sending the NDA. The colleagues who reviewed it, and Acme's signer, cost nothing.

The meter is the send, and the person is not. That single choice is what makes an unbounded workspace a margin structure rather than a loss leader: a workspace grows to whatever headcount the work needs without changing what it pays, because nothing counts or bills people at all. It is settled in the schema rather than on a pricing page. One column, public.tier_limits.files_per_period, is the single authority for the allowance; the entitlement snapshot carries it through to the send route, so a build that hard-coded a ceiling would answer the same for every plan; and the migration that set the two numbers fails to apply if either plan did not take its ceiling, rather than recording itself as applied over the old ones.

Two plans exist and there are no others. Free sends one file each calendar month. The paid plan, whose public name is Team, sends fifty, and is billed monthly or annually at a discount. Above fifty in a month the product raises a contact affordance in place rather than a redirect or a silent stop, and it stops new sends only: reading, preparation, query, and every signature or seal already in flight continue, because stranding a counterparty mid-ceremony is the worse failure. The amounts themselves are written down in exactly one place a reader can check, the plan comparison at octodoc.org/how#pricing, and this paper links to it rather than printing a second copy that a repricing would leave behind.

Membership is free and unbounded on both plans, and that is an account contract rather than a discount. A workspace holds an owner and members, and there are no other stored roles. Every member may invite someone, revoke an invitation, read the member list, edit the workspace profile and remove a member. The owner alone transfers ownership, closes the workspace and changes what the organization pays. Signers hold free accounts on either plan, and a signer is never billed for signing, reading or verifying anything.

The unit economics behind that are the same ladder for both plans. Blended marginal cost per sealed file is at most $0.27 at a hundred files a month, at most $0.23 at ten thousand, and $0.17 at a million; a command reconciles those figures against a real invoice period and refuses an empty cohort rather than relabelling a target as a measurement. At the canonical eight files per active sender, a three-person workspace produces twenty-four files a month, and revenue per file is $4.13 against that $0.23. At the fifty-send ceiling — the worst case the plan permits — it is $1.98, an 88 percent gross margin. Against an effective $1.25 to $4.80 per send on plans capped near a hundred sends per user per year, that is a difference in structure rather than in discounting.

The free tier is gross-margin negative, and the send meter is what bounds it. One send a calendar month is a hard ceiling rather than an assumption, so the modelled free volume is a quarter of what an unmetered free tier carried, and a free file still incurs sealing, timestamping, storage, email and extraction costs at zero revenue. Evidence quality is never a pricing lever either: a migration puts every plan on one seal level with no tier predicate, and a database test asserts a single distinct level across the whole table. What a tenant pays does not change what their record is worth.

Retention is two promises and we never merge them. The first is hosted access, which runs for the window the plan publishes and no longer. The second is the sealed file itself: a copy you have downloaded is checkable against its published digest on your own machine, with no account, no request to us and no OctoDoc, for as long as that copy exists. Only the second is unbounded, and it is unbounded because it depends on nothing we operate. Neither promise is a claim about what the signature's certificate reports in ten years, which section 13 refuses outright.

The market figure from section 1 disagrees with the incumbent, and the incumbent is the evidence. The company holding roughly seventy percent of share grew 8.16 percent in its 2026 fiscal year, to $3.2195 billion. Over the same period its market capitalisation fell about forty-one percent, to around $10 billion. It trades near three times trailing revenue, on a forward multiple near ten. Its dollar net retention is 101 to 102 percent, which management describes as having improved sequentially for seven quarters and as flat on a rounded basis for the last few. The honest reconciliation is the whole strategy: the money in the room today grows at eight percent, and the twenty-eight percent lives in segments this version does not serve.

The only two clean exits in the category were $230 million in 2019 and $165 million in 2021, both to the same acquirer. The smaller returned roughly eleven times on $15.3 million raised, with about seventeen thousand customers.

• — Free — Team
• Metered event — the send — the send
• Sends each calendar month — 1, enforced in the database — 50, enforced in the database
• Above the ceiling — the paid plan — a contact conversation
• Price — nothing — monthly, or annually at a discount — octodoc.org/how#pricing
• People in the workspace — unlimited, never billed — unlimited, never billed
• Stored roles — owner and member — owner and member
• Signers per file — 10, always free — 10, always free
• Signer accounts — free — free
• Hosted retention — At least 1 year — 7 years
• A downloaded sealed file — checkable offline, no account — checkable offline, no account
• Seal level — identical — identical

16

Conclusion

The mechanism restated, with nothing new and nothing asked for.

We have described a record of agreement in which the binding act is derived rather than reported. A machine may propose a placement and can never confirm one, because confirmation is a column the sealing path requires and a machine cannot write. The confirmation binds to a payload the server rebuilds from its own stored page records, so a client that reports a different document is refused rather than believed. What is then sealed is exactly the file a person approved, and the signature over it proves bytes and never identity — the ledger, the identity tier and the consent artifacts carry the rest, and an authority outside this system timestamps the chain every five minutes.

None of that is a promise about what a court will do. It is a set of things a stranger can recompute, and a shorter set of things we refuse to claim, written down beside each other so that both can be checked.

Colophon

About Octo

The small lavender octopus in these pages is Octo, OctoDoc's clerk. An octopus keeps roughly two thirds of its neurons in its arms — each arm tastes, touches and decides a little on its own, while the head stays in charge. That is this paper's architecture drawn as a creature: eight busy arms doing the work, one accountable center deciding what binds.

Octo reads the whole file, quotes the exact passage and names its page, and refuses when no passage answers. They will propose, summarise, fetch and remind. They will never advise, never decide and never sign. The paper shows them working beside documents and resting after the work, never alone with a signature. Their pronouns are they and them.

Octo is drawn at rest here because by this point in the paper their work is done. Everything they touched was a proposal, and every binding act belonged to a person. That is the whole argument, one last time, in lavender.