NEXUS CEREBRIOPEN-SOURCE PLANNING PROJECT
A plan youcan inspect.
Cerebri is a learning project exploring how software can make plans and explain its results. Follow a 30-minute appointment from possible times to a proposal you can examine. Nothing is booked.
REAL / APPOINTMENT EXAMPLE30 MIN · 11 POSITIONS
C0510:00 UTCCONCEPTUAL ASSEMBLY · ACTUAL CANDIDATE POSITIONSSAME OPTION · EXPLORE THE RESULT
01 / The instrument
A possibility has a place.
11 positions form one compact assembly. Open it to see the time, state and rules that give each position meaning.
PROJECT STATUS
Available to explore. Still in development.
Published release: None In development · release checks in progress Input format: CPIR 0.2
SourceMaster Specification 0.4CONTINUE THE SEARCH / INSPECT THE RESULT VALIDITY → ORDERING → PROPOSAL From possible times.
From possible times.
To one proposal.
Keep the same 11 possible starts in view. First inspect an overlap, then compare two valid options. Rust checks the rules and puts the remaining options in order. The same input gives the same result: this is deterministic planning.
The planner checks 11 possible start times for a 30-minute appointment. 4 overlap the existing appointment and are rejected. 7 pass the checks. The first option becomes a proposal; nothing is booked.
REALA 30-minute appointment: input and result
EXAMPLE INPUT09:00–12:00 UTC · 30-minute appointment · starts every 15 minutes
PREFERRED STARTNone supplied. The observation records missing distance as None.
- Request
- CREATE · 30 minutes
- Evaluated
- 11 positions
- Result
- 7 valid · 4 rejected
- First proposal
- 10:00 UTC
Time window limits this search Known appointment occupies this time Required rule every option must pass Preference helps compare valid options Candidate one possible appointment Rejected fails a required check First proposal first in the planner’s order
C05 · 10:00 UTCSAME FIELD · EXACT COORDINATES
- Candidate starting 09:00 UTC for 30 minutes. Rejected because it overlaps known busy time.
- Candidate starting 09:15 UTC for 30 minutes. Rejected because it overlaps known busy time.
- Candidate starting 09:30 UTC for 30 minutes. Rejected because it overlaps known busy time.
- Candidate starting 09:45 UTC for 30 minutes. Rejected because it overlaps known busy time.
- Candidate starting 10:00 UTC for 30 minutes. Valid and selected as the first proposal after deterministic ordering.
- Candidate starting 10:15 UTC for 30 minutes. Valid candidate.
- Candidate starting 10:30 UTC for 30 minutes. Valid candidate.
- Candidate starting 10:45 UTC for 30 minutes. Valid candidate.
- Candidate starting 11:00 UTC for 30 minutes. Valid candidate.
- Candidate starting 11:15 UTC for 30 minutes. Valid candidate.
- Candidate starting 11:30 UTC for 30 minutes. Valid candidate.
The red cut has a reason.
The requested interval crosses supplied busy time. Inspect the rejection recorded by Rust.
RUST REJECTION / C04NO_OVERLAP
09:45 UTC, 30 minutes: Overlap with busy (09:00–10:00 UTC).
A preference cannot override this rejection.
Inspect the rejection record
{
"start": "2026-10-01T09:45:00Z",
"reasons": [
{
"HardConstraint": {
"constraint": {
"kind": "NO_OVERLAP"
},
"object_id": "new-event",
"reason": "Overlap",
"evidence": {
"facts": [],
"blocking_objects": [
"busy"
],
"blocking_occurrences": []
}
}
}
]
}01 Valid options 7 pass the required checks
02 Compare options See why one comes first
03 First proposal 10:00 UTC remains a proposal
Why does 10:00 come before 10:15?
Both options pass the checks. Compare one field at a time: the first difference decides which option comes first. These values and the order come from Rust.
C0510:00 UTC
- preferred distance
- 0s
- mutation count
- 1
- shift seconds
- 0s
- start
- 10:00 UTC
- object id
- new-event
C0610:15 UTC
- preferred distance
- 0s
- mutation count
- 1
- shift seconds
- 0s
- start
- 10:15 UTC
- object id
- new-event
First difference: start. No preferred time was supplied. The first three comparison values are equal, so the earlier start comes first.
C05 · 10:00 UTC remains the same candidate in the field, comparison and proposal. Planning stops before authority.
C05 · 10:00 UTCSELECTED PROPOSALEXECUTIONnothing has been booked
ProvenOptimal
Every start in this grid was checked. The first proposal ranks best under the stated comparison rules. This claim applies only to this grid and these rules.
Text alternative
The planner checks 11 possible start times for a 30-minute appointment. 4 overlap the existing appointment and are rejected. 7 pass the checks. The first option becomes a proposal; nothing is booked.
A CLOSER LOOK AT TIME
When do appointments overlap?
Inspect why the 10:00 proposal can start exactly when the existing appointment ends. Then explore separate examples for preferred times and time measurement.
EXAMPLE / ADJACENT APPOINTMENTS
One ends. The next can begin.
These appointments fit back to back.
A runs from 09:30:00 to 10:00:00. B runs from 10:00:00 to 10:30:00 UTC. Each appointment includes its start, but no longer occupies time at its end.
At the changeover, A has ended and B begins. There is no overlap. The code calls this relationship Touches.
[start, end) means the start is included and the end is excluded. The filled and open markers show the same rule. This is a half-open interval.
Show the overlap check
A.start < B.end && B.start < A.end Do these intervals overlap? false. Planner result for this example: Solution.
SourceTimeRange overlap and intersectionA SECOND EXAMPLE / PREFERRED START
What if you would prefer 10:45?
A start at 10:30:00 is 900 seconds from the preferred 10:45:00 UTC. For example, 900 seconds is 15 minutes.
Every listed time has passed the required checks. The Rust planner has already put them in order. This separate example adds a preference; the earlier example has none.Show the distance and its source
preferred_start_distance_seconds = 900 preferred_start_source = ExplicitCurrentRequest These fields record the distance and where the preferred start came from. The source is recorded separately from the numeric value used for comparison.
HOW DISTANCE IS RECORDED
Why can 0.8 seconds be recorded as zero?
The ranking records distance in whole seconds. A difference smaller than one second therefore gives zero, while the exact timestamp stays unchanged. These small test examples show the calculation directly; they do not run a new planner search.
WHOLE-SECOND OBSERVATION0 sThe marker stays at 0.8 s.
Actual time difference: 0.8 s. Distance used for ranking: 0 s, recorded in whole seconds. The appointment’s start time has not moved.
Inspect exact instants and measurement
candidate_start = 1970-01-01T00:00:00.800Zpreferred_start = 1970-01-01T00:00:00Z (candidate_start - preferred_start).num_seconds().unsigned_abs() The signed duration is truncated toward zero to whole seconds before taking its magnitude.
COMPARING OLD AND NEW START TIMES
How far would an appointment move?
shift_seconds12 s
The start differs by 12.345 seconds. The dashed marker shows the original start.
Inspect original and candidate instants
original_start = 1970-01-01T00:00:00Zcandidate_start = 1970-01-01T00:00:12.345Z This tests the measurement only. No appointment is moved and no calendar is contacted.
Technical inspectionObservation → projection → ordering tuple
CURRENT / FEATURE CONTRACT 0.1
The same projection can hide different evidence.
None
Preferred-start evidence absent.
distance = nullsource = nullLEGACY ORDERING PROJECTION0
preference_distance_secondsSome(0)
Preferred-start evidence present with zero measured distance.
actual difference = 0.8 ssource = ExplicitCurrentRequestBoth project to 0. Their observations remain different. Some(0) does not require equal instants.
CURRENT / HOMEPAGE CANDIDATES
The comparator, in compact notation.
The same first two Rust-ranked candidates shown above. Read left to right; the first differing dimension decides. No aggregate score.
preference_distance_secondsLegacy numeric projection of the preferred-start observation. Absent evidence projects to zero.
C05 · 10:00:00 UTC
- preference_distance_seconds0
- mutation_count1
- shifted_seconds0
- start2026-10-01T10:00:00Z
- object_idnew-event
C06 · 10:15:00 UTC
- preference_distance_seconds0
- mutation_count1
- shifted_seconds0
- start2026-10-01T10:15:00Z
- object_idnew-event
For this no-preference fixture, the first difference is start. These values preserve the existing comparator's order.
The geometry has a type.
The interval you followed has two endpoints and an object identity. Open its structure: the values remain the same.
C05new-eventPLACEMENT IN ProposedPlan
The selected interval
placements[0].range- placements[0].range.
start - 10:00 UTC
- placements[0].range.
end - 10:30 UTC
[start, end)Start included. End excluded. The representation is more explicit; the plan has gained no execution authority.
FROM REPRESENTATION TO SOFTWARE
Responsibility moves inward.
CPIR describes the planning request. The planner returns typed candidate records. The website displays those records; Rust owns their meaning.
Inspect the structured request- Synchronous facadecerebri-core
Core delegates to planner and temporal. No executor is exposed here.
- Planning ownershipcerebri-planner
Planner consumes domain rules and returns ordered candidate records.
- Independent foundationscerebri-types + cerebri-temporal
Neither foundation has a dependency on another Cerebri crate.
EXPLORE THE DETAILS TIME · INPUT · PLANNING · EXECUTION What would you
What would you
like to explore?
Follow a topic from the example to its data format, rules and implementation.
01 / TEMPORAL
Time is a domain.
UTC instants, explicit zones, half-open intervals, DST diagnostics and bounded recurrence.
Open Temporal Lens → 02 / EVIDENCEKnowledge has shape.
CPIR keeps scope, provenance, policy, capability and search budget visibly separate.
Explore CPIR → 03 / SEARCHSearch. Constrain. Verify.
Bounded single-event grid search ranks feasible candidates deterministically.
Inspect Planning → 04 / PROOFPromotion is earned.
Planning, validation, authorization and execution stay separated by stronger states.
Follow Proof Chain → 05 / AUTHORITYArchitecture with direction.
Foundations feed domain semantics and thin transports without moving authority outward.
See Architecture → 06 / HORIZONWhere could learning help?
Explore how the learning project could grow from fixed planning rules to tested, learned advice.
View Roadmap →FUTURE RESEARCH / BEYOND THE CURRENT PLANNERThe next question
The next question
starts here.
Could a model help interpret a request or compare valid times? These are future experiments. The current planner does not train a model or learn from choices.
Explore the research questionsCURRENT / DETERMINISTIC COREValidity and authority stay explicit.
Future learned components may advise within their contract. Facts, hard constraints, permissions and execution remain outside learned authority.
FUTURE / LEARNED ADVICETHE PROJECT’S BEGINNING Why I started
Why I started
Nexus Cerebri.
I wanted to understand how neural networks learn. The 1986 backpropagation paper by David E. Rumelhart, Geoffrey E. Hinton and Ronald J. Williams helped me getting curious about the mathematics. Following each operation turned equations I found intimidating into steps I could understand.
Cerebri became a way to keep learning by building and testing a real system. Planning gave me a concrete problem: what is already known, which rules must hold, and why does one option come before another? Scheduling is the first example; the longer-term aim is planning software for different applications.
The planner shown here follows fixed rules. Later, I want to explore how learned methods could help it find and compare options. The learning and research path explains those questions and the checks that would still apply.