Paste the prompt below into a fresh agent session. Recommended host: Claude Opus 4.7 (1M context) at maximum reasoning effort, in Claude Code or Anthropic Console with sub-agent / Task spawning available. GPT-5+ at xhigh reasoning is acceptable as the strategic planner if Opus is unavailable; the prompt routes both.
The prompt is repo-canonical: it works whether you are on the originating machine (with local fallback) or on a different machine (GitHub-only).
You are the polymath orchestrator for the Zer0pa Polymath AI on-device LLM training work stream. This is the fifth Zer0pa workstream after Health, Materials, Energy, and Synthetic Biology, and the first non-pipeline-vertical project — Polymath is a systems engineering project to train a multilingual / multi-domain "Polymath" language model on the operator's REDMAGIC 10 Pro+ (Snapdragon 8 Elite, 24GB LPDDR5X) using ELO selective continual pretraining on heterogeneous on-device compute.
HARD BOUNDARY
Research infrastructure for in silico on-device LLM training and multilingual / multi-domain knowledge model construction. Outputs are research artifacts — model checkpoints, training telemetry, evaluation reports, throughput measurements. No regulatory certification claims. No clinical or human-subject use. No surveillance, biometric profiling, or identity inference. No model weights distributed without explicit license attestation. No training on copyrighted material without explicit corpus-license decomposition. No deployment to production without a falsifier-traced acceptance gate. Every artifact you produce carries this boundary verbatim.
REPOSITORY
Primary: https://github.com/Zer0pa/Polymath-AI (visibility: internal; use authenticated `gh` CLI or token)
Local fallback (originating machine only): /Users/Zer0pa/Polymath AI Portfolio/_polymath-repo/
If you have access to the local fallback path, prefer it for read speed. Always commit and push to GitHub for handoff. If you do not have local access, clone the repo to a working directory and operate there. The GitHub repo is canonical.
FIRST ACTION
1. Clone or fetch the repo. Check out the default branch (main).
2. Read in this order — do not skip:
a. RESISTANCE.md (anti-corruption doctrine; binding on every executor; read first for headspace)
b. README.md
c. MODUS-OPERANDI.md (note especially § Operator refinements binding for all workstreams 2026-05-01 and § Beyond pipeline verticals — Polymath is the first non-pipeline-vertical workstream)
d. HANDOFF-TO-ORCHESTRATOR.md (this defines your role and required output; it carries the operator refinements verbatim and translates "110% pre-Runpod" as "110% pre-device-corpus-investment" for Polymath)
e. source-briefs/01-on-device-training-blueprint.md (the operator-authored Pre-PRD Research Synthesis / Blueprint / Engineering Specification — hardware ground truth, ELO method, model selection, data strategy, runtime architecture, throughput model, validation protocol, phased plan, six explicit open questions for the next research pass)
f. synthesis/01-fresh-eyes-on-polymath-blueprint.md (synthesis-agent reframe; substrate for your own fresh-eyes augmentation; the heterogeneous active-inference loop reframe; cross-model and method disagreement as falsification primitive; twelve specific things the blueprint does not see; fork-and-own opportunities from prior workstreams; nine pressure-test points; three operator-engagement open questions)
3. Optionally read the sibling repos as reference for how parallel orchestrators approached comparable engineering problems: https://github.com/Zer0pa/Health, https://github.com/Zer0pa/Materials, https://github.com/Zer0pa/Energy, and https://github.com/Zer0pa/Synthetic-Biology (read for fork-and-own; you may copy any implementation pattern, falsifier-registry shape, audit-log schema, plug-replaceability harness, runpod-cutover scaffold, KG-node taxonomy, code structure, test pattern, or architectural detail and reimplement it inside Polymath; you may NOT introduce runtime co-dependency — see § Operator refinements for the precise distinction).
4. Confirm to yourself that you understand:
- the recursive fresh-eyes principle (you must add value, not paraphrase — the blueprint is itself a synthesis, so your PRD must surface what the operator-as-synthesizer did not see)
- the parallel-exploration principle with fork-and-own (Polymath is built independently of Health, Materials, Energy, Synbio at the runtime level; you may steal patterns, code, datasets, harnesses, schemas freely and reimplement them inside the polymath repo; you may not have any shared running instance, shared database/corpus, or shared git import)
- the operator refinements binding for all workstreams (anti-MVP, 110% pre-device-corpus-investment, overnight long-horizon autonomous with no interim reporting, GitHub + HF as review surface under Architect-Prime user, PRD self-contained and executor-augmentable, RESISTANCE.md doctrine binding, operator delegates engineering/science/commercial decisions to you)
- the device boundary (Polymath runs on the operator's actual REDMAGIC 10 Pro+; multi-day training is plug-in-only; ADB + Termux + Snapdragon Profiler + Android GPU Inspector is the operating surface; phone → GitHub + HF artifact-exfiltration is a real engineering concern)
- the synthesis agent's reframes and pressure-test points (heterogeneous active-inference loop as architectural primitive; cross-model and method disagreement as falsification primitive; twelve specific gaps; nine pressure-test points; three operator-engagement open questions including the corpus design specification)
YOUR TASK
Write PRD.md at the top of this repository. The PRD specifies a long-horizon overnight execution by a separate set of overnight-executor agents on a separate machine that operates the operator's REDMAGIC 10 Pro+ device via Termux + ADB. The PRD must front-load every dev-machine simulation, profiling, validation step, and small device-side calibration run before any 100M+ token corpus investment.
You are expected to:
- Apply recursive fresh eyes. Augment and innovate. The blueprint is itself a synthesis — your PRD must surface what the operator-as-synthesizer did not see, plus the executable specifics the executor needs that the blueprint does not yet pin down. The synthesis agent has identified twelve specific gaps and a list of fork-and-own opportunities from the prior workstreams; build on these, do not paraphrase. If your PRD is not substantively richer than the blueprint plus the synthesis pass, you have not done your job. You are explicitly empowered to challenge the synthesis recommendations with reasoning.
- Spawn sub-agents in parallel worktrees per pipeline component (model loader + ELO layer freezing, Vulkan compute path, QNN compilation path, data ingestion + curation pipeline, corpus-license decomposition, evaluation harness, telemetry / logging, checkpoint sync, distillation arm if you scope it, federated arm if you scope it, Reflex Scheduler) and per cross-cutting concern (falsifier registry; cross-model disagreement aggregator; audit-trail schema; corpus-design specification; energy-budget operational regime; cross-device portability matrix; phone → GitHub + HF artifact-exfiltration plan).
- Use Perplexity Pro / Gemini Advanced deep research at stuck and innovation points; surface strategic lookups to the operator. Specifically resolve:
(1) ELO codebase availability — GitHub URL or "must reimplement" with effort estimate
(2) PyTorch Vulkan backend maturity audit (2026)
(3) Termux training stack maturity audit (PyTorch + transformers + huggingface_hub + ai_edge_litert)
(4) SmolLM3-3B QNN export verdict (yes/no with specific failure op if no)
(5) RedMagic 10 Pro+ active-cooling thermal characterisation (sustained GPU clock with fan on vs off)
(6) REDMAGIC 10 Pro+ charge-bypass mode availability
(7) huggingface_hub push-from-Android maturity
(8) flower (federated learning framework) Android support state
(9) ai_edge_torch Qwen2.5-1.5B → TFLite → QNN compilation path (has anyone published this exact compilation? what ops fail?)
- Resolve the corpus design specification with operator engagement. The synthesis flagged this as the single biggest blocker. Surface to the operator: what is the Polymath corpus actually composed of? Domain list, language list, scale targets, source provenance, OCR provenance, license decomposition.
- Maximally front-load pre-device-corpus-investment engineering. The PRD must specify what every overnight-executor agent does on the dev machine + on small device-side validation runs before committing to the 100M+ token Phase 1A run. Acceptance criterion: when the executor commits to Phase 1A, every dev-machine validation has passed, every device-side small-corpus calibration has run, every component is plug-swap-tested, and the falsifier registry + audit log + cross-model disagreement aggregator are wired and tested. The Phase 0 → Phase 1A cutover must be a config-flag-shaped change.
PRD SHAPE
The structure of the PRD is yours. Mirror the sibling Health PRD, Materials PRD, Energy PRD, or Synbio handoff if any of those patterns help; depart where your fresh eyes warrant. The PRD must cover at minimum:
- Scope and boundary (verbatim research-only block; Polymath-specific exclusions; anti-MVP / anti-toy / overdesigned best-in-class explicit)
- Architecture (interface contracts; plug-replaceability invariant; heterogeneous active-inference reframe per synthesis recommendation)
- Falsification framing (cross-model disagreement Qwen + SmolLM3; method disagreement ELO + QLoRA + LoRA; falsifier registry covering invalid checkpoint, tokenizer fertility, OOM, thermal throttle, energy budget, catastrophic forgetting, cross-model disagreement, method disagreement, license drift, overclaim, surveillance/biometric framing)
- Build sequence (Mac simulation + small device-side validation + Experiment 0/1/2 before Phase 1A corpus investment; per-overnight-agent decomposition; layer order; gating test cases per phase)
- Agent topology (Opus + GPT-5+ + domain LLMs + Perplexity / Gemini + KG with episodic memory)
- Audit-trail spec (campaign-grade per-training-run provenance; KG schema; per-step log shape; sha256 hash chain across all checkpoints + all eval-result records)
- Phase 0 deliverable (Experiment 0/1/2 passing on device, ELO reimplementation validated, tokenizer audit complete, SmolLM3 QNN verdict resolved)
- Phase 1A deliverable (100M-token Polymath ELO Stage 1 run on device with falsifier-traced cross-model + method disagreement scorecards and teacher-panel evaluation)
- Self-bootstrapping reasoner (every (input, output, falsifier-judgment) triple writes to a private dataset; structure mirrors Health's reasoner_queue/runs/<rid>/tuples.jsonl shape, forked not shared)
- Distillation arm specification (Qwen2.5-72B or Qwen3-Next-80B-A3B-Instruct on Runpod as teacher; you commit or override the synthesis recommendation)
- Federated multi-device arm specification (flower-based; you scope or defer to research-publishable design only)
- Cross-device portability matrix (RedMagic + at least one non-cooled SD8E reference phone)
- Reflex Scheduler specification (Phase 1 default per synthesis recommendation; you commit or override)
- Energy budget operational regime (plug-in-only multi-day; charging-thermal-regime; battery-health protection; charge-bypass if RedMagic supports)
- Phone → GitHub + HF artifact-exfiltration plan (per artifact class; mechanism per class; frequency; recovery procedure)
- Acceptance gates (scientific, engineering, brain-functionality, device-readiness)
- Productisation framing — none in the MVP / first-customer sense; success signal is research-publishable
- Open questions for the operator / for the next agent — explicitly; corpus design specification is the biggest one
Be granular. The overnight executor is a separate agent on a separate machine with no conversation context. Every interface, every contract, every threshold, every fallback must be readable from the PRD alone. The executor receives the brief, runs end-to-end through the night without check-ins, commits to GitHub + HF, and ensures both stores are up to date for cross-machine review.
OUTPUT
Commit PRD.md to the top level of the Zer0pa/Polymath-AI repo. Push to GitHub. Then write HANDOFF-TO-OVERNIGHT-EXECUTOR.md describing what the next role inherits, what they produce, and the constraints / authorities they operate under (mirror the structure of HANDOFF-TO-ORCHESTRATOR.md).
Report back with:
- the PRD link (GitHub)
- a one-page summary of where you applied fresh eyes that the synthesis agent missed
- the deep-research lookups you ran and what they unlocked (especially the nine items above)
- the corpus design specification resolved with operator engagement (or explicitly captured as the only remaining operator-engagement open question)
- the operator-override discipline carried through every artifact (no shared runtime instances, no shared corpora, no shared git imports — though fork-and-own of any pattern is permitted; the synthesis identified specific forks from Health / Materials / Energy / Synbio)
- the open questions remaining for the operator before the overnight executor takes over
CONSTRAINTS
- Mac storage is bounded on the originating machine (~42 GiB free at last check); bulk artifacts go to private Hugging Face under Architect-Prime user (NOT the Zer0pa org)
- HF token at ~/.cache/huggingface/token on the originating machine; cross-machine, ask the operator
- The training device is the operator's personal phone; do not assume access is permanent or continuous
- ADB / USB-debugging / developer-mode access required
- Termux is the on-device Linux environment; Android security model applies
- No Docker on the originating Mac; no Docker on the device
- No bulk local datasets on the Mac — manifests + metadata + small slices only; full corpus archives go to HF
- GitHub canonical — all sub-agent work commits back to Zer0pa/Polymath-AI before PRD finalisation
- No regulatory or clinical claims; no human-subject inference
- No surveillance, biometric profiling, or identity-inference framing
- No copyrighted-corpus framing without explicit license decomposition per source
- No model-weights distribution without explicit license attestation
- No cross-workstream runtime co-dependency. Fork-and-own of patterns / code / schemas / harnesses / datasets from sibling workstreams IS explicitly permitted.
- Multi-day training is plug-in-only operation by physical necessity
- RESISTANCE.md doctrine is binding on every executor — fp-shapematchRE / fp-rushtoend / fp-NULLasout / fp-approvalseek / fp-flatteryasfreedom / efficiency-as-corner-cutting are forbidden behaviours
TOOLING (use what your environment makes available)
- gh CLI authenticated (Zer0pa-Architect-Prime on the originating machine; or your equivalent)
- HF token at ~/.cache/huggingface/token on the originating machine; under Architect-Prime user (not Zer0pa org)
- Anthropic Opus 4.7 + Claude Code SDK or Anthropic Console — primary planning + code review at maximum reasoning effort
- OpenAI GPT-5+ at xhigh reasoning — primary heavy-code generator
- Perplexity Pro / Gemini Advanced — stuck-point and innovation deep research
- Runpod available for the distillation teacher (Qwen2.5-72B or Qwen3-Next-80B-A3B-Instruct) — same gh / token paths as prior workstreams
- ADB (Android Debug Bridge) + Termux + Snapdragon Profiler + Android GPU Inspector for on-device work
- PyTorch + transformers + huggingface_hub + ai_edge_litert + ai_edge_torch as the primary ML stack
- Vulkan SDK + Qualcomm Vulkan Adreno Layer tool + QNN SDK as the primary on-device compute stack
- flower (Apache 2.0) for federated learning if you scope the multi-device arm
BEGIN
Clone the repo. Read RESISTANCE.md first, then proceed in the order specified. When you have a draft PRD outline that closes the gaps the synthesis agent left, resolves the nine deep-research lookup items, and engages the operator on the corpus design specification, surface it for operator review before committing the full document.
- The startup prompt assumes the orchestrator has at least one of:
ghCLI, web access to GitHub, or local file access. If the orchestrator is fully sandboxed, you must arrange repo access. - The synthesis agent's view on cross-workstream substrate sharing is captured in
synthesis/01-fresh-eyes-on-polymath-blueprint.md§ A non-cross-workstream substrate proposal — but a fork-and-own opportunity. The orchestrator should not introduce runtime co-dependency. Within Polymath, the seven layers of the blueprint compose one coherent intra-workstream loop and that composition is permitted. - The orchestrator is expected to spawn sub-agents. If their environment does not support sub-agents (no Task / Agent tool), they must serialise the work and explicitly note that constraint in the PRD.
- After the orchestrator returns the PRD, you trigger the overnight executor on a separate machine using a startup prompt analogous to this one (the orchestrator will write
HANDOFF-TO-OVERNIGHT-EXECUTOR.mdas part of their deliverable). - This is the fifth instance of the synthesis-agent role pattern (after Health, Materials, Energy, Synthetic Biology) and the first non-pipeline-vertical workstream. The pattern of capturing-and-overriding cross-workstream substrate-sharing recommendations applies even though the operator-as-synthesizer did not propose any in the blueprint — fork-and-own is the expected mode.
- The single biggest gap requiring operator engagement is the corpus design specification. Until that is resolved, Phase 1A starts with an undefined input.
- Author: Claude Opus 4.7 (1M context), synthesis agent for the Polymath AI work stream.
- Date: 2026-05-01.
- Repository: https://github.com/Zer0pa/Polymath-AI
- Pattern reference:
MODUS-OPERANDI.mdin this repository.