Checks
Validators and Handoffs
Read how command evidence becomes completion and handoff evidence.
Open routeAI Research System / Runtime Requirements
Runtime Requirements
Runtime setup does not grant write authority. Python, Node.js, Playwright, and local tools support inspection and validation only inside authorized scope.
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 depends on reproducible local tools, but a tool being installed answers only whether an operation can run, not whether anyone is authorized to run it.
This Runtime Requirements page maps those operating conditions from the simplest to the most specialized: Git, a shell, an editor, and a browser support read-only inspection; the Codex app, repository skills, and tracked control records support governed work; a Python virtual environment, declared dependencies, scripts, and tests support validators and memory tooling; Node.js, npm, Astro, and Playwright support static builds and browser review; local retrieval layers support navigation; and TeX or PDF tooling is used only when registered derivatives are explicitly in scope.
Before any command changes project state, the operator must inspect the tracked source, current task and job, role or skill contract, write-path allowlist, claim boundary, and applicable human gates. After a command runs, its result remains limited to the named surface it checked: `npm run build` compiles the website routes but does not deploy them or establish scientific correctness; implementation-control validation checks record structure but not source authority; Python tests provide evidence about tested behavior but not untested behavior or physics; and screenshots show rendered layout rather than truth.
Missing or failing runtime support becomes a bounded maintenance signal, not a scientific verdict. Memory indexes, Obsidian mirrors, SQLite databases, and `.local` caches may guide inspection, but tracked files and registries remain authority. No installed runtime, dependency, skill, script, Makefile target, validator PASS, screenshot, cache, AI output, or website page independently proves a physics claim, completes the open first-principles derivation, promotes the proposed ontology or a benchmark, grants role or source-edit authority, bypasses an AgentJob allowlist, deploys the site, refreshes sources, or authorizes an upstream mutation.
Static diagram
Keep tool capability separate from authorization.
The technical tiers diagram shows Node, Python, validators, browser checks, build tools, and the boundary that tool availability does not grant permission.
Runtime tiers
Tools are grouped by what they can safely support.
The runtime page is a map of capability, not an instruction to widen scope. Each tier needs its own authority context before it changes files.
| Tier | Tools | Safe scope |
|---|---|---|
| Read and inspect | Git, editor, shell, browser, and tracked source files. | Inspect repository state, source text, diffs, and rendered pages without changing authority. |
| Governed workflow | Codex app context, repo-local skills, prompts, task records, allowlists, completions, and handoffs. | Execute bounded packets only when live records authorize the work. |
| Validator and memory | Python `.venv`, Python tests, requirements files, PyMuPDF where PDF text extraction is in scope, and memory scripts. | Validate behavior, inspect memory state, and produce operational evidence. |
| Web and browser QA | Node.js, npm, Astro, Mermaid-related site dependencies where present, and Playwright. | Build static pages, check links and policies, and inspect desktop/mobile rendering. |
| Optional local retrieval | Obsidian reader, semantic extracts, SQLite indexes, and `.local/` retrieval caches. | Support lookup and local inspection only; not citation authority. |
| LaTeX and PDF | TeX/PDF tooling only when derivative generation or PDF QA is explicitly in scope. | Produce or inspect derivatives while registered sources remain authority. |
Command scope
Every command needs a validates and does-not-validate field.
Command references should teach interpretation. A command can pass and still leave authority, proof, deployment, or acceptance undecided.
| Command | Validates | Does not validate |
|---|---|---|
| npm run build | Astro static build and route compilation for the website state under test. | Scientific correctness, source promotion, owner acceptance, or deployment. |
| npm run validate:svg | Website SVG artwork policy, including animation and no visible embedded SVG text. | The accuracy of nearby scientific or operational claims. |
| npm run validate:implementation-control | Structural consistency of implementation-control records. | Source authority, deployment approval, or upstream write permission. |
| .venv/bin/python -m pytest | Python tests for the checked test suite. | Physics proof, benchmark promotion, or untested workflow behavior. |
Permission boundary
Availability is not authorization.
This is the central runtime discipline: an operator can have tools installed and still lack authority to use them for a mutating packet.
| Capability | Unsafe inference | Safe interpretation |
|---|---|---|
| Installed runtime | Runtime setup authorizes a packet. | Runtime setup does not grant write authority. Live task and job records decide scope. |
| Passing validators | Green checks prove the claim. | A check says only that the named validator accepted its checked surface. |
| Browser screenshot | Visual QA makes page copy authoritative. | Screenshots show rendered behavior; they do not prove physics or workflow claims. |
| Local cache access | A cache hit can be cited. | Local retrieval can guide inspection, but tracked sources and registries remain authority. |
Source basis
The source basis defines what the tools mean.
This page summarizes stable command families and runtime tiers without copying script internals or changing dependency policy.
| Source area | Used here for | Authority boundary |
|---|---|---|
| Tooling and runtime PRD | Runtime tiers, command-scope structure, and validator-versus-proof requirements. | PRD requirements plan website content; they do not change commands. |
| Package, Makefile, scripts, and tests | Observed website commands, build tooling, validation scripts, and Python test entry points. | Command availability is capability, not permission. |
| Technical requirements dossier | Tool authority tiers, safe and unsafe summaries, and local-cache boundaries. | Dossier content is implementation guidance, not source promotion. |