Expand description
ELARA Core - Fundamental types and primitives
This crate defines the core types used throughout the ELARA protocol:
- Identifiers (NodeId, SessionId, StateId)
- Time primitives (StateTime, PerceptualTime)
- State atoms and events
- Protocol constants and configuration
- Hard Invariants - System laws that all layers must obey
§Hard Invariants
ELARA is governed by five hard invariants. These are not guidelines—they are system laws. If any single invariant falls, the system is not ELARA.
- Reality Never Waits - System never blocks reality for synchronization
- Presence Over Packets - Existence matters more than data perfection
- Experience Degrades, Never Collapses - Quality reduces, never fails
- Event Is Truth, State Is Projection - Events are authoritative
- Identity Survives Transport - Identity persists beyond connections
See invariants module for details.
Re-exports§
pub use invariants::Invariant;pub use invariants::InvariantCompliant;pub use invariants::InvariantViolation;pub use models::ModelCompliant;pub use models::PerceptualWeight;pub use models::ProtocolModel;pub use models::ReconstructabilityClass;pub use science::ChaosCategory;pub use science::ChaosSuccessCriteria;pub use science::ChaosTestResult;pub use science::DegradationLevel;pub use science::EventOperator;pub use science::NodeClass;pub use science::NodeClassSet;pub use science::PresenceVector;pub use class::*;pub use error::*;pub use event::*;pub use id::*;pub use state::*;pub use time::*;
Modules§
- class
- Packet and event class definitions
- error
- Error types for ELARA protocol
- event
- Event definitions
- id
- Identity types for ELARA protocol
- invariants
- ELARA Hard Invariants
- models
- ELARA Formal Protocol Models v1
- science
- ELARA System Science — Foundational Constructs v1
- state
- State atom definitions
- time
- Time primitives for ELARA protocol