Expand description
The records a session writes while it reasons: typed engineering artefacts, never a transcript and never hidden reasoning. What is kept is what a later session needs to avoid rediscovering a decision — facts, evidence references, assumptions, questions, positions, conclusions, validation — and nothing an advisor said verbatim beyond the summary its adapter normalised.
Inputs are what a caller authors; the stored body adds what only the writer may compute: a plan is computed from the availability at the moment it is recorded, a conclusion’s review count from the consultations it cites. A caller cannot supply either, because a review count a caller can type is a review a caller can invent.
The lifecycle of one record: a caller authors a ReasoningInput (usually as JSON,
tagged by kind), the store admits it into a ReasoningBody, and the writer wraps
that body in a ReasoningRecord stamped with an id, a task and a time.
use majordomus_cli::reasoning::availability::{ModeResolution, ReasoningMode};
use majordomus_cli::reasoning::record::{
ReasoningBody, ReasoningInput, ReasoningRecord, RECORD_SCHEMA, RECORD_VERSION,
};
use majordomus_cli::reasoning::store::{admit, Admission, Loaded};
let input: ReasoningInput = serde_json::from_value(serde_json::json!({
"kind": "assessment",
"subject": "whether the cache survives a restart",
"materiality": "low",
}))
.unwrap();
let mode = ModeResolution { mode: ReasoningMode::Standard, source: "default".into() };
let admission = Admission { mode: &mode, availability: &[] };
let body: ReasoningBody = admit(input, &Loaded::default(), &admission).unwrap();
assert_eq!(body.kind(), "assessment");
let record = ReasoningRecord {
schema: RECORD_SCHEMA.into(),
version: RECORD_VERSION,
id: "assessment-20261001T000000Z-abcdef".into(),
task: "untasked".into(),
recorded_at: "2026-10-01T00:00:00Z".into(),
head: None,
redacted: vec![],
body,
};
let json = serde_json::to_value(&record).unwrap();
assert_eq!(json["body"]["kind"], "assessment");
assert_eq!(json["schema"], "majordomus/reasoning-record");Structs§
- Advisor
Usage - Token counts an adapter reported. Absent when the transport reports none; never estimated.
- Assessment
Input - A material uncertainty, stated with the evidence gathered before anyone was asked.
- Attempt
Input - A failed implementation attempt and what it taught.
- Conclusion
Input - The engineering conclusion an assessment reaches.
- Consultation
Input - One normalised advisor exchange: what was asked, how it ended, and what came back.
- Disagreement
Input - Advisors, or an advisor and the executor, disagree.
- Disagreement
Position - One side of a disagreement: whose position it is, and the position in one line.
- Plan
Input - Ask the writer to make and record the plan for an assessment.
- Reasoning
Evidence - A reference to something that supports a claim.
- Reasoning
Record - A stored record: a body with the envelope only the writer stamps.
- Resolution
Input - A disagreement settled by evidence: what was run or read, and which position it favours.
- Stored
Conclusion - A conclusion as stored: the input and what only the writer computes.
- Stored
Plan - A plan as stored: the decision and the availability it was made against.
- Validation
Input - A step of a conclusion’s validation plan, performed.
Enums§
- Consultation
Status - How a consultation ended, as the adapter classified it.
- Reasoning
Body - A stored record’s body: the admitted input, with whatever the writer computed.
- Reasoning
Evidence Kind - What a piece of evidence is.
- Reasoning
Input - Anything a session records, as authored.
- Stance
- Where an advisor’s answer stands relative to the executor’s hypothesis.
- Validation
Outcome - Whether a performed validation step passed or failed.
Constants§
- RECORD_
SCHEMA - The schema name every stored record carries.
- RECORD_
VERSION - The record format version.