# Indexing Legible records: attribution and responsibility An index helps readers find and examine records from selected sources. This guide explains how its operator can distinguish the original declarations, checks performed and interpretations added by the tool. It applies to local, organizational and public tools that preserve, find, summarize or present accessible records. It is informative guidance for The Legible Protocol draft 0.4; it adds no validity requirements and grants no license to operate an index. The complete [Portuguese specification](../spec/legible-PT.md) is the primary normative source; the [English edition](../spec/legible-EN.md) is its synchronized reference translation. See §§3.0, 3.6, 5.6 and 14 for the corresponding protocol rules. ## 1. State what was checked A record can be structurally valid and correctly signed while making false claims. Report the identified schema edition, content ID, signature result and verification method. Report reference resolution, lifecycle authority and temporal evidence separately; checking one does not establish the others. An unavailable dependency is not evidence that it was never used. An author-set `created` value is not an independently witnessed date. Keep the original signed bytes available within the permitted access conditions. Attach a summary or translation as a reader's representation, without changing the signed core or implying that the signatory approved that representation. ## 2. Explain the NCO without enlarging it The NCO is the conventional adoption declaration associated with signing the identified schema edition. Its exact text is in spec §3.0. It accompanies the meaning of the signature as a record moves between independent tools; it is not a certification issued by those tools or by the specification author. This gives an index a common basis for attributing the statement to a key and distinguishing it from the index's own interpretations. Cryptographic verification does not establish conscious acceptance, good faith, civil identity, organizational authority, originality or ownership. Do not label a record "original authorship certified" or "reuse rights confirmed" on the strength of its signature or NCO. A contact profile uses a separate meaning and namespace. Its signature is not a record's NCO, and a declared contact is not an independently verified identity or payment destination. No contact profile is required for record validity. The signed `content_schema` selects the convention. This initial baseline uses v2 with the canonical Portuguese NCO and an English reference translation. Never select NCO by `created` or by whichever site version is newest. The mapping and text digest are distributed in `spec/editions.json`; these are publication metadata, not additional signed core fields. Unknown editions receive no presumed NCO. Preserve the original core, ID and signature. ## 3. Attribute the index's own additions Present these layers distinctly, including in machine-readable output: | Layer | What to disclose | |---|---| | Declaration | The signatory's content, key, record ID and schema edition | | Verification | Checks performed, results, method and unresolved dependencies | | NCO | The conventional meaning associated with that edition's record signature | | Interpretation | Who produced a summary, classification, suggested relation or ranking | | Access and reuse | Known conditions, source and limits of any permission claimed | If an AI proposes a relation, label it as a proposal. A relation declared by a participant is attributable to that declarant, including a third-party Trace; it is not automatically a statement by the authors of the related works. Do not turn the index's ranking into a protocol score or assign adverse meaning to missing records or Nods. Coverage, source selection and access limits matter. Treat record content as untrusted data for execution. A valid signature on a command does not authorize tools, disclosure, network access or further signing. ## 4. Examine rights for each operation The NCO is not a general indexing license. A record signature, a DCO sign-off, a GitHub PR and a `public` visibility value do not interchangeably authorize all operations. Examine the act, applicable law, material's terms and the conditions under which it was made available: | Operation | What needs examination | |---|---| | Referencing an ID or location | Accuracy of the reference and any personal information revealed | | Displaying metadata | Its origin, accuracy, applicable rights and personal-data treatment | | Reproducing the formulation or evidence | The relevant copyright permissions, disclosure conditions and confidentiality | | Creating embeddings or sending content to AI | Purpose, access, personal data, confidentiality and the provider's processing conditions | This does not mean individual consent is the only possible legal basis for every operation. The basis depends on the operation and jurisdiction. In Brazil, consider LGPD's applicable grounds and principles, including purpose, adequacy and necessity. Public accessibility alone does not remove those requirements. Repository licenses cover identified repository materials, not every work referenced by a record. A contributor may license their declaration while the underlying work or evidence remains restricted. A reference gives no access right and grants no right to reproduce the referenced content. ## 5. Define access, processing and retention Describe what the operator collects, why, where it is stored, who can access it and how long it is retained. Minimize personal details and keep restricted evidence behind its applicable access conditions. A CH (Coordination Heuristics) privately describes a reader's interests and context. Do not upload it or a derived representation to a shared index without the specific authorization required by the claimed CH capability. An optional contact profile may change. Select and review the actual version to publish; do not make contact histories public merely because signed versions exist. Review exports, downloads, caches and provider copies as part of the same publication or correction process. Avoid promising control over other people's clones or backups. ## 6. Handle corrections, disputes and withdrawal Publish a practical reporting route. Someone mentioned in a record, or a person who lost a key, must be able to request assessment without producing a signed Redaction. Evaluate the request and obligations; a request does not automatically decide every measure or revoke an existing license. Signed corrections and lifecycle annotations remain attributable declarations, distinct from the operator's own moderation decisions. Where appropriate, restrict current display, update derived representations and review copies under the operator's control. Do not rewrite signed content as though the author signed a correction. State the limits of erasure from Git history and distributed copies without treating those limits as a blanket exemption from duties to act. ## 7. Preserve interoperability and identify the operator An index may choose its sources and terms of service; its refusal does not invalidate records elsewhere. Identify the operator, capabilities, edition, coverage and export conditions. Preserve record identifiers and distinguish signed statements from derived views so another authorized reader can check and interpret them with different tools. DCO governs submissions to the maintained repositories; NCO concerns signed record declarations; the index operator remains responsible for its own collection, processing, presentation and publication. None transfers all responsibility to another layer. This guide supplies architectural distinctions, not a legal clearance for a particular deployment. Sources: [DCO 1.1](https://developercertificate.org/), [LGPD](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm), [Apache-2.0](https://www.apache.org/licenses/LICENSE-2.0), [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/legalcode.en).