# The Legible Protocol
### Specification · Draft 0.4 · Schema v2 · 26 October 2026

**Legible Protocol**, or **Legible**, defines an open file format for declaring
contributions, their dependencies and consequences recognized by those who
received them. **The Legible Protocol** is the title of this specification.

**Abstract.** The grammar contains three signed, content-addressed records:
**Appoint** — I formulated this; **Trace** — this depended on that; **Nod** — this
produced a consequence for me. A contribution can be recorded before selection
for use. This condition, called **Open Legibility**, allows formulations to be
preserved for later consideration. Selection remains with whoever decides to
use, execute or fund the work.

**Language and edition.** Portuguese is the primary normative source for draft
0.4. `spec/legible-EN.md` is the synchronized English reference translation.
Technical divergences are conformance errata to resolve in both texts and tests.
Field names, enums, canonicalization and cryptographic identifiers are common
to both languages and are not translated in records. Text: CC BY 4.0; reference
code identified as such: Apache-2.0 (§16).

**Status and scope.** This specification is a **DRAFT**, not a stable edition
or certification. The initial baseline uses `legible/protocol/v2/...`, with
canonical Portuguese NCO and NRC texts and English reference translations.
Unsupported editions remain distinct from malformed records under a supported edition.

**Reading guide.** Section 1 presents the proposal; §2 explains the records;
§3 defines their formats and checks. Sections 7.1 and 9 address the recognition
convention and conformance claims. Sections 5, 10 and 11 define optional
capabilities; §12 is an experimental identity annex. Requirements for particular
roles also appear elsewhere, including authoring (§2.1), services and portability
(§8), security (§14) and tests (Appendix D). This map does not make those passages
merely informative.

**MUST** denotes a mandatory requirement; **MUST NOT**, a prohibition;
**SHOULD** and **SHOULD NOT**, strong recommendations whose exceptions need to
be understood; **MAY**, permission. These terms have the BCP 14 meanings only
when capitalized. A requirement binds its named capability or role, not every
activity of a product using the files.

Appendix A contains the canonical NRC 0.2 bytes; B presents fictional signed
examples; C guides implementation checks; D identifies conformance artifacts.
Appendix E provides the informative economic rationale. A future edition must
pin its specification, schemas and tests under immutable identifiers. A mutable
repository file does not silently replace this specification. A discrepancy
between the norm and a test is an erratum to resolve.

# 1. What the Protocol Is, and Why

The format allows people to preserve what a person formulated, what a work relied on and what
consequence another person declared receiving. Each declaration has its author.
An assistant can help prepare the content; the person is encouraged to review
the exact declaration and approve each signature (§2.1).

The [examples area](../examples/README.md) follows fictional situations in
service provision, research and development, and team coordination. Each case
shows who formulates a contribution, how they declare dependencies and who
recognizes a consequence received. The examples illustrate possible uses;
they report no observed results and add no requirements to the formats defined
in this specification.

A record is a file. In the baseline identity profile, its integrity and signature
can be checked offline from that file. Relations between records and optional
temporal proofs need their own data and checks (§3.6, §13). The signature attributes
the declaration to a key; the reader assesses its claims and evidence.

Participants constitute **Legible spaces** through their own tools, access
conditions and practices. No server, account, registry, index, token, blockchain
or operator is required. Git is the recommended substrate for preserving and
distributing files, without being a validity condition. Search, hosting and payment
services have their own operations and responsibilities (§8, §16).

## 1.1 The condition the format serves

> Open Legibility allows contributions to be formulated and preserved before selection for use.

In this section, a **coordination space** is the set of people and contributions
someone can consider when deciding what to do. It can be a company team or an
open project. The condition allows an idea to be recorded before receiving an
assignment, position or funding.

A record's existence can be known without its full content being accessible.
Knowing who formulated something and what it depends on can help a decision,
subject to access conditions. A contribution can remain available for another
reading where someone preserves it. This does not ensure discovery or an audience.

Git already separates a local commit from acceptance into a remote repository.
Legible applies this separation to declarations of formulation, dependency and
consequence. Its practical reach depends on the space participants maintain,
the sources they can consult and resources for preservation and reading.

## 1.2 What remains independent of selection

A person, project or organization can present questions and participation
conditions on a page, preserve contributions in a collection and allow reading
in participants' own tools. Participants can also formulate problems no maintainer
listed. Public, internal and mixed spaces use the same grammar under their
access and confidentiality conditions.

Preserving a contribution, presenting it and incorporating it into a maintained
collection are separate decisions. An issue, PR, commit or Git signature is not
automatically a Legible declaration. Merge establishes neither use nor received
consequence and does not generate a Nod. To consider unmerged proposals, readers
need to consult their accessible references; a main-branch checkout does not
include their changes. Independent continuation remains subject to rights,
access and confidentiality. The informative guide is in `docs/open-legibility.md`.

An Appoint requires no allocator, ranking position or funder. Services may define
scope, charge, authenticate, moderate and limit resources. Declining or removing
a record at one service does not by itself invalidate it under the protocol.

| The format keeps independent | The implementation or reader decides |
|---|---|
| Creating without admission by a canonical authority | Acceptance and publication at a service |
| Formulating before allocation | Assigning, prioritizing, executing or funding |
| Verifying without a canonical index | Sources and indexes consulted |
| Preserving without an official score | Criteria and judgments used |
| Recording consequence retrospectively | Estimates and prior commitments |
| Transporting records | Lawful access and storage arrangements |

Appoints require no assignee, priority or workflow status. Applications can
organize work through optional external metadata. That organization is not a
validity condition. Portability does not guarantee economically equivalent
alternatives; service concentration can create a practical barrier even when
its files are portable (§8.1).

## 1.3 Why this may be feasible now

Assistants can help describe work and retrieve accessible material according to
the reader's question. The hypothesis is that reducing these costs can expand
the contributions available for consideration, while time and resources remain
real limits. [Appendix E](#appendix-e-economic-rationale-informative) presents the
economic argument, its references and limits. This rationale is informative
and is not a condition of record validity.

## 1.4 Limits of interpretation

The format makes declarations attributable and open to examination. Credibility
depends on evidence, context, interactions and judgment. A key does not
automatically identify a unique person or their civil identity.

Discovery depends on whoever preserves, exposes, retrieves and reads the files.
The CH (§5) provides private context for interpreting accessible sources. Records
or a search tool do not guarantee that a source will be found.

Recording a formulation does not reserve a problem, certify priority or create
an automatic payment entitlement. Rights of use, agreements and legal effects
follow their own instruments and applicable law (§7.2, §16).

## 1.5 What such a record needs to support

Preserving provenance does not ensure that a service supports contestation,
transport or alternative readings. The table separates the format from these conditions.

| Property | What the format supplies | What depends on context |
|---|---|---|
| Independent recording | No canonical admission or prior allocation | Resources and local admission |
| No canonical reading | No official score or allocation | Diversity and reach of readers |
| Attributable declarations | Signatures distinguish who asserts | Truth, continuity and credibility |
| Optional external temporal evidence | A place for evidence of prior existence | Trust, availability and verification policy |
| Sovereign recognition | No mandatory amount or collection | Incentives, support and external agreements |

A beneficiary's Nod, an author's origin Trace and a curator's Trace are different
propositions. A reading needs to preserve their declarants. A reputational cost
for false claims depends on context; the signature does not impose it.

## 1.6 Relation to other instruments

| Related category | The distinction |
|---|---|
| Reputation system | No official score; readings are contextual |
| Résumé or portfolio | Formulation, dependency and recognition are separate acts |
| Academic citation | Traces structure relations and later recognition; citations can already declare dependency |
| Performance review | A Nod declares consequence without a fixed scale or mandatory pool |
| Matching platform | Discovery and allocation are external; the format does not allocate |
| Contribution blockchain | No global balance or consensus ledger |
| Public profile | A public projection is optional; private CH and records are legitimate end states |

| Proposition | What can be established |
|---|---|
| This key signed the declaration | Yes, with successful verification under the specified signature suite |
| The dependency actually existed | Not from the signature alone |
| A human personally reviewed it | Not from the signature alone |
| The signed content existed by T | Only under verified external proofs and their assumptions |
| Someone received a valuable consequence | The Nod establishes that its author declared one |
| No one benefited or registered recognition | Absence in accessible sources establishes neither conclusion |
| The author discovered first or owns the idea | The protocol does not determine this |

## 1.7 Resources and decisions on use

Time, committed capital, capacity and risk remain limited. Resource providers
decide their use, subject to their own commitments and obligations. Preserving
a contribution for later consideration grants no right to other people's
resources and guarantees neither cooperation nor funding.

## 1.8 Drafts and records — two layers

Legible defines formal records and an optional draft profile. Neither requires
an assigned task, organization or central operator.

A **draft** is unsigned Markdown with structured frontmatter preserving
formulations, declared dependencies and changes of direction. Legible adopts
the **Genealogy 0.1** profile in `profiles/drafts.md` and its single format source.
Participation entirely in this layer is a complete use. An informal recognition
proposal remains distinct from a signed Nod.

A **record** is a signed, content-addressed artifact. Its ID derives from its
content; the signature binds that ID to the key. External temporal evidence
is optional and can support existence of the content by a date under its
verification assumptions (§13). The author formalizes a formulation by issuing
a new Appoint, which may reference the draft as evidence (§3.1). The original
draft remains separate.

**Supporting materials.** Open Legibility is also the companion book's title
and develops the broader practice. The Economics of Legibility presents the
economic argument. Reading those works is not a participation or validity
requirement. `legibleprotocol.com` publishes the specification, materials and
reference code; it offers no hosted collaboration service.


# 2. The Grammar: Three Primitives

**Appoint:** I formulated this. **Trace:** this depended on that. **Nod:** this produced consequence for me.

The primitives are the grammar. `.response` and `.redaction` are lifecycle annotations over that grammar. Applications can compose proposals, disputes, work allocation, and recognition without making their own workflows universal record requirements.

In this document, the **core** is the content that determines the record ID,
stored in `canonical_content`. The signature binds that ID to the author's key.
The **envelope** contains this content, the ID, type, signature and any external
metadata. Section 3 defines the fields belonging to each part.

## 2.1 Git and baseline identity

An **authoring client** is the tool used to prepare or sign records. This
section's recommendations guide those tools and their implementers.

Git gives many contributors a familiar place to preserve, compare, and distribute files. A signed commit can help attribute a repository change; a commit author's name or date does not prove authorship or time by itself. Record integrity rests on the record signature, not on its storage path or repository membership.

The baseline identity is an Ed25519 `did:key`. It identifies a public key without requiring an account or registry. It does not prove a unique person, prevent shared or transferred key custody, or provide rotation. The experimental persistence design is discussed separately in §12.

**Human commitment is strongly recommended.** Authoring clients SHOULD present the exact declaration to the signer and obtain specific human approval for each signature. An agent may draft the content; it SHOULD NOT have an unattended path to the signing key. Implementations departing from this recommendation SHOULD clearly describe their automation and custody model. Such departures are not detectable from an ordinary signature and do not by themselves invalidate the record.

Clients SHOULD use protected key custody, least-privilege signing interfaces, and a confirmation mechanism bound to the content actually signed. Hardware support must match the signature suite: a FIDO security-key signature is not automatically interchangeable with the plain Ed25519 suite in §3. Biometrics or a physical touch can protect access to a key without proving understanding of the declaration. A headless client can still obtain human approval.

**The record author is the identity asserting the declaration.** The author of this specification, the author of a referenced work, the person approving a signature, and a service operator may be different people. These roles are not merged by a shared word or by use of the format (§16).

## 2.2 Appoint — declaring what you formulated

An Appoint makes a formulation recordable before it becomes an assignment. A problem with no proposed solution is a complete use. Evidence is optional because sometimes the formulation is the work; where an executed solution exists, references let others inspect it.

The signed core may contain a problem description, an optional solution, origin Traces, and references to external evidence. **The formulation itself is inline content.** A work, dataset, source tree, or supporting document can remain external. A public Appoint reveals its own core; confidentiality of additional material requires an appropriate storage and disclosure arrangement.

The author may state preferences about monetary and non-monetary recognition. Those preferences guide clients; they neither stop third parties signing statements nor control external transfers. They create no payment endpoint or automatic authorization to use a work.

**Three temporal claims.** `created` is the author's signed date for the record. `published` is optional, unsigned publication metadata. External timestamp proofs can establish an upper bound on when the committed core existed. These are different propositions. No recognition deadline or statutory priority follows from any of them.

Multiple witnesses permit stronger evidence policies, but their strength depends on the policy. Accepting the earliest assertion from any one witness is not equivalent to requiring independent corroboration. A witnessed Git push, a TSA token, and a public log have different trust and availability assumptions (§13–14).

## 2.3 Trace — declaring a dependency or discovering a lineage

A Trace names what a work is said to have built on. Origin Traces are frozen inside the Appoint's signature. Standalone Traces permit later additions, including statements by curators who authored neither endpoint. The curator signs their own assertion; they do not speak for the beneficiary.

**Lineage reaches outside the graph.** A paper, commit, released library, or document need not adopt legible before someone can refer to it. An external reference does not automatically supply a legible author or NRC adoption. It may have provenance and rights that are established elsewhere.

**The age of a work is not the age of its registration.** An older technique may be recorded after the software that uses it. The protocol therefore imposes no `target.created < source.created` rule on dependency Traces. A hash reference commits to a referenced identifier; it does not establish when the underlying intellectual contribution was made.

The assertion graph can contain unresolved edges, disagreements, or cycles. A reader may construct an acyclic genealogy projection using declared assumptions and evidence; that projection is not the complete graph and does not retroactively invalidate the underlying signatures. Traversals must handle cycles and repeated nodes safely.

Weights are optional-to-interpret attribution suggestions in the records that carry them, not debts or required payment shares. No false assertion has a mechanically guaranteed reputational cost. Contestability matters only when a relevant reader can see and assess the competing declarations.

## 2.4 Nod — recognizing consequence you received

A Nod is a beneficiary recording that a contribution produced a consequence for them. The consequence precedes the recognition. It is not a quality rating and does not measure what the work is worth to everyone.

Three forms share that act:

- **Reputational:** consequence is declared without a monetary transfer in this record.
- **Monetary:** consequence is declared together with the amount the recognizer states was transferred in recognition of the referenced contribution.
- **Non-monetary:** consequence is declared together with a reference to a proposed non-monetary recognition, whose acceptance remains a separate act.

**The amount is the recognition, not the total benefit.** If a contribution helped the recognizer earn BRL 10,000 and the recognizer transferred BRL 100 in recognition, the monetary Nod contains `amount: "100.00"`, `currency: BRL`. The statement may explain the BRL 10,000 benefit, with optional supporting evidence. It need not disclose it, and the explanation creates no prescribed ratio between the two amounts. No transfer is required to register a reputational Nod.

The monetary record declares a transfer already made; it is not a payment instruction or proof that the declaration is true. Settlement evidence is optional and is classified by what it supports. An authorization alone does not establish completed settlement. A later refund or reversal can occur on the external rail; an adequacy response does not itself perform one (§11).

A non-monetary Nod may offer equity, work, access, or another arrangement **in recognition of a consequence that already occurred**. It references external terms, not a protocol-created legal instrument. A response records acceptance or refusal of that proposal. Whether an agreement is formed, valid, modified, or terminated depends on the parties' acts, authority, terms, and applicable law. An entirely prospective collaboration proposal belongs in an Appoint or another application workflow, not in a claim that a consequence already occurred.

**Each recognition is its own Nod.** The recognizer chooses which contributions and ancestors to recognize and at what value. The graph can reveal paths and an application can suggest allocations; it neither executes an automatic split nor creates an entitlement along every edge. Repeated references to one sale do not mean that the sale occurred repeatedly.

**Adequacy is the other party's declaration.** The author of the referenced record may respond `adequate` or `inadequate`, with context, under their own key. The response does not change the amount, collect a balance, or declare compliance with the NRC. It may be private, restricted, or public according to its own visibility and actual disclosure.

**Correction preserves history.** A corrected Nod can replace the earlier assertion in a current reading while both signed records remain in the history. Replacing BRL 1,000 with BRL 100 does not add up to BRL 1,100 and does not attest to a BRL 900 refund. New transfers are separate events (§3.6).

The same grammar serves both sides of the circuit: recording a formulation and later recognizing its consequence. Neither requires a protocol fee. The time and resources used to do either are real, and services may charge for providing them.

---

# 3. Canonical Formats

Records are UTF-8 files. A directory such as `.legible/appoints/` is a convention, not a requirement. A file may be stored outside Git and may be exchanged without its repository.

**Record identity.** `id = lowercase_hex(SHA-256(JCS(canonical_content)))`. Only the core enters this hash. The envelope consists of required `id`, `type`, `canonical_content`, and `security`, plus optional `published: Time`. The envelope is closed in this edition: an extension with other top-level fields uses an explicitly identified wrapper, such as §10, rather than pretending that every presentation field was signed.

`id` is exactly 64 lowercase hexadecimal characters. `type` is one of `appoint`, `trace`, `nod`, `response`, `redaction` and MUST match the terminal component of the signed `content_schema`. Mismatch is a record-shape failure, even when the hash and signature are otherwise correct. The signature never authenticates an arbitrary replacement for the external `type` label.

## 3.0 Encoding, shared types, and the signature boundary

**Accepted encodings.**

JSON is the direct input representation. YAML is permitted as an alternative serialization of the same JSON data model, using the scalar-resolution subset defined here: quoted and block scalars are strings; plain `true` and `false` are booleans; plain `null` is null and therefore rejected by this edition; plain scalars matching JSON number syntax are numbers; other plain scalars are strings.

JSON number syntax is `-?(0|[1-9][0-9]*)(\.[0-9]+)?([eE][+-]?[0-9]+)?`, matched against the complete scalar. No implicit timestamp, hexadecimal, octal, or case-insensitive boolean conversion is performed.

The parser MUST reject duplicate mapping keys at any level, multiple YAML documents, anchors, aliases, merge keys, explicit YAML tags, non-string mapping keys, and non-JSON data types.

Dates are strings, not native timestamp objects. Comments are not part of the data model. A reader MUST NOT silently drop core fields that it cannot represent. Writers SHOULD quote strings that another YAML mode might coerce, especially dates, DIDs, references, and monetary amounts.

**Strings and NFC.**

Every core string, including every object key, MUST be valid Unicode in NFC. An authoring client SHOULD normalize before hashing and signing, rejecting key collisions that normalization would create. A verifier checks the received data without silently normalizing it. If a received core violates NFC, report that schema constraint separately from any integrity result over the received strings. No subsequent string normalization is part of JCS.

**Numbers.**

JSON numbers use finite IEEE-754 binary64 values and RFC 8785 serialization. Duplicate keys, invalid Unicode, NaN, and infinities are rejected. An implementation MUST NOT substitute generic JSON key sorting for JCS's specified ordering and number handling. These are requirements of [RFC 8785](https://www.rfc-editor.org/rfc/rfc8785.html).

Monetary amounts are strings and are never parsed through binary floating point. A parser that cannot faithfully apply the selected numeric model MUST report unsupported input rather than silently approximate outside that model.

**Absence and empty values.**

Optional fields are omitted when absent. `null` is not used in this edition. Optional arrays and maps are non-empty when present; an empty list of traces, evidence, timestamps, or context slots is represented by absence. The tables below are authoritative about required fields. Schematic examples do not create defaults, and a verifier MUST NOT insert defaults into a signed core.

**Shared types.**

| Shared type | Definition |
|---|---|
| `Text` | Non-empty NFC string; no leading/trailing trimming is performed by verification |
| `RecordID` | Exactly 64 lowercase hex characters |
| `Digest` | `sha256:` followed by 64 lowercase hex characters |
| `Time` | Valid Gregorian UTC date-time `YYYY-MM-DDTHH:MM:SSZ` or `YYYY-MM-DDTHH:MM:SS.sssZ`; year 0001–9999; no leap-second spelling; exactly three fractional digits when present |
| `DID` | DID syntax; baseline verification supports only the Ed25519 `did:key` form specified below |
| `Visibility` | `public`, `private`, or `group` |
| `Weight` | JSON number from 0 through 1 inclusive |
| `DecimalAmount` | String matching `^(0|[1-9][0-9]*)(\.[0-9]+)?$`; no sign, exponent, whitespace, or thousands separator |
| `Currency` | Three uppercase ASCII letters naming a currency; the schema does not certify its status or accepted settlement precision |
| `Relationship` | `builds-upon`, `uses`, `extends`, `references`, or `replicates` |
| `Reference` | A `RecordID`, one of the qualified content references below, or an absolute URI with an explicit scheme |

**Dates and representation.**

UTC strings denoting the same instant may have different permitted precision and therefore different record IDs. Compare instants for display, not raw strings, and do not rewrite the signed representation. A future or surprising `created` value is a time-claim concern, not a failed signature. `created` does not authorize replacement of another record.

**Content references.**

Bare 64-character hex means a legible `RecordID` only. External SHA-256 digests use `sha256:<hex>`. Git object references use `git:sha1:<40-lowercase-hex>` or `git:sha256:<64-lowercase-hex>`, committing to the Git object under that algorithm, not a generic file digest.

CID references use an absolute content URI such as `ipfs://<CID>`, whose verification requires a supported content-addressing adapter. A URI's syntax does not certify immutable content. Other schemes, including future content schemes, remain syntactically valid location references until an adapter establishes stronger semantics. No unqualified Git hash is inferred from a string that the core treats as a record ID.

Location references MAY carry a sibling `Digest`: `target-hash`, `source-hash`, or `nods-hash`. A sibling digest in this edition means SHA-256 of the exact externally supplied artifact bytes, without text normalization. An adapter for transport decoding MUST identify the bytes it exposes. A digest never grants permission to retrieve or disclose the artifact. No automatic fetching is required for record validity.

**Evidence references.**

An `Evidence` object has required `type: Text` and `ref: Reference`, plus optional `content-hash: Digest`. Types are labels, not protocol certifications. A reader can store a label it does not understand without claiming to verify its evidence. Evidence arrays contain one or more such objects; inline evidence contents are not permitted in these objects. Explanations already inside a `payload`, `statement`, or `note` are, of course, part of the core.

**Shared core fields.**

Every record requires exactly the following common fields plus the fields of its per-type table:

| Field | Type | Meaning |
|---|---|---|
| `author` | `DID` | Identity asserting this declaration |
| `content_schema` | `Text` | Exact schema identifier from the per-type section |
| `created` | `Time` | Author-declared time of this record |
| `visibility` | `Visibility` | Intended disclosure scope, not access control |

Each described object is closed: unknown fields are a shape failure for these exact v2 schemas. A future schema may add fields. Private extensions use a distinct schema identifier; `x-` is not an escape from a closed v2 enum. Applications may keep their own metadata outside the record or in an explicitly separate wrapper.

**Visibility.**

No field enforces confidentiality. A `private` record copied to a public location has been disclosed. An implementation SHOULD avoid publication until the user has selected that action; a core marked `public` is an intent declaration, not a command to upload it or a universal data-processing authorization. Changing signed visibility requires a new record; access arrangements outside the file can change without rewriting it.

**Signature suite.**

`security` requires `signature: Text`, an ASCII-armored OpenSSH `sshsig`. It MAY also contain non-empty `timestamp-proofs`, and no other fields in the baseline envelope.

The signed message is the UTF-8 encoding of the lowercase `id` string, with no trailing newline; the SSHSIG namespace is exactly `legible`. The key/signature algorithm is plain `ssh-ed25519`; SSH certificates and `sk-*` variants are outside this suite.

The SSHSIG version is 1 and the reserved field MUST be empty. The SSHSIG hash algorithm may be `sha256` or `sha512`; verifiers MUST support both and reject other values for this suite.

The envelope's signature public key MUST equal the key decoded from `author`. A signature under namespace `git` or any other namespace does not validate here. See [OpenSSH SSHSIG format](https://raw.githubusercontent.com/openssh/openssh-portable/master/PROTOCOL.sshsig).

**Baseline identity.**

For baseline `did:key`, decode the `z` multibase value using base58btc, require the Ed25519 public-key multicodec prefix (bytes `ed 01`) followed by exactly 32 public-key bytes, and reject a different codec. This pins the subset used here rather than adopting every future identity method by reference. A syntactically valid unsupported DID method is reported as `identity-unsupported`; it is not treated as a verified author. Rotation under an unchanged DID is not a baseline capability.

**Temporal proofs.**

A `timestamp-proofs` entry requires `type: Text`, `ref: Reference`, and `input: "utf8-id"`; optional `content-hash: Digest` commits to the referenced proof bytes. Supported adapters MUST bind evidence to exactly the same UTF-8 record-ID message described above, including any digesting required by that witness format. Unknown adapters yield `unsupported`, never a verified ceiling. Timestamp metadata is outside the signature; every claimed proof must be checked independently before use (§13).

**Private commitments.**

Optional `private-data-commitment` fields use the exact construction `sha256(ASCII("legible:private:v1") || 0x00 || nonce || material)`, where `nonce` is 32 cryptographically random bytes and `material` is the undisclosed byte string. The field contains the resulting `Digest`. The author retains the nonce and material privately; revealing both permits checking the commitment.

A writer MUST NOT use a fixed, predictable, or public nonce to claim confidentiality. The verifier cannot infer nonce quality from the digest. Ordinary `content-hash` remains an unsalted digest for checking public artifact bytes; do not silently substitute one construction for the other.

**NCO — adoption of the declaration.**

For `legible/protocol/v2/...`, signing has the following conventional meaning. The canonical text is Portuguese:

> Adoto como minha a declaração contida neste registro e a faço de boa-fé. Quando declaro uma formulação, afirmo que ela corresponde ao que formulei ou ao que estou autorizado a representar. Se faço a declaração em nome de outra pessoa ou organização, afirmo estar autorizado a fazê-lo.

English reference translation:

> I adopt the declaration contained in this record as my own and make it in good faith. When I declare a formulation, I state that it corresponds to what I formulated or to what I am authorized to represent. If I make the declaration on behalf of another person or organization, I state that I am authorized to do so.

The signer adopts the declaration actually contained in the record. Adopting a declaration does not confirm its hypothesis or establish that the result it presents is correct. The signature verifies integrity and attribution to a key; it does not certify truth, exclusive ownership of referenced material, legal authority, or permission to use, publish or process it.

Disclosure and processing remain separate decisions under applicable conditions. Authoring clients SHOULD present the exact content and make this edition's NCO available before signing. Verification cannot establish conscious acceptance or good faith.

**Immutable edition selection.**

The signed `content_schema`, never `created`, selects the NCO. The five `legible/protocol/v2/...` types adopt the Portuguese text above. `spec/editions.json` distributes this mapping and the text’s digest; that digest is publication metadata, not a new signed field or an explicit hash commitment to the NCO bytes inside the record. The association is normative through the signed edition identifier.

The meaning of published editions **MUST NOT** be silently replaced. An unknown edition **MUST NOT** receive a known NCO by suffix, date or latest-edition fallback. A new declaration under another edition requires its own core, ID and signature; the earlier signature cannot be reused.

**References and unsupported editions.**

The checks in §3.6 apply to referenced records, including author, type, target and cycles. An endpoint from an unsupported edition remains unresolved/unsupported; it **MUST NOT** receive an inferred author or lifecycle effect. This initial baseline supports only the five v2 schemas identified above.

**Informative — attribution across independent services.**

A record can remain
with its author, be shared later, and be presented by independent tools and
indexes. Signature verification attributes its content to a key; the NCO states
the conventional commitment associated with signing this schema edition.
Readers can therefore distinguish the signatory's declaration from a service's
summaries, classifications and inferences. Verification does not establish
conscious acceptance, good faith, civil identity, legal authority or rights.
It does not transfer an operator's responsibilities for collection, storage,
indexing, publication or processing to the signatory.

### 3.1 `.appoint`

Schema: `legible/protocol/v2/appoint`. Envelope type: `appoint`.

| Additional field | Required? | Type and constraint |
|---|---|---|
| `metadata` | Yes | Object: required `title: Text`; optional `domain: Text` |
| `payload` | Yes | Object: required `problem: Text`; optional `solution: Text` |
| `nrc` | Yes | Exactly `"0.2"` |
| `nrc-hash` | Yes | Exact digest of Appendix A, shown in §7.1 |
| `accepts-monetary` | Yes | Boolean preference |
| `accepts-non-monetary` | Yes | Boolean preference |
| `license` | No | `Text` naming an SPDX license identifier or an absolute URI; declaration, not verification of licensing authority |
| `evidence` | No | Non-empty array of `Evidence` |
| `traces` | No | 1–2048 origin Trace objects as below |
| `supersedes` | No | `RecordID` of a previous Appoint by the same author |
| `private-data-commitment` | No | `Digest` under the private-commitment construction |
| `context-slots` | No | Array of 1–4 `Digest` strings; opaque to the core |

Each origin Trace has required `target: Reference`, `weight: Weight`, and `relationship-type: Relationship`; optional `target-hash: Digest`. Origin weights SHOULD sum to 1 when the author intends them as a complete attribution allocation. Failure to sum to 1 is not a validity failure. Duplicate target entries are not automatically merged, and no sum is a binding payment split.

A missing solution, evidence, or origin genealogy is allowed. A formulation does not have to invent a dependency, completed deliverable, or externally assigned task to become a record. No party gains a right over the territory described by `problem` merely because the Appoint exists.

### 3.2 `.trace`

Schema: `legible/protocol/v2/trace`. Envelope type: `trace`.

| Additional field | Required? | Type and constraint |
|---|---|---|
| `source` | Yes | `Reference` to the work said to depend |
| `target` | Yes | `Reference` to the work said to be depended upon |
| `weight` | Yes | `Weight`, asserted by this Trace's author |
| `relationship-type` | Yes | `Relationship` |
| `note` | Yes | `Text` explaining the assertion |
| `source-hash` | No | `Digest` of external artifact bytes |
| `target-hash` | No | `Digest` of external artifact bytes |
| `evidence` | No | Non-empty array of `Evidence` |

The author may be a third party. A reader MUST NOT represent this Trace as signed by the source's author unless that attribution has actually been verified. Equality of an endpoint's DID and the asserter's DID is a checkable attribution relation, not proof of real-world causation. Cycles and chronology concerns are graph annotations, not record-signature failures.

### 3.3 `.nod`

Schema: `legible/protocol/v2/nod`. Envelope type: `nod`.

| Additional field | Required? | Type and constraint |
|---|---|---|
| `nods` | Yes | `Reference` identifying the contribution recognized |
| `consequence` | Yes | `solved`, `enabled`, `extended`, `referenced`, or `replicated` |
| `statement` | Yes | `Text` describing the consequence received by the recognizer |
| `nod-type` | Yes | `recognition` or `operational`; latter labels an organizational use, not a different validity regime |
| `form` | Yes | `reputational`, `monetary`, or `non-monetary` |
| `nods-hash` | No | `Digest` of external artifact bytes |
| `evidence` | No | Non-empty array of `Evidence` supporting the consequence or its explanation |
| `corrects` | No | `RecordID` of an earlier Nod, subject to §3.6 |
| `economic` | Iff monetary | Object with exactly `amount: DecimalAmount` and `currency: Currency` |
| `settlement-evidence` | No; monetary only | Non-empty array of settlement evidence objects defined below |
| `agreement-hash-reference` | Iff non-monetary | `Digest` of the exact external proposal/terms bytes |

`economic.amount` is the amount the recognizer declares was transferred in recognition of `nods`. It is not the recognizer's revenue, the contribution's universal value, a price demanded from someone, or a protocol balance. A zero amount is syntactically permitted; writers SHOULD use `reputational` when no transfer occurred. Decimal spellings remain as signed: `"100"` and `"100.00"` are distinct strings even though a money-aware reader may interpret equal amounts. The core sets no maximum value and no claim of payment accuracy.

An optional settlement evidence object requires `type: Text`, `ref: Reference`, and `stage` from `authorization`, `instruction`, `settlement`, `reversal`, `other`; optional `content-hash: Digest`. An author-selected `stage` is itself a claim. Evidence adapters establish, or fail to establish, what the artifact supports. `ap2-mandate`, `invoice`, `bank-receipt`, and `onchain-tx` are conventional type labels, not guarantees of settlement or legal classification.

Non-monetary `nods` MUST be a `RecordID`. The response authority is the verified author of that referenced record. Authors and clients must check whether the person actually negotiating the external proposal has the necessary authority; the core's response-author rule is not legal authority to grant equity, IP, employment, or any other right. Monetary and reputational Nods may reference external works with no protocol-identifiable author. Such references do not invent a recipient DID, ownership finding, or destination account.

### 3.4 `.response`

Schema: `legible/protocol/v2/response`. Envelope type: `response`.

| Additional field | Required? | Type and constraint |
|---|---|---|
| `about-nod` | Yes | `RecordID` of the exact Nod being answered |
| `kind` | Yes | `adequacy` or `agreement-decision` |
| `signal` | Yes | `adequate`/`inadequate` for adequacy; `accepted`/`declined` for agreement-decision |
| `note` | No | `Text` |
| `supersedes-response` | No | `RecordID` of a prior response under the relation rules below |

The response author MUST match the verified author of the record that the referenced Nod names through `nods`. This is a **referential authorization requirement**, not something a file-local signature check can establish when the target is missing. An external `nods` URI provides no response authority in this core. `agreement-decision` applies only to a non-monetary Nod.

The response records a statement; it does not execute a transfer, refund, contract, waiver, or cancellation. In particular, a later `declined` declaration does not itself undo an agreement that may already exist under external terms. A corrected Nod has a new ID; an earlier acceptance never silently attaches to changed terms.

### 3.5 `.redaction`

Schema: `legible/protocol/v2/redaction`. Envelope type: `redaction`.

Additional field: required `redacts: RecordID`. No other type-specific fields are permitted: the core contains only the four common fields and `redacts`. In particular, no free-text explanation or fragment of removed content is part of this annotation.

The author requests withdrawal of their own earlier record. Readers MUST establish same-author authorization against the target before representing a redaction as an authorized withdrawal. An unresolved target gives a pending relation, not an instruction to erase an arbitrary record.

A storage or indexing service handles the request under its declared retention and publication policies and applicable obligations. An authorized redaction SHOULD be reflected in the service's current presentation where lawful and technically supported, without falsely promising deletion of all copies. A service can also remove or restrict content under its own authority without the author's redaction. Its moderation decision is not a record signed by that author and MUST NOT be presented as one.

An author's local deletion is possible independently of any annotation. A surviving signature over an ID can remain checkable after content removal, but full core integrity and schema cannot be recomputed without the core. A redaction of a redaction records a further withdrawal; it does not automatically republish the original target or recall copies already disclosed.

### 3.6 Verification, relations, and current readings

**Independent results.** A verifier MUST distinguish at least `integrity`, `schema`, `signature/identity`, and `relations`. Each result reports success, failure, unresolved/unsupported, or not checked as appropriate. Timestamp evidence and service-policy acceptance are separate results. `signature-valid` MUST NOT be displayed as proof of full record validity, truth, human review, or legal authority.

Baseline record validation checks: safe projection; common and per-type field shapes; exact schema/type mapping; NFC; closed enums and ranges; hash equality; and the specified DID/signature suite. These checks do not include fetching references, requiring timestamps, judging truth or compelling storage. The primitive record is locally valid when those baseline checks succeed. Lifecycle applicability additionally requires the relation checks below.

| Relation | Required checks before applying a derived effect |
|---|---|
| Appoint `supersedes` | Target is an Appoint; same verified author; the supersession chain contains no cycle |
| Nod `corrects` | Target is a Nod; same verified author, exact `nods` reference, and `form`; correction chain contains no cycle |
| Response `about-nod` | Target is a Nod; its `nods` resolves to a record; response author equals that record's verified author; kind/form pair is permitted |
| `supersedes-response` | Target is an authorized response with the same author, exact `about-nod`, and `kind`; replacement chain contains no cycle |
| Redaction `redacts` | Target resolves to a verified record with the same author |

Missing target data yields `pending`; unsupported identity yields `unsupported`; known contradictory type or author yields `failed`. Keep these results separate from the local file's signature. An application MAY retain or display a pending or failed assertion as such, according to policy, but MUST NOT apply it as an authorized lifecycle act. References to withdrawn records can remain unresolved rather than being silently redirected to other records. Where redacted target bytes are unavailable, a reader may rely on its previously verified local evidence with that basis disclosed; it cannot assert fresh verification from the tombstone alone.

**Current readings are explicit projections.** Append-only here means that one signed record never changes another's bytes. It does not forbid removal of local copies or require perpetual history retention. For corrections and supersessions, an authorized descendant replaces its ancestor's assertion in the conventional current view; historical views retain both. Amounts in a correction chain MUST NOT be presented as additive payments merely because two records exist. A correction may fix an amount, currency, explanation, or evidence; it does not itself assert a new transfer. An unrelated new transfer needs a new Nod without `corrects`.

If two known authorized records independently correct the same predecessor, there are conflicting leaves. The conventional view reports the alternatives as unresolved rather than selecting the latest `created` or silently summing them. A reader may adopt a disclosed local resolution policy; it MUST label that decision as its reading. A response that supersedes an earlier response changes the author's current stated position, not any external agreement by itself. Multiple responses with no explicit replacement relation coexist, even if one has a later date. Withdrawal does not silently restore a superseded monetary amount; the current view may instead become unavailable or withdrawn.

**Duplicate transport is not a new act.** Re-ingesting the same ID reproduces the same core. Proofs and publication metadata may differ between envelopes and require their own verification; repeated copies do not increase recognition counts. Different signed records that reference the same sale or payment may still describe overlapping events. No global revenue sum follows from counting them.

**Preference checks.** When `nods` resolves to an Appoint, an authoring client SHOULD surface its `accepts-*` preferences before proposing value-bearing recognition. It SHOULD avoid initiating an unwanted offer or payment without clarification. A signed record contrary to a preference remains a declaration that can be read as such; preference mismatch is not a bad signature. A target without those fields, an external target, and an unavailable target provide no affirmative preference to infer.

**Unknown editions.** A reader may verify a computable digest or supported signature over an unfamiliar schema without claiming schema conformance. It MUST distinguish unknown from malformed under a known schema. If it retains or forwards an unknown record, it MUST preserve its core without rewriting it. No requirement forces it to retain, accept, or serve unknown, unlawful, oversized, or otherwise unwanted material.

**Resource boundaries.** The hard origin-trace limit is 2,048. Services MAY impose additional byte, depth, proof-count, rate, and traversal limits. Refusal to process under a local resource limit is a policy result, not a cryptographic conclusion. Parsers and graph readers SHOULD bound memory and work before expensive operations, avoid recursive expansion, and never assume that signed data is safe to execute.

---

# 4. Data Model

The model distinguishes the files containing declarations, the relations that
can be verified among accessible files, and the interpretations a reader builds
from them. The reader works with the material they can access; it may represent
only part of the history.

| Object | Records | Does not determine |
|---|---|---|
| Appoint | Formulation, attribution, origin Traces, NRC adoption, optional evidence and licensing statement | Originality, priority, ownership, selection, or execution |
| Trace | An author's assertion that one work depends on another | Proven causation or beneficiary assent |
| Nod | Consequence declared by its beneficiary and a chosen form of recognition | Truth, fair value, automatic entitlement, or completed settlement beyond the declaration |
| Response | The referenced record author's stated adequacy assessment or agreement decision | Automatic transfer, refund, formation, or termination of legal rights |
| Redaction | The author's request to withdraw a record | Erasure of every copy or a legal finding about retention |
| Graph projection | Relations derived from the accessible records and stated validation policy | Completeness, a universal chronology, or an authoritative ranking |
| CH | Personal interests, criteria and reflections that guide reading | A public attestation or an official classification of the person |

A graph may combine public, authorized group, and private records. Group membership and authorization to read are defined by the surrounding service or storage arrangement, not by a field in the format. A reader must not mistake the subset it sees for the complete history of a contribution or person.

Money moves through external arrangements. An application may integrate those arrangements in the same product, provided it distinguishes its payment activity from recording declarations and assumes the responsibilities of what it actually operates. The protocol has no custody function, account balance, destination registry, or settlement engine.

# 5. Coordination Heuristics (CH)

CH (*Coordination Heuristics*) is a personal, private document where you record
what you are trying to understand, which criteria matter to you, and which
limits you need to respect. It can also bring together references and
reflections about your work.

This context helps you examine other people's records and contributions:
what could help your work, what still needs clarification, and which paths
deserve investigation. The materials may come from different spaces and
sources, subject to their access conditions. You can read them on your own or
with AI assistance, using materials whose access and processing are authorized.

Using CH is optional. The document can change as your ideas develop. When an
assistant proposes changes, you decide which to accept. You also decide what
to do on the basis of that reading.

The [R&D case in the examples area](../examples/README.md#case-rd)
shows a director using this context to read her team's observations and
hypotheses before deciding on a test.

This section's requirements apply to the CH storage, editing and processing
functions of products claiming the **CH privacy capability** in §9.

## 5.1 Document content and control

The CH is written in prose. It can begin with a few lines about what the
participant considers important and wants to understand. The following six
parts suggest an organization; the participant can combine them and use their
own titles.

| Part | Content and origin |
|---|---|
| Who I am | Context and reasons the participant chooses to present |
| What I refuse | Limits and conditions defined by the participant |
| What I build on | A revisable summary of emitted Traces |
| What I said mattered | A revisable summary of emitted Nods |
| What others found consequential in my work | A summary of accessible received Nods |
| What I am looking for | Questions and directions chosen by the participant |

Parts based on records can be added when Traces or Nods are available. The
participant can write directly or ask for help formulating and organizing the
content. Structured tools can accompany the prose; the interpretation remains
personal and revisable.

The CH **MUST NOT** change automatically without the user's approval. When an
assistant proposes a revision, it presents what will be added, removed or changed;
the user approves, edits or refuses that proposal before it is applied. This
includes summaries produced from records.

A conventional path is `.ch/self.md`, outside `.legible/`; another private
location is also valid. This document is kept separately from signed records
and follows the publication and export controls in §5.2.

## 5.2 Privacy requirements

Criteria, refusals and intentions can contain sensitive information. An
implementation claiming the CH capability:

- **MUST** exclude the CH by default from public publication, usage and diagnostic data sent by the application (telemetry), and ordinary record or graph exports;
- **MUST** exclude its chosen CH directory from repository commits by default, using the appropriate ignore mechanism when Git is used;
- **MUST NOT** silently turn a CH into a signed declaration or use a signature to suggest that the document objectively describes its owner;
- **MUST** provide clear controls for authorized transmission, backup, migration or disclosure;
- **MUST** keep different users' CH contents separated and **MUST NOT** compare or aggregate them without specific authorization and an appropriate lawful basis;
- **SHOULD** encrypt stored CH content and private backups with an established authenticated-encryption implementation and a separately managed encryption key;
- **SHOULD** avoid copying sensitive CH contents into technical operation records (logs), model inputs (prompts), temporary files, diagnostics or crash reports beyond what the authorized operation requires.

A private, encrypted export can be used for backup or a change of environment.
The software **SHOULD** explain which private data each export includes. The
implementation handles access control, encryption keys, backups and deletion;
a signing key alone does not provide that protection.

## 5.3 From reflection to contribution

A CH reflection can lead to a question, proposal or other work. The participant
can keep it in the document or select a formulation to preserve separately as
a draft. If they choose formalization, they review the exact content and issue
a new Appoint under §§1.8 and 3.1. Sharing that draft or record is a separate
decision. Writing or summarizing something in the CH does not perform these
operations.

## 5.4 Creation, revision and continuity

**Creation.** The participant writes their initial direction or develops it in
conversation. They can use the parts suggested in §5.1 as they become useful.

**Revision.** A change of interest, a contribution read or a signed act can
motivate an update. The participant can edit the document; if an assistant
prepares the change, it requires the approval described in §5.1.

**Reconstruction.** Derived summaries can be rebuilt from available records,
identifying their sources and uncertainties. Initial direction and private
judgments depend on the participant's own files or backups; they cannot be
assumed recoverable from the graph.

**Change of environment.** The participant can take their CH to another tool
through an authorized private transfer. Signed records remain verifiable
independently of this document's availability.

## 5.5 Handling sensitive content

Clients **SHOULD** warn against putting unnecessary third-party personal data,
secrets, credentials or unlawfully held materials in the CH. Credentials belong
in a purpose-built secret store.

If the participant chooses to formalize a confidential formulation, they can
consider a private Appoint or the commitment to undisclosed material defined
in §3.1. Signing does not encrypt the content: storage, access and any disclosure
still need their own controls. The security considerations in §14 also apply.

## 5.6 Finding and interpreting contributions

Retrieval gathers accessible contributions; the participant examines them in
light of their question and the context they chose to keep in the CH. AI can
help explain relationships, differences and possible paths for the participant
to assess. This process can also reveal a question they had not yet formulated.

Direct references, relationship traversal, keywords, semantic search and shared
indexes are possible ways to find contributions. Their coverage and biases
differ: traversing only existing relationships, for example, may leave new or
disconnected contributions out of the reading. A service can publish its own
ordering of results, identified as that service's reading (§6).

A CH-capable implementation **MUST NOT** send the CH or a representation derived
from it to a shared index without specific user authorization. Numerical
representations used in semantic search (*embeddings*) can reveal information
about their source texts. Those derived from private CH need the same protection.
Those derived solely from public records are not, in themselves, an export
of that CH.

The informative [guide for indexers](../docs/indexing-and-responsibility.md)
details how to distinguish declarations, checks, interpretations, and access
and reuse conditions when presenting results.

## 5.7 Local or hosted processing

When AI assistance is used, local processing **SHOULD** be offered where feasible.
A hosted model can be used after the user makes an informed choice about the
content sent and the provider involved. The implementation **MUST** make this
transmission visible before it occurs and **SHOULD** minimize the data sent.

This choice authorizes the product operation and remains subject to applicable
data-protection requirements. Retention, training use, logs, international
transfers and security need to be assessed according to the actual service and
its arrangements (§14). Using the CH with a hosted model involves sending the
selected content to that provider.


# 6. Reputation Without a Protocol Score

No node has a score assigned by legible. It has declarations that a reader may place in a history: formulations, dependencies, recognized consequences, and responses. That history is incomplete wherever records are private, missing, withdrawn, or never made.

Reputation is contextual. A collaborator, investor, employer, customer, and researcher can read the same accessible history differently. The protocol defines no algorithm that collapses these purposes into one answer. A reader or service may compute a score for its own purpose; it remains responsible for its reading and for how it represents and uses it.

**Beyond volume — and beyond centrality.** Counts of records are easy to inflate. Centrality over declared dependencies can be informative, but it can also be manufactured by false assertions, Sybil identities, and collusion among real participants. A signature does not prove that someone actually built on a work. An origin Trace and a third-party Trace must remain distinguishable in the reading.

Because the protocol sets no score, there is no single official measure for
participants to try to inflate. Declarations can still be manipulated. A
history can help assess cooperation when readers can examine evidence and
people expect to keep working together. Disposable identities, one-off
exchanges and inaccessible results reduce that usefulness. Related records
alone do not distinguish trustworthy participants.

Centrality is retrospective and can privilege the already connected. A newly formulated problem may matter before anyone has depended on it. **No centrality signal is a success metric of the protocol.** A useful question for an application is whether readers can discover and consider contributions that their previous filters would have excluded, and whether that changes their decisions.

# 7. NRC — the Recognition Condition

The **Nod Recognition Convention (NRC)** describes the recognition expectation
a participant adopts when issuing an Appoint: to register a Nod when realizing
economic value in an exchange transaction from a contribution declared under
the convention. Section 7.1 explains this condition. Permission to use the work
is addressed separately through its licenses and applicable instruments (§7.2).
The NRC does not function as a license, payment demand or contract with everyone
who reads or uses the work.

Every Appoint in this edition includes the NRC version and the hash of its text
in the signed core. A verifier can check those fields. It cannot conclude from
the public history whether the participant recorded every recognition covered
by the convention: a Nod may be private or outside the sources consulted. The
absence of an accessible Nod does not prove omission.

## 7.1 The condition, immutable per version

The exact NRC 0.2 text is in Appendix A. Its digest is `sha256:42b9c41ee986a5b90c67302283d7f2ea6813979a17f41734e35b51a0e5a3953b`. `nrc` MUST equal `"0.2"` and `nrc-hash` MUST equal that digest in this edition’s Appoints. A future NRC text requires a new version and corresponding schema edition; no later publication rewrites the convention in an existing record.

The convention asks an adopting participant to register recognition when realizing economic value in an exchange transaction from a contribution declared under the convention. Consequences outside that trigger may also be recognized voluntarily. This distinguishes the minimum convention from the wider expressive range of Nods.

Registration may be private, group-restricted, or public. A reputational Nod with no monetary transfer can meet the registration expectation. Monetary and non-monetary recognition remain sovereign choices; the convention sets no amount, percentage, collection process, sanction, or automatic entitlement.

**Authorship of recognition.** The person issuing a Nod declares the consequence
they received and how they chose to recognize it. To assess that declaration,
a reader may need its context: contractual commitments, pressure, continuing
relationships or expectations of future support. The signature attributes the
declaration to a key; assessing its content requires that reading.

**Recognition does not guarantee continued support.** Whoever recognizes chooses the value of that recognition; whoever provides a resource decides whether to provide more of it, subject to that provider's own commitments and applicable obligations. A provider may consider accessible history when renewing, reducing, or ending future support. The protocol sets no required percentage and treats no provider decision as a verdict on record validity.

Removing content from one's storage is not a promise that other copies disappear. Records and evidence have actual hosts; retention, withdrawal, and data-subject requests are handled by the responsible actors under their policies and applicable law (§3.5, §14).

## 7.2 The work's license and external agreements

An Appoint's optional `license` names the license its author claims applies to the referenced work. It grants only whatever rights that license and the licensor's actual authority can supply. The protocol neither verifies title nor converts a problem formulation into ownership of a problem.

Rights may depend on licenses, contracts, statutory limitations and exceptions, employment relations, and the nature of the material. Absence of a declared license is not a universal rule that every use requires negotiated permission. A Nod does not itself transfer intellectual-property rights, create an obligation to pay royalties or replace a legally required instrument.

The NRC provides no instrument to demand payment or an answer from someone. Ordinary communication and separate agreements remain possible. A standalone Trace can make an asserted relation legible, but does not prove that the named person received a consequence, failed to register privately, or owes anything.

**Incentives and agreements.** A recognizer may want to become legible as someone who recognizes: that history can inform others' willingness to collaborate. A separate agreement may also require particular reporting or payment. Those mechanisms have different sources of obligation. The protocol's record grammar can describe either without collecting, adjudicating, or guaranteeing either one.

The informative [economic coordination guide](../docs/economic-coordination.md)
describes access to results and percentage-recognition proposals chosen after
the consequence, with external terms and selected disclosure.

## 7.3 eNRC — an organizational application profile

An organization can use the same grammar within a private perimeter: internal Appoints, operational Nods, team access, internal allocation readings, and external settlement. The organization's rules govern its own admission and workflows, subject to applicable obligations. Refusing a repository merge does not erase a person's independent local record, though that person may still have duties concerning confidentiality and disclosure.

**eNRC uses NRC 0.2.** In this edition, the name identifies its use in
organizations. It defines neither another convention nor another hash.
Internal terms and employment arrangements remain separate. A
`nod-type: operational` follows the same field, signature and evidence rules.

To make a private Appoint public, an authorized author may emit a new Appoint with the new visibility and appropriate references, using `supersedes` if its same-author conditions hold. Evidence may reference any needed organizational authorization without exposing confidential terms. The old record, its visibility, and its NRC adoption remain unchanged. Other contributors' records do not become public automatically because a descendant is published.

A different author or employer may issue its own attributed declaration, but cannot use same-author supersession to acquire another person's record. Individual authorship, organizational authority, and economic rights must remain distinct. A group key establishes a group-key declaration, not which individual performed the work or approved the signature. These matters require appropriate organizational processes and, where needed, separate legal instruments.

Applications may calculate internal allocations and perform payment integrations as their own services. There is no canonical split, and the specification author is not the employer, payroll operator, or rights adjudicator by virtue of publishing this format.

---

# 8. Governance and Sovereignty

## Contact and external operations

A record's verified signing key does not supply a contact channel or authenticate
a payment destination. Readers can use an existing conversation, organizational
directory or participant-supplied profile, checking the association as their
environment requires. An unconfirmed or unavailable contact remains explicitly
unconfirmed or unavailable. No central contact registry is required.

Contact details, banking information and operational documents belong in the
parties' chosen channels, not mandatory contribution fields. External transfer,
acceptance and delivery are distinct from the declarations in §2.4 and §3.3–3.4.
A monetary Nod states the amount declared transferred; an instruction is not
settlement evidence. A non-monetary proposal does not attest delivery. These
boundaries add no fields, signature suite or legal classification to this edition.

The optional, versioned author contact profile (`profiles/author-contact.md`)
provides one way to declare a current display name or contact channel for a
supported `did:key`. It is an auxiliary signed file, not a fourth primitive or
a condition for any record to verify. Its separate SSHSIG namespace prevents a
record signature from being repurposed as a contact declaration. The profile
does not establish civil identity, account ownership or a payment destination.
Keeping or signing it does not authorize its publication. A publisher's selection,
correction and removal process applies to the personal data it publishes,
including editorial names and record contents, independently of profile validity.

## 8.0 Service roles

A baseline record can be created and verified without authorization from, or
the continued operation of, a central protocol service. Each application
chooses the services it depends on. The table shows which functions the format
itself supports and which operations remain with services. Maintaining the
specification and operating an application are distinct activities.

| Possible role | Baseline design |
|---|---|
| Identity registrar | The author can generate a key independently |
| Record-ID allocator | The ID is derived from the core |
| Admission administrator | No membership approval enters local validity |
| Canonical index | Discovery is external; no particular index is required |
| Quality evaluator | No protocol verdict on merit or truth |
| Settlement operator | Transfers are made externally, if at all |
| Conformance certifier | Technical claims can be checked against an identified edition; no official approval service is required |

An implementation can use remote storage, a paid index, identity checks, payment services, or hosted models. Those are service dependencies it must describe honestly. They do not become universal protocol dependencies just because one product requires them.

Each reference component's documentation should identify its implemented
functions, dependencies and checks performed. A component described as offline
must operate without network access; the absence of a networking library alone
does not establish that behavior.

## 8.1 Legible centralization

An index may be centralized and still useful. A shared repository may make discovery easier. The question is which powers the operator actually has, what the user can take away, and which dependencies remain after export. A concentration of retrieval can become a practical gate even where files are portable.

A service SHOULD publish a short governance-boundary description covering its operator, supported specification edition, storage and publication scope, moderation, ranking, billing, retention, export behavior, use of hosted models, and external dependencies. These descriptions are the service's own statements, not approvals by the specification author.

An example boundary statement is: “We index records we accept under our published policies. We verify the stated cryptographic properties where supported. We compute our own search ordering. We do not establish the truth of contributions, their legal ownership, or entitlement to payment.” A product must adapt this statement to what it actually does rather than copying an inaccurate disclaimer.

## 8.2 Participant sovereignty

The participant can hold their own records, choose disclosure arrangements, use other readers, and make their own recognition decisions. Portability does not make every service free, every copy retractable, or every alternative equally useful.

Storage services claiming the portability capability MUST offer export of the user's records in their original signed form, with available proofs and associated lifecycle records that the service may lawfully supply. They MUST distinguish unavailable, restricted, or withheld material rather than representing a partial export as complete. They are not required to disclose third parties' private records, internal proprietary rankings, or material they cannot lawfully provide. Signing keys and the CH are separate private assets and MUST NOT be silently included in a public graph export.

## 8.3 Infrastructure as a participant

An infrastructure provider can itself be recognized for a contribution. An application may help formulate, index, execute, store, or verify work and receive a Nod for the consequence it produced. No mandatory protocol percentage is reserved for the specification author, an implementation, or an indexer.

A provider may extend limited resources in anticipation of future recognition and decide later whether to continue. The user chooses the recognition; the provider chooses future support, within its commitments. Such arrangements need not negotiate a percentage in advance to be expressible here. An application that does negotiate one has made an external arrangement, not changed the core convention.

Legibility can help assess whether a relationship is sustainable or disproportionate. It cannot calculate fairness from incomplete records or infer every cost and benefit. The signature makes the claims inspectable; it does not settle the assessment.

The same [informative guide](../docs/economic-coordination.md) discusses
contributions from different kinds of infrastructure, the distinction between
user benefits and operator returns, and continuity hypotheses to examine
in practice.

# 9. Conformance

A product claims conformance with an edition and the capabilities it implements.
For example, it can offer only record verification or combine authoring,
storage, search and other functions. It MUST state which capabilities it
claims, instead of treating compliance as official approval of the whole
business. The table identifies each capability's requirements.

| Capability | Required boundary |
|---|---|
| Core authoring | Emit the exact field shapes and encodings of the declared edition; compute the ID and signature; include the pinned NRC in Appoints; never silently alter signed cores |
| Core verification | Check §3 and report integrity, schema, signature/identity, and relational status distinctly; support the baseline Ed25519 DID/signature suite |
| Relational projection | Apply lifecycle effects only after required authority checks; preserve unresolved and conflicting states; distinguish third-party assertions |
| Storage and portability | Preserve retained record cores; provide lawful export under §8.2; declare service policies and retention limits |
| Indexing and discovery | Attribute readings to the service; distinguish policy refusal from validity failure; do not misrepresent incomplete coverage as universal |
| CH privacy | Apply §5 to the CH operations actually provided |
| OKF adapter | Use the explicit wrapper and round-trip rules of §10 |
| Settlement-evidence adapter | Identify evidence stage, rail/protocol edition, and verified claim under §11 |

The human approval recommendation applies to authoring clients; a format verifier cannot require proof of human presence that the suite does not carry. All authoring clients SHOULD make the adopted declaration and actual disclosure decision understandable to their users.

A service MAY decline to process, retain, publish, or index a record under its policies and applicable obligations, including content restrictions, authentication, fees, capacity, and anti-abuse controls. It MUST NOT describe that policy refusal as a failed signature or schema violation unless that failure was actually established.

An analytics product may publish its own score or ranking. A conformant product MUST NOT call its own evaluation an authoritative legible score or present it as certified by the specification author. Technical conformance does not certify legal compliance, privacy adequacy, investment quality, payment accuracy, security fitness, or any record's truth.

Supported profiles are explicitly versioned. Unknown features are not silently treated as verified. A product using `did:legible` cannot claim stable identity-profile conformance from this draft: §12 intentionally does not define a complete interoperable method.

# 10. Interoperability: The OKF Recognition Profile

**Profile: `legible-okf/0.2-draft`, targeting OKF 0.2.** This optional adapter puts signed declarations beside knowledge documents without making OKF or a particular index mandatory. OKF 0.2 includes provenance, trust, and lifecycle fields; its presence does not by itself supply a legible signature or a beneficiary's declaration of consequence. See the [official OKF specification](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md).

The adapter is a Markdown file with YAML frontmatter. Frontmatter MUST contain a non-empty OKF `type` matching the enclosed legible envelope type, and a `legible` mapping containing the **complete record envelope** defined by §3. Optional OKF presentation fields, such as `title`, `description`, `resource`, `tags`, and `generated`, remain outside this mapping. The Markdown body is also a presentation, not an additional signed core.

On import, the adapter extracts only the `legible` envelope and verifies it normally. It MUST check the correspondence of the outer `type` to the enclosed type and schema. A product MUST distinguish presentation text from authenticated core text if they differ. No OKF `generated.at` or legacy `timestamp` replaces the signed `created` value or constitutes evidence of anteriority.

On export, the adapter preserves the parsed core exactly in value, computes no replacement ID, and never normalizes received core strings. Import→export→import MUST leave the core, ID, and signature unchanged. Unknown OKF presentation metadata may be preserved where safe; it does not become part of the signed record. Unknown legible schemas remain unknown rather than being translated silently.

Example structure (schematic; placeholders are not a signed fixture):

```yaml
---
type: appoint
title: Human-readable projection
legible:
  id: <record-id>
  type: appoint
  canonical_content: <complete signed core>
  security: <signature and optional proofs>
---
```

An OKF link may suggest a candidate Trace. It is not a signed Trace until someone emits one. A shared OKF index can supply candidates to many readers without receiving their private CHs or acquiring authority over record validity. A future OKF edition requires an explicitly identified adapter update, not an implicit change to this mapping.

# 11. Interoperability: Settlement Evidence and AP2/x402

**Profile: `legible-settlement-evidence/0.2-draft`.** This profile classifies references to external payment evidence; it does not initiate, route, custody, or settle funds. A product integrating payment functions does so in its own operational role.

The core's `economic.amount` states the transfer the recognizer declares. Optional evidence supports narrower propositions:

| Stage | Possible proposition | What does not follow automatically |
|---|---|---|
| `authorization` | A specified party authorized an action within stated constraints | That money moved |
| `instruction` | An instruction, request, invoice, or submission exists | That it was accepted or settled |
| `settlement` | The referenced source reports a transfer at a stated stage of completion | Irreversibility, absence of later dispute, or truth beyond the evidence's trust model |
| `reversal` | A referenced source reports a refund, reversal, or other undoing | Automatic mutation of the earlier signed Nod |
| `other` | A separately described evidential proposition | Any unexpressed settlement conclusion |

AP2 0.2's published terminology distinguishes Checkout and Payment Mandates, with open and closed forms. They concern authorization and transaction coordination; a mandate is not, by itself, a completed-settlement receipt. An AP2 adapter MUST identify the specific AP2 edition, object type, issuer, and proposition it verifies. This draft does not freeze an AP2 SDK's serialization or claim every payment rail is implemented. See [AP2 documentation](https://ap2-protocol.org/).

An x402 or on-chain adapter similarly identifies the supported protocol/rail, network, transaction interpretation, and confirmation assumptions. It must not infer licensed-provider status, global finality, or legal compliance merely from a type label. Traditional bank, card, and manual evidence can also be referenced. The core prescribes no provider, country-specific rail, token, or mandatory currency beyond its declared currency-field syntax.

An invoice hash is evidence that an invoice's bytes were referenced, not evidence of payment. A bank receipt may contain personal or confidential information; its publication is a separate decision. A reference alone is not permission to fetch it or retain it indefinitely. Authors may keep evidence private and provide it selectively.

If a declared payment is later reversed, a subsequent declaration can explain the event and cite evidence. An app may use a correction to update its current view of the earlier assertion, but MUST distinguish a correction from the external event that motivated it. This edition defines no universal accounting ledger, netting rule, negative charge, or cross-currency total. Operational accounting and legal documents remain external.

# 12. Experimental Design Annex: Identity Persistence

**Status: experimental, not a stable conformance profile.** This annex examines
how to keep an author identifier when the key authorized to sign is replaced.
The baseline Ed25519 `did:key` does not provide that continuity. The proposed
`did:legible` method could use signed authorization events for this purpose.
The proposal does not yet define a complete method for interoperable key
rotation or secure social recovery.

The retained design direction is a signed genesis event followed by linked key-authorization events, with possible threshold guardians and a contestable recovery process. These are design candidates, not authorization rules that a baseline verifier may assume. Existing sketches and reference-code experiments require explicit versioning before use with meaningful assets or identity history. The file `.legible/did/log.json` carries public keys and timestamps; this description of scope is not a data-protection classification.

The following decisions must be specified and tested before a persistence edition can claim conformance:

1. Exact event schemas, event hashing, signature domains, authorized signers, and accepted algorithms.
2. Handling of two authorized events with the same predecessor. A signed log may fork; verification of a branch is not proof that no other branch exists.
3. A time source for a recovery window and an actual means for the holder to discover the event in time to contest it. An author-controlled `created` cannot establish elapsed public notice.
4. Threshold validation, distinct guardian counting, guardian replacement, concurrent recoveries, veto scope, and how a compromised current key affects recovery.
5. Treatment of records signed by compromised historical keys, including evidence of existence before rotation and records with insufficient temporal evidence.
6. Offline verification with a supplied authorization bundle, missing events, stale views, and an explicit ambiguous result when evidence conflicts.

A local experiment may choose these policies, but MUST identify itself as experimental and MUST NOT label unsupported identity resolution as successful baseline verification. A record using another DID method can be retained as data where policy permits; its author authorization remains unsupported until a specified verifier establishes it.

**Rotation cannot reach an author's chosen date.** A stolen old key can sign a new record with an old `created`. Historical authorization alone does not distinguish it from a legitimate older record. A verified commitment predating the compromise can provide evidence; a later timestamp does not prove forgery, because a genuine record may have been witnessed late.

Guardian immutability, indefinite veto, and particular dispute rules are trade-offs, not inevitable consequences of having no central operator. A future profile may make different choices and must state the new assumptions openly. The core does not promise algorithm agility or recovery that it has not specified.

# 13. The Substrate, Witnesses, and Adoption

Three checks are often collapsed and should remain separate:

1. **Integrity:** the core corresponds to its ID.
2. **Attribution:** the specified key signed that ID under the proper namespace.
3. **Temporal evidence:** an external witness supports existence of the committed core by a certain time.

The baseline file supplies the first two. The third requires proof material and a trust policy. It can sometimes be verified offline when that material, certificates, and relevant chain or log data are already available. “External evidence” does not always mean “make a network request now.”

For an RFC 3161 adapter, the token's message imprint must match its declared hash algorithm applied to the UTF-8 record-ID message. The adapter checks token integrity, the TSA signature, relevant certificate/trust requirements, and its time claim under a disclosed verification policy. The token does not prove human authorship or the moment an idea was conceived. [RFC 3161](https://www.rfc-editor.org/rfc/rfc3161.html).

For a public log or chain witness, the adapter must establish the applicable inclusion, ordering, and trust assumptions. A commitment to a hash does not automatically publish a record's contents or supply a complete catalog of statements by a key. In particular, OpenTimestamps is evidence of prior existence, not a public per-author declaration index. [OpenTimestamps](https://opentimestamps.org/).

Multiple independent witnesses can improve a reader's evidence. The reader must say whether it requires one, several, or a particular trust set before making a temporal conclusion. An array of proofs alone does not make falsification require compromising every listed witness.

**Git is the recommended substrate**, and it earns the recommendation on familiarity, history, and portability rather than being a trusted clock. A local commit is not proof of a remote publication time. A public push can become evidence through an external observer or service, whose reliability and available records still matter. Deleting a file from a working tree does not remove it from historical objects or clones.

Git and an optional OKF adapter can lower one part of adoption cost. They do not create readers or recognition incentives by themselves. The early value can be local: preserving a formulation and its declared genealogy before another institution has chosen it. Wider coordination depends on discovery, actual use, and people deciding that recognition is worth making legible.

---

# 14. Security Considerations

Record verification checks properties such as integrity and signature. An
application's security also depends on how it stores keys, receives content,
accesses the network and publishes data. This section gathers the threats and
limits an operator needs to consider in those operations. Conformance tests
do not constitute a security audit of the application.

| Threat or limitation | What the design provides | What it does not provide |
|---|---|---|
| Forged or changed core | Content addressing and signature verification under the specified suite | Truth, honesty, or resistance after key compromise |
| Signature reuse across protocols | An exact `legible` namespace check | Protection when a legitimate signer approves malicious content |
| Compromised key | Attribution to the key; an explicit baseline limitation | Revocation or recovery in `did:key` |
| Sybil identities and collusion | Inspectable declarations; no authoritative score to inflate | Proof of unique people or genuine dependencies |
| Conflicting claims shown to different readers | Separate attributed records, if readers obtain them | Universal discovery, consensus, or automatic contradiction detection |
| False third-party genealogy | Attribution to the asserter distinct from origin genealogy | Beneficiary admission or verified causation |
| Harmful or unlawful content | Service policies, authoring warnings, and attributable publication | Semantic legality checking by the cryptographic verifier |
| Withdrawal | An attributable request and local handling | Erasure of external copies, caches, backups, or Git history |
| Incomplete graph | Explicit unresolved and unavailable results | Proof that an absent record was never made |
| Resource exhaustion | A bounded origin list and permitted local limits | Unlimited safe ingestion or affordable reading of every record |

**Host and key compromise.** Malware can misuse an unlocked signing key or replace what a person sees. Per-record approval and compatible hardware custody reduce particular risks; they do not establish conscious review from the final signature. The baseline has no revocation registry. If a key is compromised, a new key creates a different baseline identity and readers need external context to evaluate continuity claims.

**Equivocation and overlapping events.** Two Nods with different amounts are not necessarily contradictory: they may concern different transfers, contexts, or a declared correction. Contradiction requires identifying incompatible propositions about the same event. A public-log service can improve visibility only when its publication, inclusion, availability, and monitoring rules actually do so. A bare timestamp on an undisclosed hash supplies none of those guarantees by itself.

**Commitment privacy.** Unsalted digests of guessable data permit dictionary tests. Private commitments use the construction in §3.0, with a secret random nonce and a separately controlled opening. Hashes, signatures, references, and public keys may still enable linkage; opacity is not a claim of anonymity. Publishing a core exposes any free text it contains.

**Data minimization.** Authoring clients SHOULD discourage unnecessary personal data and confidential details in free text and SHOULD make publication scope explicit. They cannot reliably decide every semantic or legal question. References themselves may identify people. The fact that a record is signed or publicly accessible is not a blanket lawful basis for every later processing operation.

**Hostile content for agents.** A verified record is authenticated input, not an instruction with authority over the reader. It may contain prompt injection, malicious links, requests to sign, or instructions to reveal the CH. Agents and applications MUST NOT promote content to tool authorization merely because its signature verifies. Network retrieval SHOULD enforce destination and scheme policies, avoid unauthorized access to local or private-network resources, and treat retrieved content as untrusted. Referenced code is not executed by verification.

**Resource exhaustion and parsing.** Bound file sizes, depth, parallel retrieval, graph traversal, and proof validation according to the service's capacity. Reject unsafe YAML features before expansion. Track visited nodes and conflicts explicitly. A quota refusal is a processing decision, not proof that the signer lied.

**No shared-state assumption.** A reader sees an accessible subset at a time. It must not use self-declared `created` as a global conflict-resolution clock, assume every accepted proposal remains current, or restore a corrected amount because a later record disappeared. It may retain its previously verified evidence according to policy and law, with its evidential basis distinguished from fresh verification.

**Hosted-model exposure.** Sending a CH to a provider is an actual disclosure under the user's selected processing arrangement. A provider's privacy, retention, training, and security commitments must be assessed separately.

**Inference from absence and concentration.** Private registration, selective visibility, and incomplete indexing limit what silence means. Shared readers and retrieval systems may converge even without a canonical score. The protocol permits alternatives and makes their roles explicit; it neither mandates meaningful competition nor guarantees plural outcomes.

# 15. The Questions the Protocol Makes Legible

| Question | What a reader can examine |
|---|---|
| Who formulated this? | The Appoint's attributed declaration and supporting evidence |
| What did the work build on? | Origin and standalone Traces, with their asserting authors kept distinct |
| Who says they benefited? | Nods signed by the declared beneficiaries |
| What was recognized, and how? | The consequence statement, chosen recognition form, amount if monetary, and optional evidence |
| How was that recognition received? | Authorized responses and their explicit replacement history |
| Which claims were revised or withdrawn? | Corrections, supersessions, and redactions within the accessible evidence |
| What deserves trust or further resources? | A contextual judgment by the reader, not a protocol answer |

Git helps preserve what changed and the author information supplied with a commit; its metadata alone does not authenticate a person's civil identity. Legible makes another question examinable: *who declared that a contribution mattered to them, and in what way?* A Nod attributes that recognition to a signing key; it does not establish universal value or the truth of the stated consequence.

Records preserve formulations, dependencies and declared consequences for consideration by different readers. Their attribution can be checked across services; assessment and operating conditions follow §§8 and 16.

# 16. Licensing and Scope

This specification, including the NRC text, is available under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/legalcode.en). Reference code identified as such is distributed under [Apache-2.0](https://www.apache.org/licenses/LICENSE-2.0). The respective licenses govern reuse, attribution, warranty disclaimers, and limitations of liability.

Conformance describes technical compatibility with an identified edition and capability. It does not imply certification or endorsement of an implementation by the specification author. Applications and services operate under their own terms and arrangements; those activities are separate from publication of this format.

Records contain declarations by their signatories. A signature verifies attribution to a key, not the truth of a claim, ownership of a work, or legal authority. The NCO is the signatory's declaration, not a certification by the specification author.

The protocol records recognition and references external evidence; it does not execute payments or determine the legal effect of a declaration, signature, or agreement. Those effects depend on the parties' actual acts, applicable terms, and applicable law.
---

# Acknowledgments

The author thanks the people below for discussions and experiences that helped
shape his ideas. These acknowledgments describe that intellectual relationship;
they do not indicate participation in operating the protocol, certification or
endorsement. Editorial choices are the author's.

- **Oswaldo Oliveira** (*in memoriam*, d. 2017) — the distinction between a paradigm of scarcity and one of abundance, and the applied organizational work at Prospera from which this author's understanding of it descends.
- **Carl Amorim** — co-author of the Prospera manifesto and of the field practice that stress-tested those principles in a live organization.
- **Marcelo Michelsohn** — years of joint experimentation on making distributed coordination livable at scale, from Project Syntropy onward.
- **Amanda Guimarães** — philosophical synthesis and sustained dialogue on the coordination principles the grammar rests on.
- **Courtnay Guimarães** — intellectual provocation and adversarial defense of the protocol's claims.
- **Fernando Lemos** — architectural interrogation and the exploration of corporate adoption pathways.

The intellectual genealogy of the underlying argument — including the lineage this author declares, and its limits — is stated in the author's own companion works, which are **not part of this protocol** and which this specification does not depend on.

---

# Normative References

Only the specified subsets are requirements of the capabilities that use them. Referencing an external document does not delegate version changes to a mutable website.

1. [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119.html) and [RFC 8174](https://www.rfc-editor.org/rfc/rfc8174.html): BCP 14 requirement language.
2. [RFC 8259](https://www.rfc-editor.org/rfc/rfc8259.html) and [RFC 8785](https://www.rfc-editor.org/rfc/rfc8785.html): JSON and JCS, with the additional input constraints in §3.0.
3. [YAML 1.2.2](https://yaml.org/spec/1.2.2/): alternative serialization, restricted to the explicit §3.0 subset.
4. [Unicode Normalization Forms, UAX #15](https://www.unicode.org/reports/tr15/): NFC for core strings before emission. Unicode-version support should be documented by implementations; received strings are never silently rewritten.
5. [RFC 8032](https://www.rfc-editor.org/rfc/rfc8032.html): Ed25519; [OpenSSH SSHSIG format](https://raw.githubusercontent.com/openssh/openssh-portable/master/PROTOCOL.sshsig): the signature structure, constrained by §3.0.
6. [DID Core 1.0](https://www.w3.org/TR/did-core/) and [did:key method](https://w3c-ccg.github.io/did-key-spec/): identifier syntax and baseline key encoding; the exact Ed25519 subset is pinned in §3.0.
7. [FIPS 180-4](https://csrc.nist.gov/pubs/fips/180-4/upd1/final): SHA-256 used for record IDs and specified commitments.

Profile-specific references: RFC 3161 for a claimed TSA adapter; OKF 0.2 for §10; the explicitly identified AP2/x402 edition and rail specifications for a claimed settlement adapter. These profiles are not prerequisites for baseline records.

# Informative References

---

- [ALM03] Autor, D. H., Levy, F., & Murnane, R. J. (2003). The Skill Content of Recent Technological Change: An Empirical Exploration. *Quarterly Journal of Economics*, 118(4), 1279–1333.
- [AA11] Acemoglu, D., & Autor, D. (2011). Skills, Tasks and Technologies: Implications for Employment and Earnings. *Handbook of Labor Economics*, vol. 4B, 1043–1171.
- [Aut14] Autor, D. H. (2014). Polanyi's Paradox and the Shape of Employment Growth. *NBER Working Paper 20485*.
- [NZ23] Noy, S., & Zhang, W. (2023). Experimental Evidence on the Productivity Effects of Generative Artificial Intelligence. *Science*, 381(6654), 187–192.
- [BLR25] Brynjolfsson, E., Li, D., & Raymond, L. (2025). Generative AI at Work. *Quarterly Journal of Economics*, 140(2), 889–942.
- [DA23] Dell'Acqua, F., et al. (2023). Navigating the Jagged Technological Frontier: Field Experimental Evidence of the Effects of AI on Knowledge Worker Productivity and Quality. *Harvard Business School Working Paper 24-013*.

---

Additional references:

- [Open Knowledge Format](https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md), optional knowledge-document integration.
- [AP2](https://ap2-protocol.org/) and [x402](https://www.x402.org/), optional external payment-protocol integrations.
- [OpenTimestamps](https://opentimestamps.org/), optional temporal evidence.
- The licenses linked in §16, governing reuse of the specification and reference code rather than record validity.

# Appendix A. Canonical NRC 0.2 Text

The canonical bytes are the Portuguese UTF-8 text inside the block, with LF
line endings, no BOM or indentation, and one LF after the last line. Fence
delimiters are excluded. The digest is `sha256:42b9c41ee986a5b90c67302283d7f2ea6813979a17f41734e35b51a0e5a3953b`.
The English reference translation is `nrc/v0.2/nrc-EN.txt`; its bytes do not
replace the canonical Portuguese artifact.

```text
Convenção de Reconhecimento por Nod 0.2
Esta convenção distingue o reconhecimento de consequência da permissão para usar uma obra.
Um participante que adota esta convenção registra um Nod quando realiza valor econômico em uma transação de troca a partir de uma contribuição declarada sob esta convenção, identificando a contribuição e a consequência que recebeu.
O registro pode ser privado, restrito a um grupo ou público. A publicação é uma decisão separada.
O reconhecimento pode não incluir pagamento. Qualquer montante monetário ou oferta não monetária é escolhido pelo reconhecedor; esta convenção não estabelece mínimo, percentual, dívida ou direito automático.
Um Nod monetário informa o montante declarado como transferido em reconhecimento, não o benefício total recebido pelo reconhecedor. O benefício pode ser explicado separadamente.
A convenção não oferece mecanismo de cobrança, execução, penalidade ou exigência. Não obriga à continuidade da colaboração nem à oferta de recursos futuros.
Um registro contém uma declaração, não uma consequência verificada, uma determinação de direitos ou prova de cumprimento por qualquer outra pessoa. A ausência de Nod público não demonstra ausência de registro.
Adotar esta convenção não vincula, por si só, outra pessoa a um contrato nem altera a licença da obra. Eventuais obrigações jurídicas dependem da lei aplicável e dos atos e acordos efetivos das partes.
```

# Appendix B. Fictional Signed Examples

These examples belong to the initial publication baseline and use v2 schemas, the Portuguese NCO and the digest of the Portuguese NRC in Appendix A. Their identities and signatures are exclusively for testing.

These are **fictional test records**, not actual transactions, grants of rights, or statements by real contribution participants. All example private keys are intentionally public fixtures. Never use them for operational records.

For each fixture role, the Ed25519 private seed is SHA-256 of the ASCII string `legible-v1-public-fixture:` followed by `ana`, `recognizer`, or `curator`. Derive the public key and baseline DID under §3.0. Each core below uses ASCII and the integer 1 where a numeric weight occurs, so its compact, lexicographically sorted JSON is also its JCS representation. This restricted fixture construction is not a replacement for a general JCS implementation.

The examples include a problem-only Appoint, a dependent Appoint, third-party curation, an initially mistaken monetary amount, its correction, an authorized adequacy response, and withdrawal of that response. The corrected recognition is **BRL 100.00**, not BRL 1,100.00. The BRL 10,000.00 benefit appears only in the explanation. No payment evidence is required by the record shape, and these fixtures do not prove that payment occurred.

Hashes and the included signatures were checked for these exact fixtures with OpenSSH. Altered signed messages and an incorrect namespace were rejected. This check does not claim independent implementation conformance, general parser correctness, deployment readiness, or a security audit.

---

## 01-appoint

```json
{
  "id": "8f8aea6e732adc78a6dc5ab5341415aacff280c4055e2e4ea104427b5bb926ab",
  "type": "appoint",
  "canonical_content": {
    "accepts-monetary": true,
    "accepts-non-monetary": true,
    "author": "did:key:z6MkmxdZv6WLYxFmajNpvhyUy6Dr6kcFzE75mMopZWANqHX7",
    "content_schema": "legible/protocol/v2/appoint",
    "created": "2026-09-19T12:00:00Z",
    "metadata": {
      "title": "A reusable export method"
    },
    "nrc": "0.2",
    "nrc-hash": "sha256:42b9c41ee986a5b90c67302283d7f2ea6813979a17f41734e35b51a0e5a3953b",
    "payload": {
      "problem": "How can a software project export its data without tying users to one provider?"
    },
    "visibility": "public"
  },
  "security": {
    "signature": "-----BEGIN SSH SIGNATURE-----\nU1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgb4f852IKOREtTUDuXV3awLtTYp\nC7i8DSUxRYWCs1ZcIAAAAHbGVnaWJsZQAAAAAAAAAGc2hhNTEyAAAAUwAAAAtzc2gtZWQy\nNTUxOQAAAEBWN3q192Qx7GG6yMmkkhN8Y/Pdl9LXt/hFm+h978HCJxZC4hmn+48hE2GKEJ\nhBp8NJD/lSMWTBZAaNXHE3O68I\n-----END SSH SIGNATURE-----\n"
  }
}
```

---

## 02-dependent-appoint

```json
{
  "id": "2e3876c9a2bcdcee3ea26b690dad892ba7f56ef20c8c717182e74573579de7cb",
  "type": "appoint",
  "canonical_content": {
    "accepts-monetary": true,
    "accepts-non-monetary": false,
    "author": "did:key:z6MkuAa5axDG7AzQHJwSUDVmzBEtkKTyxQrjAduVZwbhqjpw",
    "content_schema": "legible/protocol/v2/appoint",
    "created": "2026-09-19T12:01:00Z",
    "metadata": {
      "title": "Software using the export method"
    },
    "nrc": "0.2",
    "nrc-hash": "sha256:42b9c41ee986a5b90c67302283d7f2ea6813979a17f41734e35b51a0e5a3953b",
    "payload": {
      "problem": "Users need to move their project data.",
      "solution": "Implement the referenced export method."
    },
    "traces": [
      {
        "relationship-type": "uses",
        "target": "8f8aea6e732adc78a6dc5ab5341415aacff280c4055e2e4ea104427b5bb926ab",
        "weight": 1
      }
    ],
    "visibility": "public"
  },
  "security": {
    "signature": "-----BEGIN SSH SIGNATURE-----\nU1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAg2pjSWrsLaWOIQAEXHmEVZs53Y8\nOoV6RCqozbyK6iAYQAAAAHbGVnaWJsZQAAAAAAAAAGc2hhNTEyAAAAUwAAAAtzc2gtZWQy\nNTUxOQAAAEAjrvi2lpPoENQyRpxZcKN55lDMDCUwtz6z98d4Rne2P3uJN8U47IrssmC9xK\nOkFLfWc6X604pfeTzW74bqd8IO\n-----END SSH SIGNATURE-----\n"
  }
}
```

---

## 03-curator-trace

```json
{
  "id": "c977756d0a8d7761806f2394b232b8a13e600c51757c541e1b2ec18e9a05dd33",
  "type": "trace",
  "canonical_content": {
    "author": "did:key:z6MktHWjMTwzfn6h6U8wFyby42qb3HvWqtkVEXajNk2ttJUp",
    "content_schema": "legible/protocol/v2/trace",
    "created": "2026-09-19T12:02:00Z",
    "note": "A curator asserts this dependency; this is not a declaration by the source author.",
    "relationship-type": "uses",
    "source": "2e3876c9a2bcdcee3ea26b690dad892ba7f56ef20c8c717182e74573579de7cb",
    "target": "8f8aea6e732adc78a6dc5ab5341415aacff280c4055e2e4ea104427b5bb926ab",
    "visibility": "public",
    "weight": 1
  },
  "security": {
    "signature": "-----BEGIN SSH SIGNATURE-----\nU1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgzYRp9NZVleKRxySvxChAADdWHr\ngJr9wcjGKMPKXCmLkAAAAHbGVnaWJsZQAAAAAAAAAGc2hhNTEyAAAAUwAAAAtzc2gtZWQy\nNTUxOQAAAEAxxK6zA0SWuhzjB1mD9SIxYZU4b5/KD9150AQB5TzHHAxIfEwWs4zojaOS7d\ngMcZCif8xfz9zhfqBwrSJPj+MB\n-----END SSH SIGNATURE-----\n"
  }
}
```

---

## 04-initial-nod

```json
{
  "id": "d5c2a9a89c1fcb664a6a6a272bea71305949b0eed67edf69a523116953b08990",
  "type": "nod",
  "canonical_content": {
    "author": "did:key:z6MkuAa5axDG7AzQHJwSUDVmzBEtkKTyxQrjAduVZwbhqjpw",
    "consequence": "enabled",
    "content_schema": "legible/protocol/v2/nod",
    "created": "2026-09-19T12:03:00Z",
    "economic": {
      "amount": "1000.00",
      "currency": "BRL"
    },
    "form": "monetary",
    "nod-type": "recognition",
    "nods": "8f8aea6e732adc78a6dc5ab5341415aacff280c4055e2e4ea104427b5bb926ab",
    "statement": "The contribution enabled the software sale. This initial amount contains a transcription error.",
    "visibility": "public"
  },
  "security": {
    "signature": "-----BEGIN SSH SIGNATURE-----\nU1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAg2pjSWrsLaWOIQAEXHmEVZs53Y8\nOoV6RCqozbyK6iAYQAAAAHbGVnaWJsZQAAAAAAAAAGc2hhNTEyAAAAUwAAAAtzc2gtZWQy\nNTUxOQAAAECVFTg+wU/cJCAnwUfdf29yXUmpI0YJFVdIALm4Q1RwqztpD/bD+Y3iCXsLFO\nfGChFVEANFsp0+Dw8AfUvngS8P\n-----END SSH SIGNATURE-----\n"
  }
}
```

---

## 05-corrected-nod

```json
{
  "id": "aebedf660cd240eebe01cc4bf3225a012d724e80f3f95bc5b7b77d2476f12b4e",
  "type": "nod",
  "canonical_content": {
    "author": "did:key:z6MkuAa5axDG7AzQHJwSUDVmzBEtkKTyxQrjAduVZwbhqjpw",
    "consequence": "enabled",
    "content_schema": "legible/protocol/v2/nod",
    "corrects": "d5c2a9a89c1fcb664a6a6a272bea71305949b0eed67edf69a523116953b08990",
    "created": "2026-09-19T12:04:00Z",
    "economic": {
      "amount": "100.00",
      "currency": "BRL"
    },
    "form": "monetary",
    "nod-type": "recognition",
    "nods": "8f8aea6e732adc78a6dc5ab5341415aacff280c4055e2e4ea104427b5bb926ab",
    "statement": "The contribution enabled a BRL 10000.00 sale. The amount transferred in recognition was BRL 100.00. This corrects the earlier amount; it does not declare a refund.",
    "visibility": "public"
  },
  "security": {
    "signature": "-----BEGIN SSH SIGNATURE-----\nU1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAg2pjSWrsLaWOIQAEXHmEVZs53Y8\nOoV6RCqozbyK6iAYQAAAAHbGVnaWJsZQAAAAAAAAAGc2hhNTEyAAAAUwAAAAtzc2gtZWQy\nNTUxOQAAAED985P5YjZO8tXsZfm07MBhQmlclpSzXUTa5ny8vxdF23mYAB3I1JP0R+Xtnt\nU3W3XqrSQdCkhHHst5jRVI7KUL\n-----END SSH SIGNATURE-----\n"
  }
}
```

---

## 06-response

```json
{
  "id": "8c896411bda37d14787299983b77a65012759ff5addeb53e3a92eac4567f57ec",
  "type": "response",
  "canonical_content": {
    "about-nod": "aebedf660cd240eebe01cc4bf3225a012d724e80f3f95bc5b7b77d2476f12b4e",
    "author": "did:key:z6MkmxdZv6WLYxFmajNpvhyUy6Dr6kcFzE75mMopZWANqHX7",
    "content_schema": "legible/protocol/v2/response",
    "created": "2026-09-19T12:05:00Z",
    "kind": "adequacy",
    "signal": "adequate",
    "visibility": "public"
  },
  "security": {
    "signature": "-----BEGIN SSH SIGNATURE-----\nU1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgb4f852IKOREtTUDuXV3awLtTYp\nC7i8DSUxRYWCs1ZcIAAAAHbGVnaWJsZQAAAAAAAAAGc2hhNTEyAAAAUwAAAAtzc2gtZWQy\nNTUxOQAAAEBzwUXvWoSCXAUKy8X9bF+Kf/tAJ5rJeybfAGngDYD/Q2W72W3fcVHkOyDtCk\nXxzAh6j0+Q1Y8QucpGag5hv04G\n-----END SSH SIGNATURE-----\n"
  }
}
```

---

## 07-redaction

```json
{
  "id": "f8e165d7fab903bcf7469c2423e7b2deb5dd5d1caed17d16be01b3f59bc98382",
  "type": "redaction",
  "canonical_content": {
    "author": "did:key:z6MkmxdZv6WLYxFmajNpvhyUy6Dr6kcFzE75mMopZWANqHX7",
    "content_schema": "legible/protocol/v2/redaction",
    "created": "2026-09-19T12:06:00Z",
    "redacts": "8c896411bda37d14787299983b77a65012759ff5addeb53e3a92eac4567f57ec",
    "visibility": "public"
  },
  "security": {
    "signature": "-----BEGIN SSH SIGNATURE-----\nU1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgb4f852IKOREtTUDuXV3awLtTYp\nC7i8DSUxRYWCs1ZcIAAAAHbGVnaWJsZQAAAAAAAAAGc2hhNTEyAAAAUwAAAAtzc2gtZWQy\nNTUxOQAAAEBwOHSqTX8liju54Hh1EnsxwUyVtoQrZmR6SGKr0jlJ15079+JG6Kd1xYc3gB\n74mC5xTeHGbMF+27zgTXCLyv8L\n-----END SSH SIGNATURE-----\n"
  }
}
```

---

# Appendix C. Implementation and Conformance Cases

Each implementation identifies the capabilities it offers and the tests it
runs. The distribution includes the NRC, schemas, positive and negative cases
and licenses to support those checks.

A conformance assessment examines cross-language JCS, NFC, duplicate keys,
unknown schemas, optional fields, outer-type correspondence and signature
namespace. It also considers unauthorized relations, missing targets,
conflicts, response replacement, late records, cycles, policy refusals,
withdrawal and OKF round trips, according to the capabilities claimed.
Identity recovery remains experimental.

Implemented tests are identified in `conformance/README.md` and
`conformance/demos/README.md`. The checklist above also includes cases to assess;
it does not mean that all are implemented or have passed. This distribution
does not yet include a specific OKF wrapper round-trip test. Compatibility
with another product requires its own execution evidence.

Legible is a contribution that can be examined, implemented, criticized and forked.
Independent specifications need no Legible approval or catalogue. A fork must identify
its own authorship, normative artifact and actual differences. Distinct names
and independent versioning identify proposals without establishing official
succession or an operational relationship between their maintainers.

# Appendix D. Conformance artifacts

The conformance set is `conformance/vectors.json`, its signed fixture is `conformance/signed-fixture.json`, and the seven complete examples are in `conformance/records.json`. Schemas are in `schemas/`. All belong to the initial baseline identified by v2 and use fictional identities. A verifier claiming support for this edition **MUST** reproduce its IDs and check the test signatures. An unknown edition **MUST NOT** be reinterpreted as v2. Tests also cover content alteration, an incorrect namespace and the lifecycle relations in §3.6. The NRC is the exact Portuguese text and digest in Appendix A.

# Appendix E. Economic rationale (informative)

This appendix gathers the design's economic motivation. Its hypotheses and
references help examine the proposal; they add no record-validity requirements.

## E.1 Recording and reading costs

Preserving contributions before selecting them is not a new idea. Its practical
reach depends on the costs of recording, maintaining, finding and examining the
material. A person can formulate something outside an assigned task; preserving
that formulation allows another reader to consider it later where storage and
access support this.

The author's argument is that titles, credentials and categories can serve as
proxies when examining each contribution is costly. If the total cost of recording
and useful reading falls, it may become feasible to consider material previously
excluded by those filters. Assistants can help describe interventions during work
and retrieve sources for a particular question. Attention remains finite; the
hypothesis does not assume that every contribution will be read.

## E.2 Execution, initiative and judgment

The task-based literature describes technological substitution for tasks rather
than workers, especially routine, codifiable execution, alongside greater demand
for non-routine cognitive work [ALM03], [AA11]. When execution is the bottleneck,
the deliverable can serve as a sufficient proxy for contribution. As cognitive
execution becomes more accessible, initiative, commitment and judgment may matter
relatively more. Cheap execution does not create their value; it may reveal value
that previously did not need to be recorded.

A delivery leaves an artifact; the initiative and judgment that made it useful
do not always leave a comparable record. The argument goes beyond that literature:
generative systems have also begun assisting or substituting for non-routine
cognitive activities associated with Polanyi's paradox [Aut14]. Empirical studies
and experiments report modest, uneven per-task gains in the tens of percent and
worse results outside the capability frontier [NZ23], [BLR25], [DA23]. These
findings do not establish universal execution at zero cost.

The hypothesis concerns a possible asymmetry between execution costs and the
costs of choosing purposes, taking responsibility and committing resources. Its
reach varies by activity and available capabilities; it is neither a permanent
law nor a prediction about what machines will never do. The protocol allows
declarations of who acted in each layer. The human-approval recommendation for
signing concerns adoption of the declaration (§2.1); the file proves neither
human presence nor understanding.

## E.3 What to observe in a trial

A trial can examine whether participants can preserve questions before work
allocation, find accessible contributions their previous filters would have
excluded, and use them in new formulations or decisions. Description, retrieval,
review and maintenance costs need to be included. A working record exchange
demonstrates operations; coordination benefits need their own observation,
including inconclusive or adverse results. The author's companion works develop
the wider argument.