From f1d160ee0d0272bd714a0d7fee0d35fbae937375 Mon Sep 17 00:00:00 2001
From: Christopher Allen <ChristopherA@LifeWithAlacrity.com>
Date: Tue, 3 Feb 2026 02:46:55 -0800
Subject: [PATCH 1/9] Add BCR-2026-007: Principal Authority Predicates

Proposes Known Values for principal-agent authority relationships:
principalAuthority, assertsDelegationFrom, delegationScope, constraints.

Community range 1040-1043. Seeking rough consensus; willing to use
100000+ if community prefers.

Signed-off-by: Christopher Allen <ChristopherA@LifeWithAlacrity.com>
---
 papers/bcr-2026-007-principal-authority.md | 405 +++++++++++++++++++++
 1 file changed, 405 insertions(+)
 create mode 100644 papers/bcr-2026-007-principal-authority.md

diff --git a/papers/bcr-2026-007-principal-authority.md b/papers/bcr-2026-007-principal-authority.md
new file mode 100644
index 0000000..a036276
--- /dev/null
+++ b/papers/bcr-2026-007-principal-authority.md
@@ -0,0 +1,405 @@
+# Principal Authority Predicates
+
+## BCR-2026-007
+
+**© 2026 Blockchain Commons**
+
+Authors: Christopher Allen<br/>
+Date: February 2, 2026
+
+---
+
+## Abstract
+
+This document specifies Known Value predicates for expressing principal-agent authority relationships in Gordian Envelopes. These predicates enable clear attribution when authorship and responsibility are distinct — such as AI-generated content under human direction, ghostwritten works, or any delegation of creative authority.
+
+This BCR depends on [BCR-2026-005: General Assertion Predicates](bcr-2026-005-general-assertions.md) for lifecycle management (`supersedes`, `revocationReason`, `processDisclosure`).
+
+## 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
+
+Existing metadata schemas (Schema.org, Dublin Core, FOAF) conflate two concepts that are increasingly distinct:
+
+1. **Authorship** — who performed the act of creating (writing words, generating code, making artifacts)
+2. **Responsibility** — who directed the creation, whose judgment shaped it, who stands behind it
+
+This conflation was always imperfect — ghost writers, collaborators, and editors have existed for centuries — but it becomes untenable when AI agents perform authorship under human direction. Current predicates force a false choice: either the human claims authorship they didn't perform, or the AI is attributed authorship without having any authority over what was created.
+
+### Why This Matters
+
+The interest in terms like "principal" isn't just about credit or convenience — it's about preserving agency as AI tools become more capable.
+
+When we delegate to AI agents, there's a subtle risk that our "augmented" selves stop being fully ours. Systems can erode autonomy not just through coercion, but through convenience, defaults, and invisible delegation. The agent rewrites your draft and it's better — but is it still you? The agent makes a thousand small decisions and ships the project — but whose judgment shaped it?
+
+Without vocabulary to express these relationships, attribution becomes a polite fiction. With it, attribution becomes a meaningful statement about where agency actually lives.
+
+### Solution
+
+This specification defines four predicates for principal-agent authority relationships:
+
+1. **`principalAuthority`** — Identifies who directs and takes responsibility
+2. **`assertsDelegationFrom`** — Agent asserts delegation from a principal
+3. **`delegationScope`** — What the delegation covers
+4. **`delegationConstraints`** — What limits apply to the delegation
+
+These predicates draw on the legal concept of Principal Authority from the Laws of Agency, where a principal delegates authority to an agent who acts on their behalf while owing duties back to the principal.
+
+### Scope Boundary
+
+This BCR defines **authority relationship predicates**, not:
+- Contribution roles (Author, Editor, etc.) — see [BCR-2026-008: CreativeWork Role Predicates](bcr-2026-008-creativework-roles.md)
+- Signature context (`signingAs`, `onBehalfOf`) — see [BCR-2026-006: Signature Context Predicates](bcr-2026-006-signature-context.md)
+- Assertion lifecycle (`supersedes`, `revocationReason`) — see [BCR-2026-005: General Assertion Predicates](bcr-2026-005-general-assertions.md)
+
+## Terminology
+
+**Principal**: An entity with ultimate authority over a work or action, who takes responsibility for it and to whom agents owe duties.
+
+**Agent**: An entity that acts on behalf of a principal, within delegated authority boundaries.
+
+**Delegation**: The grant of authority from principal to agent to act within specified scope and constraints.
+
+**Authorship**: The act of creating content — writing, coding, generating.
+
+**Responsibility**: The authority over and accountability for content — directing, reviewing, standing behind.
+
+**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 Specifications
+
+### BCR-2026-005: General Assertion Predicates
+
+This BCR uses predicates from BCR-2026-005 for assertion lifecycle:
+
+| Codepoint | Predicate | Usage in This Context |
+|-----------|-----------|----------------------|
+| 1000 | `supersedes` | Updating or replacing authority assertions |
+| 1001 | `revocationReason` | Documenting why delegation was revoked |
+| 1002 | `processDisclosure` | Describing how work was produced |
+
+### Core Registry
+
+| Codepoint | Predicate | Usage in This Context |
+|-----------|-----------|----------------------|
+| 21 | `validFrom` | When delegation becomes effective |
+| 22 | `validUntil` | When delegation expires |
+
+### 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 **authority relationships** — who directed what work and under what terms.
+
+The two concerns are orthogonal:
+- A key may have `delegate` (63) privileges without any `assertsDelegationFrom` authority
+- An `assertsDelegationFrom` assertion may exist without granting cryptographic `delegate` privileges
+- Both may be used together when authority delegation includes signing rights
+
+## Proposed Known Value Assignments
+
+All proposed codepoints are in the **Community Assigned (specification required)** range (1000-1999).
+
+### Principal Authority (1040-1043)
+
+---
+
+#### 1040: `principalAuthority`
+
+**Type**: property
+**Definition**: The entity who directed the work and takes responsibility for it.
+**Domain**: Creative work, assertion, or action
+**Range**: XID, DID, or identifier of the principal
+**Usage**: Identifies who holds ultimate authority, regardless of who performed the work.
+
+```
+{
+    CID(ai-generated-document) [
+        'principalAuthority': XID(alice)
+        'processDisclosure': "Generated by Claude under Alice's direction and review."
+    ]
+}
+```
+
+**Notes**:
+- The principal need not have performed any authorship
+- Multiple principals are possible for collaborative direction (use multiple assertions or array)
+- This predicate answers "whose work is this?" in terms of authority, not performance
+
+---
+
+#### 1041: `assertsDelegationFrom`
+
+**Type**: property
+**Definition**: The agent asserts that it acts under delegation from the specified principal.
+**Domain**: Agent declaration or work attribution
+**Range**: XID, DID, or identifier of the delegating principal
+**Usage**: Expresses the agent's claim of delegated authority.
+
+```
+{
+    CID(agent-work-claim) [
+        'assertsDelegationFrom': XID(alice)
+        'delegationScope': "Draft technical documentation"
+        'delegationConstraints': "Subject to human review before publication"
+    ]
+}
+```
+
+**Notes**:
+- This is an **assertion by the agent**, not a statement of fact
+- The principal may separately confirm or deny the delegation
+- The assertion-first framing (`assertsDelegationFrom` rather than `delegatedAgentOf`) makes the claim nature explicit
+- Relying parties must evaluate whether to trust the delegation claim
+
+---
+
+#### 1042: `delegationScope`
+
+**Type**: property
+**Definition**: The boundaries of what the delegation covers.
+**Domain**: Delegation context
+**Range**: Text description or structured scope definition
+**Usage**: Documents what the agent is authorized to do.
+
+```
+{
+    CID(delegation) [
+        'assertsDelegationFrom': XID(corporate-principal)
+        'delegationScope': "Sign routine vendor contracts under $10,000"
+    ]
+}
+```
+
+**Notes**:
+- Scope defines the positive space — what is included
+- Use `delegationConstraints` for limitations and exclusions
+- Scope can be narrow ("this specific document") or broad ("all technical writing")
+
+---
+
+#### 1043: `delegationConstraints`
+
+**Type**: property
+**Definition**: Limitations or conditions on the delegated authority.
+**Domain**: Delegation context
+**Range**: Text description or structured constraints
+**Usage**: Documents what the agent is NOT authorized to do or conditions that apply.
+
+```
+{
+    CID(delegation) [
+        'assertsDelegationFrom': XID(alice)
+        'delegationScope': "Manage social media presence"
+        'delegationConstraints': "No political statements. No financial commitments. Human approval required for crisis response."
+    ]
+}
+```
+
+**Notes**:
+- Constraints define the negative space — what is excluded or conditional
+- Constraints may include approval requirements, prohibited actions, or review processes
+- The prefix `delegation-` provides symmetry with `delegationScope`
+
+---
+
+## Usage Patterns
+
+### Basic Principal-Agent Attribution
+
+The simplest case: identifying who directed a work.
+
+```
+{
+    CID(blog-post) [
+        'principalAuthority': XID(human-author)
+        'processDisclosure': "Written with AI assistance for research and drafting."
+    ]
+}
+```
+
+### Agent Claiming Delegation
+
+An agent (human or AI) asserting its authority source.
+
+```
+{
+    CID(code-commit) [
+        'assertsDelegationFrom': XID(project-lead)
+        'delegationScope': "Implement feature X per specification"
+        'delegationConstraints': "No changes to public API without review"
+    ]
+}
+```
+
+### Delegation with Lifecycle
+
+Using BCR-2026-004 predicates for delegation management.
+
+```
+{
+    CID(delegation-v2) [
+        'assertsDelegationFrom': XID(alice)
+        'delegationScope': "Extended to include customer communications"
+        'supersedes': CID(delegation-v1)
+        'validFrom': 2026-03-01
+    ]
+}
+```
+
+### Revoked Delegation
+
+```
+{
+    CID(revocation) [
+        'supersedes': CID(original-delegation)
+        'revocationReason': "Project concluded"
+    ]
+}
+```
+
+## Design Notes
+
+### Standing vs. Contextual Delegation
+
+This BCR does not distinguish between:
+- **Standing delegation** — ongoing authority ("you may always sign contracts under $10K")
+- **Contextual delegation** — task-specific authority ("draft this specific document")
+
+Both use the same predicates. The distinction, when needed, is expressed through:
+- `delegationScope` (narrow vs. broad)
+- `validFrom`/`validUntil` (time-bounded vs. open-ended)
+- Context of the work itself
+
+This intentional collapse keeps the predicate set minimal. Domain profiles may add distinctions if needed.
+
+### The `producedBy` Question
+
+Earlier drafts considered a `producedBy` predicate to mark causal participation (who/what actually created the content). This BCR intentionally omits it because:
+
+1. **Role predicates handle "who did what"** — BCR-2026-006 defines Author, Editor, etc.
+2. **Process disclosure handles "how"** — `processDisclosure` captures production method
+3. **Principal authority handles "whose"** — `principalAuthority` captures responsibility
+
+A separate `producedBy` would duplicate these concerns. If a use case emerges that these three don't cover, it can be added in a future BCR.
+
+### Domain Profiles
+
+Domain-specific applications (legal, medical, financial) may define profiles that:
+- **Constrain** which predicates are required or optional
+- **Specialize** range values (e.g., specific role vocabularies)
+- **Add** domain-specific predicates that reference these
+
+Profiles should **not redefine** the core predicate semantics. A `principalAuthority` means the same thing in healthcare as in publishing — profiles add context, not new meanings.
+
+### Meaningful Principal Authority
+
+For `principalAuthority` to represent genuine direction rather than nominal attribution, three conditions should hold:
+
+1. **Legibility** — The principal can see what the agent is doing and why. Black-box systems that can't explain their reasoning undermine this.
+
+2. **Boundaries** — The agent operates within constraints the principal defined. Autonomous systems that decide their own scope undermine this.
+
+3. **Override** — The principal can intervene, revoke, or redirect at any point. Systems that resist correction undermine this.
+
+Without these conditions, "I directed this" becomes a polite fiction. With them, `principalAuthority` is a meaningful statement about where agency actually lives.
+
+These conditions are guidance for system designers and relying parties, not predicates to be asserted. A `principalAuthority` claim does not prove these conditions hold — it asserts who bears responsibility regardless.
+
+## Security Considerations
+
+### Delegation Claims Are Assertions
+
+The `assertsDelegationFrom` predicate expresses a **claim by the agent**. Relying parties must:
+- Verify the agent's identity
+- Evaluate whether to trust the delegation claim
+- Optionally seek confirmation from the claimed principal
+
+The predicate structure does not enforce or verify the delegation — it only expresses the claim.
+
+### Authority vs. Key Privileges
+
+Having `principalAuthority` over a work does not grant cryptographic signing privileges. Having cryptographic `delegate` (63) privileges does not grant authority. Systems must track both concerns when both apply.
+
+### Scope and Constraint Interpretation
+
+The `delegationScope` and `delegationConstraints` predicates contain human-readable text (or structured data). Automated systems should:
+- Treat scope/constraints as advisory unless they can parse structured formats
+- Default to restrictive interpretation when scope is ambiguous
+- Require human review for high-stakes decisions
+
+## Open Questions
+
+### Responsibility vs. Authority
+
+This BCR defines `principalAuthority` as the entity who "directs the work AND takes responsibility." Community discussion is invited on whether these should be separate concerns:
+
+- **External accountability** (to society) — Who receives feedback, complaints, or legal action
+- **Internal authority** (to team/agents) — Who directs the creative process
+
+A publisher might be externally accountable for a work they didn't direct. A director might shape work without being the public face of responsibility. Should these be expressible separately, or does conflating them serve most use cases adequately?
+
+### Oversight as Distinct from Authority
+
+Is there a need for an `oversightAuthority` predicate — the entity responsible for ongoing monitoring/approval of the work or process?
+
+Oversight suggests a monitoring relationship distinct from:
+- **Direction** — deciding what to create
+- **Execution** — doing the work
+- **Review** — one-time quality check (already covered by `Reviewer` role in BCR-2026-008)
+
+Examples where oversight and authority might be held by different parties:
+- A board provides oversight of a CEO's work (CEO has authority, board monitors)
+- An editor provides ongoing oversight of drafts (author has authority, editor monitors quality)
+- A code reviewer must approve before merge (author has authority, reviewer gates release)
+
+The "Meaningful Principal Authority" design note describes Legibility, Boundaries, and Override as conditions for genuine direction — but these are also aspects of oversight. Should oversight be expressible as a separate relationship when it's held by a different party than the principal?
+
+## References
+
+- [BCR-2023-002: Known Value Registry](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2023-002-known-value.md)
+- [BCR-2026-005: General Assertion Predicates](bcr-2026-005-general-assertions.md)
+- [BCR-2026-006: Signature Context Predicates](bcr-2026-006-signature-context.md)
+- [Gordian Envelope Specification](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-001-envelope.md)
+
+## Related BCRs
+
+- **BCR-2026-005: General Assertion Predicates** — Lifecycle predicates used by this BCR
+- **BCR-2026-006: Signature Context Predicates** — Signing capacity and delegation (complementary)
+- **BCR-2026-008: CreativeWork Role Predicates** — Contribution roles (Author, Editor, etc.)
+
+---
+
+*BCR-2026-007: Principal Authority Predicates*
+*Draft - February 2, 2026*

From 801d73ae24c6695120808ce85b5941379f92c9b3 Mon Sep 17 00:00:00 2001
From: Christopher Allen <ChristopherA@LifeWithAlacrity.com>
Date: Wed, 4 Feb 2026 00:23:10 -0800
Subject: [PATCH 2/9] Rename delegation predicates to conferral terminology
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- assertsDelegationFrom → assertsConferralFrom
- delegationScope → conferralScope
- delegationConstraints → conferralConstraints
- Updated terminology section with conferral definition
- Updated all examples and usage patterns
- Moved Open Question Q3 to Design Note (terminology resolved)
- Changed "key-level" to "cryptographic signing privileges"

Rationale: "Conferral" avoids collision with cryptographic delegation
(XID delegate predicate), OAuth grants, and access control terminology.

Signed-off-by: Christopher Allen <ChristopherA@LifeWithAlacrity.com>
---
 papers/bcr-2026-007-principal-authority.md | 152 ++++++++++++---------
 1 file changed, 87 insertions(+), 65 deletions(-)

diff --git a/papers/bcr-2026-007-principal-authority.md b/papers/bcr-2026-007-principal-authority.md
index a036276..3a4f89f 100644
--- a/papers/bcr-2026-007-principal-authority.md
+++ b/papers/bcr-2026-007-principal-authority.md
@@ -65,11 +65,11 @@ Without vocabulary to express these relationships, attribution becomes a polite
 This specification defines four predicates for principal-agent authority relationships:
 
 1. **`principalAuthority`** — Identifies who directs and takes responsibility
-2. **`assertsDelegationFrom`** — Agent asserts delegation from a principal
-3. **`delegationScope`** — What the delegation covers
-4. **`delegationConstraints`** — What limits apply to the delegation
+2. **`assertsConferralFrom`** — Agent asserts authority was conferred by a principal
+3. **`conferralScope`** — What the conferral covers
+4. **`conferralConstraints`** — What limits apply to the conferral
 
-These predicates draw on the legal concept of Principal Authority from the Laws of Agency, where a principal delegates authority to an agent who acts on their behalf while owing duties back to the principal.
+These predicates draw on the legal concept of Principal Authority from the Laws of Agency, where a principal confers authority to an agent who acts on their behalf while owing duties back to the principal. The term "conferral" is used instead of "delegation" to avoid confusion with cryptographic delegation (XID `delegate` predicate).
 
 ### Scope Boundary
 
@@ -82,9 +82,9 @@ This BCR defines **authority relationship predicates**, not:
 
 **Principal**: An entity with ultimate authority over a work or action, who takes responsibility for it and to whom agents owe duties.
 
-**Agent**: An entity that acts on behalf of a principal, within delegated authority boundaries.
+**Agent**: An entity that acts on behalf of a principal, within conferred authority boundaries.
 
-**Delegation**: The grant of authority from principal to agent to act within specified scope and constraints.
+**Conferral**: The grant of authority from principal to agent to act within specified scope and constraints. This term is used instead of "delegation" to distinguish from cryptographic delegation (XID `delegate` predicate) which grants cryptographic signing privileges.
 
 **Authorship**: The act of creating content — writing, coding, generating.
 
@@ -101,15 +101,15 @@ This BCR uses predicates from BCR-2026-005 for assertion lifecycle:
 | Codepoint | Predicate | Usage in This Context |
 |-----------|-----------|----------------------|
 | 1000 | `supersedes` | Updating or replacing authority assertions |
-| 1001 | `revocationReason` | Documenting why delegation was revoked |
+| 1001 | `revocationReason` | Documenting why authority conferral was revoked |
 | 1002 | `processDisclosure` | Describing how work was produced |
 
 ### Core Registry
 
 | Codepoint | Predicate | Usage in This Context |
 |-----------|-----------|----------------------|
-| 21 | `validFrom` | When delegation becomes effective |
-| 22 | `validUntil` | When delegation expires |
+| 21 | `validFrom` | When authority conferral becomes effective |
+| 22 | `validUntil` | When authority conferral expires |
 
 ### Distinction from XID Predicates
 
@@ -120,12 +120,12 @@ The core registry includes predicates for cryptographic key operations:
 | 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 **authority relationships** — who directed what work and under what terms.
+These XID predicates manage **cryptographic signing privileges** — who can sign on behalf of which keys. The predicates in this BCR manage **authority relationships** — who directed what work and under what terms.
 
 The two concerns are orthogonal:
-- A key may have `delegate` (63) privileges without any `assertsDelegationFrom` authority
-- An `assertsDelegationFrom` assertion may exist without granting cryptographic `delegate` privileges
-- Both may be used together when authority delegation includes signing rights
+- A key may have `delegate` (63) privileges without any `assertsConferralFrom` authority
+- An `assertsConferralFrom` assertion may exist without granting cryptographic `delegate` privileges
+- Both may be used together when authority conferral includes signing rights
 
 ## Proposed Known Value Assignments
 
@@ -145,7 +145,7 @@ All proposed codepoints are in the **Community Assigned (specification required)
 
 ```
 {
-    CID(ai-generated-document) [
+    Digest(ai-generated-document) [
         'principalAuthority': XID(alice)
         'processDisclosure': "Generated by Claude under Alice's direction and review."
     ]
@@ -159,70 +159,71 @@ All proposed codepoints are in the **Community Assigned (specification required)
 
 ---
 
-#### 1041: `assertsDelegationFrom`
+#### 1041: `assertsConferralFrom`
 
 **Type**: property
-**Definition**: The agent asserts that it acts under delegation from the specified principal.
+**Definition**: The agent asserts that it acts under authority conferred by the specified principal.
 **Domain**: Agent declaration or work attribution
-**Range**: XID, DID, or identifier of the delegating principal
-**Usage**: Expresses the agent's claim of delegated authority.
+**Range**: XID, DID, or identifier of the conferring principal
+**Usage**: Expresses the agent's claim of conferred authority.
 
 ```
 {
-    CID(agent-work-claim) [
-        'assertsDelegationFrom': XID(alice)
-        'delegationScope': "Draft technical documentation"
-        'delegationConstraints': "Subject to human review before publication"
+    Digest(agent-work-claim) [
+        'assertsConferralFrom': XID(alice)
+        'conferralScope': "Draft technical documentation"
+        'conferralConstraints': "Subject to human review before publication"
     ]
 }
 ```
 
 **Notes**:
 - This is an **assertion by the agent**, not a statement of fact
-- The principal may separately confirm or deny the delegation
-- The assertion-first framing (`assertsDelegationFrom` rather than `delegatedAgentOf`) makes the claim nature explicit
-- Relying parties must evaluate whether to trust the delegation claim
+- The principal may separately confirm or deny the conferral
+- The assertion-first framing (`assertsConferralFrom` rather than `agentOf`) makes the claim nature explicit
+- Relying parties must evaluate whether to trust the conferral claim
+- "Conferral" is used instead of "delegation" to distinguish from cryptographic delegation (XID `delegate` predicate)
 
 ---
 
-#### 1042: `delegationScope`
+#### 1042: `conferralScope`
 
 **Type**: property
-**Definition**: The boundaries of what the delegation covers.
-**Domain**: Delegation context
+**Definition**: The boundaries of what the authority conferral covers.
+**Domain**: Conferral context
 **Range**: Text description or structured scope definition
 **Usage**: Documents what the agent is authorized to do.
 
 ```
 {
-    CID(delegation) [
-        'assertsDelegationFrom': XID(corporate-principal)
-        'delegationScope': "Sign routine vendor contracts under $10,000"
+    Digest(authority-conferral) [
+        'assertsConferralFrom': XID(corporate-principal)
+        'conferralScope': "Sign routine vendor contracts under $10,000"
     ]
 }
 ```
 
 **Notes**:
 - Scope defines the positive space — what is included
-- Use `delegationConstraints` for limitations and exclusions
+- Use `conferralConstraints` for limitations and exclusions
 - Scope can be narrow ("this specific document") or broad ("all technical writing")
 
 ---
 
-#### 1043: `delegationConstraints`
+#### 1043: `conferralConstraints`
 
 **Type**: property
-**Definition**: Limitations or conditions on the delegated authority.
-**Domain**: Delegation context
+**Definition**: Limitations or conditions on the conferred authority.
+**Domain**: Conferral context
 **Range**: Text description or structured constraints
 **Usage**: Documents what the agent is NOT authorized to do or conditions that apply.
 
 ```
 {
-    CID(delegation) [
-        'assertsDelegationFrom': XID(alice)
-        'delegationScope': "Manage social media presence"
-        'delegationConstraints': "No political statements. No financial commitments. Human approval required for crisis response."
+    Digest(authority-conferral) [
+        'assertsConferralFrom': XID(alice)
+        'conferralScope': "Manage social media presence"
+        'conferralConstraints': "No political statements. No financial commitments. Human approval required for crisis response."
     ]
 }
 ```
@@ -230,7 +231,7 @@ All proposed codepoints are in the **Community Assigned (specification required)
 **Notes**:
 - Constraints define the negative space — what is excluded or conditional
 - Constraints may include approval requirements, prohibited actions, or review processes
-- The prefix `delegation-` provides symmetry with `delegationScope`
+- The prefix `conferral-` provides symmetry with `conferralScope`
 
 ---
 
@@ -242,48 +243,48 @@ The simplest case: identifying who directed a work.
 
 ```
 {
-    CID(blog-post) [
+    Digest(blog-post) [
         'principalAuthority': XID(human-author)
         'processDisclosure': "Written with AI assistance for research and drafting."
     ]
 }
 ```
 
-### Agent Claiming Delegation
+### Agent Claiming Authority Conferral
 
 An agent (human or AI) asserting its authority source.
 
 ```
 {
-    CID(code-commit) [
-        'assertsDelegationFrom': XID(project-lead)
-        'delegationScope': "Implement feature X per specification"
-        'delegationConstraints': "No changes to public API without review"
+    Digest(code-commit) [
+        'assertsConferralFrom': XID(project-lead)
+        'conferralScope': "Implement feature X per specification"
+        'conferralConstraints': "No changes to public API without review"
     ]
 }
 ```
 
-### Delegation with Lifecycle
+### Authority Conferral with Lifecycle
 
-Using BCR-2026-004 predicates for delegation management.
+Using BCR-2026-005 predicates for conferral management.
 
 ```
 {
-    CID(delegation-v2) [
-        'assertsDelegationFrom': XID(alice)
-        'delegationScope': "Extended to include customer communications"
-        'supersedes': CID(delegation-v1)
+    Digest(conferral-v2) [
+        'assertsConferralFrom': XID(alice)
+        'conferralScope': "Extended to include customer communications"
+        'supersedes': Digest(conferral-v1)
         'validFrom': 2026-03-01
     ]
 }
 ```
 
-### Revoked Delegation
+### Revoked Authority Conferral
 
 ```
 {
-    CID(revocation) [
-        'supersedes': CID(original-delegation)
+    Digest(revocation) [
+        'supersedes': Digest(original-conferral)
         'revocationReason': "Project concluded"
     ]
 }
@@ -291,14 +292,14 @@ Using BCR-2026-004 predicates for delegation management.
 
 ## Design Notes
 
-### Standing vs. Contextual Delegation
+### Standing vs. Contextual Authority Conferral
 
 This BCR does not distinguish between:
-- **Standing delegation** — ongoing authority ("you may always sign contracts under $10K")
-- **Contextual delegation** — task-specific authority ("draft this specific document")
+- **Standing conferral** — ongoing authority ("you may always sign contracts under $10K")
+- **Contextual conferral** — task-specific authority ("draft this specific document")
 
 Both use the same predicates. The distinction, when needed, is expressed through:
-- `delegationScope` (narrow vs. broad)
+- `conferralScope` (narrow vs. broad)
 - `validFrom`/`validUntil` (time-bounded vs. open-ended)
 - Context of the work itself
 
@@ -337,16 +338,37 @@ Without these conditions, "I directed this" becomes a polite fiction. With them,
 
 These conditions are guidance for system designers and relying parties, not predicates to be asserted. A `principalAuthority` claim does not prove these conditions hold — it asserts who bears responsibility regardless.
 
+### Why "Conferral" Instead of "Delegation"
+
+This BCR uses "conferral" terminology (`assertsConferralFrom`, `conferralScope`, `conferralConstraints`) rather than "delegation" to avoid collision with cryptographic delegation:
+
+**Cryptographic delegation** (object capabilities):
+- Core registry predicate `delegate` (63) grants signing privileges to another key
+- This is a verifiable, enforceable capability transfer
+- The delegation IS the grant — possession of the delegated key proves authority
+
+**Authority conferral** (this BCR):
+- Expresses claims about principal-agent relationships from agency law
+- These are assertions about social/legal relationships, not cryptographic capabilities
+- The conferral claim must be evaluated for trustworthiness, not just verified
+
+The term "conferral" was chosen because:
+1. It's the formal legal term for granting authority ("confer authority")
+2. It has minimal collision with existing technical vocabulary (OAuth, access control, cryptographic delegation)
+3. It clearly signals a social/legal relationship rather than a cryptographic operation
+
+BCR-2026-006 (Signature Context) uses matching terminology (`conferredBy`, `conferralChain`) for consistency.
+
 ## Security Considerations
 
-### Delegation Claims Are Assertions
+### Authority Conferral Claims Are Assertions
 
-The `assertsDelegationFrom` predicate expresses a **claim by the agent**. Relying parties must:
+The `assertsConferralFrom` predicate expresses a **claim by the agent**. Relying parties must:
 - Verify the agent's identity
-- Evaluate whether to trust the delegation claim
+- Evaluate whether to trust the conferral claim
 - Optionally seek confirmation from the claimed principal
 
-The predicate structure does not enforce or verify the delegation — it only expresses the claim.
+The predicate structure does not enforce or verify the conferral — it only expresses the claim.
 
 ### Authority vs. Key Privileges
 
@@ -354,7 +376,7 @@ Having `principalAuthority` over a work does not grant cryptographic signing pri
 
 ### Scope and Constraint Interpretation
 
-The `delegationScope` and `delegationConstraints` predicates contain human-readable text (or structured data). Automated systems should:
+The `conferralScope` and `conferralConstraints` predicates contain human-readable text (or structured data). Automated systems should:
 - Treat scope/constraints as advisory unless they can parse structured formats
 - Default to restrictive interpretation when scope is ambiguous
 - Require human review for high-stakes decisions
@@ -396,7 +418,7 @@ The "Meaningful Principal Authority" design note describes Legibility, Boundarie
 ## Related BCRs
 
 - **BCR-2026-005: General Assertion Predicates** — Lifecycle predicates used by this BCR
-- **BCR-2026-006: Signature Context Predicates** — Signing capacity and delegation (complementary)
+- **BCR-2026-006: Signature Context Predicates** — Signing capacity and authority conferral (uses matching `conferral*` terminology)
 - **BCR-2026-008: CreativeWork Role Predicates** — Contribution roles (Author, Editor, etc.)
 
 ---

From 9defcf516eb99048fa8b4d6d32598bd30fac4b27 Mon Sep 17 00:00:00 2001
From: Christopher Allen <ChristopherA@LifeWithAlacrity.com>
Date: Wed, 4 Feb 2026 00:27:19 -0800
Subject: [PATCH 3/9] Add conferredBy and conferralChain predicates (moved from
 BCR-006)

Consolidating all authority conferral predicates in one place:
- Added conferredBy (1044) for single-hop authority
- Added conferralChain (1045) for multi-hop authority chains
- BCR-007 now has full conferral vocabulary (1040-1045)
- Updated solution section and related BCRs references

This avoids having conferral terminology split across two BCRs.
BCR-2026-006 now focuses solely on signing context (signingAs, onBehalfOf).

Signed-off-by: Christopher Allen <ChristopherA@LifeWithAlacrity.com>
---
 papers/bcr-2026-007-principal-authority.md | 65 +++++++++++++++++++++-
 1 file changed, 63 insertions(+), 2 deletions(-)

diff --git a/papers/bcr-2026-007-principal-authority.md b/papers/bcr-2026-007-principal-authority.md
index 3a4f89f..ee1c131 100644
--- a/papers/bcr-2026-007-principal-authority.md
+++ b/papers/bcr-2026-007-principal-authority.md
@@ -68,6 +68,8 @@ This specification defines four predicates for principal-agent authority relatio
 2. **`assertsConferralFrom`** — Agent asserts authority was conferred by a principal
 3. **`conferralScope`** — What the conferral covers
 4. **`conferralConstraints`** — What limits apply to the conferral
+5. **`conferredBy`** — Who granted authority (single-hop)
+6. **`conferralChain`** — Full chain of authority conferral (multi-hop)
 
 These predicates draw on the legal concept of Principal Authority from the Laws of Agency, where a principal confers authority to an agent who acts on their behalf while owing duties back to the principal. The term "conferral" is used instead of "delegation" to avoid confusion with cryptographic delegation (XID `delegate` predicate).
 
@@ -131,7 +133,7 @@ The two concerns are orthogonal:
 
 All proposed codepoints are in the **Community Assigned (specification required)** range (1000-1999).
 
-### Principal Authority (1040-1043)
+### Principal Authority (1040-1045)
 
 ---
 
@@ -235,6 +237,65 @@ All proposed codepoints are in the **Community Assigned (specification required)
 
 ---
 
+#### 1044: `conferredBy`
+
+**Type**: property
+**Definition**: The entity that granted the signer's or agent's authority.
+**Domain**: Signature context or authority assertion
+**Range**: XID, DID, or identifier of the conferring party
+**Usage**: Documents the immediate source of authority.
+
+```
+{
+    Digest(approval-document) [
+        'signed': {
+            XID(department-head) [
+                'signingAs': "Authorized Approver"
+                'conferredBy': XID(cfo)
+            ]
+        }
+    ]
+}
+```
+
+**Notes**:
+- For single-hop authority conferral, `conferredBy` is sufficient
+- For multi-hop conferral, use `conferralChain`
+- The conferral may be standing (ongoing) or contextual (one-time)
+- Works with both signature contexts and work authority assertions
+
+---
+
+#### 1045: `conferralChain`
+
+**Type**: property
+**Definition**: The full chain of authority conferral from original authority to current actor.
+**Domain**: Signature context or authority assertion
+**Range**: Ordered list of XIDs/DIDs representing the conferral path
+**Usage**: Documents multi-hop authority conferral for complex authority structures.
+
+```
+{
+    Digest(field-authorization) [
+        'signed': {
+            XID(field-manager) [
+                'signingAs': "Emergency Coordinator"
+                'onBehalfOf': XID(corporation)
+                'conferralChain': [XID(board), XID(ceo), XID(coo), XID(regional-vp)]
+            ]
+        }
+    ]
+}
+```
+
+**Notes**:
+- Chain is ordered from original authority to immediate conferrer
+- The actor (signer or agent) is implicitly at the end of the chain
+- Use for audit trails and authority verification
+- Simpler cases can use `conferredBy` alone
+
+---
+
 ## Usage Patterns
 
 ### Basic Principal-Agent Attribution
@@ -418,7 +479,7 @@ The "Meaningful Principal Authority" design note describes Legibility, Boundarie
 ## Related BCRs
 
 - **BCR-2026-005: General Assertion Predicates** — Lifecycle predicates used by this BCR
-- **BCR-2026-006: Signature Context Predicates** — Signing capacity and authority conferral (uses matching `conferral*` terminology)
+- **BCR-2026-006: Signature Context Predicates** — Signing capacity (`signingAs`, `onBehalfOf`); references this BCR for authority chains
 - **BCR-2026-008: CreativeWork Role Predicates** — Contribution roles (Author, Editor, etc.)
 
 ---

From fa4680e51992c054d6c16cab65a9192887f5c39a Mon Sep 17 00:00:00 2001
From: Christopher Allen <ChristopherA@LifeWithAlacrity.com>
Date: Wed, 4 Feb 2026 00:30:02 -0800
Subject: [PATCH 4/9] =?UTF-8?q?Add=20confersTo=20predicate=20for=20princip?=
 =?UTF-8?q?al=E2=86=92agent=20direction?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Per Shannon's feedback, added bidirectional conferral:
- confersTo (1046): Principal declares conferral TO agent (signed by principal)
- assertsConferralFrom (1041): Agent claims conferral FROM principal

Together they provide complete verification:
- Agent can claim authority
- Principal can confirm by signing a confersTo declaration

Signed-off-by: Christopher Allen <ChristopherA@LifeWithAlacrity.com>
---
 papers/bcr-2026-007-principal-authority.md | 38 +++++++++++++++++++++-
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/papers/bcr-2026-007-principal-authority.md b/papers/bcr-2026-007-principal-authority.md
index ee1c131..2030152 100644
--- a/papers/bcr-2026-007-principal-authority.md
+++ b/papers/bcr-2026-007-principal-authority.md
@@ -70,6 +70,7 @@ This specification defines four predicates for principal-agent authority relatio
 4. **`conferralConstraints`** — What limits apply to the conferral
 5. **`conferredBy`** — Who granted authority (single-hop)
 6. **`conferralChain`** — Full chain of authority conferral (multi-hop)
+7. **`confersTo`** — Principal declares conferral to an agent
 
 These predicates draw on the legal concept of Principal Authority from the Laws of Agency, where a principal confers authority to an agent who acts on their behalf while owing duties back to the principal. The term "conferral" is used instead of "delegation" to avoid confusion with cryptographic delegation (XID `delegate` predicate).
 
@@ -133,7 +134,7 @@ The two concerns are orthogonal:
 
 All proposed codepoints are in the **Community Assigned (specification required)** range (1000-1999).
 
-### Principal Authority (1040-1045)
+### Principal Authority (1040-1046)
 
 ---
 
@@ -296,6 +297,41 @@ All proposed codepoints are in the **Community Assigned (specification required)
 
 ---
 
+#### 1046: `confersTo`
+
+**Type**: property
+**Definition**: The principal declares that authority is conferred to the specified agent.
+**Domain**: Authority declaration by principal
+**Range**: XID, DID, or identifier of the agent receiving authority
+**Usage**: Principal signs a conferral TO an agent, establishing the authority relationship.
+
+```
+{
+    Digest(authority-grant) [
+        'confersTo': XID(agent-alice)
+        'conferralScope': "Draft technical documentation"
+        'conferralConstraints': "Subject to review before publication"
+        'validFrom': 2026-02-01
+        'signed': {
+            XID(principal-bob) [
+                'signingAs': "Project Lead"
+            ]
+        }
+    ]
+}
+```
+
+**Notes**:
+- This is a **declaration by the principal**, signed by them
+- Complements `assertsConferralFrom` which is the agent's claim
+- Together they provide bidirectional verification:
+  - Agent claims: `assertsConferralFrom`: XID(principal)
+  - Principal confirms: `confersTo`: XID(agent)
+- For standing conferrals, use `validFrom`/`validUntil` for time bounds
+- The signed conferral can be referenced by the agent as proof of authority
+
+---
+
 ## Usage Patterns
 
 ### Basic Principal-Agent Attribution

From 699fe866763a2f948861bf30e0e042f74aed991e Mon Sep 17 00:00:00 2001
From: Christopher Allen <ChristopherA@LifeWithAlacrity.com>
Date: Wed, 4 Feb 2026 00:51:28 -0800
Subject: [PATCH 5/9] Remove unnecessary envelope wrapping from unsigned
 examples

---
 papers/bcr-2026-007-principal-authority.md | 16 ----------------
 1 file changed, 16 deletions(-)

diff --git a/papers/bcr-2026-007-principal-authority.md b/papers/bcr-2026-007-principal-authority.md
index 2030152..5ca7905 100644
--- a/papers/bcr-2026-007-principal-authority.md
+++ b/papers/bcr-2026-007-principal-authority.md
@@ -147,12 +147,10 @@ All proposed codepoints are in the **Community Assigned (specification required)
 **Usage**: Identifies who holds ultimate authority, regardless of who performed the work.
 
 ```
-{
     Digest(ai-generated-document) [
         'principalAuthority': XID(alice)
         'processDisclosure': "Generated by Claude under Alice's direction and review."
     ]
-}
 ```
 
 **Notes**:
@@ -171,13 +169,11 @@ All proposed codepoints are in the **Community Assigned (specification required)
 **Usage**: Expresses the agent's claim of conferred authority.
 
 ```
-{
     Digest(agent-work-claim) [
         'assertsConferralFrom': XID(alice)
         'conferralScope': "Draft technical documentation"
         'conferralConstraints': "Subject to human review before publication"
     ]
-}
 ```
 
 **Notes**:
@@ -198,12 +194,10 @@ All proposed codepoints are in the **Community Assigned (specification required)
 **Usage**: Documents what the agent is authorized to do.
 
 ```
-{
     Digest(authority-conferral) [
         'assertsConferralFrom': XID(corporate-principal)
         'conferralScope': "Sign routine vendor contracts under $10,000"
     ]
-}
 ```
 
 **Notes**:
@@ -222,13 +216,11 @@ All proposed codepoints are in the **Community Assigned (specification required)
 **Usage**: Documents what the agent is NOT authorized to do or conditions that apply.
 
 ```
-{
     Digest(authority-conferral) [
         'assertsConferralFrom': XID(alice)
         'conferralScope': "Manage social media presence"
         'conferralConstraints': "No political statements. No financial commitments. Human approval required for crisis response."
     ]
-}
 ```
 
 **Notes**:
@@ -339,12 +331,10 @@ All proposed codepoints are in the **Community Assigned (specification required)
 The simplest case: identifying who directed a work.
 
 ```
-{
     Digest(blog-post) [
         'principalAuthority': XID(human-author)
         'processDisclosure': "Written with AI assistance for research and drafting."
     ]
-}
 ```
 
 ### Agent Claiming Authority Conferral
@@ -352,13 +342,11 @@ The simplest case: identifying who directed a work.
 An agent (human or AI) asserting its authority source.
 
 ```
-{
     Digest(code-commit) [
         'assertsConferralFrom': XID(project-lead)
         'conferralScope': "Implement feature X per specification"
         'conferralConstraints': "No changes to public API without review"
     ]
-}
 ```
 
 ### Authority Conferral with Lifecycle
@@ -366,25 +354,21 @@ An agent (human or AI) asserting its authority source.
 Using BCR-2026-005 predicates for conferral management.
 
 ```
-{
     Digest(conferral-v2) [
         'assertsConferralFrom': XID(alice)
         'conferralScope': "Extended to include customer communications"
         'supersedes': Digest(conferral-v1)
         'validFrom': 2026-03-01
     ]
-}
 ```
 
 ### Revoked Authority Conferral
 
 ```
-{
     Digest(revocation) [
         'supersedes': Digest(original-conferral)
         'revocationReason': "Project concluded"
     ]
-}
 ```
 
 ## Design Notes

From 1aec991453918562f533c2ec4ec427d24e10b46b Mon Sep 17 00:00:00 2001
From: Christopher Allen <ChristopherA@LifeWithAlacrity.com>
Date: Wed, 4 Feb 2026 01:12:25 -0800
Subject: [PATCH 6/9] Remove supersedes references (moved to structural
 predicates BCR)

---
 papers/bcr-2026-007-principal-authority.md | 29 +++++++++++-----------
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/papers/bcr-2026-007-principal-authority.md b/papers/bcr-2026-007-principal-authority.md
index 5ca7905..0d66807 100644
--- a/papers/bcr-2026-007-principal-authority.md
+++ b/papers/bcr-2026-007-principal-authority.md
@@ -13,7 +13,7 @@ Date: February 2, 2026
 
 This document specifies Known Value predicates for expressing principal-agent authority relationships in Gordian Envelopes. These predicates enable clear attribution when authorship and responsibility are distinct — such as AI-generated content under human direction, ghostwritten works, or any delegation of creative authority.
 
-This BCR depends on [BCR-2026-005: General Assertion Predicates](bcr-2026-005-general-assertions.md) for lifecycle management (`supersedes`, `revocationReason`, `processDisclosure`).
+This BCR depends on [BCR-2026-005: General Assertion Predicates](bcr-2026-005-general-assertions.md) for lifecycle management (`revocationReason`, `processDisclosure`).
 
 ## Status: Pre-Registration Proposal
 
@@ -79,7 +79,7 @@ These predicates draw on the legal concept of Principal Authority from the Laws
 This BCR defines **authority relationship predicates**, not:
 - Contribution roles (Author, Editor, etc.) — see [BCR-2026-008: CreativeWork Role Predicates](bcr-2026-008-creativework-roles.md)
 - Signature context (`signingAs`, `onBehalfOf`) — see [BCR-2026-006: Signature Context Predicates](bcr-2026-006-signature-context.md)
-- Assertion lifecycle (`supersedes`, `revocationReason`) — see [BCR-2026-005: General Assertion Predicates](bcr-2026-005-general-assertions.md)
+- Assertion lifecycle (`revocationReason`) — see [BCR-2026-005: General Assertion Predicates](bcr-2026-005-general-assertions.md)
 
 ## Terminology
 
@@ -103,7 +103,6 @@ This BCR uses predicates from BCR-2026-005 for assertion lifecycle:
 
 | Codepoint | Predicate | Usage in This Context |
 |-----------|-----------|----------------------|
-| 1000 | `supersedes` | Updating or replacing authority assertions |
 | 1001 | `revocationReason` | Documenting why authority conferral was revoked |
 | 1002 | `processDisclosure` | Describing how work was produced |
 
@@ -349,26 +348,26 @@ An agent (human or AI) asserting its authority source.
     ]
 ```
 
-### Authority Conferral with Lifecycle
+### Authority Conferral with Time Bounds
 
-Using BCR-2026-005 predicates for conferral management.
+Using time bounds for conferral management.
 
 ```
-    Digest(conferral-v2) [
-        'assertsConferralFrom': XID(alice)
-        'conferralScope': "Extended to include customer communications"
-        'supersedes': Digest(conferral-v1)
-        'validFrom': 2026-03-01
-    ]
+Digest(conferral) [
+    'assertsConferralFrom': XID(alice)
+    'conferralScope': "Draft technical documentation"
+    'validFrom': 2026-03-01
+    'validUntil': 2026-12-31
+]
 ```
 
 ### Revoked Authority Conferral
 
 ```
-    Digest(revocation) [
-        'supersedes': Digest(original-conferral)
-        'revocationReason': "Project concluded"
-    ]
+Digest(revocation) [
+    'revokes': Digest(original-conferral)
+    'revocationReason': "Project concluded"
+]
 ```
 
 ## Design Notes

From f521f4b0957ffcec5ed6b1baa87aca9d1151d104 Mon Sep 17 00:00:00 2001
From: Christopher Allen <ChristopherA@LifeWithAlacrity.com>
Date: Wed, 4 Feb 2026 13:31:03 -0800
Subject: [PATCH 7/9] =?UTF-8?q?Renumber:=20BCR-2026-007=20=E2=86=92=20BCR-?=
 =?UTF-8?q?2026-006=20Principal=20Authority?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

File renamed: bcr-2026-007-principal-authority.md → bcr-2026-006-principal-authority.md

Also fixes signature examples to use proper double-signing pattern per BCR-2026-004:
- conferredBy/conferralChain examples simplified to unsigned assertions
- confersTo example uses double-signing pattern with signer predicate

Signed-off-by: Christopher Allen <ChristopherA@LifeWithAlacrity.com>
---
 ...md => bcr-2026-006-principal-authority.md} | 70 ++++++++-----------
 1 file changed, 30 insertions(+), 40 deletions(-)
 rename papers/{bcr-2026-007-principal-authority.md => bcr-2026-006-principal-authority.md} (92%)

diff --git a/papers/bcr-2026-007-principal-authority.md b/papers/bcr-2026-006-principal-authority.md
similarity index 92%
rename from papers/bcr-2026-007-principal-authority.md
rename to papers/bcr-2026-006-principal-authority.md
index 0d66807..9921a99 100644
--- a/papers/bcr-2026-007-principal-authority.md
+++ b/papers/bcr-2026-006-principal-authority.md
@@ -1,6 +1,6 @@
 # Principal Authority Predicates
 
-## BCR-2026-007
+## BCR-2026-006
 
 **© 2026 Blockchain Commons**
 
@@ -77,8 +77,8 @@ These predicates draw on the legal concept of Principal Authority from the Laws
 ### Scope Boundary
 
 This BCR defines **authority relationship predicates**, not:
-- Contribution roles (Author, Editor, etc.) — see [BCR-2026-008: CreativeWork Role Predicates](bcr-2026-008-creativework-roles.md)
-- Signature context (`signingAs`, `onBehalfOf`) — see [BCR-2026-006: Signature Context Predicates](bcr-2026-006-signature-context.md)
+- Contribution roles (Author, Editor, etc.) — see [BCR-2026-007: CreativeWork Role Predicates](bcr-2026-007-creativework-roles.md)
+- Signature context (`signer`, `signedOnBehalfOf`) — see [BCR-2026-004: Signing Event Attestations](bcr-2026-004-signing-event-attestations.md)
 - Assertion lifecycle (`revocationReason`) — see [BCR-2026-005: General Assertion Predicates](bcr-2026-005-general-assertions.md)
 
 ## Terminology
@@ -238,23 +238,17 @@ All proposed codepoints are in the **Community Assigned (specification required)
 **Usage**: Documents the immediate source of authority.
 
 ```
-{
-    Digest(approval-document) [
-        'signed': {
-            XID(department-head) [
-                'signingAs': "Authorized Approver"
-                'conferredBy': XID(cfo)
-            ]
-        }
+    Digest(agent-work) [
+        'assertsConferralFrom': XID(cfo)
+        'conferredBy': XID(department-head)
     ]
-}
 ```
 
 **Notes**:
 - For single-hop authority conferral, `conferredBy` is sufficient
 - For multi-hop conferral, use `conferralChain`
 - The conferral may be standing (ongoing) or contextual (one-time)
-- Works with both signature contexts and work authority assertions
+- Works with both work authority assertions and signing event attestations (see BCR-2026-004)
 
 ---
 
@@ -267,17 +261,10 @@ All proposed codepoints are in the **Community Assigned (specification required)
 **Usage**: Documents multi-hop authority conferral for complex authority structures.
 
 ```
-{
     Digest(field-authorization) [
-        'signed': {
-            XID(field-manager) [
-                'signingAs': "Emergency Coordinator"
-                'onBehalfOf': XID(corporation)
-                'conferralChain': [XID(board), XID(ceo), XID(coo), XID(regional-vp)]
-            ]
-        }
+        'assertsConferralFrom': XID(corporation)
+        'conferralChain': [XID(board), XID(ceo), XID(coo), XID(regional-vp)]
     ]
-}
 ```
 
 **Notes**:
@@ -285,6 +272,7 @@ All proposed codepoints are in the **Community Assigned (specification required)
 - The actor (signer or agent) is implicitly at the end of the chain
 - Use for audit trails and authority verification
 - Simpler cases can use `conferredBy` alone
+- For signing event attestations with conferral chain, see BCR-2026-004
 
 ---
 
@@ -298,22 +286,24 @@ All proposed codepoints are in the **Community Assigned (specification required)
 
 ```
 {
-    Digest(authority-grant) [
-        'confersTo': XID(agent-alice)
-        'conferralScope': "Draft technical documentation"
-        'conferralConstraints': "Subject to review before publication"
-        'validFrom': 2026-02-01
-        'signed': {
-            XID(principal-bob) [
-                'signingAs': "Project Lead"
-            ]
-        }
+    {
+        Digest(authority-grant) [
+            'confersTo': XID(agent-alice)
+            'conferralScope': "Draft technical documentation"
+            'conferralConstraints': "Subject to review before publication"
+            'validFrom': 2026-02-01
+        ]
+    } 'signed': Signature
+    [
+        'signer': XID(principal-bob)
+        'xades:ClaimedRole': "Project Lead"
     ]
-}
+} 'signed': Signature
 ```
 
 **Notes**:
 - This is a **declaration by the principal**, signed by them
+- Uses double-signing pattern (BCR-2026-004) to bind signer identity to signature
 - Complements `assertsConferralFrom` which is the agent's claim
 - Together they provide bidirectional verification:
   - Agent claims: `assertsConferralFrom`: XID(principal)
@@ -389,7 +379,7 @@ This intentional collapse keeps the predicate set minimal. Domain profiles may a
 
 Earlier drafts considered a `producedBy` predicate to mark causal participation (who/what actually created the content). This BCR intentionally omits it because:
 
-1. **Role predicates handle "who did what"** — BCR-2026-006 defines Author, Editor, etc.
+1. **Role predicates handle "who did what"** — BCR-2026-007 defines Author, Editor, etc.
 2. **Process disclosure handles "how"** — `processDisclosure` captures production method
 3. **Principal authority handles "whose"** — `principalAuthority` captures responsibility
 
@@ -437,7 +427,7 @@ The term "conferral" was chosen because:
 2. It has minimal collision with existing technical vocabulary (OAuth, access control, cryptographic delegation)
 3. It clearly signals a social/legal relationship rather than a cryptographic operation
 
-BCR-2026-006 (Signature Context) uses matching terminology (`conferredBy`, `conferralChain`) for consistency.
+BCR-2026-004 (Signing Event Attestations) uses matching terminology (`conferredBy`, `conferralChain`) for consistency.
 
 ## Security Considerations
 
@@ -479,7 +469,7 @@ Is there a need for an `oversightAuthority` predicate — the entity responsible
 Oversight suggests a monitoring relationship distinct from:
 - **Direction** — deciding what to create
 - **Execution** — doing the work
-- **Review** — one-time quality check (already covered by `Reviewer` role in BCR-2026-008)
+- **Review** — one-time quality check (already covered by `Reviewer` role in BCR-2026-007)
 
 Examples where oversight and authority might be held by different parties:
 - A board provides oversight of a CEO's work (CEO has authority, board monitors)
@@ -492,16 +482,16 @@ The "Meaningful Principal Authority" design note describes Legibility, Boundarie
 
 - [BCR-2023-002: Known Value Registry](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2023-002-known-value.md)
 - [BCR-2026-005: General Assertion Predicates](bcr-2026-005-general-assertions.md)
-- [BCR-2026-006: Signature Context Predicates](bcr-2026-006-signature-context.md)
+- [BCR-2026-004: Signing Event Attestations](bcr-2026-004-signing-event-attestations.md)
 - [Gordian Envelope Specification](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-001-envelope.md)
 
 ## Related BCRs
 
 - **BCR-2026-005: General Assertion Predicates** — Lifecycle predicates used by this BCR
-- **BCR-2026-006: Signature Context Predicates** — Signing capacity (`signingAs`, `onBehalfOf`); references this BCR for authority chains
-- **BCR-2026-008: CreativeWork Role Predicates** — Contribution roles (Author, Editor, etc.)
+- **BCR-2026-004: Signing Event Attestations** — Signing context (`signer`, `signedOnBehalfOf`, `xades:ClaimedRole`); references this BCR for authority chains
+- **BCR-2026-007: CreativeWork Role Predicates** — Contribution roles (Author, Editor, etc.)
 
 ---
 
-*BCR-2026-007: Principal Authority Predicates*
+*BCR-2026-006: Principal Authority Predicates*
 *Draft - February 2, 2026*

From fc55ccd806a3bd85c2fe70344d7c412bdcb6dcc4 Mon Sep 17 00:00:00 2001
From: Christopher Allen <ChristopherA@LifeWithAlacrity.com>
Date: Wed, 4 Feb 2026 15:49:11 -0800
Subject: [PATCH 8/9] Update confersTo example to signature-with-assertions
 pattern

Signed-off-by: Christopher Allen <ChristopherA@LifeWithAlacrity.com>
---
 papers/bcr-2026-006-principal-authority.md | 27 +++++++++++-----------
 1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/papers/bcr-2026-006-principal-authority.md b/papers/bcr-2026-006-principal-authority.md
index 9921a99..c82f5a1 100644
--- a/papers/bcr-2026-006-principal-authority.md
+++ b/papers/bcr-2026-006-principal-authority.md
@@ -286,24 +286,25 @@ All proposed codepoints are in the **Community Assigned (specification required)
 
 ```
 {
-    {
-        Digest(authority-grant) [
-            'confersTo': XID(agent-alice)
-            'conferralScope': "Draft technical documentation"
-            'conferralConstraints': "Subject to review before publication"
-            'validFrom': 2026-02-01
-        ]
-    } 'signed': Signature
-    [
-        'signer': XID(principal-bob)
-        'xades:ClaimedRole': "Project Lead"
+    Digest(authority-grant) [
+        'confersTo': XID(agent-alice)
+        'conferralScope': "Draft technical documentation"
+        'conferralConstraints': "Subject to review before publication"
+        'validFrom': 2026-02-01
     ]
-} 'signed': Signature
+} [
+    'signed': {
+        Signature [
+            'signer': XID(principal-bob)
+            'xades:ClaimedRole': "Project Lead"
+        ]
+    } ['signed': Signature]
+]
 ```
 
 **Notes**:
 - This is a **declaration by the principal**, signed by them
-- Uses double-signing pattern (BCR-2026-004) to bind signer identity to signature
+- Uses signature-with-assertions pattern (BCR-2026-004) to bind signer identity to signature
 - Complements `assertsConferralFrom` which is the agent's claim
 - Together they provide bidirectional verification:
   - Agent claims: `assertsConferralFrom`: XID(principal)

From dbd3582002682e1ca36f50808b3b889d208d5cf5 Mon Sep 17 00:00:00 2001
From: Christopher Allen <ChristopherA@LifeWithAlacrity.com>
Date: Thu, 5 Feb 2026 10:21:12 -0800
Subject: [PATCH 9/9] Rename to BCR-2026-XXX temporary designation

Per Wolf's recommendation: use temporary letter designations.
Actual BCR numbers will be assigned at merge time.
Updated all internal cross-references to XXX format.

Signed-off-by: Christopher Allen <ChristopherA@LifeWithAlacrity.com>
---
 ...md => bcr-2026-xxx-principal-authority.md} | 38 +++++++++----------
 1 file changed, 19 insertions(+), 19 deletions(-)
 rename papers/{bcr-2026-006-principal-authority.md => bcr-2026-xxx-principal-authority.md} (94%)

diff --git a/papers/bcr-2026-006-principal-authority.md b/papers/bcr-2026-xxx-principal-authority.md
similarity index 94%
rename from papers/bcr-2026-006-principal-authority.md
rename to papers/bcr-2026-xxx-principal-authority.md
index c82f5a1..3f979f7 100644
--- a/papers/bcr-2026-006-principal-authority.md
+++ b/papers/bcr-2026-xxx-principal-authority.md
@@ -1,6 +1,6 @@
 # Principal Authority Predicates
 
-## BCR-2026-006
+## BCR-2026-XXX
 
 **© 2026 Blockchain Commons**
 
@@ -13,7 +13,7 @@ Date: February 2, 2026
 
 This document specifies Known Value predicates for expressing principal-agent authority relationships in Gordian Envelopes. These predicates enable clear attribution when authorship and responsibility are distinct — such as AI-generated content under human direction, ghostwritten works, or any delegation of creative authority.
 
-This BCR depends on [BCR-2026-005: General Assertion Predicates](bcr-2026-005-general-assertions.md) for lifecycle management (`revocationReason`, `processDisclosure`).
+This BCR depends on [BCR-2026-XXX: General Assertion Predicates](bcr-2026-xxx-general-assertions.md) for lifecycle management (`revocationReason`, `processDisclosure`).
 
 ## Status: Pre-Registration Proposal
 
@@ -77,9 +77,9 @@ These predicates draw on the legal concept of Principal Authority from the Laws
 ### Scope Boundary
 
 This BCR defines **authority relationship predicates**, not:
-- Contribution roles (Author, Editor, etc.) — see [BCR-2026-007: CreativeWork Role Predicates](bcr-2026-007-creativework-roles.md)
-- Signature context (`signer`, `signedOnBehalfOf`) — see [BCR-2026-004: Signing Event Attestations](bcr-2026-004-signing-event-attestations.md)
-- Assertion lifecycle (`revocationReason`) — see [BCR-2026-005: General Assertion Predicates](bcr-2026-005-general-assertions.md)
+- Contribution roles (Author, Editor, etc.) — see [BCR-2026-XXX: CreativeWork Role Predicates](bcr-2026-xxx-creativework-roles.md)
+- Signature context (`signer`, `signedOnBehalfOf`) — see [BCR-2026-XXX: Signing Event Attestations](bcr-2026-xxx-signing-event-assertions.md)
+- Assertion lifecycle (`revocationReason`) — see [BCR-2026-XXX: General Assertion Predicates](bcr-2026-xxx-general-assertions.md)
 
 ## Terminology
 
@@ -97,9 +97,9 @@ This BCR defines **authority relationship predicates**, not:
 
 ## Referenced Specifications
 
-### BCR-2026-005: General Assertion Predicates
+### BCR-2026-XXX: General Assertion Predicates
 
-This BCR uses predicates from BCR-2026-005 for assertion lifecycle:
+This BCR uses predicates from BCR-2026-XXX for assertion lifecycle:
 
 | Codepoint | Predicate | Usage in This Context |
 |-----------|-----------|----------------------|
@@ -248,7 +248,7 @@ All proposed codepoints are in the **Community Assigned (specification required)
 - For single-hop authority conferral, `conferredBy` is sufficient
 - For multi-hop conferral, use `conferralChain`
 - The conferral may be standing (ongoing) or contextual (one-time)
-- Works with both work authority assertions and signing event attestations (see BCR-2026-004)
+- Works with both work authority assertions and signing event attestations (see BCR-2026-XXX)
 
 ---
 
@@ -272,7 +272,7 @@ All proposed codepoints are in the **Community Assigned (specification required)
 - The actor (signer or agent) is implicitly at the end of the chain
 - Use for audit trails and authority verification
 - Simpler cases can use `conferredBy` alone
-- For signing event attestations with conferral chain, see BCR-2026-004
+- For signing event attestations with conferral chain, see BCR-2026-XXX
 
 ---
 
@@ -304,7 +304,7 @@ All proposed codepoints are in the **Community Assigned (specification required)
 
 **Notes**:
 - This is a **declaration by the principal**, signed by them
-- Uses signature-with-assertions pattern (BCR-2026-004) to bind signer identity to signature
+- Uses signature-with-assertions pattern (BCR-2026-XXX) to bind signer identity to signature
 - Complements `assertsConferralFrom` which is the agent's claim
 - Together they provide bidirectional verification:
   - Agent claims: `assertsConferralFrom`: XID(principal)
@@ -380,7 +380,7 @@ This intentional collapse keeps the predicate set minimal. Domain profiles may a
 
 Earlier drafts considered a `producedBy` predicate to mark causal participation (who/what actually created the content). This BCR intentionally omits it because:
 
-1. **Role predicates handle "who did what"** — BCR-2026-007 defines Author, Editor, etc.
+1. **Role predicates handle "who did what"** — BCR-2026-XXX defines Author, Editor, etc.
 2. **Process disclosure handles "how"** — `processDisclosure` captures production method
 3. **Principal authority handles "whose"** — `principalAuthority` captures responsibility
 
@@ -428,7 +428,7 @@ The term "conferral" was chosen because:
 2. It has minimal collision with existing technical vocabulary (OAuth, access control, cryptographic delegation)
 3. It clearly signals a social/legal relationship rather than a cryptographic operation
 
-BCR-2026-004 (Signing Event Attestations) uses matching terminology (`conferredBy`, `conferralChain`) for consistency.
+BCR-2026-XXX (Signing Event Attestations) uses matching terminology (`conferredBy`, `conferralChain`) for consistency.
 
 ## Security Considerations
 
@@ -470,7 +470,7 @@ Is there a need for an `oversightAuthority` predicate — the entity responsible
 Oversight suggests a monitoring relationship distinct from:
 - **Direction** — deciding what to create
 - **Execution** — doing the work
-- **Review** — one-time quality check (already covered by `Reviewer` role in BCR-2026-007)
+- **Review** — one-time quality check (already covered by `Reviewer` role in BCR-2026-XXX)
 
 Examples where oversight and authority might be held by different parties:
 - A board provides oversight of a CEO's work (CEO has authority, board monitors)
@@ -482,17 +482,17 @@ The "Meaningful Principal Authority" design note describes Legibility, Boundarie
 ## References
 
 - [BCR-2023-002: Known Value Registry](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2023-002-known-value.md)
-- [BCR-2026-005: General Assertion Predicates](bcr-2026-005-general-assertions.md)
-- [BCR-2026-004: Signing Event Attestations](bcr-2026-004-signing-event-attestations.md)
+- [BCR-2026-XXX: General Assertion Predicates](bcr-2026-xxx-general-assertions.md)
+- [BCR-2026-XXX: Signing Event Attestations](bcr-2026-xxx-signing-event-assertions.md)
 - [Gordian Envelope Specification](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2024-001-envelope.md)
 
 ## Related BCRs
 
-- **BCR-2026-005: General Assertion Predicates** — Lifecycle predicates used by this BCR
-- **BCR-2026-004: Signing Event Attestations** — Signing context (`signer`, `signedOnBehalfOf`, `xades:ClaimedRole`); references this BCR for authority chains
-- **BCR-2026-007: CreativeWork Role Predicates** — Contribution roles (Author, Editor, etc.)
+- **BCR-2026-XXX: General Assertion Predicates** — Lifecycle predicates used by this BCR
+- **BCR-2026-XXX: Signing Event Attestations** — Signing context (`signer`, `signedOnBehalfOf`, `xades:ClaimedRole`); references this BCR for authority chains
+- **BCR-2026-XXX: CreativeWork Role Predicates** — Contribution roles (Author, Editor, etc.)
 
 ---
 
-*BCR-2026-006: Principal Authority Predicates*
+*BCR-2026-XXX: Principal Authority Predicates*
 *Draft - February 2, 2026*