Skip to content

Dual-Engine Architecture

Codaris separates the decisions that have a small, fixed set of answers from the work that needs a language model. The first kind goes to a local decision model; the second kind goes to the model you configured.

graph LR
    User[Prompt] --> S1[Decision model: nf-pilot]
    S1 -->|turn kind, failure category, tool choice| S2[Language model]
    S2 -->|plan, repairs, judgement| Build[Build graph: scaffold, compile, verify]
    Build --> Pipeline[Pipeline tree]

    subgraph "Local, offline"
      S1 --> D1[classify_intent]
      S1 --> D2[diagnose_error]
      S1 --> D3[select_tool]
      S1 --> D4[plan-stage choices]
    end

    subgraph "Configured provider"
      S2 --> G1[BuildPlan]
      S2 --> G2[Fix proposals]
      S2 --> G3[Judge and review]
    end

The decision model (Primeomicx/nf-pilot)

  • Model: Primeomicx/nf-pilot, loaded through the laya agent library at the revision pinned in the image.
  • Execution: CPU by default; CODARIS_NF_PILOT_DEVICE=cuda or mps when the hardware is there.
  • Offline: the image caches the weights and sets HF_HUB_OFFLINE=1, so no network call is made to load it.
  • Latency: measured, not assumed. GET /health reports the running average over the calls made since the backend started and the number of samples behind it.

What it answers

Function Question Answers
classify_intent What kind of turn is this? build_pipeline, ask_question, debug_error, prepare_data
diagnose_error What went wrong in this run log? out_of_memory, walltime_timeout, command_missing, file_not_found, container_failure
select_tool Which of these candidate tools fits this step? one of the candidates
resolve_qc, resolve_structure, resolve_samplesheet Which option should the plan stage propose as its default? one of the candidates

Each answer carries a confidence. When the model is unavailable the caller falls back to a stated default (build_pipeline for intent, the first candidate for a choice) and records "source": "fallback", so a missing model degrades visibly rather than silently.

The language model

  • Models: any entry in the catalog on the configuration page: the current OpenAI, Anthropic, and Google generations, the Perplexity Sonar family, or a local OpenAI-compatible server.
  • Role: the BuildPlan (assay, module chain, assets, test data) through structured output; corrected files when the compile gate or lint fails; the judge and the compliance evaluator; research turns.
  • Tools: the bounded surface on the tool surface page.

How the two interact

The decision model runs first and shapes what the language model is asked to do: a turn classified as a question is not handed the build tools' output format, a run log triaged as out-of-memory goes to the readiness fixer before any model is asked to reason about it, and a plan stage opens with a default the decision model picked from the real candidates. The language model then works inside the compiler's constraints: it proposes, and the validators, the compile gate, and the lint decide.

Health check

curl -s http://localhost:8000/health | jq .

{
  "status": "ok",
  "version": "1.0.0",
  "system1_nfpilot": {
    "status": "ready",
    "model": "Primeomicx/nf-pilot",
    "version": "nf-pilot",
    "engine": "nf-pilot",
    "device": "cpu",
    "role": "System 1 Fast-Path Decision & Tool Filter Engine",
    "avg_latency_ms": 148.6,
    "latency_samples": 12
  }
}

avg_latency_ms is null until the first call. codaris doctor reports the toolchain rather than the model; the model's state is on /health and /api/nf-pilot/status.