One Generation, From Hypothesis to Inheritance

Praxist's basic unit of progress is a generation: a bounded cohort of peer investigations followed by a decision about what evidence and plans may move forward. The useful question here is how a task contract becomes actual experimental work, how that work becomes committed state, and why a completed-looking folder is not necessarily a completed generation.

A generation starts with inherited state

Before any peer begins, Praxist resolves the selected task, plugins, prompts, baseline references, model provider, agent runtime, and initial durable state. It freezes the run-level choices so that the cohort has one declared context. Generation zero starts from the task's baseline and initial prompt. Later generations inherit the preceding committed agenda together with the evidence that the task has authorized for planning.

That inherited state is broader than a single “best result.” A peer's context can include the task prompt and role, the allowed work surface, current frontier and incubator views, optional Gems, finding-graph guidance, negative-evidence summaries, peer-local memory, and the evaluator and protocol contract. The point is not to expose every historical artifact at once. The point is to give the peer enough structured context to decide what should be tried next while keeping the underlying records available for exact inspection.

A generation therefore has both a scientific input and a control input. The scientific input is the task's objective, constraints, evaluator, metrics, and existing evidence. The control input says which agents are active, which tools and runtime they receive, how much time or budget is available, and when the cohort may close. Praxist coordinates the latter without changing the meaning of the former.

The previous agenda is also not a command to repeat a result. It is a plan for assigning work. A later peer may restart from the baseline, repair a credible signal, ablate a strong candidate, combine compatible mechanisms, investigate an off-mainline direction, or inherit a durable candidate. Which of those choices is appropriate depends on the evidence and task policy that arrive with the generation context.

What a peer is responsible for

A peer is not merely asked to “improve the score.” Its work has a more disciplined shape. First, it reads the task and role contract, the current agenda, and the inherited evidence. It then states a mechanism hypothesis and the evidence stage it intends to produce. That statement connects an intervention to an expected observation before the result is available.

Next, the peer creates an independent variant under the run's permitted work surface and changes only the files the task allows. This boundary matters because a score can improve for the wrong reason. If a peer changes the evaluator, data split, metric calculation, or a protected asset, the output may no longer answer the original question. Praxist's framework can record or reject such a result, but the task contract must say what counts as a violation.

The peer then submits the variant through the task's public evaluator path. The public path is important because it gives every peer the same measurement interface. Internal training or simulation helpers may be complicated, but the evaluator should produce a structured result summary rather than asking each peer to invent its own parsing and ranking rules.

The summary answers the first factual question: what did the evaluator measure? It can contain the task's metrics, stage or maturity information, protocol facts, caveats, and provenance. The peer's finding answers a different question: how might later research interpret or use that result? It can state the mechanism, limitations, evidence valence, follow-up, and whether the result appears suitable for a particular retention lane. The two objects are related, but they should not be collapsed into one optimistic score.

Finally, the peer publishes structured output under the run's result and finding paths. A failed experiment can still carry a useful negative result or failure mode. A partial evaluation can identify a repair target. A promising result can still need fuller coverage before it becomes a durable parent. The peer's responsibility is to make the observation and its qualifications available; later stages decide how much authority it receives.

The generation in motion

The lifecycle is easier to interpret when the handoffs are explicit. Praxist does not ask a panel to imagine experimental evidence before peers run, and it does not let a live score silently become a next-generation plan. Each transition has a different owner.

sequenceDiagram participant Task as Task project participant PraxistLoop as Praxist loop participant Peers as Peer cohort participant Eval as Public evaluator participant Store as Run evidence participant Panel as PI or Chair Task->>PraxistLoop: Provide contract and inherited policy PraxistLoop->>Peers: Render context and launch cohort Peers->>Eval: Submit permitted variant Eval-->>Peers: Return structured result summary Peers->>Store: Publish result and finding Note over Peers,Eval: Multiple peers follow this path in parallel PraxistLoop->>Store: Refresh evidence and apply close boundary Store-->>PraxistLoop: Return eligible findings and retention state PraxistLoop->>Panel: Supply committed evidence for synthesis Panel-->>PraxistLoop: Return next research agenda PraxistLoop-->>Peers: Next generation inherits the committed plan

The parallel portion creates search breadth, but it also creates coordination problems. Peers may finish at different times. One may be waiting on an evaluator while another has already published a result. A generation can reach an information-density trigger, a configured time bound, or another close condition while protected work is still draining. The system therefore needs a boundary that is more precise than “the last log line appeared.”

The boundary is a commit, not a timestamp

At close, Praxist takes an evidence snapshot and applies a cutoff to the current generation. It then performs an ordered refresh so that results published at the boundary are not lost merely because materialization happened a moment earlier or later. The boundary collects the available findings, preserves the source relationships, annotates relevant diversity information, and passes the eligible evidence to frontier promotion.

That order prevents two opposite errors. Without a final refresh, a valid result could be excluded because its summary became visible just after the first scan. Without a cutoff, a late file could arrive during retry and rewrite a generation that had already informed later planning. Praxist's compromise is to retain the late output as a visible validation signal while refusing to treat it as if it had been present at the original decision point.

After the evidence is refreshed, the boundary updates the canonical finding and retention state. Depending on the task, that can include the frontier, incubator, optional Gems, research memory, and the finding graph. The graph and memory can improve the context available to later agents, but they do not replace the raw result or the canonical finding. A leaderboard or report can summarize the state, but it is not allowed to override it.

Only after these updates does Praxist ask the planning layer to synthesize the next agenda. A single Principal Investigator can propose the next work; an optional multi-PI topology can ask several planning agents to produce independent views before a Chair consolidates them. In either case, planning reads committed evidence and task constraints. It does not turn an attractive hypothesis into a measured result.

The final acknowledgment is the generation boundary marker. The repository describes gen_N/generation_boundary.json as the completion fact. If a run contains result files, frontier entries, or a partial agenda but lacks a contiguous boundary marker, the generation remains pending boundary work for resume. This rule may feel strict, but it answers a question that timestamps cannot: did the system complete the whole ordered transition from peer output to inherited state?

Why the order matters in a messy run

Consider three peers reaching the end of a generation at different times. One has a complete result, one has a preliminary result, and one is still inside a protected evaluation. If the framework simply promoted whatever it saw first, the first peer's score could determine the next agenda before the cohort had been reconciled. If it waited forever for every process, a crashed or unproductive peer could block the entire run.

The event-driven loop addresses this tension with bounded liveness. Peers can wait for meaningful filesystem or lifecycle events rather than repeatedly resending the same context. A new finding, a lifecycle signal, a resource-supply event, or a heartbeat expiry can change what the peer should do next; an unchanged state does not justify paying for another identical context window. This is particularly important when one peer is productive and another is waiting: the loop can wake the relevant session without turning every sibling update into a broadcast or an uncontrolled polling cycle.

A synthesis trigger can fire when enough findings and contributing peers exist, while a safety cap prevents the generation from running without bound. When closing begins, new experiment admission is frozen, active protected work is allowed to drain, and peers receive a chance to publish final evidence. Work that remains unresolved is preserved and labeled rather than silently treated as a clean success. The result is not perfect synchronization. It is an explicit compromise between waiting for useful work, protecting the historical cutoff, and keeping one stalled process from holding the whole generation hostage.

This is an architectural trade-off, not a promise of perfect synchronization. A cutoff can protect historical consistency while leaving a useful late signal for a later repair. A non-strict planning failure can keep the run alive while producing a weaker or older agenda. A strict policy can stop the run when a valid next plan is indispensable. The task owner decides how much maturity and continuity the research problem requires; Praxist supplies the machinery for recording the outcome.

The generation marker also makes resume more intelligible. On restart, Praxist can count contiguous committed boundaries and distinguish a genuinely completed generation from one whose evidence or planning work was interrupted. It can finish pending boundary work or prepare a later generation from the last known committed state. It does not need to guess from a directory name or assume that a generated report represents a completed scientific transition.

Inheritance is a feedback loop, not automatic self-improvement

When a boundary succeeds, the next agenda gives the following cohort a more informed starting point. It may assign a repair, a comparison, a new mechanism, a validation task, or a deliberate challenge to the current frontier. This is where Praxist's persistent model becomes more than an archive: the output of one generation changes the context in which the next set of hypotheses is chosen.

But inheritance has limits. An agenda is planned work, not evidence. Frontier membership is task-authorized retention, not proof that a candidate generalizes. A finding graph edge is guidance, not a rewritten measurement. The framework preserves these distinctions because otherwise feedback would amplify its own assumptions: a weak early result could become a parent, its descendants could look confirmed, and the final report could hide the original uncertainty.

The same logic explains why a generation can be complete without producing an improvement. The boundary may commit a negative result, a diagnostic finding, or an insufficient-maturity outcome. Those records still shape the next decision by showing what was tried and what it failed to establish. A run that ends with no better score can therefore be informative, provided the evidence is retained with enough provenance to rule out or revisit the tested direction.

The most useful way to read a Praxist run is consequently to ask four questions in order: what did the task authorize, what did each peer actually change, what did the evaluator measure, and what did the boundary make inheritable? That sequence keeps the control plane visible while preserving the task project's ownership of scientific meaning.

The next question is what happens when those outputs differ in authority. A result can be measured but incomplete, a finding can be useful but non-durable, a report can be clear but derived, and a late artifact can be valuable without belonging to the closed generation. Understanding those categories is necessary before judging which evidence should influence exploration or become a parent.

References