Memory
Memory Preflight
Use retrieval drift as a candidate maintenance signal, not source truth.
Open routeAI Research System / Project-System Improvement
Project-System Improvement
Project-system improvement is not research continuation. It is a bounded maintenance loop for the machinery around governed work.
The Æther Flow Project is a two-part research program about foundational physics and the governed, human-accountable AI research system used to organize and test that work. Its physics track asks whether ordinary general relativity can be interpreted, and eventually derived, from a deeper Æther or Æther-Flow foundation; general relativity remains the exact benchmark for observable gravity, while the first-principles substrate derivation is still open.
The AI track keeps research and maintenance separate: research packets investigate physics, while Project-System Improvement repairs the machinery around that work, including documentation, validators, schemas, memory retrieval, routing, trigger logic, and generated-document pipelines, without continuing the science by implication.
The repair loop starts when observable evidence identifies friction through a current working-tree diff, a registered open signal, a repeated workflow problem, or a source-bridged project-improvement sidecar from a qualifying completion. Memory may locate earlier context, but tracked source files and registry rows must be inspected before that context affects action.
A classifier describes the issue as documentation drift, a validator gap, routing ambiguity, a schema problem, or another registered signal type; an advisory resolver ranks the candidate; and the Director routes one bounded AgentJob with an explicit write-path allowlist and claim boundary. When a repair changes project state, a documentation-impact receipt records affected source surfaces, generated derivatives, classifier reason codes, and required validators.
Completion and handoff records preserve the result, while a signal closes only with matching PASS completion evidence or a documented rejection decision. A project-improvement sidecar is a separate maintenance input and never replaces the normal research handoff; a resolver recommendation alone neither authorizes nor blocks checkpointing; and a registered role or descriptive perspective does not activate authority.
This Project-System Improvement page explains that reliability loop for readers, but no diff, classifier, resolver, sidecar, signal, registry row, documentation-impact receipt, validator PASS, completion, handoff, commit, AI output, or webpage independently proves a physics claim, completes the open first-principles derivation, promotes the proposed ontology or a benchmark, grants role authority, expands an allowlist, or authorizes research continuation.
Static diagram
Read project-system improvement as a bounded repair loop.
The improvement diagram shows signal, classification, sidecar input, one AgentJob, evidence receipts, and close/defer/reject outcomes.
Bounded repair loop
Signals become one scoped maintenance packet.
The improvement loop is useful because it treats friction as evidence, classifies it, and repairs one concrete surface with explicit closeout.
| Input | Classification | Allowed output |
|---|---|---|
| Observed diff or repeated workflow problem | Classify the issue as documentation drift, validator gap, routing ambiguity, schema problem, or tooling reliability signal. | A bounded project-system candidate, not a physics continuation. |
| Registered signal | Check signal type, severity, evidence, current status, and required closure receipt. | One repair route with explicit close, defer, or reject evidence. |
| Source-bridged sidecar | Use exact-path source evidence as support context for the proposed maintenance action. | A scoped input; never a global allowlist or replacement handoff. |
| Resolver recommendation | Rank the next repair using current state, open signals, and allowed project-system scope. | Advisory routing below validators, allowlists, and live control records. |
Review evidence
Maintenance evidence has a narrow claim.
The closeout should say exactly what was repaired, what was checked, and what remains outside the packet.
| Artifact | What it supports | What it does not support |
|---|---|---|
| One bounded repair | A specific project-system issue was addressed inside an allowed packet. | The repair does not promote physics claims or continue research by implication. |
| Documentation-impact receipt | State-changing documentation or control-surface effects were recorded for audit. | The receipt is not owner acceptance, Gate Chair approval, or source adoption. |
| Validator PASS | The named check accepted the checked maintenance state. | PASS is not a theorem check, scientific verdict, or global workflow guarantee. |
| Signal closure | A signal was closed, deferred, or rejected with explicit evidence. | Signals do not disappear by assertion or because a page says they are fixed. |
Blocked overreads
Repair work must not become hidden authority.
The safest maintenance system names the conclusions it cannot draw.
| Overread | Correction |
|---|---|
| Project-system improvement is not research continuation. | It repairs the machinery around research control; a separate live research packet is needed for research work. |
| A sidecar replaces the normal handoff. | A sidecar can inform routing only inside its exact source-bridged scope. |
| Resolver output alone blocks or authorizes checkpointing. | Resolver output is advisory unless a validator, allowlist, source authority, or live record creates the gate. |
| A maintenance packet can quietly alter source claims. | Project-system repair does not promote physics claims, role authority, or Gate Chair decisions. |
Source basis
The source basis defines the maintenance lane.
This page explains project-system repair from dossiers, PRDs, script documentation, and workflow boundaries without changing the source project.
| Source area | Used here for | Authority boundary |
|---|---|---|
| Project-system improvement dossier | Signal, classifier, resolver, sidecar, one-job repair, and documentation-impact framing. | Dossier summaries do not close signals without matching evidence. |
| Project-control script documentation | Classifier, resolver, signal collection, sidecar validation, and documentation-impact validation roles. | Tooling supports maintenance routing; it cannot mutate research claims by itself. |
| Workflow and runtime requirements | One-packet execution, validators, completion, handoff, and checkpoint interpretation. | Operational evidence stays below source authority and human gates. |