Share and develop¶
When you share work, someone else may find a question they know how to investigate, a decision that needs revisiting or a solution they can develop. To recognize that possibility, they need to understand the problem, the reasons for the chosen path and what remains open.
The record provides a starting point for this exchange. Recipients can examine what you took responsibility for and respond from their own experience; you can understand what they added and decide how to continue. A short formulation may suffice. A larger piece of work can travel with its cognitive genealogy: a description of the formulations, choices and relationships participants declare, alongside references to evidence, without sending the entire conversation or archive.
The example files at the end demonstrate the distinction between independent formulations and a new proposal that declares it used earlier work.
For the complete path, see Operate in Open Legibility. An organization can open a space with a page, repository and participation conditions. When reading that space, also examine accessible proposals not yet incorporated. The main branch does not include their files. Preserving, presenting and incorporating a contribution remain distinct decisions.
Two directions of participation¶
Participation works in both directions: you may seek a contribution to help your work or recognize in someone else's formulation an occasion to use what you know. Knowing a condition of use or noticing a flaw already allows you to prepare a response, even without an invitation from the author.
Ask your AI to examine accessible sources and explain why it considers a contribution relevant. Without configured search, select files or excerpts that can be attached. Discovery depends on that actual reading.
The original author decides what to do with the response. They may incorporate it, dispute it or prefer another path. Sharing opens a possibility of collaboration without obliging anyone to respond, execute or provide resources.
From an encounter to collaboration¶
Read the problem and the conditions described by its author, looking for what your experience lets you add. An observation, test or objection can change the work even when you cannot execute the whole solution.
When context is missing, conversation can bring out knowledge not yet recorded. When preparing an account of that exchange, distinguish each participant's contribution from AI suggestions and review the synthesis before presenting it as their declaration; silence does not confirm its content.
Try to preserve the context needed to continue: the question, the criterion that changed and the relevant evidence. Consider the effort on both sides. An exchange that is hard to sustain may deter someone with something useful to offer.
Preserve origin, authorship and access¶
Keep the received file, its handle and the origin supplied by the sender. In automated interchange, the draft profile adds a separate manifest with the hash of the exact bytes. This manifest accompanies the draft; it does not change its fields.
Before sending, choose the files and recipients and check that each contribution's authorship is preserved, including in shared sessions. The team account, conversation owner and bot do not become authors of what others said, just as adopting an AI suggestion does not erase its origin.
Evidence has its own permissions. An accessible record may point to restricted code or reports. The reference indicates what informed the declaration, but grants no access, right to copy or authorization to send that content to an AI provider.
Develop a contribution without erasing its origin¶
When developing another formulation, prepare your own Appoint and, if it draws on a previous contribution, explain that relationship in a Trace. The relationship must correspond to what you declare having used, since similarity between proposals does not, on its own, establish dependency.
A substantial reformulation after sharing receives a new handle and a Trace relating it to the earlier one. Someone who received the first version can then understand what changed. Resending the same file with the same origin, handle and bytes creates no new contribution. The reference importer distinguishes that retransmission from a revision or conflict and does not silently overwrite different bytes.
A third party may also declare a relationship in a formal Trace. Their signature attributes the assertion to them without speaking for the cited authors. Use the relationships allowed by the specification, §2.3, distinguishing AI inference, the participant's declaration and the available evidence. A hypothetical combination can be proposed in an Appoint; it should not appear as established prior use.
Recognition enters when a beneficiary chooses to declare a received consequence through a Nod. Completing a task or installing the protocol does not produce that recognition automatically.
Exchange example: a software improvement¶
The four files below demonstrate the exchange structure: two Appoints describe independent investigations, a third presents a solution that used both and a Trace declares that dependency. They are entirely fictional and unsigned; they contain no real reports, completed implementation or investment approval.
To examine the exchange, check each Appoint's formulation, the files' origins and the references preserved by the Trace. Similarity between two proposals does not establish dependency; this set's Trace explains the new solution's declared use of both antecedents. No Nod is needed to complete this exchange.
The names and identifiers in the files belong only to the test data. The complete blocks below allow their fields and references to be checked.
Ana's draft¶
View the complete file
---
genealogy: "0.1"
type: appoint
id: appoint-20261023-inspect-before-export
created: "2026-10-23T12:00:00Z"
author: ana-example
author_kind: human
title: "Check data before export"
formulation: "Users need to be able to check data before exporting reports."
---
## Context
I observed customer support cases in which customers sent incorrect reports.
My observation is that the system does not adequately allow data to be checked.
## Criterion
The solution needs to let users check the data that will be sent.
## Evidence and references
The support cases are in a restricted collection and do not accompany this example.
No real address or evidence is distributed here.
## Open question
How can users be allowed to check the data before export?
Bruno's draft¶
View the complete file
---
genealogy: "0.1"
type: appoint
id: appoint-20261023-confirmation-analysis
created: "2026-10-23T12:10:00Z"
author: bruno-example
author_kind: human
title: "Why a confirmation message is insufficient"
formulation: "A confirmation message does not let users check the data that will be sent."
---
## Context
I examined the export process independently of Ana's investigation.
## Analysis
A generic message requests confirmation without showing the content to be sent.
My analysis proposes allowing data review before export.
## Open question
Which interface would allow this review at an appropriate implementation cost?
Carla's draft¶
View the complete file
---
genealogy: "0.1"
type: appoint
id: appoint-20261023-essential-data-review
created: "2026-10-23T13:00:00Z"
author: carla-example
author_kind: human
title: "Review essential information"
formulation: "I propose showing essential information before export as an alternative to a complete preview."
---
## Context
I read Ana's formulation and Bruno's analysis. The initial complete-preview
proposal was not approved given its cost and the company's priorities.
## Proposal
Investigate whether showing only essential information can meet the checking
criterion at a lower cost than a complete preview.
## Open questions
Which information is essential for checking?
Does the alternative reduce errors without making export excessively slow?
Carla's Trace¶
View the complete file
---
genealogy: "0.1"
type: trace
id: trace-20261023-review-origins
created: "2026-10-23T13:05:00Z"
author: carla-example
author_kind: human
title: "Ana's and Bruno's investigations informed my proposal"
appoint_ref: appoint-20261023-essential-data-review
depends_on:
- "urn:example:en:ana#appoint-20261023-inspect-before-export"
- "urn:example:en:bruno#appoint-20261023-confirmation-analysis"
statement: "My proposal used Ana's criterion and Bruno's analysis of why a generic message is insufficient."
---
## Relationship
Ana's formulation informed the criterion of allowing data to be checked.
Bruno's analysis explains why a generic confirmation does not meet that
criterion. My proposal investigates a simpler interface based on both.
## Limits
I did not examine the restricted support reports. This relationship describes
what I used, not a proven outcome or the approval of an investment.
After preparing a response, its author can share the new Appoint and Trace with the authors of the work used. Each recipient decides what to consider; receiving a response does not mean accepting a task or agreeing with the solution.
The fictional origins are urn:example:en:ana, urn:example:en:bruno and urn:example:en:carla. They identify this example's collections, not download addresses or authenticated identities. Do not use them for your real work. The Trace preserves both antecedent origins, while its own Appoint is identified within Carla's collection.
For a real exchange, keep the stable origin alongside the files. If it was not supplied, ask the sender before creating a reference. See how to choose and keep the origin.
Formalize when it makes sense¶
Drafts can remain informal. If you choose formalization, prepare a new declaration, review its content and sign through the supported path in your trusted environment. You can keep the record privately before choosing to share it.
Records and verifiability explains what each check establishes. Local setup and MCP brings together the technical procedures, including selecting files for a shared collection. The docs/first-appoint.md guide in the reference package provides the complete signing workflow.