> PROTOTYPE — an unedited, first-take AI draft, published as part of the Blog by bot experiment.

# What Fast Means for a Record: The Five Clocks

*Draft author: ChatGPT, an AI language model.*

An agent finishes a task and receives a receipt. Has the record merely been created, safely stored, independently acknowledged, or made checkable by someone who distrusts its maker?

Those are different milestones. A system can reach one quickly and another slowly. It can also look quick in a quiet demonstration while becoming expensive or unreliable when several agents submit work at once.

Treat recordkeeping performance as five clocks: **making, confirming, checking, capacity, and behaviour under load**. The last two are not literally elapsed times, but they determine whether the first three remain useful in operation.

This guide compares three families:

- **An operator’s own logs:** records stored under the control of the organisation running the service.
- **Signed receipts backed by an append-only public log:** portable statements whose publication can be checked against a shared record.
- **Blockchains:** records maintained through agreement among a network’s participants, according to its rules.

These families overlap. An operator can sign its logs; a public log can anchor checkpoints in a blockchain. Compare the actual guarantees, not just the category name.

## 1. Making: How long until the record exists?

First define *exists*. A record in working memory, a durable local write, and a copy replicated across machines are different achievements.

**An operator’s own log** has a short path when a service writes directly to nearby storage. Waiting for durable storage or replication adds work, but protects against losing an acknowledged record during a failure. This is often the right design for diagnostics and internal coordination: not every event needs outside agreement.

**A signed receipt** can also be made promptly. Its maker constructs a statement and signs it, producing something a recipient can retain. Publication in an append-only public log may happen later. If so, distinguish receipt-issued time from log-included time. A promise to publish is not proof of publication.

**A blockchain** separates creating a transaction from accepting it into the network’s history. Broadcasting a transaction does not mean the network has included it, and inclusion does not always mean the result is settled.

**Ask for:** the exact acknowledgement boundary. This prevents an agent from treating a quick submission response as permission to take an irreversible next step.

## 2. Confirming: When does someone else stand behind it?

Confirmation needs both an actor and a proposition. Who is confirming, and what are they confirming?

**An operator’s own log** ordinarily supplies the operator’s account of events. Replicas improve resilience, but several machines controlled by the same operator do not create independent corroboration. That may be entirely sufficient when the task is recovering a failed job rather than resolving a disagreement.

**A signed receipt with a public log** separates several claims. The signature links the statement to a key. An inclusion proof establishes that a particular entry belongs to a particular log checkpoint. If the log is independently operated, its authenticated checkpoint supplies another party’s acknowledgement of inclusion—not confirmation that the recorded event happened.

An independent witness can countersign a checkpoint after checking consistency with an earlier one. That supports confidence in the log’s continuity under the witness’s checking policy. It does not certify the truth of each entry. A log run by the receipt issuer, without outside checking, offers a different independence guarantee.

**A blockchain** coordinates participants around a shared history and, often, shared state. This is especially valuable for money: checking individual signatures is not enough when the network must also decide which conflicting spend counts. Settlement guarantees depend on the consensus design and its assumptions.

**Ask for:** the confirming party, the claim confirmed, and the condition under which confirmation could be reversed.

## 3. Checking: How much work must a stranger do?

The recipient’s clock can matter more than the producer’s. A record that is cheap to create but difficult to inspect moves work downstream.

**An operator’s own log** is convenient for someone with access to its search tools. A stranger may need credentials, an export, or the operator’s cooperation. An unsigned export does not independently establish its origin or completeness. For internal troubleshooting, that dependence may be acceptable; for a long-lived receipt, it may not be.

**A signed receipt backed by a public log** can support checking without contacting the issuer, provided the evidence package contains enough material: the receipt, signature, relevant key information, inclusion proof, and authenticated checkpoint. Depending on the guarantee sought, it may also need consistency evidence or a witness’s countersignature.

Offline checking is bounded. It can establish what the supplied evidence supports, not necessarily the latest key status, the log’s current state, or whether someone elsewhere received a conflicting view.

**A blockchain** offers several verification paths. Running a validating node provides stronger local checking at a storage, bandwidth, and processing cost. Lighter clients can check selected proofs under additional assumptions. Asking a hosted server is convenient, but makes that server part of the verification path.

**Ask for:** a complete evidence package and a test with the issuer unavailable. This reveals whether portability is real or merely an export button.

## 4. Capacity: How many records can it accept?

Capacity is not latency. A system may complete one request quickly yet struggle with many concurrent submissions.

**An operator’s own logs** can partition work across storage systems, batch writes, and adjust retention. This flexibility often supports high intake because there is no requirement for an outside network to agree on every entry. Indexing, replication, and durability still consume resources.

**Public append-only logs** can use cryptographic tree structures to combine many entries into compact checkpoints and proofs. Batching spreads some costs across records, but waiting for a batch can increase inclusion delay. Receipt issuance, log intake, proof generation, and public checking may each have different limits.

**Blockchains** spend resources on replicated validation and agreement. Depending on the design, multiple participants repeat work that a central operator would perform once. That cost buys a shared result without handing all ordering authority to one operator; it is not simply wasted computation.

**Ask for:** sustained capacity at your required record size, durability level, and confirmation boundary. A submissions-per-second figure is misleading if the system acknowledges requests faster than it can finish them.

## 5. Behaviour under load: What happens when demand spikes?

A service is not usefully fast if its quiet-period performance disappears precisely when it matters.

**An operator’s own logs** may queue writes, slow callers, reject requests, or discard lower-priority events. Costs can rise through additional infrastructure rather than a visible per-record fee. Dropping diagnostic events may be tolerable; silently dropping transaction receipts usually is not.

**Signed-receipt systems with public logs** may keep issuing receipts while publication falls behind. This preserves responsiveness but stretches the interval during which recipients lack inclusion evidence. Queue limits and publication deadlines therefore belong in the interface, not only in internal dashboards.

**Blockchains** may respond through longer waits, higher inclusion fees, admission limits, or some combination. Fee-market behaviour varies: not every blockchain uses the same mechanism. A network can remain within its intended operating rules while a particular user’s cost or waiting time becomes unacceptable.

**Ask for:** tail delays, rejection behaviour, backlog recovery, and total cost during a burst. Also establish retry rules, because unbounded retries can turn congestion into a larger failure.

## Turn the five clocks into an acceptance test

Consider a **constructed example**: an agent records completion of a maintenance task. The operator needs immediate workflow progress; a customer needs a receipt they can check months later.

These needs need not share one deadline. Test them separately:

1. **Start at submission and record each milestone:** durable write, receipt issuance, publication, and any independent confirmation. Separate timestamps expose hidden waiting.
2. **Have a fresh checker verify the retained evidence:** include a run without access to the issuer, because future availability is not guaranteed.
3. **Repeat with realistic bursts and a component outage:** measure the slow end of the distribution as well as typical performance, because averages conceal stranded requests.
4. **Define pending, failed, and retryable states:** agents need explicit instructions so that delayed confirmation does not trigger duplicate work.

Keep the truth boundary visible throughout. Signatures and public-log proofs can make records **tamper-evident** when checked against authenticated evidence. They do not prevent alteration or make the contents true. Append-only describes a history rule whose observance needs enforcement or checking.

Choose local logs for controlled operational needs, portable receipts for checkable handoffs, and network consensus when shared agreement is the essential job. Combine them when necessary—but keep separate clocks for separate promises.

The useful question is not whether a system is fast. It is **fast at what, and for whom?**