--- fragment_peers: create-a-new-signed-record: criar-um-novo-registro-assinado how-to-specify-a-traces-weight: como-informar-o-peso-de-um-trace looking-after-your-signing-key: cuidados-com-a-chave-de-assinatura prepare-and-retain-a-draft: preparar-e-guardar-um-rascunho records-and-verifiability: registros-e-verificabilidade share-a-selected-draft: compartilhar-um-rascunho-selecionado states-and-operations: estados-e-operacoes the-draft-contract: o-contrato-dos-rascunhos tools-for-preparation-and-verification: ferramentas-para-preparar-e-verificar what-each-declaration-presents: o-que-cada-declaracao-apresenta what-you-want-to-verify: o-que-voce-deseja-poder-verificar lang: en peer: pt/drafts/ shared_fragments: false title: Records and verifiability --- # Records and verifiability How much to record depends on what is at stake. An informal observation may need only a few lines. A project involving risks, investments or several organizations may justify references, evidence and more detailed records. A draft can remain informal throughout its use. If someone wants to formalize a formulation, they can create a signed declaration that references the draft as evidence. What matters is that the record is proportionate to what you want to preserve and how others may use it. [Your first draft](first-draft.md) shows how to start without a signature. ## What each declaration presents **Appoint** presents a formulation someone takes responsibility for: a problem, hypothesis, criterion or proposal. **Trace** declares what drew on what; it can also record an attributed third-party reading. **Nod** records a consequence acknowledged by its beneficiary. Records can be read together, preserving who declared each relationship or recognition. A Nod assigns no universal rating to the work. In monetary recognition, the declared transferred amount differs from the described benefit. The [specification](specification.md) defines exact fields and conditions. ## What you want to verify | Question | Relevant element | |---|---| | What does someone declare they formulated or took responsibility for? | The declaration's content, context and available evidence | | Does the file match its identified content, signed by the indicated key? | Content identifier and signature, checked by verifiers | | Did this content demonstrably exist by a certain time? | Independent temporal evidence, checked under its trust conditions | | Is the declaration true or the work suitable for my context? | The reader's examination of reasons, evidence and relationships | A signature allows integrity and key attribution to be checked without establishing civil identity or content correctness. The author's declared date does not establish independently witnessed prior existence either. When time matters, timestamps or other witnesses described in [section 13](specification.md#section-13) can be added. Evidence obtained today does not by itself establish existence yesterday. Recording an old technique today does not assert it was created today either: the age of a work and of its declaration differ. ## Looking after your signing key Before signing, choose where to keep your private key and how to maintain a protected backup. It should remain in your trusted environment, separate from the records you share. Do not paste it into an AI conversation, include it in a repository or send it with the files. The public key, by contrast, allows signatures to be checked and can be presented through a channel by which you are already known. In this edition's baseline profile, the `did:key` identifier derives from the public key. If you lose the private key and have no usable backup, you can no longer sign new declarations with it. Previously preserved records remain verifiable: their existence and signatures do not depend on retaining the private key. If someone obtains your private key, they can sign declarations as the controller of that same key, including with an old `created` date. That date does not establish when the record existed. Independent temporal evidence predating the compromise can help distinguish records that already existed; evidence obtained afterwards does not resolve that uncertainty on its own. The baseline profile provides no revocation, rotation or recovery that retains the same `did:key`. If you need another key, communicate the change through known channels and present the relevant evidence. Readers will assess that link; it is not automatic recovery by the protocol. The persistence design in [section 12](specification.md#section-12) remains experimental. An optional contact profile can present a key and a channel declared by its author. The profile's signature establishes neither civil identity nor control of the email address provided. Anyone who needs to check the link should use means independent of the declaration itself. ## How to specify a Trace's weight A formal Trace requires the declared relationship, an explanation in `note` and a numeric `weight` from zero to one inclusive. The draft uses the Genealogy 0.1 convention's fields and does not require that weight. Preparing a formal declaration therefore requires choosing the value its author will actually take responsibility for. The weight expresses an attribution suggestion, according to the judgment of whoever declares the relationship. It is neither a verified probability, a universal measure of merit nor a mandatory payment share. In `note`, explain the dependency and the meaning assigned to the number: stating `0.5`, for example, does not demonstrate that half of the work's total value came from that source. Stating `1` does not exclude other dependencies either. If you do not yet know what weight to take responsibility for, keep the relationship in draft while examining it. AI can help discuss the choice, but should not fill in the value silently. Origin weights in an Appoint are only recommended to sum to one when the author intends a complete attribution allocation; that sum is neither a validity condition nor a financial distribution rule. Consult [sections 2 and 3](specification.md#section-2) for the formal contract. ## States and operations
### Prepare and retain a draft Describe the contribution and review what has been attributed to you. You can keep editing privately or save it for later. Authorship is declared, without a cryptographic signature. ### Share a selected draft Choose the version and recipient. The recipient preserves the file and its origin to understand relationships and recognize a later retransmission. ### Create a new signed record Review and sign a separate declaration, which may reference the draft as evidence. The draft remains informal. The signed record can also be kept private.
These operations are independent choices. Preparing does not authorize sharing, and sharing a draft does not formalize it. The same applies to proposed recognition: it is not yet a signed Nod. ## The draft contract **Legible Draft** uses the **Genealogy 0.1** convention: Markdown with a YAML header. The [format](downloads/genealogy-0.1.md) defines the fields, including `genealogy: "0.1"`; the [draft profile](downloads/draft-profile.md) defines identification, exchange and relationships. The documents complement one another. In interchange, preserve origin, handle and hash of the exact bytes. A local handle may appear in more than one origin. Resending the same version creates no new contribution; different bytes under a shared handle require revision or conflict handling. A substantial reformulation receives a new handle and a Trace relating the new Appoint to the earlier formulation. ## Tools for preparation and verification You can prepare a draft in an editor or with AI assistance. For automated operations, the reference components provide import, selected export, local search and preparation of formal declarations. The [code and configuration catalogue](implementations.md) identifies available capabilities. [Implementation contracts](implementation.md#native-events-and-tools) detail identification, transport and failure handling, while the [configuration guide](configurations.md) brings together the procedures for running them. [Share and develop](participation.md) ยท [Protocol specification](specification.md)