On this page

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 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 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.

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.

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 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 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 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 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.

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):

---
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.

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.

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.

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. Reference code identified as such is distributed under Apache-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 and RFC 8174: BCP 14 requirement language.
2. RFC 8259 and RFC 8785: JSON and JCS, with the additional input constraints in §3.0.
3. YAML 1.2.2: alternative serialization, restricted to the explicit §3.0 subset.
4. Unicode Normalization Forms, UAX #15: NFC for core strings before emission. Unicode-version support should be documented by implementations; received strings are never silently rewritten.
5. RFC 8032: Ed25519; OpenSSH SSHSIG format: the signature structure, constrained by §3.0.
6. DID Core 1.0 and did:key method: identifier syntax and baseline key encoding; the exact Ed25519 subset is pinned in §3.0.
7. FIPS 180-4: 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, optional knowledge-document integration.
• AP2 and x402, optional external payment-protocol integrations.
• OpenTimestamps, 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.

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

{
  "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

{
  "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

{
  "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

{
  "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

{
  "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

{
  "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

{
  "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.

Read this page as Markdown