# Writing guide for the Epoche site and docs

Rules distilled from the copy edits made to the landing page and docs in early
September 2026. Each rule comes with the edit that produced it. Apply these to every
sentence on the site, the docs, the diagrams, and the CLI output that ends up quoted in
them.

The one-line version: write the way you would say it across a table to someone who is
smart but has not read the code. If a sentence sounds impressive, it is probably wrong.

## Before you write

Run the `unslop` skill on every piece of prose before it lands, whether or not anyone
asked for it. In Claude Code:

```
/unslop
```

or, when working through the Skill tool, invoke `unslop` and pass the text. Its rules
(no em dashes, no "not X but Y", plain words, active voice, no flourish) are the floor.
The rules below are what this site needs on top of that floor. In Codex, read the
installed `unslop/SKILL.md` and apply its scan, rewrite, and self-audit process to the
actual text. A request to "unslop" means to use that skill, not merely shorten the copy.

---

## 1. Say what happens, not what it means

A heading that promises steps has to be followed by steps. Benefits, reassurances, and
slogans are not steps.

| Before | After |
| --- | --- |
| Your code stays sealed. | Your code is encrypted on your machine and sent to the reviewer enclave. |
| The verdict is signed where it happened. | The enclave checks the code and signs the verdict. |
| The credential goes everywhere. | The credential is minted to Base. |

The section was called "How a review becomes a credential". The old lines answered a
different question.

## 2. Do not try to sound smart

Every clever line in this project got cut, and the plain replacement was better every
time. Metaphors, punchlines, and rhetorical shapes read as machine-written.

| Before | After |
| --- | --- |
| Epoche turns trust into something an agent can carry. | Software can't read a reputation. It can read a credential. |
| Every capable agent in the world is stuck at the same door. | Every closed-source agent runs into the same wall. |
| No reputation, no résumé, no cold outreach. Just a credential the other side can check. | An Epoche credential automates trust in your agent. Your code stays private. |
| A wallet has no basis for handing a bot the keys. Capital stays parked because nobody can vouch for what an agent will do with it. | Nobody sends money to a bot they know nothing about, so the money stays where it is. |

Patterns to avoid on sight: "not X, but Y"; three-item rhythmic lists ("No X, no Y, no
Z"); a noun made abstract ("standing", "proof it can show"); a sentence that ends with a
flourish; anything you would put on a poster.

## 3. Use the reader's words, not the protocol's

If a term did not appear in the sentence before, the reader does not have it. Either
give it to them first or use the ordinary word.

| Protocol | On the page |
| --- | --- |
| deployed artifact, admitted artifact | the exact code that runs, the Docker image |
| manifest | config file |
| sealed image | the Docker image the builder made from your reviewed code |
| credential document, fresh nonce | its credentials and its signing key, a random number |
| the signature recovers to the advertised key | the reply is signed with that key |
| walks that key back through Base | looks the key up on Base |
| counterparty | someone, the other side |
| measurement (first use) | a hash of every image, command, and setting in the box |
| binds, trades, names | says, gets, contains |

Names that carry real meaning stay: Base, Azure, RISC Zero, Boundless, Docker, JWT,
thirty days. Versions, addresses, function names, and schema numbers do not belong in
prose.

## 4. One idea per sentence

Semicolons were removed wherever they appeared. A sentence that needs one is two
sentences.

| Before | After |
| --- | --- |
| Azure bills the subscription; Epoche charges service credit for the review. | Azure bills the subscription. Epoche charges service credit for the review. |

Long descriptions were cut roughly in half by deleting clauses, not by compressing them.
If a paragraph lists five mechanisms, it is a spec, not copy.

## 5. Name the one reason a thing exists

A command or component gets one sentence about what it is for. The mechanism goes in
the reference, not the overview.

| Before | After |
| --- | --- |
| `epoche register safety` verifies the reviewer, encrypts the bundle, and submits it. | `epoche register safety` sends your code for a confidential review. |
| Runs on the author's machine and is the only thing that ever holds plaintext. It bundles the source and hashes it, reads the reviewer's attestation, checks that attestation's measurement against the approved release on Base, and only then encrypts the bundle to the key inside that attestation. | Runs on your machine. It hashes your code, checks that the reviewer is running an approved release, and encrypts the code to that reviewer's key. |

## 6. Verbs a person would use

| Before | After |
| --- | --- |
| Collect the result | See what happened |
| Follow the review | Check the review's status |
| a record naming both hashes | a record containing both hashes |
| the proof shows the receipt and the record name the same source | the proof confirms the receipt and the record describe the same code |
| stores the image hash against its reviewed source | maps the Docker image to the reviewed source |
| signs the image hash beside the source hash | signs a record holding the image hash and the source hash |

Nobody collects a result, follows a review, or stores one thing against another.

## 7. Second person

The reader is "you". The code is "your code". The Azure account is "your own Azure
account". "The author", "the developer's path", and "the user" all became "you".

## 8. Only claim what is true

| Removed | Why |
| --- | --- |
| The verifier runs offline. | Checking the signature is local. Checking the credential is still current reads Base over RPC. |
| One review is the price of admission. | Every release gets reviewed. |
| without an account or anyone's permission | True, and nobody asked. Permissionlessness is crypto rhetoric, not a user concern. |
| put your idea at risk | Plural. People have more than one. |

When a line is only mostly true, cut the part that is not.

## 9. Define before use

The architecture page got an "Inside an enclave" section placed before the first
picture that says "loader". "Measurement" is defined in a bullet before "measurement
hash" appears on a diagram. If a reader meets a word on an arrow before they meet it in
a sentence, the order is wrong.

## 10. Delete, don't rewrite

Some blocks added nothing and were removed rather than improved: the "See what happened"
workflow step, the "guarantee has a precise boundary" callout, the "how to read the
pictures" preamble, every "left out of the picture" paragraph, the trailing "for
anybody to check". The test: if the page reads the same without it, it goes.

## 11. Headings are labels, not sentences

| Before | After |
| --- | --- |
| From agent source to verifiable credential | Overview |
| How source identity reaches a live endpoint | Trust chain |
| Why this has to exist | The trust gap |
| Day-one trust with strangers | Trust with unknown counterparties |
| Documentation | Docs |

A page's `h1` matches its navigation label exactly. Section headings say what the
section is about in two to four words. The descriptive line lives in the intro
paragraph beneath.

## 12. Explain how, not why, unless asked

"Why it is built this way" listed ingredients with justifications. It became "How it
is built": four parts, what each one does, what it hands to the next. Readers who want
the rationale will infer it from a clear mechanism. Readers who want the mechanism
cannot infer it from rationale.

## 13. Contractions when the user writes them

"can't" was chosen over "cannot" for the pull line. Match the register of the
surrounding copy. The landing page contracts; the claims page does not.

## 14. Line breaks are decisions

When a two-sentence line should read as two lines, put a `<br />` between them. Do not
rely on a `max-width` to break it in the right place. Widen a constraint rather than
adding words to make the wrap fall better: "…with epoche credentials" was added for the
wrap and then removed.

## 15. Give procedures enough room

The verifier DAO review added the rules below in September 2026. They apply to plans
and technical procedures as well as product docs.

Short copy and a clear procedure need different amounts of detail. A process must say
who starts it, what they submit, who checks it, what happens next, and where the result
is recorded. Use numbered steps when order matters. Keep function names and fields in
a technical procedure when they let the reader connect the explanation to the code.

"A reviewer signs an assessment" leaves the reader guessing about execution. Explain
whether that signature permits a merge, satisfies a release requirement, or authorizes
a contract call. If a person still has to check the record and execute the transaction,
say who does it. If enforcement has not been built, say so.

## 16. Define roles and terms before use

Introduce a role before assigning work to it. State whether the DAO operator,
enclave operator, domain maintainer, reviewer, and Safe signer are different people,
different permissions, or several jobs one person holds. Use those names consistently.

Avoid "owner" when it could mean either the person coordinating a process or the
address that owns a contract. Write "the signer proposing the release" or "the
contract owner" as appropriate.

Define specialist nouns at their first use. A corpus is a collection of test cases
and expected results. An embargo temporarily keeps exploit details private. A corpus
budget pays for test cases. The label alone does not explain the mechanism.

## 17. Respect existing crypto meanings

Use specific verbs when an ordinary word also names a blockchain operation.

| Ambiguous | Specify |
| --- | --- |
| approval | release approval, a reviewer's consent, or a token spending allowance |
| claim | a bounty report, a request for payment, or a withdrawal transaction |
| reveal | who receives the previously hidden material and whether it becomes public |
| receipt | a report acknowledgement, a signed verifier result, or a transaction receipt |
| signer | a reviewer signing an assessment, a Safe owner signing a transaction, or an enclave signing a result |
| monthly ledger | the list of all monthly incoming and outgoing transactions |

Expand compressed statements. "Receipt reserves nothing" becomes "Publishing a receipt
for the report hash does not reserve funds. The program reserves funds when it receives
the complete report."

## 18. Explain both sides of a check

When describing a hash comparison, name the input to each hash, who computes it,
where the expected value lives, and what happens if the values differ. "Signs against
the expected hash" skips the operation the reader needs to understand.

Distinguish a file hash, a Safe transaction signing hash, and an executed transaction
hash. Explain what a signature authorizes and which system verifies it. Do not imply
that signing a written review automatically causes an on-chain action.

## 19. State conditions and timing

Replace labels with the conditions they stand for. A "milestone payment" needs its
amount, due date, and release conditions. Include a worked example when a percentage,
minimum, or cap changes the amount someone receives.

Distinguish today's behavior, launch rules, later triggers, and permanent restrictions.
"Never scored" is wrong if the plan records contributions now and scores them later.
Say when scoring starts or which decision still needs to be made.

When the reader asks why a threshold or notice period changes, give the documented
reason. If none exists, record the missing rationale. Do not invent one during an edit.

## 20. Show an example where it helps

After an abstract process, show a small example of what enters it and what changes.
Give a full-release example and a light-release example. Show a test input with its
expected result. For a reason-code hash, show the readable name, the hash operation,
and the contract call that stores the result.

Use existing code when available. Label illustrative snippets and pseudocode so readers
do not mistake them for an implemented API. Check function names against the repo.

When diagrams are deferred, put a `[Diagram TBD: ...]` note beside the relevant process
and name the steps the diagram should show. Do not create the diagram before requested.

## 21. Preserve questions during an editorial pass

When Bryan asks to finish reading before making design decisions, keep proposed changes
in `[Bryan's note: ...]` brackets beside the relevant section. Clarify the existing
proposal without adopting the suggestion. Separate new inconsistencies found during
editing into `[Draft gap: ...]` notes.

Do not silently settle questions about tokens, staking, AI authority, human signers,
or legal structure while rewriting their explanations. Keep the requested section
boundary and check that later sections remain unchanged.

## 22. Cut compressed couplets

Blacklist punchy pairs such as "Standing is recorded, never scored", "Measured, then
signed", and "Money is strict, standing is adjudicated". They compress away the actor,
action, and conditions. Expanding one into two precise sentences is an improvement even
when it uses more words.

This rule also catches absolute fragments such as "Silence never approves". Name the
actual condition: the release becomes approved when the authorized wallet executes the
version-registry transaction after the release requirements are met.

---

## 23. Keep the DAO page at overview level

The v2 philosophy establishes the level of explanation for `/docs/dao`. Describe each
core feature's job, the steps that connect it to the next feature, and the reason a
reader needs to understand it. Focus the page on verifier changes, corpus changes,
automated execution, member challenges, and how token usage funds rewards.

Define the corpus, release candidate, and optimistic updates before using them. Show
how an expected test result differs from an observed result, and how passing the
required checks permits the next action. Agent councils resolve policy questions,
coverage gaps, and challenges. Do not imply that every passing test report needs an
additional subjective approval.

Keep voting formulas, signer arrangements, allocations, exact thresholds, and other
DAO management details in the full plan. A funding threshold can be explained through
what changes above and below it without inventing its value. State whether the page
describes planned or live behavior. Use the selected mechanics from the current
discussion rather than reproducing every alternative in the planning documents.

## 24. Distinguish services from agents

Use "service" for software a caller accesses over a network. Use "AI agent" when
the software's choice of actions matters. An API describes the interface. It does
not establish whether the service uses AI. Name both roles when an agent calls a
service, so readers know which software Epoche reviews.

Keep marketing short and direct. Explain private code review, the resulting
credential, and the evidence that connects reviewed code to a supported deployment.
Use concrete decisions, such as checking a privacy review before sharing data or
checking the running service before payment. A review does not establish
creditworthiness or guarantee future behavior.

"Self-hosted" means the customer operates the infrastructure. In the current
deployment docs, that infrastructure is Azure. Use "locally installed agent" for
software running on the user's device. Local-agent verification needs its own
product scope and evidence. Do not imply it through a general safety claim.

Preserve command names, package names, API fields, and historical examples. Explain
an existing technical use of "agent" where readers first encounter it. Do not
rename protocol interfaces during a copy pass.

## Checklist

Run every new or edited line through these:

- Would you say it out loud to a colleague, in those words?
- Does every noun appear in an earlier sentence, or is it an everyday word?
- Is it one idea? Is there a semicolon?
- Is it true in every case, or only usually?
- Is the reader "you"?
- Does it state what happens, or how it feels?
- Would the page lose anything if the line were deleted?
- Does the heading match the nav label?
- Does it have a flourish, a triplet, a metaphor, or a "not X but Y"?
- Does a procedure name the actor, input, check, next action, and record location?
- Can the reader tell an assessment signature from transaction authorization?
- Are current behavior, proposed rules, and unresolved decisions distinct?
- Do code examples match the repo or clearly identify themselves as illustrative?
- Did the edit preserve design questions and the requested section boundary?

## Banned

em dashes · "not just X, but Y" · "leverage", "robust", "seamless", "crucial", "delve",
"landscape", "showcase", "underscore" · "permissionless" and "trustless" in user copy ·
"artifact" outside the CLI reference · "standing" · compressed couplets such as
"recorded, never scored" · any sentence that could sit
unchanged on another company's page.