Proposal: Core structural predicates for envelope-to-envelope relationships

During work on the attribution predicates BCR suite, I identified a category of predicates that are fundamentally different from semantic predicates: **structural predicates** whose range is `Digest` only.

These predicates express cryptographically verifiable relationships between envelopes. They're envelope infrastructure, not semantic claims.

### The Key Insight

What makes a predicate "structural" in the envelope context is that its **range is Digest only**. This means:

1. The relationship is content-addressed (cryptographically verifiable)
2. The relationship works whether the target is revealed OR elided
3. The predicate expresses envelope-to-envelope topology, not semantic meaning

This is distinct from predicates in existing vocabularies (Dublin Core, PROV-O, etc.) which operate on URIs. URI-based relationships require resolution; digest-based relationships are self-verifying.

### Proposed Predicates (5 total)

#### `supersedes` — Version replacement

```
// With content: "v2 replaces v1"
{ Digest(policy-v2) ['supersedes': Digest(policy-v1)] }

// With ELIDED: "v2 replaces something (verify if you have v1)"
{ Digest(policy-v2) ['supersedes': ELIDED] }
```

#### `derivedFrom` — Lineage (different thing from source)

```
// With content: "This analysis came from that dataset"
{ Digest(quarterly-analysis) ['derivedFrom': Digest(sales-data-q4)] }

// With ELIDED: "This analysis came from a private source"
{ Digest(quarterly-analysis) ['derivedFrom': ELIDED] }
```

#### `includes` — Composition

```
// With content: "This collection contains these items"
{ Digest(audit-bundle) ['includes': Digest(finding-1), 'includes': Digest(finding-2)] }

// With ELIDED: "This collection contains something (membership proof)"
{ Digest(audit-bundle) ['includes': ELIDED] }
```

#### `reveals` — Elision relationship

```
// The revealed envelope proves it matches the elided form
{ Digest(full-document) ['reveals': Digest(redacted-document)] }
```

Unique: Works even when digests are salted differently — it's about the cryptographic operation.

#### `about` — Subject relationship

```
// With content: "This review is about these things"
{
Digest(code-review) [
'about': Digest(pull-request-123)
'about': Digest(security-policy)
]
}

// With ELIDED: "This review is about something (verify if you have it)"
{
Digest(code-review) [
'about': ELIDED
'reviewer': XID(alice)
]
}
```

**Why `about` when envelopes have subjects?**

| Aspect | Subject position | `about` predicate |
|--------|------------------|-------------------|
| Cardinality | Exactly one | Zero or more |
| Meaning | Identity (what this IS) | Reference (what this RELATES TO) |
| When ELIDED | Envelope loses identity | Envelope keeps identity |

The ELIDED case is the key distinction:

```
// Subject elided — you don't know WHAT this is
{ ELIDED ['reviewer': XID(alice)] }

// Subject present, about elided — you know it's a review, not what it reviewed
{ Digest(code-review) ['about': ELIDED, 'reviewer': XID(alice)] }
```

The second pattern lets you prove "Alice reviewed *something*" without revealing what. Subject elision alone can't express this.

### Why These Five?

**`supersedes`** — Version chains. PROV-O's `wasRevisionOf` validates this as distinct from derivation. "Same thing, newer version."

**`derivedFrom`** — Lineage. PROV-O's `wasDerivedFrom` is the established pattern. "Different thing, from source." Distinct from `supersedes`.

**`includes`** — Composition. Universal across Git (tree→blob), LDP (`ldp:contains`), Dublin Core (`hasPart`). Merkle trees are built on this.

**`reveals`** — Unique to content-addressed systems with elision. Expresses the cryptographic operation of revealing elided content. Works even when digests are salted differently.

**`about`** — Subject relationship. The structural primitive for "this envelope is about that thing." Web Annotation's `oa:hasTarget` is the closest analog.

### Research Validation

I reviewed structural relationships across:
- Content-addressed systems (IPLD, Git, CAS)
- Provenance ontologies (PROV-O)
- Metadata standards (Dublin Core)
- Semantic web (RDF/OWL, SKOS)
- Linked data (LDP)
- Web Annotation

The research confirmed these five cover the structural primitives. Other candidates (`quotedFrom`, `requires`, `sameAs`, `references`) are either semantic specializations or redundant with hash equality.

### Why Core (<1000)?

1. **Range is Digest only** — These operate on content-addressed identifiers, not URIs or text
2. **Cryptographically verifiable** — Unlike URI-based relationships, these can be verified by hashing
3. **Envelope infrastructure** — They express how envelopes relate to each other structurally
4. **Enable privacy patterns** — Combined with ELIDED, they enable privacy-preserving cryptographic commitments

### Example: Privacy-Preserving Attestation

```
{
Digest(security-audit) [
'about': ELIDED
'processDisclosure': "Conducted under NDA"
]
}
```

The verifier knows:
- An audit exists with a specific digest
- It's about *something* (can verify if they have the subject)
- It was conducted under NDA

Without revealing what was audited.

### Open Question: `attestsTo`

Is `attestsTo` a sixth structural predicate, or is it `about` with semantic context?

```
// Option A: attestsTo is structural (6th predicate)
{ Digest(endorsement) ['attestsTo': ELIDED] }

// Option B: about + semantic wrapper
{ Digest(endorsement) ['about': ELIDED, 'isA': 'Attestation'] }
```

The ELIDED pattern suggests `attestsTo` might be structural — "this exists to attest to that" is a content-agnostic relationship. But it may be sufficiently covered by `about`.

### Research Questions for Wolf

1. **`reveals` mechanics**: Does `reveals` work across different salting? My understanding is it's about the cryptographic operation, not just digest equality.

2. **`attestsTo` placement**: Is `attestsTo` structurally different from `about`, or is attestation a semantic layer on top of `about`?

3. **Existing coverage**: Are any of these already covered by core predicates? Current registry (0-706) doesn't appear to have digest-only predicates.

4. **Codepoint range**: If these belong in core, what range? Following XID privileges (ends at 86), perhaps 87-92?

### Context

This emerged from reviewing `supersedes` (currently proposed at 1000 in BCR-2026-005). The realization that its range is Digest suggests it may belong in core with other structural predicates.

Related: BCR-2026-005 General Assertion Predicates (PR #150)

/cc @shannona