# Intertween — actor identity and selective disclosure

Date: 20 September 2026
Status: adopted framework design principle; proposed implementation requirements for PRE-1.0.
This document defines intended behaviour. It does not change existing schemas or claim that the current validator, demo or federation layer implements it.

## Principle

An actor’s participation may be visible without revealing their identity. Identity disclosure is evaluated separately for each recipient and purpose. Withheld identity must remain distinguishable from unknown identity.

Actorship describes participation in a context, rather than an intrinsic entity type. These rules apply to people, organisations and software participating as actors, including their roles as creators, contributors, custodians and other parties. Recording participation does not require public identification.

## Three separate decisions

1. Participation: what contribution or action is recorded, and with what evidence?
2. Authority: what is the actor authorised to do in this context, and how is that authority supported?
3. Disclosure: which identity attributes, references and relationships may this recipient see for this purpose?

Identity disclosure neither grants authority nor proves a contribution trustworthy. Authority may be evidenced without exposing a personal name to the recipient. The method and scope of that evidence must be explicit. A role label alone is not verification. If required authority cannot be established, an operation requiring that authority must not proceed.

## Identity cases

| Case | Meaning |
| --- | --- |
| Identified | The recipient receives permitted identity attributes. This is not a claim of verification. |
| Masked / pseudonymous | The recipient sees a limited identity or a context-scoped reference. An underlying identity or mapping may be held by an authorised custodian; it is not disclosed automatically. |
| Anonymous | No identifying link is retained within the defined contribution context. Later identification cannot be promised. Remaining identifying clues must be assessed before claiming anonymity. |
| Unknown | Identity was not established or the source lacks it. This is missing knowledge, not an assurance of anonymity. |

Disclosure state, evidence of identity or authority, and whether a recoverable mapping exists are separate facts. A missing name must not be interpreted as any particular state. Masking is recipient-specific: the same participation may be identified locally and pseudonymous to another organisation. Do not invent a hidden identity or recovery mechanism for an anonymous or unknown source.

## Disclosure requirements

- Apply policy to actor existence, identity attributes, identifiers, affiliations, roles, relationships and history as well as knowledge-object fields. Even revealing participation may be disallowed.
- Evaluate disclosure for the recipient, purpose, action and time. Federation membership does not grant access to identity or to a pseudonym mapping.
- Use context-scoped pseudonyms where cross-context linkage is unnecessary. Do not expose a universal actor identifier or derive a public pseudonym from a guessable name or email address.
- Include indirect identifiers in the assessment: timestamps, location, sensor ownership, relationship graphs, logs, signatures, public keys and export metadata may identify or link an actor.
- Protect any retained identity mapping separately with access and retention rules. Re-identification requires explicit authority and a recorded decision; it is never a default capability or a promise for anonymous contributions.
- Preserve accurate attribution in recipient-specific views. State when attribution is withheld or unknown where that disclosure is permitted. If it is not, omit the participation assertion rather than manufacture a named contributor.
- Record the minimum necessary decision evidence in a protected event log. Auditability does not require a publicly visible identity or a retained re-identification map for every contribution.
- Apply the same policy to search results, exports, relations and historical views. Masking the main display alone is insufficient. Re-evaluate future access when policy changes; already disclosed information cannot be assumed recalled.
- Do not imply that a masked projection retains the original content hash or signature unchanged. Distinguish source integrity from the integrity and provenance of a disclosed view; the verification mechanism remains an implementation design task.

## Worked example: city sensor maintenance

A technician records a water-level sensor inspection. The local node may retain the technician’s identity under its policy. A recipient may receive the observation, its permitted timestamp and the responsible municipal department, plus evidence that the inspection was performed in an authorised maintenance role. The technician’s name and local identifier are withheld. A public view may require further reduction of time, location or relationships.

This is masked participation, not an anonymous contribution. If an unrelated tip is submitted without a retained identifying link, it must be handled as a separate anonymous contribution, without implying verified maintenance authority.

## Proposed acceptance scenarios

These are requirements for a future implementation, not passing tests of the current prototype.

1. The same contribution produces an identified local view and a masked external view according to policy.
2. A permitted role claim does not expose the actor’s name, local identifier or identity mapping in search, relations, exports or history.
3. An anonymous contribution remains distinct from an unknown source and from an identity withheld by a custodian.
4. Two contexts cannot link pseudonyms through a shared identifier unless that linkage is explicitly permitted.
5. An operation requiring verified authority is refused when only an unverified anonymous claim is available.
6. A request to reveal a masked identity is evaluated separately and logged without leaking the mapping into the public log.
7. Changed permissions affect future views; previously disclosed copies are not claimed to have been erased.

## Implementation boundary

Before wire-format adoption, specify disclosure and evidence fields, pseudonym scope and lifecycle, protected mapping storage, policy evaluation, projection integrity and conformance tests. Existing PRE-1.0 schema validation checks none of these requirements. Do not relax required provenance fields or replace real actor identifiers with one shared “anonymous” identifier to simulate support.