The problem this decision solves
Most "AI for research" demos show a single prompt and a single answer. A PhD researcher's actual workflow is a loop: find context, propose a hypothesis, derive something, check it numerically, get it critiqued, and write it up. At almost every stage, the researcher already has a strong prior about what a correct answer looks like. The interesting question isn't "can a model produce an answer," it's "where in this loop does a second opinion, or a numerical check, or an explicit critique actually change what gets published."
The research lifecycle assistant PoC tests that shape end to end on one illustrative problem (the ground-state energy shift of a quantum harmonic oscillator under a quartic anharmonic perturbation) using entirely fabricated literature, model answers, and simulation results.
Six stages, one thread
Literature & context
Retrieve prior work relevant to the question, each entry tagged by why it matters: foundational theory, the method being applied, numerical precedent, or an applied context worth citing in the motivation.
Hypothesis & derivation
State a testable hypothesis, then walk a step-by-step symbolic derivation the researcher can check line by line rather than accept as a black box.
Model comparison
Send the same question to several models and show the answers side by side, including where they disagree on how much of the derivation to show unprompted.
Simulation
Check the closed-form estimate against a numerical experiment, and report the two side by side instead of asking the researcher to trust either one alone.
Peer review
A reviewer pass that specifically hunts for unstated assumptions: degeneracy, validity range, basis truncation, unit conventions, the exact kind of gap a real reviewer would flag.
Write-up & export
Assemble the accepted findings and the stage-one citations into a draft section, ready to paste into a paper draft.
What the mock deliberately fakes
Every literature entry, model answer, derivation step, and simulation number in the demo is a hand-written constant. There is no retrieval index, no API call to any model provider, and no numerical solver running anywhere. That's intentional: it lets the six-stage shape, the comparison UI, and the write-up assembly get tested and refined before committing to a specific vector store, a specific set of model API contracts, or a specific numerical backend. The model names are real because a researcher's actual choice is between real models with real behavioral differences; every response shown is illustrative rather than a benchmark result.
Path to a real implementation
Turning the mock into a running system means replacing each stage's fabricated data with a real service, without changing the six-stage shape the mock already validated. The target environment is a local kind (Kubernetes-in-Docker) cluster: small enough to iterate on a laptop, structured enough that the same manifests port to a managed cluster later.
Options considered per stage
| Stage | Lightweight option | Fuller option | Primary tradeoff |
|---|---|---|---|
| Literature & context | Static/curated corpus, keyword search | Vector DB (Qdrant or pgvector) over arXiv + Semantic Scholar ingestion | Ingestion pipeline complexity vs. retrieval quality |
| Model comparison | Single gateway service fanning out to provider APIs sequentially | Per-model adapter services behind a shared gateway, called in parallel | Operational surface area vs. latency and independent rate-limit handling |
| Simulation | Synchronous compute in the request path | Kubernetes Jobs (or a queue such as Redis/RabbitMQ) for longer-running numerics | Simplicity vs. not blocking the UI on a multi-minute solve |
| Peer review | A second pass of the same model with a critique-specific prompt | A distinct model/config dedicated to critique, run after the primary derivation | Cost and latency vs. genuinely independent critique |
| Write-up & export | Template assembly of prior-stage outputs | A dedicated drafting pass that can revise for coherence across stages | Predictability vs. polish |
Recommended first architecture on kind
Start with a single API gateway rather than per-model adapter services: the mock's model-comparison stage only needs a shared request/response shape until a specific provider's quirks (rate limits, streaming behavior) force independent deployability. Kubernetes Jobs are enough for the simulation stage before a queue is justified; a queue earns its keep once simulations run long enough, or often enough, that the API gateway can't wait on them synchronously.
Production checklist
- Replace one stage at a time behind the same UI contract the mock already defines: the six-stage shape shouldn't change as the backend gets real.
- Keep provider API keys in Kubernetes Secrets, never in application config or environment defaults checked into the repo.
- Log every model call's provider, model version, and latency: the model-comparison stage is only trustworthy if it's reproducible after the fact.
- Cap simulation job runtime and resource requests explicitly; an unbounded numerical job on a shared local cluster starves everything else.
- Version the retrieval corpus's ingestion date alongside any citation it returns: a literature answer is only as current as its last ingest.
- Treat the peer-review stage's output as a checklist for a human reviewer to work through, rather than an automatic pass/fail gate.
- Validate the full local
kinddeployment against the exact mock walkthrough before adding a second environment.