Framework#
The saealib framework places Component contracts in a ComponentGraph and provides the execution foundation for the Compiler to turn them into a verified ExecutablePlan. It treats contract structure and execution flow as separate relationships.
Concept pages#
Components return their static contract through contract().
ComponentContract describes contract inclusion for the components a Component holds and the capabilities it requires, not a Component inheritance hierarchy.
PortSpec, DataSpec, and StateContract are declarative values that compose a contract, not Component subclasses.
The following pages explain the concepts needed for extensions by responsibility.
The Component Protocol, contract(), and PartSpec.
Contract elements and invariants.
Declarative values for ports, data, services, and compatibility.
Nodes, edges, state bindings, and structured regions.
Verification, resolution, diagnostics, and ExecutablePlan.
ExecutablePlan execution, state application, resumption, and asynchronous waiting.
Candidate representation, services, and the RepresentationSpec boundary.
Candidate IDs and the correspondence between observations, true values, and predictions.
The ownership boundary between Stage-compatible and graph-native state.
Execution flow#
The runtime relationship is Component → ComponentNode → ComponentGraph → Compiler → ExecutablePlan → ExecutionRuntime.
This flow is separate from the contract tree; ComponentContract does not directly represent execution order.
See OptimizationState and Runtime for detailed state boundaries, and SearchSpace and Feedback for candidate-representation and observation boundaries.
Extension paths#
When you only need to swap the behavior of a built-in component, choose the corresponding extension page. When you need a new contract, candidate representation, Graph connection, Compiler rule, or Runtime semantic, see Framework extensions. See the API reference for import paths for public types.