Skip to content

BCR-2026-XXX: General Assertion Predicates #150

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ChristopherA wants to merge 6 commits into
base: master
Choose a base branch
from
Open

BCR-2026-XXX: General Assertion Predicates #150

Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
ad51986
Add BCR-2026-005: General Assertion Predicates
ChristopherA Feb 3, 2026
6f6305e
Update BCR-2026-005 per reviewer feedback
ChristopherA Feb 4, 2026
f2b2d0e
Remove unnecessary envelope wrapping from unsigned examples
ChristopherA Feb 4, 2026
d2a11b7
Remove supersedes references (moved to structural predicates BCR)
ChristopherA Feb 4, 2026
36eed8d
Update cross-references for BCR suite renumbering
ChristopherA Feb 4, 2026
ca1b823
Rename to BCR-2026-XXX temporary designation
ChristopherA Feb 5, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
306 changes: 306 additions & 0 deletions papers/bcr-2026-xxx-general-assertions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,306 @@
# General Assertion Predicates

## BCR-2026-XXX

**© 2026 Blockchain Commons**

Authors: Christopher Allen<br/>
Date: February 2, 2026

---

## Abstract

This document specifies Known Value predicates for general-purpose assertion lifecycle management in Gordian Envelopes. These predicates handle revocation, disclosure, and transparency — concerns that apply across all assertion types.

This BCR is intentionally minimal. It provides foundational predicates that domain-specific BCRs (Principal Authority, CreativeWork Roles, Fair Witness, Peer Endorsement) can reference without duplication.

## Status: Pre-Registration Proposal

📙 **Research** — This BCR proposes new Known Values and is seeking community review.

### Registration Intent

We propose registering these predicates in the **Community Assigned (specification required)** range (1000-1999) as defined in [BCR-2023-002](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2023-002-known-value.md).

This range is currently unassigned. We are seeking **rough consensus** from the Gordian developer community before claiming these codepoints. If the community determines these predicates:
- Do not merit the 1000-1999 range, or
- Should use different codepoint assignments

We will register in the **Community Assigned (first come-first served)** range (100000+) instead.

### Request for Community Review

We invite feedback on:
- Whether these predicates fill genuine gaps in the Known Value registry
- Whether the 1000-1999 range is appropriate for this vocabulary
- Any conflicts or overlaps with existing ontologies
- Suggested refinements to predicate definitions

Please submit feedback via:
- [Gordian Developer Community Discussions](https://github.com/BlockchainCommons/Gordian-Developer-Community/discussions)
- Pull requests to this specification

## Introduction

### Problem Statement

Assertions in Gordian Envelopes need lifecycle management: they can be revoked and may carry disclosure about how they were produced. Currently, these common needs are addressed ad-hoc in each domain-specific vocabulary, leading to inconsistency and duplication.

### Solution

This specification defines five predicates for assertion lifecycle and transparency:

**Lifecycle predicates:**
1. **`revocationReason`** — Documents why an assertion was revoked
2. **`processDisclosure`** — Narrative about how the assertion was produced

**Transparency predicates:**
3. **`disclosedBias`** — Potential biases the attestor discloses
4. **`disclosedLimitations`** — Limitations on the attestor's knowledge or perspective
5. **`assertionLimitations`** — Scope or constraints of the assertion itself

These predicates complement existing core predicates `validFrom` (21) and `validUntil` (22), which this BCR references but does not redefine.

### Scope Boundary

This BCR defines **lifecycle and disclosure predicates**, not contribution types or roles. Predicates describing *what kind* of contribution was made (Author, Editor, etc.) belong in domain-specific BCRs such as the CreativeWork Roles BCR.

### Design Principles

These principles guide predicate design across this BCR suite:

1. **Clarity over brevity** — Names should be immediately understandable; Known Value encoding size is constant regardless of name length
2. **Consistency within categories** — Similar predicates follow similar naming patterns (e.g., `delegation*` prefix)
3. **Reusability across contexts** — Generic predicates (like those in this BCR) work outside their primary category
4. **Collision avoidance** — Avoid terms heavily used in other ontologies (see Collision Analysis below)
5. **Self-documenting** — Names hint at expected value types
6. **Defer to standards** — When a predicate is semantically equivalent to an existing standard (Schema.org, Dublin Core, VC), reference that standard rather than creating a duplicate
7. **Agent type orthogonality** — Definitions describe *what* is being done, not *who or what* does it; any role can be filled by humans, AI systems, tools, or hybrid teams

### Collision Analysis

The following terms were evaluated for collision risk with major ontologies:

| Term | Collision Risk | Resolution |
|------|----------------|------------|
| `domain` | rdfs:domain, Schema.org | Avoided — use specific terms |
| `role` | Schema.org Role type | Avoided — use context-specific predicates |
| `context` | JSON-LD @context | Avoided — use specific terms |
| `bias` | General term | `disclosedBias` — prefixed for clarity |
| `limitations` | General term | `disclosedLimitations`, `assertionLimitations` — prefixed |

## Terminology

**Assertion**: A signed statement in a Gordian Envelope expressing a claim about something.

**Revocation**: The explicit withdrawal of an assertion, distinct from expiration (reaching `validUntil`).

**Known Value**: A registered predicate identifier in the Gordian Envelope system, encoded as a numeric codepoint for efficient representation. See [BCR-2023-002](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2023-002-known-value.md).

## Referenced Core Predicates

This BCR uses the following predicates from the core registry. These are **not redefined** here — implementers should use the existing core codepoints.

| Codepoint | Predicate | Usage in This Context |
|-----------|-----------|----------------------|
| 21 | `validFrom` | When the assertion becomes effective |
| 22 | `validUntil` | When the assertion expires |

### Time Bounds Semantics

The `validFrom` and `validUntil` predicates apply to **the assertion itself**, not necessarily to the underlying relationship being asserted.

For example, if Alice asserts "I delegate signing authority to Bob" with `validFrom: 2026-02-01` and `validUntil: 2026-12-31`:
- The **assertion** is valid during that period
- The **delegation relationship** may have different temporal bounds defined by external policy or law
- Relying parties should interpret time bounds as "this assertion is authoritative during this period," not as legal terms of the underlying relationship

### Distinction from XID Predicates

The core registry includes predicates for cryptographic key operations:

| Codepoint | Predicate | Purpose |
|-----------|-----------|---------|
| 63 | `delegate` | Grants cryptographic signing privileges to another key |
| 86 | `Revoke` | Revokes cryptographic key permissions |

These XID predicates manage **key-level privileges** — who can sign on behalf of which keys. The predicates in this BCR manage **assertion-level semantics** — how assertions relate to each other over time.

The two concerns are orthogonal:
- A key may have `delegate` privileges without any authority assertions
- An authority assertion may exist without granting `delegate` key privileges
- Both may be used together when delegation includes signing rights

## Proposed Known Value Assignments

All proposed codepoints are in the **Community Assigned (specification required)** range (1000-1999).

### General Assertions (1001-1005)

---

#### 1001: `revocationReason`

**Type**: property
**Definition**: Documents why an assertion was revoked.
**Domain**: Revocation assertion
**Range**: Text or Known Value for reason category
**Usage**: Distinguishes revocation causes (key compromise, error, withdrawal of consent, etc.)

```
Digest(revocation) [
'revokes': Digest(original-assertion)
'revocationReason': "Key compromise suspected"
]
```

**Notes**:
- This predicate is optional — revocation can occur without stating a reason
- The reason is for human understanding; automated systems should rely on the presence of supersession

---

#### 1002: `processDisclosure`

**Type**: property
**Definition**: Narrative disclosure about how the assertion or work was produced.
**Domain**: Any assertion or creative work
**Range**: Text
**Usage**: Provides context about production methods, tools used, or collaboration involved.

```
Digest(document) [
'processDisclosure': "Drafted with AI assistance using Claude. Human author reviewed, edited, and approved final content."
]
```

**Notes**:
- This predicate captures the *how* of production, not the *who* (which is handled by role predicates in other BCRs)
- Useful for AI-assisted content, tool-generated outputs, collaborative works, or any situation where production process matters

---

#### 1003: `disclosedBias`

**Type**: property
**Definition**: Potential biases the attestor discloses about their perspective or relationship to the subject.
**Domain**: Any assertion
**Range**: Text
**Usage**: Enables attestors to proactively disclose factors that might affect interpretation of their assertion.

```
Digest(endorsement) [
'disclosedBias': "I have a professional relationship with the subject. We have collaborated on three projects."
]
```

**Notes**:
- Self-reported disclosure — relying parties should treat as a claim, not verified fact
- Absence of `disclosedBias` does not mean absence of bias
- Useful for endorsements, reviews, recommendations, and any evaluative assertion
- Domain-specific BCRs (Fair Witness, Peer Endorsement) reference this predicate rather than defining their own

---

#### 1004: `disclosedLimitations`

**Type**: property
**Definition**: Known limitations on the attestor's knowledge, perspective, or ability to evaluate.
**Domain**: Any assertion
**Range**: Text
**Usage**: Enables attestors to acknowledge gaps in their knowledge or constraints on their perspective.

```
Digest(skill-endorsement) [
'disclosedLimitations': "I observed their work on frontend components only. I cannot speak to their backend or infrastructure skills."
]
```

**Notes**:
- Complements `disclosedBias` — bias is about perspective, limitations is about scope of knowledge
- Particularly important for endorsements and attestations where partial observation is common
- Encourages epistemic humility in assertions

---

#### 1005: `assertionLimitations`

**Type**: property
**Definition**: Scope or constraints of the assertion itself, independent of the attestor's limitations.
**Domain**: Any assertion
**Range**: Text
**Usage**: Documents what the assertion does and does not claim, establishing its boundaries.

```
Digest(competency-assertion) [
'assertionLimitations': "This assertion covers demonstrated skill as of the observation date. It does not predict future performance or guarantee results."
]
```

**Notes**:
- Different from `disclosedLimitations`: attestor limitations are about the person making the claim; assertion limitations are about the claim itself
- Helps prevent over-interpretation of assertions
- Useful for any assertion that might be misunderstood as broader than intended

---

## Usage Patterns

### Signature as Acceptance

When an assertion requires acceptance by multiple parties (such as a delegation that binds both principal and agent), the signature pattern handles acceptance:

- **Single signature**: The signer accepts the assertion's terms
- **Multi-signature**: All signers accept; the assertion is effective when all required signatures are present

This BCR does not define an `acceptance` predicate because signing already carries acceptance semantics. External policy or law may impose additional acceptance requirements beyond cryptographic signature.

**Important**: Signature represents **cryptographic assent** — evidence that a key holder signed. It does not establish temporal acceptance ("when did they agree?") or legal acceptance ("is this binding?"). Those determinations depend on external policy, jurisdiction, and context.

### Third-Party Revocation

When an entity other than the original signer needs to revoke an assertion:

1. The third party creates a revocation assertion referencing the original
2. The revocation may include `revocationReason`
3. Relying parties must determine whether the third party has authority to revoke

This BCR does not define who may revoke — that is a policy decision. It provides the vocabulary to express that revocation occurred and why.

## Security Considerations

### Revocation Timing

The `validFrom` on a revocation indicates when the revocation becomes effective, not when the original assertion was compromised. For key compromise scenarios, the actual compromise time may be unknown or earlier than the revocation.

### Disclosure Integrity

The `processDisclosure`, `disclosedBias`, `disclosedLimitations`, and `assertionLimitations` predicates contain self-reported information. Relying parties should treat these as claims by the signer, not as verified fact.

### Transparency Predicate Interpretation

The presence of transparency predicates (`disclosedBias`, `disclosedLimitations`, `assertionLimitations`) indicates the attestor made an effort at disclosure. However:
- Absence of these predicates does not indicate absence of bias or limitations
- Disclosed limitations may be incomplete
- Transparency predicates do not validate the assertion itself

## References

- [BCR-2023-002: Known Value Registry](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2023-002-known-value.md)
- [Gordian Envelope Specification](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-001-envelope.md)

## Related BCRs

This BCR provides foundational predicates used by:

- **BCR-2026-XXX: Signing Event Attestations** — Signing capacity and delegation
- **BCR-2026-XXX: Principal Authority Predicates** — Authority relationships (principal, delegation, scope)
- **BCR-2026-XXX: CreativeWork Role Predicates** — Contribution roles (Author, Editor, etc.)
- **BCR-2026-XXX: Fair Witness Predicates** — Neutral observer attestations (references `disclosedBias`, `disclosedLimitations`)
- **BCR-2026-XXX: Peer Endorsement Predicates** — Peer-to-peer trust building (references transparency predicates)

---

*BCR-2026-XXX: General Assertion Predicates*
*Draft - February 2, 2026*