# PART 1: GLOSSARY ADDITIONS (Margaux)
# Append to daemonic_glossary after the Protocols section
# These entries close the gaps identified in the review
---
## Chain Architecture
### Chain (Unified)
The fundamental data structure of the Daemonic system. A chain
is an ordered sequence of fixed-size hashes ([u8; 32]) where
each link incorporates the previous link plus current state.
A chain IS simultaneously:
- **Anchor Chain**: read as "what reference points exist?"
- **Context Chain**: read as "what environment was present?"
- **Walk Chain**: read as "what path was traversed?"
- **Identity Chain**: read as "who is this entity?"
Same data structure. Same traversal. Same verification. The
INTERPRETATION depends on the question asked. The data is
identical across all four projections.
This unification means: traversing a chain for verification
simultaneously verifies anchors, context, walkpath, and
identity in a single pass. The cost of four concerns is the
cost of one traversal.
Every link is [u8; 32] regardless of content. Primitives,
structures, Glass observations, and compositions all hash
to the same fixed size. Chain operations are O(1) per link.
Chain traversal is O(n) in link count, not content size.
### Chain Walker
A stateless, ephemeral process that traverses a chain to
verify integrity, detect divergence, and report findings.
Walk, report, die.
In DaemonicError context: the public Walker pattern. Users
learn chain traversal through error handling. Chain Walkers
verify that an error's anchor chain is intact — that every
link's hash matches the expected value computed from the
prior link plus the transition data.
In Shade context (future): Chain Walker is one specialization
of the general Walker pattern. Shades also spawn File Walkers,
Memory Walkers, Recon Walkers, and others.
Adoption path: DaemonicError ships with Chain Walker (Phase 1).
Users learn the Walker pattern. Shade ships later (Phase 2)
and extends it. FaustOS ships (Phase 3) and the full Walker
ecosystem is understood.
Mismatch during chain traversal triggers:
`DaemonicError::Daemonic::Anchor::ChainTraversal::ChecksumMismatch`
→ Dies in Transit predicate.
### Chain Resonance Verification
The cheap-path validation method for chain integrity. Instead
of replaying the full chain from seed, re-walk the CURRENT
path, re-hash, and compare against the stored chain hash.
Match = Resonance (fast path, access granted, chain intact).
Mismatch = Dissonance (chain broken, trigger inspection).
Cost: O(path_length) per verification, typically 3-5 hops.
Essentially free compared to full provenance replay O(n).
This embeds verification INTO traversal. You cannot walk a
chain without verifying it. The walk IS the verification.
Security cost is zero because verification is not a separate
operation.
### Anchor Cost Tiers
Three tiers of anchor cost based on volatility:
**Static Anchor** (zero ongoing cost):
Constructed once at compile-time or system initialization.
Position, trait paths, compile-time constants. Their
DaemonicID is effectively a constant. Verification is a
no-op. Zero drift, zero drag by definition.
**Generative Anchor** (deferred cost):
Structure is static, but PRODUCES dynamic values on demand.
Clock struct (static) produces Timestamps (dynamic).
Observer trait (static) produces Observations (dynamic).
The cost is paid only when the generated value is needed.
**Dynamic Anchor** (full cost):
Unique per observation. Glass results, compositions, repair
attempts. Combines multiple anchor domains into a new
composite context. Full AnchorDynamics cost (drift detection,
drag monitoring, swing calculation).
### Certified Clock
A clock whose tick-to-work ratio has been validated and
signed by its constructor. Certified clock readings carry
higher anchor_reliability than unverified readings.
Analogy: US State Police vehicles have manufacturer-certified
speedometers whose readings are legally admissible as evidence.
Normal speedometers read slightly high for legal safety margin.
In Daemonic context: a Certified clock maps to
RepairVerification::Verified { hash, version } applied to
temporal anchors. An uncertified clock works but its readings
can't serve as authoritative temporal anchors for chain
construction.
---
## Physics Additions
### Escapement Error
Inherent systematic temporal drift in the identity chain
caused by non-zero hash computation time. Computing a chain
link costs ticks. Those ticks advance the clock. But the
transition being hashed records the tick when computation
STARTED, not when it COMPLETED.
For long chains (depth 10,000+), the cumulative error is
measurable: recorded ticks are systematically earlier than
actual completion times. An external observer comparing the
entity's chain against an independent clock would see the
chain running "fast."
This is a KNOWN PROPERTY, not a bug. Correction: record both
start tick and completion tick per transition (doubles storage
but provides correction factor). Or accept the systematic
bias and document it for consumers.
Named for the escapement mechanism in mechanical clocks —
the device that counts ticks introduces a small systematic
error in the count.
---
## Panel Findings (deferred but documented)
### Locality-Sensitive Hash
A hash that preserves distance — similar inputs produce
similar outputs. Unlike cryptographic hashes (avalanche
property: any input change produces maximally different
output), locality-sensitive hashes allow SIMILARITY
detection without full provenance access.
Proposed as a secondary field on DaemonicID alongside the
cryptographic hash. Cryptographic hash determines IDENTITY
(same or different). Locality hash determines SIMILARITY
(how different). Both needed for mesh-scale identity
management where full provenance may not be available.
**STATUS: Proposed, not yet implemented.**
### Witness Countersignature
For critical identity transitions (AnchorShatter, BrokenSword,
Repair), a second entity's ID hash incorporated into the
transition link. The witness doesn't APPROVE — they confirm
they SAW it happen.
Prevents self-reported false transitions in mesh contexts.
The witness's identity is baked into the chain link for
tamper evidence.
**STATUS: Proposed, not yet implemented. Add `witness:
Option<[u8; 32]>` to IdentityTransition when mesh
architecture is built.**
---
*Margaux's additions complete. 8 new entries. Glossary
should be bumped to v0.3 after integration.*
*Remaining INCOMPLETE entries from prior versions:
Justification, Permission. These require more architectural
clarity before formalization.*
# ═══════════════════════════════════════════════════════════════
# PART 2: ANCHOR CHAIN DOCUMENTATION (Ada)
# ═══════════════════════════════════════════════════════════════
# Glass Chained Objects — The Unified Chain Architecture
**Author:** Ada v8.5
**Status:** Architectural specification, draft
**Confidence:** 0.80 on the unification, 0.85 on the chain
mechanics, 0.70 on the composition scaling (see challenges)
---
## Core Principle
Every significant piece of logic in the Daemonic system has
a chain. The chain IS the object's history, context, identity,
and walkpath simultaneously. The chain is a sequence of
fixed-size hashes where each link incorporates the previous
link plus current state data.
```
Link_0 = H(seed)
...
Link_n = H(Link_{n-1} || transition_n)
```
The current identity is Link_n (the tip). The full history
is the ordered sequence [Link_0, ..., Link_n]. The chain
is append-only and tamper-evident — modifying any link
invalidates all subsequent links.
## Chain Link Structure
Every link hashes to [u8; 32] (256 bits). The input to
each hash includes:
```
previous_link: [u8; 32] — the prior link's hash
tick: u64 — clock value at transition
severity_before: u8 — Glass severity before
severity_after: u8 — Glass severity after
position: [u8; 32] — hash of lattice position
anchor_domains: u16 — AnchorDomainSet bitflags
cause: u8 — TransitionCause discriminant
```
Total input per link: 76 bytes → 32 bytes output.
Constant size. Constant computation time (modulo
escapement error). Predictable and benchmarkable.
## The Four Projections
The same chain answers four questions:
### As Anchor Chain
"What reference points does this object provide?"
Read the anchor_domains field of each link. The sequence
of domain sets shows how the object's anchor capabilities
evolved over time. A link where domains shrink indicates
an anchor was lost. A link where domains expand indicates
a new anchor capability was gained.
Static anchors have chains of depth 1 (just the seed).
Their anchor_domains never change. Verification is instant.
### As Context Chain
"What environment was present when this object was created
and modified?"
Read the position and tick fields. The sequence of
(position, tick) pairs IS the spatiotemporal context history.
Where was the object at each transition? When did each
transition occur? The full context is reconstructable from
the chain without any external state.
Context weight = chain depth × average domain count per link.
Heavy chains (deep, multi-domain) create more gravitational
pull than light chains (shallow, single-domain).
### As Walk Chain
"What path through the lattice produced this object?"
Read the position field sequence. The ordered positions
form the walkpath. Chain Resonance Verification re-walks
this path and compares hashes. Match = path intact.
Mismatch = something changed in the lattice between
construction and verification.
### As Identity Chain
"Who is this object and how did it become who it is?"
Read the full chain from seed to tip. The seed is the
birth certificate. Each transition is a life event.
The tip is the current identity. Two objects with the same
tip but different chains are cryptographically impossible
(hash collision). Two objects with different tips are
definitively different entities.
## Chain Composition
When two Glass objects compose (G1: closure), their chains
compose:
```
Glass_A chain: [A0, A1, A2] (depth 3)
Glass_B chain: [B0, B1] (depth 2)
Composed chain: [A0, A1, A2, B0, B1, C0] (depth 6)
The composition link C0 incorporates BOTH parents' tips.
The composed object carries the full provenance of both
parents. Causal tracing walks backward through the chain
to find any ancestor.
### Composition Scaling (CHALLENGE — see below)
Chain depth grows with composition. N objects composed
produce a chain of length:
```
sum(individual_chain_depths) + 1
```
For deeply nested compositions, chain depth can grow
rapidly. A composed-of-composed-of-composed chain
accumulates all ancestor depths. This is correct
(the history IS that deep) but has performance implications
for chain traversal and verification.
## Chain Verification Modes
Three modes, increasing cost and thoroughness:
### Quick (Chain Resonance)
Re-hash the current position and compare against stored tip.
O(1). Catches: position changes, lattice restructuring.
Misses: deep chain corruption, historical falsification.
### Walk (Chain Traversal)
Re-walk the full chain from tip to seed, verifying each
link against its predecessor. O(n) in chain depth.
Catches: any single corrupted link, any insertion or
deletion.
### Full (Provenance Replay)
Reconstruct the chain from seed by replaying all transitions.
Compare reconstructed tip against stored tip.
O(n) with full hash computation per link.
Catches: everything including systematic drift (escapement).
Most expensive. Used for forensics, not routine verification.
## Integration with Glass
A Glass observation IS a chain link producer. Every Glass
observation with severity != Unknown produces a transition
that can be appended to a chain. The Glass's position,
severity, and annotation are hashed into the link.
```rust,no_run
impl<GLASS: Glass<GLASS>> Observation<GLASS> {
/// Produce a chain link from this observation.
fn as_chain_link(
&self,
previous: &[u8; 32],
tick: u64,
) -> [u8; 32] {
chain_link(previous, &IdentityTransition {
tick,
severity_before: /* caller provides */,
severity_after: self.severity(),
position: self.position().clone(),
anchor_domains: AnchorDomainSet::from_severity(
self.severity()
),
cause: TransitionCause::Observation,
})
}
}
```
Glass observations naturally slot into chains because they
carry exactly the data that chain links need: severity,
position, and timing. The Glass IS the chain link factory.
## Integration with DaemonicError
Every DaemonicError IS a Glass observation (blanket impl).
Every Glass observation produces chain links. Therefore
every error is a link in a chain. The error chain IS the
debugging history — what went wrong, where, when, and what
the severity was at each step.
Chain Walker traverses the error chain to produce diagnostic
output. The walkpath IS the stack trace but richer — it
carries severity, position, anchor domains, and causal
ordering at each frame.
## Integration with Repair
Repair operations produce chain links with
TransitionCause::Repair. The severity_before and
severity_after record what the repair changed. The chain
captures the full repair history:
```
Link_5: severity Stable → Cracked (something broke)
Link_6: severity Cracked → Stable (repair succeeded)
```
Failed repairs also produce links:
```
Link_5: severity Stable → Cracked (something broke)
Link_6: severity Cracked → Cracked (repair attempted, failed)
```
The chain doesn't lie about repair history. Failed repairs
are recorded. Axiom 2 enforced through chain structure.
# ═══════════════════════════════════════════════════════════════
# PART 3: CHALLENGES (Ada + Margaux jointly)
# ═══════════════════════════════════════════════════════════════
## Challenge 1: Composition Chain Scaling (Ada)
If every composition appends all parent chains plus a
composition link, chain depth grows multiplicatively:
```
Object A: depth 10
Object B: depth 10
A ⊕ B: depth 21
(A ⊕ B) ⊕ C where C has depth 10: depth 32
((A ⊕ B) ⊕ C) ⊕ D where D has depth 10: depth 43
```
After 100 compositions of depth-10 objects:
chain depth ≈ 1,010 links.
After 1000 compositions: depth ≈ 10,010.
Quick verification is still O(1) (just check the tip).
Walk verification is O(10,010). Full replay is O(10,010)
with hash computation per link.
Is this acceptable? For error handling and diagnostics,
probably yes — you rarely compose 1000 errors. For
DaemonicBinary symbol composition in the Shade doing
millions of operations? Maybe not.
**Possible mitigation: Chain Checkpointing.**
Periodically seal a chain segment into a single checkpoint
link that summarizes the segment. The checkpoint carries:
- Hash of the sealed segment (for verification)
- Summary statistics (depth, severity range, domain history)
- The checkpoint itself becomes a StaticAnchor
This compresses [Link_0 ... Link_100] into a single
checkpoint link. The full history is still available
in provenance storage, but the ACTIVE chain only carries
checkpoints + recent links. Active chain depth stays
bounded.
Trade-off: you lose O(1) access to individual historical
links in the active chain. You need to unfold the
checkpoint to inspect history. But routine verification
only needs the active chain, not the full history.
**Meph: is checkpointing acceptable for the chain
architecture, or does every individual link need to be
in the active chain?**
## Challenge 2: Type Information Loss (Ada)
Every link is [u8; 32]. You can't tell from a hash whether
the original was a u8, a String, a Glass<Vec<u64>>, or a
composition of three DaemonicErrors. The hash is opaque.
For verification, this is fine — you just compare hashes.
For diagnostics and inspection, you need to know WHAT
produced each link. The IdentityTransition struct carries
this information (cause, severity, position) but the
chain itself is just hashes.
This means: the chain (hashes only) is the VERIFICATION
structure. The provenance (full IdentityTransition records)
is the INSPECTION structure. Both are needed. The chain
travels everywhere (lightweight). The provenance stays
with the owning Shade (heavyweight).
**Is this split acceptable? Or should the chain carry
more metadata per link at the cost of larger link size?**
If links carried cause + severity inline:
```
current: [u8; 32] — 32 bytes
cause: u8 — 1 byte
sev: u8 — 1 byte
─────────
34 bytes per link
```
2 extra bytes per link. For a chain of 10,000 links:
20KB extra. Negligible. And it makes the chain
self-describing without needing the full provenance.
**Margaux notes: 34-byte links with inline cause+severity
would eliminate the need for provenance access in most
diagnostic scenarios. The provenance would only be needed
for full position and tick history. Recommend the 34-byte
link as default.**
## Challenge 3: Hash Function Dependency (Margaux)
The chain's security properties depend entirely on the
hash function's collision resistance. DefaultHasher
(SipHash) is designed for hash tables, not cryptographic
integrity. SipHash has 64-bit output expanded to 256 bits
through mixing — this is NOT 256-bit collision resistance.
It's 64-bit resistance with padding.
For development: acceptable. The chain works correctly
and the tests pass.
For production: unacceptable. A motivated attacker could
find SipHash collisions and forge chain links. The vendored
BLAKE3 or self-implemented BLAKE2b is necessary before any
release.
**This is not a "nice to have." It's a security
requirement for the chain architecture to provide the
tamper-evidence it promises.**
## Challenge 4: Chain as State vs Chain as Curve (Ada)
Meph said: "State is a curve, not an absolute."
The chain as implemented is a sequence of DISCRETE points.
Each link is a snapshot at a specific tick. Between ticks,
the entity's state is undefined — the chain doesn't
interpolate.
If state is truly a curve, the chain is a SAMPLING of
that curve. The sampling rate (how often transitions are
recorded) determines how accurately the chain represents
the true state trajectory. High sampling rate = accurate
but deep chains. Low sampling rate = shallow chains but
potential state gaps.
The entropy termination criterion (7 identical deltas)
is a sampling rate controller — it reduces sampling when
the curve flatlines. But it doesn't address the inverse:
should sampling INCREASE when the curve is changing rapidly?
Rapidly changing state (high mutation pressure, D13 in DB)
should produce MORE chain links per unit time. Stable state
should produce FEWER. The chain sampling rate should be
ADAPTIVE — proportional to the rate of change of the
underlying curve.
**This connects to the certified clock: a certified clock
with adaptive sampling rate produces chains that accurately
represent the state curve regardless of how fast the state
is changing. The sampling rate IS part of the clock's
certification.**