Back to docs index

Local AI Ops infrastructure on existing Foundry codebase

Executive ruling

Do not rewrite Foundry.

The right next layer is to extend the existing Foundry control/evidence spine into four tightly-coupled product surfaces:

  1. Local AI Doctor
  2. Flight Recorder
  3. Specialist Eval Harness
  4. Pack System v0

Those should ship as one staged Local AI Ops layer with clear boundaries:

The approved Hermes/PDF Ops seam is already strong enough to act as the first proof workflow. The missing work is mostly productization and contract wiring, not invention.

What exists already vs what is missing

Already exists and should be reused

Foundry core control/evidence spine

Foundry ops / capacity / observability layer from Tes

Local LLM Stats read-only visibility layer

Approved Hermes/PDF Ops evidence seam

Missing and must be built

Architecture boundary

Foundry owns

Foundry is the only control plane and product truth for:

Local LLM Stats owns

Local LLM Stats owns:

It must not own:

Hermes owns

Hermes owns:

It does not own:

LocalMaxxing owns

LocalMaxxing owns:

It does not own:

Component mapping: proposed product surface to current code

SurfaceExisting code to reuseExtendMissing
Local AI Doctorfoundry_core/runtime_inspector.py, foundry_core/daemon.py::doctor, project_foundry/status_dashboard.py, project_foundry/support_summary.py, llm_stats/status.pyunify runtime, harness, capacity, pack, and permissions into one doctor verdictpack-aware doctor clauses, operator remediation per failed clause
Flight Recorderfoundry_core/observability.py, foundry_core/store.py, foundry_core/support_bundle.py, project_foundry/status_dashboard.pyadd route decision logs, pack run IDs, eval result links, permission-resolution snapshotsexplicit flight-recorder schema, query/export command, pack-run timeline
Specialist Eval Harnessproject_foundry/localmaxxing_pipeline.py, project_foundry/docs/evaluation-framework.md, foundry_core/store.py::benchmark_runsconvert benchmark runs into Foundry-owned route/pack eval records with thresholds and promotion statepack/route eval registry, eval CLI/API, readiness gating on eval pass
Pack System v0pack-system-v0-contract.md, foundry_core/manifest.py, foundry_core/daemon.py, foundry_core/adapter_manager.pyadd pack manifest compile/validate, lifecycle commands, grouped permissions, pack evidence spineactual foundry pack ... implementation and persisted pack state
Router / model registryfoundry_core/manifest.py, foundry_core/runtime/truth.py, project_foundry/capacity_guard.py, status_dashboard.pyseparate declared model roles, route readiness, fallback state, parked/offline statepack-facing model registry/status view and route registry surfaced in status/support bundle
Grouped permissionspack-system-v0-contract.md, foundry_core/security.py, foundry_core/support_bundle.pypersist grants/denials by capability group and include in status/evidencepermission resolver, storage model, doctor clauses, pack partial/demo-only states

Recommended target architecture

1. Local AI Doctor

Purpose

A single truthful operator command that answers:

Base to reuse

Required extension

Doctor must become clause-based and pack-aware. It should report, per pack:

Why this matters

Without pack-aware doctor output, Pack System v0 becomes packaged mystery meat. Doctor is the first anti-theater layer.

2. Flight Recorder

Purpose

A Foundry-owned timeline of what happened during install/check/run/eval, with enough context to debug failures and enough redaction to be support-safe.

Base to reuse

Required extension

Add explicit entities:

Each pack run should emit a linked record chain:

Why this matters

Pam's Local AI Doctor / Flight Recorder recommendation is right. Supportability and trust depend on reconstructing a truthful sequence, not just showing current status.

3. Specialist Eval Harness

Purpose

Make route readiness and pack readiness evidence-backed instead of intuition-backed.

Base to reuse

Required extension

Foundry should own a route/pack eval layer with:

Why this matters

The modular thesis only becomes commercially defensible when route choice is tested. Otherwise the router is vibes.

4. Pack System v0

Purpose

Turn pre-skilled workflow teams into an installable, supportable, auditable unit.

Base to reuse

Required extension

Implement:

First reference pack

pdf-ops-pack should be the first real pack because it already has:

5. Router / model registry

Purpose

Expose, in a product-safe way, which model serves which route and whether that claim is proven.

Base to reuse

Required extension

Add a Foundry registry view that distinguishes:

This should remain a Foundry export first, with Local LLM Stats only displaying it.

6. Grouped permissions

Purpose

Avoid the per-exec approval death spiral and make packs auditable as capability bundles.

Base to reuse

Required extension

Foundry must persist and display permission groups with scope and state, for example:

Pack status must surface:

Data/control flow

  1. Operator installs pack.
  2. Foundry validates pack manifest and resolves grouped permissions.
  3. Foundry checks runtime inventory/capacity/harness readiness.
  4. Foundry runs pack check and required smoke evals.
  5. Foundry marks routes as ready or declared-not-proven.
  6. Local LLM Stats renders Foundry health/visibility output read-only.
  7. Operator runs pack.
  8. Hermes executes workflow contents.
  9. Foundry records route decisions, permission state, eval outcomes, and evidence into Flight Recorder.
  10. Foundry emits support bundle / support summary.

Build sequence and owners

Stage 0 — Architecture gate and contract freeze

Stage 1 — Foundry pack runtime spine

Stage 2 — PDF Ops reference pack contents

Stage 3 — Pack run path plus Flight Recorder linkage

Stage 4 — Specialist Eval Harness promotion state

Stage 5 — Local LLM Stats polish on top of Foundry truth

First three implementation tasks to open now

Task 1 — Tes: Foundry pack runtime spine

What this delivers A Foundry-native pack lifecycle path that validates foundry-pack/v0, resolves grouped permissions, runs pack-aware doctor/checks, and emits a pack support bundle.

Grounding files

Must implement

Binary acceptance criteria

Task 2 — Pam: PDF Ops reference pack contents

What this delivers A real pdf-ops-pack built by wrapping the approved Hermes/PDF workflow seam into pack contents, not rebuilding the harness.

Grounding files

Must implement

Binary acceptance criteria

Task 3 — Tes + Pam seam: pack run path and Flight Recorder evidence

What this delivers A truthful demo run path for pdf-ops-pack where Foundry records route choices, Hermes run facts, and emitted evidence as one linked supportable trace.

Grounding files

Must implement

Binary acceptance criteria

Risks and non-goals

Non-goals

Main risks

  1. Control-plane drift
  1. Pack greenwashing
  1. Permission ambiguity
  1. Evidence split-brain
  1. Scope bloat

Immediate recommendation

Approve Stage 1 now.

The first implementation step should be Tes building the Foundry pack runtime spine on the existing manifest/daemon/observability/store code, because that is the smallest honest move that unlocks Doctor, Flight Recorder, Eval Harness, and PDF Ops Pack work without re-arguing architecture.

Evidence basis used for this brief