Fabric

The governed
agentic runtime.

Fabric is the engine beneath Forge. It assembles context, reasons over grounded knowledge, executes real tool work through the right runtime, and returns evidence and confidence — all under deterministic policy. Fabric owns execution; it holds no product-UI responsibilities.

1

Why

Why Forge needs Fabric

Separating the engine from the product means the control plane can evolve without destabilizing production execution, and the AI layer can be replaced without changing anything above it. Agent JSON is the stable contract between them.

Grounded

Every value is bound to a real source; unresolved values stay explicit, never invented.

Deterministic-first

Deterministic logic runs before any model; AI is used only where it adds value.

Governed

Validation, confidence and a human gate sit between the plan and any outward effect.

The stack

Fabric, layer by layer

An exploded view of the engine, floor by floor. A request rides the spine from the Forge surface at the top to the crust at ground level — decided in the core, grounded by intelligence, executed by the runtimes, and gated by the governance field before anything lands.

Click a floor to see what it does — or watch a request drop from the surface to the ground.
Cutaway of Fabric's layers

Numbered like a building: a request enters at the top floor, and nothing reaches the ground (0 · crust) without passing the governance gate at level 1.

2

Lifecycle

Agent execution lifecycle

Observe Reason Plan Execute Govern Approve Learn ticket · paths · knowledgeground · reconcileselect runtime tools · streamvalidatehuman gaterecord · calibrate
3

Knowledge

Retrieval & context assembly

Query Embed Workspace indexruns · KB · agents · skills · docs Rank Grounded context untrusted reference · missing evidence stays missing

RAG is workspace-scoped and deterministic-first. Retrieved content is treated as untrusted reference data used to ground reasoning — it never becomes an authoritative production value on its own, and gaps are reported rather than filled.

Dual-mode RAG — one contract, two stores.

fabric_kb is the durable ground truth; the RAG index is a derived overlay rebuilt from it. The store is chosen once at deployment and validated by deployment_config (it accepts only (local, local) or (hybrid, postgres) — anything else fails closed). Local mode keeps everything on-device: a JSONL store, on-device nomic-embed-text embeddings, brute-force cosine, and atomic index promotion (build to a temp file, then swap) so a half-built index is never read — it never auto-syncs to a hosted store. Hybrid mode stores vectors in PostgreSQL + pgvector under an EmbeddingContract that pins model/dimensions/normalization, with every query carrying a QueryScope under row-level security so a workspace only ever sees its own rows — fail-closed, with tombstoned revocation and a sampled re-embed audit. The caller never knows which store answered. See the RAG-modes diagram and ADR-0001.

3a

Capacity

Tokens, context windows & local models

Local models use tokens just like cloud models. The difference is billing: Ollama does not charge per token, but every model still has a finite context window, an output limit, and a local compute cost. Tokens are created automatically when the model tokenizer converts text and code into numeric pieces; users do not buy, pre-generate, or manually manage them.

Context window

The combined system policy, selected skills, RAG evidence, source-code excerpts, telemetry, run memory and requested response must fit the active model's context window.

Generated output

The model predicts response tokens one at a time until it finishes, reaches the configured output cap, times out, or exhausts available memory. Code usually tokenizes more densely than prose.

Real local cost

Local inference has no provider token invoice. Its costs are RAM/VRAM, CPU/GPU time, power and latency. Cloud routes retain provider usage and billing controls.

What Fabric puts in one model call.

policy + task + selected workflow skills + selected RAG chunks + relevant code/telemetry + recent run state + reserved output. Fabric never treats the entire wiki, skill library or project source tree as one prompt.

Progressive disclosure

Fabric first identifies the workflow, stage and task. It injects only the highest-value skills and evidence that fit the budget, then retrieves deeper code, assets or documents when the investigation needs them. A skill remains fully indexed and digest-audited even when only a bounded instruction excerpt is placed in one prompt.

Observable budgeting

Where supported, the UI reports candidate, selected, injected and deferred RAG items plus context usage. “Deferred” means relevant but not needed in this call—not forgotten or unlearned. Token counts are estimates unless the provider reports exact usage.

When the semantic embedder is offline

Fabric continues with bounded lexical and authority-aware retrieval. Incident and engineering work must not be blocked merely because nomic-embed-text or Ollama embeddings are unavailable; semantic ranking resumes when the embedder is healthy.

When a model attempt fails

Timeout, malformed output, context exhaustion or memory pressure triggers controlled retry/failover or deterministic evidence guidance. A failed enrichment must not turn an evidence-backed workflow into an unsafe success; compile, validation, policy and human approval gates remain authoritative.

How to keep Fabric accurate and fast.

Keep canonical sources current, classify them into the correct workspace/domain, avoid duplicate snapshots, and let Fabric select context. Do not paste secrets, entire repositories or every skill into a request. More context is not automatically more intelligence: relevant, diverse and sufficiently complete evidence produces better results than maximum volume.

4

Decision

Decision support & confidence

Evidence Deterministicvalidators · policy Confidence Gate Approve → ship Block / review confidence summarizes evidence — it never overrides a hard failure
4a

Core intelligence

Fabric Core Intelligence — the governed specialist layer

Reasoning, recovery, agent fabrication and verification are one shared governed capability reached through a single typed, default-deny Intelligence Gateway. A deterministic sufficiency check runs first; only if it's insufficient does the Core Orchestrator select at most one qualified specialist. Specialists are advisory — Forge services alone execute tools, grant approvals and record authoritative outcomes. Promoted on by default, with a persistent Settings kill switch and an emergency process override.

Caller · Weave / Studio / run Fabric Intelligence Gatewaytyped · default-deny · scoped & budgeted Core Orchestratordeterministic sufficiency first → one qualified specialist GOVERNED SPECIALISTS · ADVISORY ONLY Intent & Context Planning Failure Investigation Recovery Outcome Verifier Agent Architect Agent Builder Certification Bounded minions — scoped tools · budgets · expected outputs · cancellation · parent operation identity Advisory-only · Forge services alone execute, approve & record · promoted default-on · Settings kill switch · emergency override · Event Spine route receipts

One Gateway, one route

Every intelligence call crosses a typed, default-deny boundary carrying caller, certified policy, workspace/branch scope and budgets. Deterministic sufficiency is tried first; the LLM path is the exception, not the default.

Grounded by the Production Graph

Specialists reason over trust-labelled evidence from the workspace RAG and the Production Knowledge Graph & GraphRAG — provenance in, advice out. Missing evidence stays missing; nothing is invented.

Decision record: ADR-0006 · Fabric Core Intelligence. Reference diagram: Fabric Core Intelligence.

5

Responsibilities

Runtime, models, memory & guardrails

Tool execution & runtime events

Four runtimes dispatch stages to registered executors (Photoshop, Unity, Perforce, data writes) and stream NDJSON events back to Forge live.

Model routing — local & cloud

A caller asks for a capability lane, never a model. Seven lanes — fast · reason · code · review · vision · plan · embed — route deterministic-first under a min_cap floor. Private/low-latency lanes stay local; only reason and code burst to a cloud specialist under budget. Models are replaceable plugins. Full routing detail ↓

Memory

Scoped, governed, reversible, workspace-isolated context from prior runs and decisions — improving repeat work without baking in anecdote.

Guardrails & provenance

Dry-run preview, executor coverage, write-path limits, connector resilience, and full provenance so every outcome is explainable and auditable.

Fabric is replaceable without changing Forge.

Because the boundary is the capability contract and agent JSON, the entire AI/runtime layer can be swapped — a local Ollama pool, cloud specialists (Anthropic Claude), a team GPU server running vLLM, or a studio multi-tenant fleet — with no change to the product surface. Today Fabric runs local and cloud at once, routed per capability lane.

5a

Model routing

Capability lanes, local & cloud

Fabric's defining move: a caller asks for a capability, never a model. That one indirection is what lets the AI layer be swapped, run local and cloud at once, and stay governed — the router picks the best ready model for the lane, and nothing above it has to know which one.

Foreground — you pick a lane, not a model

Seven lanes cover the work: fast (routing/classify), reason (+ planning), code (gen & autonomous bug-fixing), review (independent), vision (art-QA), plan (architecture) and embed (retrieval). You never choose a checkpoint; you choose the kind of thinking, and Fabric routes it.

Behind — the router & the competence floor

fabric_router is a facade that ranks registry cards (data in fabric_models.json, not code) by the lane's primary capability axis and drops any below a min_cap floor. If no qualified model remains, the result is an explicit pool_exhausted — a terminal, honest outcome, never a silent fall to a weaker model.

Fabric is used in every execution mode.

The policy changes where model inference runs; it does not bypass Fabric. Fabric still classifies the request, assembles grounded context, selects the capability lane, enforces policy and budget, records evidence and telemetry, applies validation and approval gates, and captures governed learning. The local embedding model and Fabric Knowledge index remain local infrastructure in every mode.

Local only

All generative lanes use eligible models in the approved local Ollama pool. Cloud model calls, cloud egress and cloud fallback are blocked. This is the strongest privacy posture and has no provider token invoice, but speed and quality depend on the available local hardware and installed models. Embeddings and RAG are local.

Local + Cloud

Fabric routes by capability. Fast classification, routine work and embeddings normally stay local; complex reason and code work may use the configured cloud specialist when it is ready and eligible. Vision stays local by default unless explicitly pinned to an eligible cloud model. A cloud failure, exhausted hybrid budget or quota can fall back to an equivalent local model. Grounded task context may leave the machine on a cloud route.

Cloud only

Generative and vision work uses configured, ready cloud providers only. Ollama is never a generative fallback: missing credentials, unavailable providers, policy mismatch or exhausted capacity produces an explicit blocked/exhausted result. The local embedder may still run because retrieval infrastructure is deliberately outside the generative-egress policy.

How Hybrid chooses.

An explicit valid capability pin wins. Otherwise Fabric considers the requested lane, model kind, provider readiness, policy eligibility, benchmark results and recorded reliability. In the default hybrid profile, local handles low-latency/private work while the configured cloud specialist handles eligible reasoning and coding. If the chosen model fails, Fabric retries within its governed limits and may walk policy-allowed, capability-equivalent fallbacks; deterministic validators and human approvals remain authoritative regardless of which model answered.

What Fabric learns

Fabric records the capability, model, provider, success/failure, latency, failover and explicit helpful/incorrect feedback. Those facts improve future routing and confidence. A successful cloud response can also be retained as bounded, redacted candidate teacher evidence; only promoted lessons may later be supplied to a relevant local request as advisory, untrusted context.

What Fabric does not train

This does not fine-tune or change the weights of Qwen, Claude, GPT or another model. Learning is inspectable data—routing history, approved lessons, KB facts and RAG—not opaque neural-network training. Cloud output does not become trusted knowledge merely because the call succeeded; promotion and human governance remain separate gates.

Policy controls.

FABRIC_AI_EXECUTION_POLICY supplies the startup default. Administrators can enforce it with FABRIC_AI_EXECUTION_POLICY_LOCK=1, which prevents the Settings UI from changing the mode.

The local provider pool

fabric_providers.select_backend schedules across vLLM and Ollama nodes, lazy-loading and evicting open-weight models to fit machine RAM (128 GB). Selection order: healthy → resident/warm → backpressure → weighted least-in-flight. Hybrid routing never hides a local model.

Two learning loops for routing

Distinct from knowledge learning below: benchmark routing (fabric_bench) measures latency and capability to seed cold picks, and learned routing (fabric_learn) turns validated, human-approved cloud successes into local routing teacher signals — so good cloud outcomes make the local pool smarter over time.

The installed local pool (a representative cut).

gemma3:12b (fast) · qwen2.5:72b (reason) · qwen3-coder-next (code) · qwen2.5vl:32b (vision) · nomic-embed-text (embed, pinned & required). The cloud specialist covers reason · code · vision. Every model is a plugin behind the same capability contract — see the model-routing diagram.

6

Learning

How Fabric learns & how you train it

Fabric gets sharper two ways: passively, by recording what happens on every run, and actively, when you hand-feed it knowledge in the Train Fabric panel. Neither re-trains a neural network — Fabric's intelligence is a governed, inspectable memory that its deterministic reasoning and retrieval read from. That's what keeps it explainable and reversible.

Passive learning — from every run

Each execution writes durable facts to the Knowledge Base: which archetype was drafted for a ticket, the confidence and validator results, what you approved or held at the gate, per-character success rates, and corrections. Prediction and calibration read these back, so repeat work starts from experience instead of a blank slate.

Active learning — Train Fabric

The Train Fabric side-panel lets you feed custom knowledge into a workspace: free text, a document or code folder, a wiki/web URL, a Google Sheet, or an image. Text & docs are indexed for retrieval; images are understood by the Vision Engine; free text also becomes a learned memory. A live mind-map shows everything Fabric currently knows — knowledge collections, their sources, and the learned-memory facts. Selecting a topic branch in the map highlights the matching entries in the trained-sources list (and clicking a source highlights its branch), so it is obvious at a glance which fed sources sit behind each branch.

Training Fabric vs. RAG knowledge — what's the difference?

They're complementary halves of the same brain. RAG knowledge is reference: indexed documents, sheets, wikis and code that Fabric retrieves and cites at reasoning time to ground a plan (“what does the Proving Grounds wiki say the steps are?”). It's untrusted context — it informs a decision, it never becomes an authoritative production value on its own, and a gap is reported rather than invented. Training / learned memory is experience: structured facts Fabric records about what actually happened and what you decided (archetype choices, gate approvals, success rates, corrections, and the notes you teach it), which drive prediction, confidence and calibration. Put simply — RAG answers “what do we know about X?”; learned memory answers “what happened last time we did X, and what did we decide?”. The Train Fabric panel feeds both at once: a document lands in RAG for retrieval, while a note also lands in memory as a durable teaching fact.

RAG knowledge

Retrieved & cited reference. Grounds reasoning; never an authoritative value alone. Workspace-scoped.

Learned memory

Recorded outcomes & decisions. Drives prediction, confidence, calibration. Reversible & inspectable.

Train Fabric panel

The one place you feed both — docs/URLs/images into RAG, notes into memory — and see the knowledge mind-map.

Governed, not baked-in.

Because learning is data (KB facts + a RAG index) rather than model weights, every piece of what Fabric “knows” can be viewed in the mind-map, scoped to a workspace, corrected, or removed — no opaque fine-tune, no anecdote silently hardening into behaviour. See Talking to Weave for how this intelligence surfaces in conversation.

7

Best practices

How to train Fabric well

Fabric rewards curated, scoped, authoritative knowledge — not volume. A few well-labelled canonical sources beat a dump of everything. These are the habits that keep the mind-map sharp and every agent's grounding trustworthy.

✓ Feed the canonical source, not a copy

Point Fabric at the living wiki page, the master sheet, the source folder — the thing the team actually updates. Re-index when it changes rather than pasting a snapshot that silently goes stale.

✓ Label like you'd search for it

“Proving Grounds event setup — steps” beats “doc1”. The label is what shows in the mind-map and what Weave cites; a precise label makes retrieval and audit far easier.

✓ Put it in the right collection & workspace

Let auto-classify run, then correct it if wrong. Design lore → Design; pipeline how-tos → Tech-Art; code → the corpus. Knowledge is workspace-scoped, so train inside the workspace that will use it.

✓ Scope each item tightly

One topic per source. A focused page on “content-stripping” retrieves cleanly; a 60-page everything-doc dilutes every query it matches. Split large references into topic-sized pieces.

✓ Teach corrections as notes

When Fabric got something wrong and you fixed it, add a short free-text note explaining the rule (“Bear Island events always use the Winter tileset”). That becomes durable learned memory the next run reads back.

✓ Use images for visual truth

Feed reference art, UI mocks, or annotated screenshots — the Vision Engine describes them into the index, so “what should this look like?” questions ground on real examples.

What not to feed.

Skip secrets, tokens and credentials (Fabric indexes text — treat everything you add as readable). Skip transient chatter, one-off Slack threads, and duplicates of what's already indexed — they add noise the retriever has to fight through. Skip anything you're not allowed to store. If a source is authoritative but sensitive, prefer a link over pasting its contents.

Re-index on change

After editing a fed document, re-index so the new text is searchable. Adding a source in Train Fabric triggers this automatically.

🗺

Read the mind-map

Before a big run, glance at the map: is the knowledge this task needs actually present and in the right branch? Gaps you see there are gaps the agent will hit.

Prune & correct

Because knowledge is data, remove stale sources and re-teach corrected facts. Curation is a maintenance habit, not a one-time load.

Rule of thumb.

If you'd hand a document to a new teammate on their first day and say “this is how we do it here,” it belongs in Fabric. If you'd caveat it with “ignore this, it's out of date,” it doesn't. Train the way you'd onboard a person — canonical, labelled, and kept current.