N29 THE REALITY LAYER
The Open/Private Boundary in Collaborative Science
The boundary should be an explicit product surface, not an implicit social norm.
IN THIS NOTE · MAY 2026
Scientists collaborate through a patchwork of public papers, conference conversations, shared drives, confidential agreements and private datasets. A collaboration platform must model these boundaries rather than assuming one default.
Separate discourse from execution
A public layer can host hypotheses, reviews and non-confidential requests. A project layer can coordinate roles and progress. Controlled spaces can contain sensitive files, unpublished methods or personal data. The transitions should be visible and deliberate.
Users need to know when an agent, collaborator or external service can access each object.
Make permissions understandable
Complex access systems fail when participants cannot predict them. Permissions should follow familiar project roles and be inspectable at the file, tool and export level. Activity logs should show who changed what and why.
Confidentiality is weakened when summaries or embeddings quietly escape the boundary even if the original file remains protected.
Design for graduation and disclosure
Projects should be able to release methods, results or datasets intentionally as they mature. Timed disclosure and redaction can let a team contribute to public knowledge without sacrificing legitimate rights.
The goal is not to maximize private space. It is to make safe openness possible.
Track lineage through derived artifacts
Scientific data rarely remain in one file. They are cleaned, joined, summarized, embedded, plotted, used in model prompts and copied into presentations. A permission system that protects only the original object creates false confidence. Lineage should record which sources produced each derivative and carry forward the most restrictive relevant obligations until an authorized transformation, aggregation or release changes the boundary.
Agents make this more important because they can move information across tools quickly. The workspace should show what an agent can read, where outputs can be written and whether an external service retains inputs. High-risk exports can require review; routine operations can proceed inside an approved enclave. The objective is not to block collaboration but to make the data path predictable enough that researchers can share without relying on perfect memory.
Design revocation and graduation
Access is not permanent. A contributor changes roles, a data-use period ends, consent is withdrawn or a partner exits. The system needs a revocation path that covers credentials, local copies, derived indexes and future agent access, with an evidence trail showing what was removed and what must be retained for legitimate reasons. Ambiguous offboarding is one of the easiest ways for a carefully negotiated boundary to collapse.
The opposite transition matters too. Work should be able to graduate from private to public through an intentional release package: approved methods, redacted data, provenance, licensing, contributor credit and a stable version. This converts openness into a project milestone rather than a default setting. Collaboration becomes safer when every object has both a current boundary and a plausible route to broader use.
- Label the visibility of every project object.
- Audit agent access and derivative data, not only source files.
- Create a deliberate path from private work to public evidence.
I would revise this if users could reliably manage sensitive collaboration through informal norms without explicit permission architecture.
Primary and institutional sources used as the grounding layer. Interpretation and synthesis are Luca's.
01