Capability Genealogy Tracking

Mechanism

Capability genealogy tracking is the structural mechanism by which the agent records the derivation history of every capability in its registry, enforces inheritance of parent bounds onto derived capabilities, and prevents circular derivation. The mechanism is defined in Chapter 6 of the cognition patent as a deterministic graph-construction and graph-checking function whose inputs are the existing capability registry and a candidate derivation, and whose outputs are an updated registry and a structured admission decision recorded in the agent's lineage.

Every capability admitted to the registry is annotated with a genealogy record consisting of the identifiers of its direct parents, the derivation rule that produced it, the bounds it inherits from each parent, and the additional bounds imposed by the derivation rule itself. The bounds are expressed in the agent's canonical capability vocabulary and include resource ceilings, latency floors, authorization scopes, side-effect classes, and policy-reference invariants. The genealogy record is immutable once written and is the sole authoritative source of derivation truth for the capability.

Inheritance is structural and monotonic. When a derived capability is constructed from one or more parent capabilities, its effective bounds are computed as the meet of the parent bounds under the bound lattice defined in the policy reference. The derived capability cannot exceed any parent's ceiling along any dimension, and any attempt to declare a derived capability whose declared bounds exceed the inherited meet is rejected at composition time. This structural property is what guarantees that no chain of derivations can produce a capability with looser bounds than its ancestors.

Cycle rejection operates at composition time rather than at execution time. When a candidate derivation is presented, the genealogy engine performs a depth-first traversal of the proposed extension to the derivation graph and rejects any derivation that would introduce a directed cycle. The check is performed before the derived capability is admitted, so cycles cannot be observed in the registry at any point. The structural guarantee is that the genealogy graph is, at all times, a directed acyclic graph rooted in a finite set of axiomatic capabilities declared in the policy reference.

The axiomatic capabilities are the only capabilities admitted without parents. They are declared in the policy reference and are the structural foundation against which all derivation is anchored. Every non-axiomatic capability has at least one parent, and its bounds are derived from those parents according to the derivation rule. The set of axiomatic capabilities is fixed at deployment time and cannot be extended at runtime.

Operating Parameters

The genealogy engine is parameterized by the bound lattice, the derivation rule set, the maximum derivation depth, and the cycle-detection budget. Each parameter is specified declaratively in the policy reference and is auditable without inspection of the underlying capability registry.

The bound lattice defines, for each capability dimension, the partial order under which inheritance is computed. Resource dimensions such as compute, memory, and network bandwidth use a numeric meet that selects the smaller of two ceilings. Authorization dimensions use a set-intersection meet that selects the common scope. Side-effect dimensions use a class-restriction meet that selects the more restrictive class. Policy-invariant dimensions use a conjunction meet that selects the stronger invariant. The lattice is configured per deployment and is the structural specification against which all inheritance is evaluated.

The derivation rule set defines the admissible derivation patterns, including pure inheritance, restriction, parallel composition, sequential composition, and delegation. Each rule specifies how parent bounds combine and what additional bounds the rule imposes. Rules are declared in the policy reference and cannot be extended at runtime. Capabilities derived under a rule not in the set are rejected at composition time.

The maximum derivation depth bounds the length of any chain of derivations from an axiomatic capability to a derived capability. Depth limits prevent uncontrolled proliferation of capabilities and ensure that genealogy traversal terminates in bounded time. The cycle-detection budget bounds the work performed during the directed-acyclic-graph check and ensures that pathological derivation graphs cannot exhaust the engine's resources.

Alternative Embodiments

Embodiments differ in the representation of the genealogy graph. A materialized embodiment stores the full derivation graph in the agent's canonical store and traverses it at composition time. A hashed embodiment stores only a Merkle root of the graph and reconstructs paths on demand from a content-addressed log. The embodiments are structurally equivalent under the patent's claims; the distinction is operational and concerns audit and storage cost.

Embodiments differ in the locus of cycle detection. In an eager embodiment, the cycle check runs at every derivation. In a deferred embodiment, derivations are admitted provisionally and the cycle check runs in batch at policy-reference checkpoints, with provisional capabilities revoked if a cycle is detected. The deferred embodiment supports high-throughput derivation but requires that provisional capabilities be marked as such and excluded from execution until confirmed.

Embodiments differ in the granularity of bound inheritance. A coarse embodiment inherits bounds at the capability level, treating each capability as a single bundle. A fine embodiment inherits bounds at the dimension level, allowing per-dimension overrides subject to the lattice. The fine embodiment supports more expressive derivation patterns but requires that the policy reference specify per-dimension inheritance rules.

A federated embodiment partitions the genealogy across multiple authority domains, with each domain maintaining its own subgraph and exchanging signed derivation tokens. The federated embodiment supports deployments in which capabilities are derived across organizational boundaries, and the structural property that the global graph is acyclic is preserved by requiring each cross-domain derivation to carry a signed predecessor reference.

Composition With Adjacent Mechanisms

The genealogy engine composes with the capability registry by serving as the registry's gatekeeper for all admission events. No capability is admitted to the registry without a genealogy record, and the registry exposes the genealogy as a queryable structure for downstream consumers. Composition with the multimodal evaluation pipeline is direct: the evidence vector that justified a skill's admission is recorded as part of its genealogy record, providing a unified audit trail.

Composition with the confidence-governance subsystem is structural. The confidence associated with a derived capability is bounded above by the minimum of its parents' confidences, mirroring the bound-inheritance property. A derived capability cannot be more confident than its least-confident ancestor, and this property is enforced at composition time rather than at execution time.

Distinction From Prior Art

Prior art in capability systems typically uses flat capability registries with no derivation history, or uses derivation histories that lack structural inheritance enforcement. Such systems can detect missing capabilities but cannot prevent the construction of derived capabilities that exceed their parents' bounds. Prior art in dependency tracking detects cycles in build systems but does not enforce bound inheritance and is not integrated with capability admission.

The genealogy engine's distinguishing structural property is the unification of derivation tracking, bound inheritance, and cycle prevention into a single composition-time mechanism whose output is an immutable genealogy record. This unification is the basis for the patent's claim and is not present in prior capability or dependency systems.

Implementation Considerations

A faithful implementation must serialize derivations through the genealogy engine such that no two derivations can be admitted concurrently without a structural reconciliation step. Concurrent admission risks the construction of a cycle that neither derivation, viewed in isolation, would close. The reference implementation places admission events behind a single-writer lock per genealogy partition, and the partition boundary is selected such that cross-partition derivations require an explicit signed reference that the cycle check can resolve.

The engine also enforces a structural property on the bound lattice: the lattice must be well-founded, so that the meet of any chain of bounds terminates. Lattices that admit infinite descending chains can produce derivations whose effective bounds are computed only as a limit, breaking the determinism guarantee. The policy reference accordingly requires that all bound dimensions admit a discrete representation with a structural minimum, and the engine rejects any policy reference that violates this property.

Garbage collection of obsolete capabilities is a structural rather than operational concern. A capability whose ancestors have all been retired cannot itself be retired without a corresponding genealogy update, and the update is itself recorded as a derivation event. The engine accordingly treats retirement as a derivation that produces a tombstone capability inheriting its parent's bounds, and the tombstone is preserved in the lineage even after the runtime registry has discarded the capability.

Performance considerations favor the hashed embodiment for high-throughput deployments. The Merkle root of the genealogy graph can be exchanged across audit boundaries without disclosing the full derivation history, and the audit consumer can request specific paths on demand. The eager cycle check, in contrast, is preferred for safety-critical deployments where provisional capabilities are unacceptable. Mixed embodiments partition capabilities by consequence class and apply the eager check to high-consequence classes while applying the deferred check to low-consequence classes.

Failure Modes And Mitigations

The genealogy engine fails safely under three structural failure modes. Lineage corruption, in which an adversary attempts to modify a genealogy record after it has been written, is mitigated by content-addressing the records and storing the addresses in an append-only log; any modification produces a different address and is therefore detectable by lineage verification. Cycle injection, in which an adversary attempts to admit a derivation that closes a cycle by exploiting a race condition in the cycle check, is mitigated by serializing admission events through the per-partition single-writer lock. Bound inflation, in which a derivation declares bounds exceeding the inherited meet, is rejected at composition time by the structural inheritance check.

Pathological derivation graphs, in which a malicious or buggy proposer emits a chain of derivations whose cycle check would exhaust the cycle-detection budget, are rejected when the budget is exhausted. The structural property is that budget exhaustion produces a rejection rather than a default-admit, so an attacker cannot induce admission by inflating graph complexity. The rejection is recorded in the lineage with the budget-exhaustion class identifier, supporting downstream forensic analysis.

Disclosure Scope

This article discloses the structural mechanism, operating parameters, and alternative embodiments of capability genealogy tracking as defined in Chapter 6 of the cognition patent. The disclosure is sufficient to enable a person of ordinary skill in the art to construct an embodiment without reference to the patent's underlying implementation. The patent's claims govern all embodiments that incorporate the bound-inheritance and cycle-rejection properties, regardless of the specific lattice, rule set, or graph representation adopted.