Glossary
The words,
defined once.
Writfold keeps several ideas apart that are often blurred together. These short definitions are used across the site.
Terms
- Approval
- Your signed decision to allow one exact prepared edit, under a context's policy and a current grant. It names that change, not a file or a source.
- Assessment
- A Weft report on a plan's claims, saying which checks follow from the stated assumptions and evidence: entailed, refuted or undetermined. It never grants permission to change anything.
- Citation
- A reference from a claim to retained evidence, bound to its exact bytes by digest. In the trial,
writfold trial retainand Tuft create them aswritfold-citation/1bindings. A citation can support a claim; it never approves a change. - Context
- A named scope with its own sources and policy, such as work or personal. Evidence and approval in one context do not carry over to another.
- Effect
- A change outside Writfold's own records, such as writing a file. Only Writfold performs effects, and only after approval.
- Grant
- A signed, revocable authorization from an operator. An approval counts only while the grant it relies on is still current.
- Harness
- The layer Writfold forms underneath a coding agent. The agent keeps its own loop; the harness keeps evidence, conclusions, approval and change apart, and records each step.
- Hypothetical
- How Writfold records a Weft result: it holds under the assumptions the report declares, not as a fact Writfold has established. An approval can require a check to be entailed; the result is still recorded as hypothetical.
- Kernel
- A small, pure piece of Rust that makes one decision, such as whether a ledger append or a grant is allowed. Some kernels are proved over the shipped Rust: translated to Lean and proved for every input. See how we know.
- Ledger
- Writfold's append-only history of decisions and effects. Its current head decides the state of a run. In the trial, every append replays the run's history through the proved kernel first.
- Owner
- Writfold itself. It alone holds the knowledge store and the approval policy, and it alone writes files, only in worktrees it created. Weft, Splicery and the agent only read and propose.
- Pinned
- Fixed to an exact version or hash, so the same input always means the same bytes.
- Prepared edit
- A Splicery result: the exact bytes to change and the candidate file they produce. Preparing an edit does not apply it.
- Proposal
- Knowledge or a change that has been suggested but not yet approved or published.
- Realm
- One isolated Writfold installation's trust boundary: its own store, keys and policy.
- Receipt
- A durable record that an effect happened, with the bytes before and after. After a lost response, the receipt lets Writfold return the same result rather than act twice.
- Retained input
- An exact, unchangeable copy of bytes that were read, kept with their source and revision.
- Scribe
- A planned small program that fetches a source for Writfold. It cannot approve, write or choose a context.
- Trial profile
- The cooperating single-user profile that runs the connected flow today (
writfold trial). It never writes your checkout, but it does not stop an agent's own shell, and it assumes nobody races it on its worktree. - Tuft
- The family's query language for exact evidence: find text or a bounded regex in one pinned commit, retain the hits as citations, and project a compact view under a token budget. It lives in the Writfold repository.
- Worktree
- A separate Git working directory Writfold creates for a run, so an edit never lands in a checkout someone else is using.
- Writ
- The immutable record Writfold keeps of what a scribe returned.