NEXUS CEREBRI / Architecture
Which part does what?
Rust checks the appointment details, tests possible times and compares valid options. The API and Node bridge pass requests to that code. The Lab and website show the results. Carrying out a change requires separate validation, permission checks and an executor.
cerebri-core forwards planning calls to cerebri-planner. The planner owns CPIR and the stages through AuthorizedActionPlan; cerebri-integrations owns execution. An import arrow shows a code dependency, not an execution step.
cerebri-ml defines metadata and interfaces, but the current planner does not call a learned model. Learning experiments in research/ stay outside production dependencies.
The same compressed system opens into ownership: transports delegate inward through the core facade to planner and domain foundations; results return outward. Research is detached. Candidate checks and later lifecycle validation remain separate.
Following explanation depth
Exploded precision
- 01Structured state
- 02Planner
- 03CandidatesAfter hard-rule checks
- 04ProposalNot yet a ValidatedPlan
01 REST / Node delegate inward to core. They do not own planning semantics.
02 Core delegates to planner and temporal. No executor is exposed here.
03 Planner consumes domain rules and returns ordered candidate records.
04 These domain crates depend on the independent foundations.
05 Neither foundation has a dependency on another Cerebri crate.
Site fixture input
scripts/build-site-data.mjscerebri-core / example plangenerated runtimeData- Static site reads typed output
The site does not run the planner in the browser.
Validation follows proposal.
Candidate hard-rule checks belong to search. Lifecycle validation separately promotes ProposedPlan → ValidatedPlan in cerebri-planner.
cerebri-integrations owns execution ports and the later execution path. Authorization and preflight remain required; REST and Node do not expose execution.
candidates[0].proposed →Text alternative
The same compressed system opens into ownership: transports delegate inward through the core facade to planner and domain foundations; results return outward. Research is detached. Candidate checks and later lifecycle validation remain separate.