Loom Protocol Specification

Version: 0.1 Date: 2026-04-12 Status: Draft.

1. Scope

Loom is a protocol for the structured recording of assertions about a domain, with the minimum structure necessary to make those records interchangeable, authoritative, and durable across implementations. Loom does not specify what assertions are about, who makes them, why they matter, where they live, what is done with them, or how they are presented.

1.1 Provenance: what Loom requires and where it gets it

Loom requires that assertion records carry inspectable, interchangeable provenance supporting attribution, lineage, revision, invalidation, qualified relationships, and cross-record reference. These properties are what Loom needs in order to record assertions in a way that survives interchange and reasoning about authority.

W3C PROV (PROV-DM, PROV-O, and the qualified-relation pattern) provides all these properties and is the standard substrate Loom is designed against. Loom-conformant implementations are expected to use PROV unless they pair Loom with an alternative provenance substrate that provides equivalent guarantees. The burden of demonstrating equivalence is on the implementation. Loom does not duplicate what PROV provides; the structural commitments Loom adds are commitments about what to record and how, not a new provenance vocabulary.

1.2 Anchoring: what Loom benefits from and where it gets it

Loom is designed to be paired with FORAY for tamper-evident anchoring of transitions. This pairing is what makes Loom records reliable at scale. A Loom-conformant implementation that does not pair with FORAY (or with another tamper-evident anchoring substrate) is still Loom-conformant, but the records it produces are weaker in their verifiability guarantees, and consumers of those records must rely on the implementation's chosen mechanism for trust.

Loom's structural commitments do not depend on FORAY. Implementations can be Loom-conformant without it. But Loom is most valuable when paired with FORAY, and FORAY is the substrate Loom expects implementations to use unless they have specific reasons to use something else.

2. The assertion record

A Loom assertion has six required fields. Implementations may add fields beyond these using PROV's extension-point pattern (or the equivalent in their chosen provenance substrate); such additions remain conformant.

Identifier. Stable, unique, persistent across the assertion's lifetime including revisions and retraction.

Content. The substance of the assertion in whatever form its grammar element requires.

Grammar element. One of: Definition (a performative claim about meaning within the recording context, with stipulative truth conditions) or Constraint (a normative claim that binds on behaviour or state).

Provenance. A provenance chain meeting the requirements of §1.1. In PROV-using implementations this is a PROV-conformant chain.

Normative force. One of: required, recommended, optional. Forbidden assertions are required negations. Conditional assertions are expressed using qualified relationships with the precondition recorded as a qualifier.

State. One of: held (recorded but not authoritative) or committed (authoritative within the recording context).

3. Relationships

Relationships between assertions use the standard provenance vocabulary of the chosen substrate (in PROV: wasDerivedFrom, wasRevisionOf, wasInvalidatedBy, wasAttributedTo, wasGeneratedBy, and qualified relations). Loom adds one relationship that PROV does not provide:

wasConsideredAndRejected. Links an assertion to alternatives that were available, considered against it, and not chosen. Implementations expressing considered-and-rejected must use this name.

4. Transitions

A transition is any change to an assertion or its relationships after recording. Every transition must be recorded with attribution, timestamp, and inspectability. Implementations are expected to anchor transitions in a tamper-evident substrate (typically FORAY); such anchoring is strongly recommended but is not required for Loom-conformance.

Add. A new assertion enters in the held state.

Commit. An assertion moves from held to committed. Requires a human-attributable confirming party — an identifiable party whose contribution can be distinguished from automated agent action. The mechanism of distinction is implementation-defined.

Revise. An assertion is revised. The new version is recorded as a revision of the prior version using the substrate's revision relationship. The prior version is preserved.

Retract. An assertion is marked as invalidated using the substrate's invalidation relationship. The assertion is preserved.

Relate. A relationship between two assertions is recorded.

These five transitions are the protocol's complete set. Implementations may compose them into higher-level operations; such compositions are implementation concerns and are not specified by Loom.

5. Cross-record reference

A Loom assertion may reference an assertion in a different Loom-conformant record set. Cross-record references use the chosen provenance substrate's standard mechanisms for cross-bundle reference. Loom requires that such references:

1. Preserve the referenced assertion's identifier without modification.
2. Preserve the referenced assertion's provenance chain across the boundary.
3. Be recorded as Relate transitions.

Loom does not specify how cross-record references are discovered, governed, trusted, or maintained.

6. Erasure

Loom records are not erased. Retracted assertions, prior revisions, and superseded relationships remain accessible via their stable identifiers. Implementations that delete records are not Loom-conformant.

7. Conformance

A record set is Loom-conformant if and only if:

1. It uses a provenance substrate meeting §1.1's requirements (typically PROV).
2. Every assertion has the six required fields from §2.
3. Every relationship uses the substrate's standard vocabulary or wasConsideredAndRejected.
4. Every transition is recorded with attribution, timestamp, and inspectability.
5. The Commit transition records a human-attributable confirming party distinguishable from agent action.
6. Cross-record references satisfy §5.
7. No assertion has been erased.
8. The record set can be read by any consumer of its provenance substrate, even if that consumer does not understand Loom's additions.

A record set with implementation-specific fields beyond this minimum, recorded under the substrate's extension-point pattern, remains conformant.

8. What Loom deliberately does not specify

Outside the protocol's scope, addressed by other documents or by implementations:

• The meaning, interpretation, or domain of any assertion.
• The interface through which contributors interact with Loom records.
• The mechanism by which an implementation distinguishes a human-attributable confirming party.
• The mechanism by which transitions are anchored for tamper-evidence (though FORAY is the recommended substrate).
• The choice of provenance substrate beyond the requirement that it meet §1.1 (though PROV is the standard substrate).
• The algorithm by which weights, scores, attestations, or any derived authority measures are computed.
• The classification of assertions beyond Definition and Constraint.
• The presentation, summarisation, or surfacing of records to any reader.
• The rendering of records into projections, reports, or any other output.
• The discovery, governance, trust, or social structure of cross-record reference.
• Any operation built by composing the five protocol transitions.

9. Version

| Version | Date | Notes | |---|---|---| | 0.1 | 2026-04-12 | First specification of Loom as a minimal protocol. PROV is the standard provenance substrate; FORAY is the recommended anchoring substrate; both are the expected pairings without being constitutive. Six required fields on an assertion; five protocol transitions; one Loom-specific relationship beyond what PROV provides. |

DUNIN7 — Done In Seven LLC — Miami, Florida Loom Protocol