# Genealogy 0.1 — Legible draft profile

A draft is an unsigned Markdown file that preserves a formulation, a declared
dependency or an informal recognition with context for later reading.
This optional normative profile defines how Legible tools handle those drafts.
It does not change the signed v2 schemas.
The single field-format definition is `draft-format.md`, copied from the
Genealogy source at packaging time. Implementations MUST use that convention,
not invent a second frontmatter format or require a signing key to participate.

## Identity and origin

A draft's `id` is a local handle, not a globally unique cryptographic identifier.
Exchange MUST preserve its handle, declared author, origin and exact shared bytes.
The interchange identity is `(origin URI, id, sha256 of exact bytes)`. No network
access is implied by a URI. Implementations MUST distinguish participant handles
from session ownership and from verified signing identities. Agent-authored work
uses `author_kind: agent`; a human may adopt a formulation by preparing a separate
draft under their own responsibility, preserving the relation to its source.

Private editing is ordinary preparation. Sharing is a separately selected act.
Retransmitting identical bytes with the same origin MUST NOT create another
contribution. Changed bytes under the same handle MUST be reported as a revision
or conflict, not silently overwrite the received contribution.

## Reformulation and formalization

After sharing, a substantial reformulation MUST use a new draft handle. Declare
the relation in a draft Trace with `appoint_ref` pointing to the new draft Appoint and
`depends_on` pointing to the origin-qualified earlier draft. Keep both accessible
under the conditions their owners selected. Pure transport copies are not Traces.

Formalization produces a new signed Legible record. An Appoint contains the signer's
own formulation and MAY reference the exact draft bytes as Evidence. The draft
does not acquire a signature or a formal assertion retrospectively. Save and
share the new record separately; private signed storage is a legitimate end state.

## Native events

An event adapter MUST identify its mapping name/version and the tool/version,
event ID, participant identity claim and original event bytes or their digest.
Put mapping metadata in a separate transport manifest; the Markdown draft still
uses Genealogy 0.1. Document losses and unsupported fields. A native event's
signature is not a Legible record signature. Imported recognition remains informal
unless a participant independently reviews and signs a new Legible declaration.

## Processing and reading

Neither a draft's availability nor record `visibility` permits arbitrary external
model processing. Clients apply their own access and processing authorizations.
Do not fetch restricted evidence on behalf of someone without that authority.
Readers can use exact matching or optional semantic retrieval; no model, global
index, official score or prior assignment is required.