UnifiedFlow Data Center Platform for Scientific Execution
UnifiedFlow (UF) is the platform layer for turning our data-center capacity into governed scientific and engineering work. It is meant to coordinate machines, storage, models, evidence, review, and publication as one operating system: work should be schedulable, observable, repeatable, auditable, and promotable without losing the boundary between raw data, generated artifacts, model judgment, and human interpretation.
The operating promise is that a domain can enter UnifiedFlow with explicit source boundaries, workflow stages, compute requirements, evidence obligations, model-review rules, and publication paths. Neuroscience is the first domain entering that pattern, and calcium imaging is the first concrete emphasis because it exercises the whole platform: large source movies, GPU-backed processing, reviewable biological candidates, reusable model profiles, downstream figures, and strict claim boundaries. The same contract should support future domains without rebuilding the platform around any single workflow.
Platform Purpose
UnifiedFlow exists to make larger applications of our data center legible. A successful platform should let us ask for work, assign it to appropriate capacity, track what happened, preserve the artifacts that matter, understand how model and human review changed the outcome, and publish the resulting knowledge into Labs without flattening everything into a static article.
The platform should support several kinds of work at once: scientific processing, model training, architecture studies, operational runbooks, evidence review, figure generation, and long-lived research notes. The common requirement is continuity. A run should not disappear after a terminal closes. A model profile should not be a private memory. A figure should be traceable to evidence. A conclusion should carry its claim tier.
| Objective | What UnifiedFlow Should Provide |
|---|---|
| Domain onboarding | New scientific and engineering domains can enter through explicit source boundaries, workflows, evidence models, and review rules |
| Governed capacity | Machines become usable through admission evidence, capability profiles, heartbeats, leases, and retirement states |
| Durable execution | Jobs have envelopes, declared inputs, bounded runtime policy, artifact expectations, retries, and stage histories |
| Data custody | Source data, scratch, output, archive, object storage, and portable model memory remain distinct surfaces |
| Model memory | Weights, profiles, critic reports, rejected examples, and calibration artifacts can improve future work without becoming unsupported claims |
| Evidence promotion | Outputs move from candidate evidence to reviewed artifacts to Labs only when claim tier, provenance, and review state are explicit |
| Human and agent continuity | Codex, operators, reviewers, and future readers can continue work because the platform preserves context and decisions |
Domain Entry Model
A domain enters UnifiedFlow by declaring the work it needs the platform to preserve. That declaration should happen before the platform treats the domain as routine capacity.
| Domain Element | Platform Question | First Neuroscience/Calcium-Imaging Shape | Continuation Lab |
|---|---|---|---|
| Program boundary | What scientific or engineering program is entering the platform? | Neuroscience enters first, with calcium imaging as the initial workflow family | Domain onboarding and scientific programs |
| Source boundary | What data is read, where does it live, and who owns it? | Lab-owned imaging source data remains distinct from UnifiedFlow outputs and portable memory | Source boundaries and data custody |
| Workflow boundary | What stages transform source data into reviewable artifacts? | Calcium processing includes motion, postmotion, candidate ROIs, traces, event qualification, figures, and review gates | Full-source rerun readiness |
| Compute boundary | What capacity is required and how is it admitted? | GPU-backed workers need identity, capabilities, heartbeat, telemetry, and lease eligibility | Worker admission and capability routing |
| Model boundary | What model outputs are reusable, and what claims remain blocked? | Profiles, critic reports, rejected examples, and weights can be reused while biological claims remain review-bound | Portable IP and model memory |
| Review boundary | Who or what can promote evidence? | Model Plane critics can advise or block inside defined claim tiers; human review still governs scientific interpretation | Model Plane scientific critics |
| Publication boundary | What becomes durable knowledge? | Evidence, figures, decisions, and unresolved questions graduate into Labs with provenance and review state | Knowledge promotion and Labs continuation |
Core Platform Systems
UnifiedFlow should be understood as a set of systems with separate responsibilities. The separation matters because domains will change, workers will change, and model capabilities will change; the platform contract should remain legible.
| System | Responsibility | Subsystems | Primary Output |
|---|---|---|---|
| Program and domain system | Defines what domain work exists and what rigor it requires | domain profiles, workflow families, claim tiers, review roles | domain onboarding record |
| Control and governance system | Owns authority, policy, state transitions, and promotion rules | control plane, authZ, promotion gates, run state | authorized transition |
| Work graph system | Turns requests into durable graph-shaped work | jobs, stages, dependencies, leases, retries, reconciliation | executable work graph |
| Worker and capability system | Decides which capacity can execute which work | node admission, heartbeat, capability profiles, scheduling | trusted worker assignment |
| Execution envelope system | Carries bounded execution context to workers | inputs, params, runtime policy, expected outputs, artifact policy | validated execution envelope |
| Data custody system | Separates source, scratch, output, archive, and portable memory | source refs, scratch policy, output manifests, provenance | governed artifact lineage |
| Model and critic system | Routes model calls and critic authority through explicit profiles | model profiles, critic schemas, adjudicators, evaluations | bounded model judgment |
| Knowledge and Labs system | Promotes evidence into durable research surfaces | evidence graph, figures, Labs pages, review queues | reviewable knowledge artifact |
Platform Navigation
Use the platform by choosing the decision you need to make. Each path below opens a subsystem lab that should accumulate its own evidence, figures, failure modes, operating procedures, and promotion criteria.
| Decision | Open | What The Lab Should Help Decide |
|---|---|---|
| Which domain enters next? | Domain onboarding and scientific programs | Whether a domain has source boundaries, workflows, evidence obligations, review roles, and claim tiers defined enough to enter UnifiedFlow |
| Which machines can take work? | Worker admission and capability routing | Whether compute capacity is approved, heartbeating, advertising the right capabilities, and safe to lease |
| Is a run healthy right now? | Remote-run telemetry and health evidence | Whether telemetry, canary state, resource pressure, and stage history support continue, pause, retry, or investigate |
| Can work touch this data? | Source boundaries and data custody | Whether source, scratch, output, archive, and portable memory boundaries preserve custody and provenance |
| What should the platform learn? | Portable IP and model memory | Which weights, profiles, examples, calibration artifacts, and critic outputs should persist across runs |
| Is evidence ready to rerun at scale? | Full-source rerun readiness | Whether exploratory artifacts have enough source coverage, critic agreement, and figure readiness for production reruns |
| Which model judgments count? | Model Plane scientific critics | Which critics can advise, block, or promote, and what claims each critic is allowed to touch |
| What becomes durable knowledge? | Knowledge promotion and Labs continuation | Which evidence, figures, decisions, and unresolved questions should graduate into Labs |
The order matters. Domain onboarding defines what kind of work exists. Worker admission supplies trusted capacity. Data custody defines where work may operate. Telemetry explains what happened. Portable memory preserves reusable learning. Critics and readiness gates decide what can advance. Labs promotion turns the result into shared knowledge.
Continuation Queue
The same paths are queued as first-class labs so each subsystem can mature separately instead of bloating this overview.
| Queued Lab | Subsystem | Continuation Work |
|---|---|---|
| Worker admission and capability routing | Data-center capacity | Define worker states, admission evidence, advertised capabilities, leases, and drain/quarantine behavior |
| Remote-run telemetry and health evidence | Observability | Define telemetry schema, sampling cadence, canary state, stage health, and run-level charts |
| Source boundaries and data custody | Data governance | Separate source, scratch, output, archive, object references, and source-duration truth |
| Portable IP and model memory | Reusable learning | Define weights, profiles, calibration artifacts, critic datasets, rejected examples, and portability rules |
| Full-source rerun readiness | Scientific eligibility | Replace fixed-duration assumptions with metadata-confirmed full-source coverage and critic agreement |
| Model Plane scientific critics | Evaluation authority | Specify profile, neuroscience, condition, event, and figure-readiness critics as bounded authorities |
| Knowledge promotion and Labs continuation | Research memory | Define how active system knowledge becomes durable Labs material with figures and review states |
| Domain onboarding and scientific programs | Program expansion | Define how neuroscience/calcium imaging becomes the first domain path without constraining future domains |
First Domain Pressure: Neuroscience Calcium Imaging
The first scientific domain entering UnifiedFlow is neuroscience, with calcium imaging as the initial workflow family. That domain is useful as pressure because it forces the platform to coordinate large source movies, GPU-heavy processing, candidate biological signals, model-assisted review, and durable figure-ready evidence.
| Domain Pressure | Platform System Exercised | What It Teaches UnifiedFlow | Continuation Lab |
|---|---|---|---|
| Source movie scale | Data custody system | Source duration, read posture, output lineage, and full-coverage eligibility must be explicit before reruns become scientific evidence | Source boundaries and data custody |
| GPU-side processing | Worker and capability system | Compute should be admitted by identity, heartbeat, capability, storage visibility, and lease policy | Worker admission and capability routing |
| Remote run visibility | Execution telemetry system | Resource samples, canary state, stage progress, retry history, and failure reasons become part of the run record | Remote-run telemetry and health evidence |
| Candidate ROI and event outputs | Scientific readiness system | Candidate artifacts need claim tiers, review state, condition awareness, and figure gates before promotion | Full-source rerun readiness |
| Reusable model artifacts | Portable IP and model memory system | Weights, profiles, calibration outputs, rejected examples, and critic reports should persist without moving raw source ownership | Portable IP and model memory |
| Model-assisted review | Model and critic system | Critics need schemas, activation rules, allowed claim tiers, and disagreement handling | Model Plane scientific critics |
| Durable explanation | Knowledge and Labs system | Evidence should become inspectable studies with figures, decisions, unresolved questions, and branch links | Knowledge promotion and Labs continuation |
System And Subsystem Contract
UnifiedFlow is the platform contract that lets scientific domains enter a governed execution environment. Each system owns a different class of responsibility, and each system should expose enough state for Codex, operators, reviewers, and future domain teams to understand what happened.
| System | Owns | Receives From | Emits | Continuation Lab |
|---|---|---|---|---|
| Program and domain system | Domain profiles, workflow families, claim tiers, review roles | Scientific program intent, first-domain requirements, lab constraints | Domain onboarding record and platform vocabulary | Domain onboarding and scientific programs |
| Control and governance system | Authority, policy, state transitions, promotion rules | Domain policy, worker state, critic results, artifact manifests | Authorized transition, blocked transition, audit record | Knowledge promotion and Labs continuation |
| Work graph system | Jobs, stages, dependencies, leases, retries, reconciliation | Work requests, execution envelopes, capability constraints | Executable graph and stage-level status | Worker admission and capability routing |
| Worker and capability system | Node admission, heartbeat, capability profiles, scheduling eligibility | Hardware evidence, resource telemetry, storage visibility | Trusted worker assignment or drain/quarantine decision | Worker admission and capability routing |
| Execution envelope system | Inputs, parameters, runtime policy, expected outputs, artifact policy | Work graph stage, source refs, model/profile refs, policy | Validated execution envelope and completion manifest | Remote-run telemetry and health evidence |
| Data custody system | Source refs, scratch policy, output manifests, archive rules, provenance | Lab data boundaries, source metadata, run outputs | Governed artifact lineage and source-coverage evidence | Source boundaries and data custody |
| Model and critic system | Model profiles, critic schemas, adjudicators, evaluation authority | Portable memory, candidate artifacts, claim tier requests | Bounded model judgment and blocked/promoted claim state | Model Plane scientific critics |
| Knowledge and Labs system | Evidence graph, figures, Labs pages, review queues, branch state | Artifacts, telemetry, critic outputs, human decisions | Reviewable knowledge artifact and continuation route | Knowledge promotion and Labs continuation |
Figure: UnifiedFlow platform planes. The platform is easier to reason about when authority, execution, model judgment, storage, and knowledge promotion are visible as separate but connected planes.
{
"type": "network",
"title": "UnifiedFlow platform planes",
"caption": "Control Plane authority, Work Graph leases, worker execution, Model Plane critics, portable memory, and Labs promotion form one inspectable scientific platform.",
"badges": [
{ "label": "Domain", "value": "multi-domain", "tone": "surface" },
{ "label": "First emphasis", "value": "calcium imaging", "tone": "agent" },
{ "label": "Memory", "value": "portable IP", "tone": "evidence" }
],
"nodes": [
{ "id": "domain", "label": "Domain programs", "group": "surface", "value": 5, "x": 0.08, "y": 0.20 },
{ "id": "control", "label": "Control Plane", "group": "surface", "value": 5, "x": 0.30, "y": 0.20 },
{ "id": "workgraph", "label": "Work Graph", "group": "workflow", "value": 5, "x": 0.50, "y": 0.20 },
{ "id": "workers", "label": "Workers", "group": "agent", "value": 5, "x": 0.50, "y": 0.48 },
{ "id": "data", "label": "Data custody", "group": "storage", "value": 5, "x": 0.28, "y": 0.70 },
{ "id": "memory", "label": "Portable IP / model memory", "group": "evidence", "value": 5, "x": 0.70, "y": 0.68 },
{ "id": "model", "label": "Model Plane critics", "group": "surface", "value": 4, "x": 0.75, "y": 0.25 },
{ "id": "labs", "label": "Labs knowledge", "group": "metadata", "value": 5, "x": 0.90, "y": 0.48 }
],
"links": [
{ "source": "domain", "target": "control", "label": "declares rigor" },
{ "source": "control", "target": "workgraph", "label": "authorizes" },
{ "source": "workgraph", "target": "workers", "label": "leases" },
{ "source": "workers", "target": "data", "label": "reads/writes governed refs" },
{ "source": "workers", "target": "memory", "label": "emits reusable artifacts" },
{ "source": "memory", "target": "model", "label": "feeds profiles" },
{ "source": "model", "target": "control", "label": "advises gates" },
{ "source": "model", "target": "labs", "label": "supports claims" },
{ "source": "labs", "target": "domain", "label": "teaches next work" }
]
}
Operating Flow
| Step | System Of Record | Subsystem Detail | Output | Failure Mode To Make Visible |
|---|---|---|---|---|
| Domain declared | Program and domain system | Workflow family, claim tiers, review roles, custody expectations | Domain entry record | Domain enters without enough vocabulary to govern work |
| Work requested | Control and Work Graph systems | Stage graph, dependency order, retry policy, expected artifacts | Executable work graph | A script runs outside authorized platform state |
| Capacity selected | Worker and capability system | Worker identity, capability profile, heartbeat freshness, storage reachability | Lease candidate | Work routes to stale or mismatched hardware |
| Envelope issued | Execution envelope system | Inputs, params, runtime policy, refs, model/profile versions | Immutable execution envelope | A worker receives ambiguous context or mutable instructions |
| Stage executed | Worker and telemetry systems | Launch state, resource samples, canary state, stage progress | Stage record and telemetry stream | Long-running work becomes opaque |
| Artifacts registered | Data custody system | Source refs, scratch outputs, archive refs, checksums, manifests | Artifact lineage | Output exists without source boundary or provenance |
| Critics evaluate | Model and critic system | Profile critic, domain critic, condition gate, figure gate | Bounded judgment | Model commentary is mistaken for scientific authority |
| Knowledge promoted | Knowledge and Labs system | Figures, claims, review state, unresolved questions, branch links | Durable lab artifact | Evidence is published without continuation path or review state |
Subsystem Introductions
Domain And Program System
| Subsystem | Role | Current First-Domain Example | What To Document Next |
|---|---|---|---|
| Domain profile | Names the scientific or engineering program entering UnifiedFlow | Neuroscience enters first; calcium imaging is the first concrete workflow family | Domain onboarding and scientific programs |
| Workflow family | Groups related stages and artifacts | Motion, postmotion, ROI/event qualification, trace review, figure readiness | Full-source rerun readiness |
| Claim tiers | Separates candidates, review evidence, and scientific conclusions | Candidate events and ROI bundles remain review-state evidence until gates agree | Model Plane scientific critics |
| Review roles | Defines who can advise, block, promote, or retire | Codex can structure and update content; critics can gate defined claims; humans decide scientific interpretation | Knowledge promotion and Labs continuation |
Data Center Capacity System
| Subsystem | Role | Current First-Domain Example | What To Document Next |
|---|---|---|---|
| Worker admission | Promotes machines into trusted platform capacity | A lab-side GPU worker must prove identity, resource class, heartbeat, and storage visibility | Worker admission and capability routing |
| Capability routing | Matches work to resource and policy requirements | GPU calcium stages require advertised GPU capacity and access to approved source/output boundaries | Worker admission and capability routing |
| Lease policy | Bounds what a worker can run and for how long | Remote worker runs should be assigned by Work Graph lease rather than direct ad hoc invocation | Remote-run telemetry and health evidence |
| Drain and quarantine | Removes capacity from eligible scheduling when evidence degrades | Missing heartbeat, failed resource sampler, storage errors, or repeated stage failures should change state | Worker admission and capability routing |
Figure: Worker admission lifecycle. Remote machines become scientific capacity through evidence-backed state transitions.
{
"type": "line",
"title": "Worker admission lifecycle",
"xLabel": "State",
"yLabel": "Operational confidence",
"caption": "The platform should promote machines into capacity through evidence, approval, heartbeat, capability advertisement, and bounded assignment.",
"badges": [
{ "label": "Admission", "value": "evidence first", "tone": "review" },
{ "label": "Scheduling", "value": "capability routed", "tone": "agent" }
],
"data": [
{ "label": "Physical machine", "value": 1.0 },
{ "label": "Bootstrap evidence", "value": 2.0 },
{ "label": "Candidate", "value": 2.7 },
{ "label": "Approved profile", "value": 3.6 },
{ "label": "Fresh heartbeat", "value": 4.2 },
{ "label": "Bounded assignment", "value": 4.7 }
]
}
Execution And Telemetry System
| Subsystem | Role | Current First-Domain Example | What To Document Next |
|---|---|---|---|
| Execution envelope | Carries bounded run context to the worker | Calcium processing should receive source refs, stage params, expected outputs, runtime policy, and artifact rules | Remote-run telemetry and health evidence |
| Stage telemetry | Makes long-running work inspectable | CPU, RAM, GPU utilization, GPU memory, temperature, power, canary state, and stage progress become run evidence | Remote-run telemetry and health evidence |
| Retry and reconciliation | Connects failure recovery to platform state | SSH retries, wrapper restarts, partial outputs, and downstream continuation need explicit status | Worker admission and capability routing |
| Health evidence | Supports continue, pause, retry, investigate, or promote decisions | A run can be healthy, resource constrained, blocked by data, or blocked by scientific gates | Remote-run telemetry and health evidence |
Data Custody And Artifact System
| Subsystem | Role | Current First-Domain Example | What To Document Next |
|---|---|---|---|
| Source boundary | Keeps lab-owned raw data distinct from platform outputs | Source movies remain governed source records while workers read through approved references | Source boundaries and data custody |
| Scratch/output boundary | Separates active compute material from durable artifacts | Motion/postmotion output, traces, intermediate files, and figures should carry manifests | Source boundaries and data custody |
| Source-duration truth | Determines what coverage claims are allowed | Calcium reruns should qualify against actual source movie duration rather than a fixed-duration assumption | Full-source rerun readiness |
| Provenance manifest | Preserves lineage from source to claim | Figures, bundles, critic reports, and portable memory should point back to source refs and run envelopes | Knowledge promotion and Labs continuation |
Model Memory And Critic System
| Subsystem | Role | Current First-Domain Example | What To Document Next |
|---|---|---|---|
| Portable IP memory | Preserves reusable learning across execution contexts | T7 currently represents the portable surface for weights, profiles, calibration outputs, training-adjacent artifacts, and review evidence | Portable IP and model memory |
| Profile memory | Carries condition-aware parameter and model behavior evidence | Shorter artifacts can still train profile awareness and pressure models when labeled with their coverage limits | Portable IP and model memory |
| Critic routing | Assigns model judgment to bounded authorities | Profile, neuroscience, condition, event, and figure-readiness critics should each publish allowed/blocked claims | Model Plane scientific critics |
| Disagreement memory | Keeps rejected and quarantined examples useful | Candidate disagreements, over/under-calling evidence, and figure blockers become training and review assets | Model Plane scientific critics |
Scientific Readiness And Claim System
| Subsystem | Role | Current First-Domain Example | What To Document Next |
|---|---|---|---|
| Coverage gate | Confirms whether the artifact covers the source obligation | Full-source calcium reruns require metadata-confirmed source movie duration | Full-source rerun readiness |
| Figure readiness gate | Tests whether downstream figures are interpretable enough to carry claims | Candidate coactivity and condition-level figures can block promotion when saturated, unstable, or under-supported | Full-source rerun readiness |
| Claim matrix | States what a result can and cannot support | Candidate events, ROI review bundles, model profiles, and biological conclusions sit in different claim tiers | Model Plane scientific critics |
| Review consensus | Combines human and critic authority | Human review remains decisive for scientific interpretation while critics structure evidence pressure | Knowledge promotion and Labs continuation |
Figure: Scientific readiness gate pressure. Readiness work should show which gate is blocking promotion and which artifact class can still be reused.
{
"type": "matrix",
"title": "Scientific readiness gate pressure",
"xLabel": "Gate dimension",
"yLabel": "Readiness state",
"valueLabel": "pressure",
"caption": "The first-domain calcium workflow separates reusable profile evidence from production evidence by requiring source coverage, critic agreement, and figure readiness.",
"badges": [
{ "label": "Domain", "value": "calcium imaging", "tone": "agent" },
{ "label": "Broad reruns", "value": "gate-bound", "tone": "review" },
{ "label": "Profiles", "value": "reusable", "tone": "evidence" }
],
"data": [
{ "row": "Gate-bound", "column": "Source duration", "value": 4 },
{ "row": "Gate-bound", "column": "Profile critic", "value": 3 },
{ "row": "Gate-bound", "column": "Neuro critic", "value": 8 },
{ "row": "Gate-bound", "column": "Figure readiness", "value": 4 },
{ "row": "Reusable", "column": "Profile learning", "value": 7 },
{ "row": "Reusable", "column": "Critic training", "value": 6 },
{ "row": "Reusable", "column": "Pressure analysis", "value": 5 },
{ "row": "Promotable", "column": "Full-source evidence", "value": 1 }
]
}
Knowledge Promotion And Labs System
| Subsystem | Role | Current First-Domain Example | What To Document Next |
|---|---|---|---|
| Evidence graph | Links source, run, artifact, critic, figure, and claim | Calcium artifacts should resolve to source refs, run envelopes, model/critic versions, and review states | Knowledge promotion and Labs continuation |
| Figure library | Keeps visual evidence near the relevant section | Figures should appear throughout studies as hierarchy, network, matrix, line, radar, and domain-specific views | Knowledge promotion and Labs continuation |
| Review state | Communicates maturity without flattening evidence | Draft, review, published, consolidate, archive, and blocked states help Codex manage updates | Knowledge promotion and Labs continuation |
| Branch queue | Turns platform pressure into dedicated subsystem studies | The overview routes readers into focused labs for admission, telemetry, custody, memory, readiness, critics, knowledge, and domain onboarding | Domain onboarding and scientific programs |
Figure: Knowledge promotion path. Working knowledge, portable artifacts, model memory, and Labs should mature together while keeping provenance visible.
{
"type": "hierarchy",
"title": "Knowledge promotion path",
"caption": "UnifiedFlow turns working evidence into durable studies by preserving source refs, artifact manifests, critic decisions, figure obligations, and continuation links.",
"hierarchy": {
"name": "Research memory",
"children": [
{ "name": "Working knowledge", "children": [ { "name": "Architecture vocabulary" }, { "name": "Runbooks" }, { "name": "Domain profiles" } ] },
{ "name": "Portable IP", "children": [ { "name": "Weights" }, { "name": "Profiles" }, { "name": "Critic reports" }, { "name": "Rejected examples" } ] },
{ "name": "Labs", "children": [ { "name": "Overview" }, { "name": "Subsystem studies" }, { "name": "Figures" }, { "name": "Review states" } ] }
]
}
}
Continuation Plan
| Continuation Lab | Primary Question | First Table To Build There |
|---|---|---|
| Worker admission and capability routing | Which machines can carry scientific work? | Worker state, required evidence, operator action, failure mode |
| Remote-run telemetry and health evidence | Is a remote run healthy and interpretable? | Metric, source, cadence, decision supported, retention |
| Source boundaries and data custody | What can touch source data and what custody does it create? | Data class, owner, allowed access, output path, provenance obligation |
| Portable IP and model memory | What should persist as reusable model/IP memory? | Artifact class, reuse value, claim tier, versioning, forbidden confusion |
| Full-source rerun readiness | When can exploratory evidence become production rerun evidence? | Gate, required evidence, critic authority, pass/fail state, next action |
| Model Plane scientific critics | Which model judgments can advise or block? | Critic, schema, allowed claim, blocked claim, escalation |
| Knowledge promotion and Labs continuation | What becomes durable Labs knowledge? | Evidence type, figure obligation, review state, branch target, update owner |
| Domain onboarding and scientific programs | How do future scientific domains enter the platform? | Domain, workflow family, source boundary, compute need, claim model |
Platform Starting Position
UnifiedFlow is ready to be documented as a platform model with a clear first-domain test. The overview should orient readers around objectives, vocabulary, systems, subsystem contracts, and continuation routes. Neuroscience and calcium imaging provide the first demanding scientific pressure; future domains should enter through the same platform contract rather than through one-off documentation patterns.
The next useful work is to let each continuation lab become dense on its own terms: admission evidence, telemetry schemas, custody manifests, portable model memory, full-source readiness, critic authority, knowledge promotion, and domain onboarding. Codex can help maintain that system by creating branch labs, updating tables as evidence changes, attaching figures in the relevant sections, and preserving review state instead of flattening everything into a single article.