Phase 0: Subject and object node storage #46

Merged

erikinkinen merged 4 commits from 0-subject-and-object-node-storage into main

2026-02-17 04:47:40 +01:00

erikinkinen commented

2026-02-17 04:46:14 +01:00

Owner

Task

Closes #4

Summary

This PR implements Subject and Object node storage as the foundational building blocks of the Phase 0 authority graph.

Subjects represent active authority-bearing entities, and Objects represent passive entities that can receive capabilities. Both are opaque structures with no internal state or behavior—all authority is derived from capabilities that will be introduced in later work.

This implementation establishes the structural nodes of the authority graph and provides the storage infrastructure needed for future capability creation and manipulation.

Scope

Included

Subject and Object types with deterministic ID assignment
SubjectStore and ObjectStore for managing node lifecycle (create/delete/query)
Optional debug labels (compile-time only, excluded from release builds)
Comprehensive unit tests for:
- Subject creation, deletion, and retrieval
- Object creation, deletion, and retrieval
- Debug label functionality
CMake integration and test harness updates

Explicitly excluded

Capabilities (deferred to future PR)
Authority relationships or graph edges
Delegation, attenuation, or revocation semantics
Provenance tracking or temporal behavior
Subject or Object behavior beyond storage

Design intent

This PR establishes the structural foundation for the authority graph:

Nodes are opaque: Subjects and Objects carry no intrinsic authority or state. They exist solely as endpoints for capabilities.
Deterministic identity: All IDs are assigned through the central Ids generator, ensuring reproducibility across runs.
Storage separation: SubjectStore and ObjectStore are independent, reflecting their distinct roles in the authority model.
Debug ergonomics: Optional debug labels (present only in debug builds) improve testability and inspection without affecting release semantics.
Phase 0 discipline: No assumptions about temporal behavior, revocation, or multi-phase semantics are introduced.

The separation of Subjects and Objects aligns with the conceptual model in model.md, where authority flows from Subjects to Objects via capabilities.

Phase discipline

This PR is Phase 0 only: it introduces no reserved-but-absent fields for later phases.
Subject and Object structures are minimal and complete for Phase 0 needs.
Debug labels are compile-time optional and do not affect Phase 0 invariants.
Storage interfaces are designed to support future capability graph operations without requiring structural changes.

Verification

All unit tests pass (aes_subject_tests, aes_object_tests, aes_debug_label_tests)
Smoke test passes with new infrastructure integrated
Debug labels are present in debug builds and absent in release builds
No memory leaks or undefined behavior (verified with sanitizers)
CMake integration correct for core library and test binaries
Pre-commit hooks pass (formatting, linting, checks)

Notes

This PR is infrastructure-only and does not yet enable authority operations.

Reviewers should focus on:

Structural correctness: Do Subjects and Objects correctly represent Phase 0 nodes?
Storage invariants: Does the store correctly manage creation, deletion, and lookup?
Debug ergonomics: Are debug labels useful without compromising determinism?
Phase discipline: Does this implementation avoid commitments beyond Phase 0?

Follow-up work will introduce:

Capabilities (edges in the authority graph)
Authority operations (grant, revoke, check)
Graph traversal and queries

### Task Closes #4 --- ### Summary This PR implements **Subject and Object node storage** as the foundational building blocks of the Phase 0 authority graph. Subjects represent active authority-bearing entities, and Objects represent passive entities that can receive capabilities. Both are opaque structures with no internal state or behavior—all authority is derived from capabilities that will be introduced in later work. This implementation establishes the structural nodes of the authority graph and provides the storage infrastructure needed for future capability creation and manipulation. --- ### Scope **Included** * `Subject` and `Object` types with deterministic ID assignment * `SubjectStore` and `ObjectStore` for managing node lifecycle (create/delete/query) * Optional debug labels (compile-time only, excluded from release builds) * Comprehensive unit tests for: * Subject creation, deletion, and retrieval * Object creation, deletion, and retrieval * Debug label functionality * CMake integration and test harness updates **Explicitly excluded** * Capabilities (deferred to future PR) * Authority relationships or graph edges * Delegation, attenuation, or revocation semantics * Provenance tracking or temporal behavior * Subject or Object behavior beyond storage --- ### Design intent This PR establishes the **structural foundation** for the authority graph: * **Nodes are opaque**: Subjects and Objects carry no intrinsic authority or state. They exist solely as endpoints for capabilities. * **Deterministic identity**: All IDs are assigned through the central `Ids` generator, ensuring reproducibility across runs. * **Storage separation**: `SubjectStore` and `ObjectStore` are independent, reflecting their distinct roles in the authority model. * **Debug ergonomics**: Optional debug labels (present only in debug builds) improve testability and inspection without affecting release semantics. * **Phase 0 discipline**: No assumptions about temporal behavior, revocation, or multi-phase semantics are introduced. The separation of Subjects and Objects aligns with the conceptual model in model.md, where authority flows from Subjects to Objects via capabilities. --- ### Phase discipline * This PR is **Phase 0 only**: it introduces no reserved-but-absent fields for later phases. * Subject and Object structures are minimal and complete for Phase 0 needs. * Debug labels are compile-time optional and do not affect Phase 0 invariants. * Storage interfaces are designed to support future capability graph operations without requiring structural changes. --- ### Verification * [x] All unit tests pass (`aes_subject_tests`, `aes_object_tests`, `aes_debug_label_tests`) * [x] Smoke test passes with new infrastructure integrated * [x] Debug labels are present in debug builds and absent in release builds * [x] No memory leaks or undefined behavior (verified with sanitizers) * [x] CMake integration correct for core library and test binaries * [x] Pre-commit hooks pass (formatting, linting, checks) --- ### Notes This PR is **infrastructure-only** and does not yet enable authority operations. Reviewers should focus on: * **Structural correctness**: Do Subjects and Objects correctly represent Phase 0 nodes? * **Storage invariants**: Does the store correctly manage creation, deletion, and lookup? * **Debug ergonomics**: Are debug labels useful without compromising determinism? * **Phase discipline**: Does this implementation avoid commitments beyond Phase 0? Follow-up work will introduce: * Capabilities (edges in the authority graph) * Authority operations (grant, revoke, check) * Graph traversal and queries

erikinkinen added 4 commits

2026-02-17 04:46:14 +01:00