AI 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.
Runtime evidence does not prove physics, promote source laws, bypass AgentJob allowlists, or authorize upstream writes. Capability and permission are separate facts.
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. |
Related internal routes
Read tools beside the authority model.
Runtime requirements connect to validators, maintenance, memory, workflow, AgentJob boundaries, and resource pages.
Checks
Validators and Handoffs
Read how command evidence becomes completion and handoff evidence.
Open routeImprove
Project-System Improvement
Use runtime failures as bounded maintenance signals, not research verdicts.
Open routeMemory
Memory Preflight
Keep local retrieval tooling below canonical inspection.
Open routeWorkflow
Workflow
Place tools inside the governed state-to-handoff lifecycle.
Open routeAgentJob
AgentJob Lifecycle
Confirm that runtime capability stays inside one authorized job.
Open routeResources
Resources
Use public resources as reader aids while source authority stays explicit.
Open route