Grounded
Every value is bound to a real source; unresolved values stay explicit, never invented.
Fabric Intelligence
The governed
agentic runtime.
Fabric Intelligence is the engine beneath Fabric. 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 Intelligence owns execution; it holds no product-UI responsibilities.
1
Why
Why Fabric needs Fabric Intelligence
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.
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.
Current inventory.
Fabric Intelligence discovers 92 skills: 55 executable and 37 awaiting reviewed activation contracts. The physical manifest contains 143 Photoshop/Unity operations: 87 production-ready and 54 still gated, with two unsafe unbounded Unity proposals retired from activation. Its shared registry contains 30 contracts and 3 compatibility deprecations. Those counts describe repository state, not production qualification or commissioning.
◉
The stack
Fabric Intelligence, layer by layer
An exploded deployment view of the engine, floor by floor. A request rides the spine from the Fabric 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. The separate authoritative responsibility map is Intelligence → Context & Knowledge → Capability → Execution → Governance → Assurance.
Click a floor to see what it does — or watch a request drop from the surface to the ground.
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
3
Knowledge
Retrieval & context assembly
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.
Context is composed, not copied.
The read-only Context Envelope binds World State, the exact plan and outcomes, retrieval provenance and a replayable decision manifest under one digest. It adds no competing store. The gateway injects an exact, expiring server-owned source verifier; shared admission still returns source_authority_unverified unless authoritative host producers registered the exact source, revision, digest, workspace and caller binding.
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.
Current operational state.
All seven workspaces are reconciled current and usable. Default was recommissioned at a clean Event Spine boundary: the previous signed chain remains read-only under a checksum manifest, zero ambiguous Default facts were migrated, and every non-Default signed row and sequence was preserved exactly. Protected Google Sheets remain visible as degraded collectors until service authorization is provisioned. Indexed text is never reverse-reconciled into authority.
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 Intelligence puts in one model call.
policy + task + selected workflow skills + selected RAG chunks + relevant code/telemetry + recent run state + reserved output. Fabric Intelligence never treats the entire wiki, skill library or project source tree as one prompt.
Progressive disclosure
Fabric Intelligence 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 Intelligence 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 Intelligence accurate and fast.
Keep canonical sources current, classify them into the correct workspace/domain, avoid duplicate snapshots, and let Fabric Intelligence 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.
Cache follows state.
World State, Context Envelope, evidence-derived confidence and state-aware replanning come before cache optimization. Provider/runtime KV and exact prompt-prefix caching may improve latency but grant no authority. Fabric Intelligence intentionally does not use a semantic answer cache: a prior generated answer can be stale across source, workspace, model, policy, approval and validation changes.
4
Decision
Decision support & confidence
Confidence is computed from validation results, retrieval/source coverage and tool/run history—not accepted as a model's self-reported certainty. It selects proceed, verify, escalate or stop guidance, but it cannot override policy, permission, consent, an emergency stop or a deterministic failure. Replanning is bound to the exact World State and complete plan-step outcomes so a sibling plan or omitted result fails closed.
4a
Core intelligence
Fabric Intelligence 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 — Fabric 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.
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 Intelligence Core Intelligence. Reference diagram: Fabric Intelligence 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 Fabric 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 Intelligence is replaceable without changing Fabric.
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 Intelligence runs local and cloud at once, routed per capability lane.
5a
Model routing
Capability lanes, local & cloud
Fabric Intelligence'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 Intelligence 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 Intelligence is used in every execution mode.
The policy changes where model inference runs; it does not bypass Fabric Intelligence. Fabric Intelligence 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 Intelligence 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 Intelligence 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 Intelligence 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 Intelligence 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 Intelligence learns
Fabric Intelligence 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 Intelligence 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.
5b
Physical autonomy
Toolsmith, Photoshop & Unity — what works now
Toolsmith does not directly click applications. It discovers a required operation, matches it to the canonical physical-capability manifest, checks the exact runtime binding and health evidence, and either gives the governed runtime a sealed operation or creates an inert acquisition candidate. Photoshop and Unity are touched only by their typed executors, with exact inputs, policy gates, validation and receipts.
Photoshop · typed native surface
Fabric Intelligence UXP v2 exposes 47 exact semantic actions across document/layer inspection, working-copy lifecycle, canvas transforms, layers/groups, text, Smart Objects, masks, layer comps, color/history and typed BMP/GIF/JPEG/PNG/PSD/PSB/WebP/artboard/atlas output. It exposes no raw JSX or caller-supplied batchPlay. Live Photoshop 27.8 v2 proof duplicated sources into unsaved working documents, resized and exported a 190×180 PNG, then produced independently identified non-empty PSD, PSB, JPEG, WebP, BMP and GIF outputs. Both copies closed without saving and the source digest stayed unchanged.
Unity · complete registered surface
The manifest covers all 61 handlers exposed by Unity MCP 0.4.315. Fabric Intelligence keeps the Fabric Toolsmith package in its own repository, deploys it into the active Unity project only for a governed operation, and restores the exact project manifest afterward. The package adds sealed serialized-state inspection and stable UI Toolkit inspect/set/invoke. Live Unity 2022.3.62f2 proof passed a real disposable AssetDatabase import, exact identity/reference/console verification and restricted rollback to zero remaining assets.
Toolsmith · governed acquisition
When no exact production handler exists, Toolsmith records a proposed candidate with provider, schema, risk, validators and compiler requirements. It does not auto-install, auto-promote or execute that candidate. Implementation, disposable-fixture qualification, live pilot approval and promotion remain explicit gates.
The shared readiness contract is the authority.
Studio, Upgrade Agent, certification, the planner, Capability Center and physical helper assignment now consume the same runtime-binding evidence. A candidate becomes production only when the agent has a typed run contract, its architecture binding is explicitly resolved, and its exact stage ID or capability has a registered typed handler. Generic approval, policy, notification and validation controls may run, but cannot make an unknown physical capability production-ready.
Capability Center is a discovery and setup surface, not an executor. Use it to find an operation, detect/connect its provider, or prepare a non-executable workbench candidate when the operation is genuinely absent. Provider refresh returns an explicit checked-at result and next action. Browser/Computer Control detection fails closed unless an enabled MCP connector explicitly declares that capability, is live-discovered, and has at least one exact approved tool; the Studio node still needs its own exact binding.
What “autonomous” means today
For a capability already marked production-ready, Fabric Intelligence may plan and execute the typed sequence, pause for required approvals, validate postconditions and reconcile outcomes. Stale app health, missing authoritative parameters, an unregistered operation or a failed validator stops the run. Agentic planning may choose among proven operations; it cannot invent authority.
What remains release evidence
The supported typed Photoshop/Unity surface and live disposable mutation/rollback pilots are complete. Fabric Intelligence intentionally does not execute arbitrary model-authored C#, JSX, editor method names or screen coordinates; genuinely unknown actions stay acquisition-only. Production promotion still requires 20 unique accepted real tickets per application for the exact candidate—those external cases are not fabricated from repository tests.
Production is now a measured state.
A generated pilot reaches production only after 20 unique attributable real-ticket cases prove actual provider execution, zero manual app operations, at least 95% mechanical success, 100% postconditions and source preservation, zero unauthorized writes or fabricated completion, complete recovery-or-stop behavior, human acceptance and independent review. Every dimension must score 10/10. Studio recomputes the sealed report, binds a separate human approval to the exact pilot and benchmark digests, and keeps publish and commission as later actions.
A two-phase sandbox smoke lane precedes promotion.
capability_sandbox qualifies one capability at a time before it can be promoted. It builds a minimal one-node Skill Graph from the capability's own manifest row (with the correct workspace:write effect closure for a writing operation), then runs Phase 1 — dry run: a no-write qualification (qualify_no_write) that performs no side effects. Only if the dry run passes does it attempt Phase 2 — live smoke against the real provider through an explicitly injected runner. If the provider is unavailable, or no runner is supplied, the lane records an honest skip (skipped_provider_unavailable / no-runner) — never a pass. A live run that returns success with no validations, or fails a validation, is also not a pass.
The evidence is sealed and hash-digested (fabric.capability-smoke-evidence.v1) and bound to the capability id, graph digest and candidate digest; a forged, unsealed or tampered record is rejected as evidence_invalid, and evidence whose identity does not match the graph fails closed. capability_builder.transition(…, "production") consults capability_sandbox.gate as a mandatory additional condition on EVERY production promotion, evaluated after the 20-ticket benchmark and human approval above so it never short-circuits them: the sealed envelope at evidence["sandbox_smoke"] must verify and be bound to this candidate's exact digest and the declared graph digest, the dry run must pass, and the live smoke must be verified. There is no waiver — missing, stale, failed, unverifiable or mis-bound evidence (including an honest live skip) denies the promotion. The legacy physical_toolsmith.promote_production path is held to the same gate: it threads the pilot's sealed smoke evidence (supplied or retained on the candidate) through capability_sandbox.gate and refuses to promote without it. physical_toolsmith.activate_pilot produces that evidence: when a real commissioned live runner and the capability's compiled graph are injected, it runs one genuine capability_sandbox.smoke bound to the pilot's stable identity digest (the candidate sealed with the smoke receipt excluded, so embedding it is not circular) and retains it at evidence["sandbox_smoke"] only if it verifies; with no runner it retains nothing and promotion stays fail-closed. The gate is additive: the benchmark, independent-review and human-approval gates are unchanged, and one smoke success grants no production, publication, commission or execution authority. A commissioned live runner remains opt-in and requires an explicit governance resolver plus retained execution evidence.
Intelligence and flow do not change tool access.
Deterministic vs. Agentic AI changes how plans and bounded recovery are chosen. Linear vs. DAG changes ordering, branching, joins, waits and checkpoints. All four combinations use the same exact capability manifest, runtime health, approvals, effect gates and validators; none grants an absent Photoshop or Unity function.
Skill Graph supervisor execution and scoped commissioning are implemented.
Fabric Intelligence validates versioned Skill Graph DAGs, exact capability bindings, typed handoffs, effects, recovery bounds and digest invalidation; compiles atomic Photoshop and Unity partitions through the existing sealed runtime; and reconstructs Toolsmith runs from signed events plus content-addressed plan artifacts. Character-production Studio stages name the exact graph version and require a sealed per-input Jira contract; the runtime never chooses “latest” or guesses paths, component IDs, properties or build commands. Studio now provides a guided, no-write editor for that exact block. One supervisor run owns both app partitions. Commissioning accepts authoritative Confluence URLs only: Fabric fetches the current page body and revision, computes the digest itself, retains a signed Event Spine observation and seals the scope. The background monitor repeats those live SOP and real Photoshop/Unity readiness probes; an unavailable or changed authority suspends the commission. Studio shows Candidate, Certified, Published, Commissioned, Suspended, Expired and Revoked separately. Nothing publishes or commissions merely by opening, qualifying or certifying a graph.
The new CharacterProductionAutonomy.v1 Expert Pack candidate and character-production-autonomy skill cover Flat Art, animation/prefab, ability/VFX, final review, Addressables/tests and the approved project build action using registered Photoshop/Unity operations. GOTRPG character-production tickets now draft this typed family. The candidate is not registered, certified, published or commissioned. Autonomous final-review acceptance additionally requires 20 unique complete ticket replays and independent review; the four Daemon tickets are reference material, not a fabricated release corpus.
The Photoshop UXP provider source and authenticated loopback sidecar now have a first-class Studio pairing and health flow. Owner-only token and qualification files are generated locally; the one-time token is shown only for explicit pairing. One v2 contract drives pairing, transport validation and the exact 47-handler inventory. Thirty additional manifest operations remain candidates while the already proven JSX surface stays available; overlapping UXP handlers do not erase that fallback. A durable reconciliation ledger records request identity when completion is uncertain, permits only named read-only inspection and requires an operator decision plus evidence; it never replays the mutation. The provider and representative working-copy PNG export are live-qualified. Unexercised actions remain non-production until their own evidence exists; Adobe signing/distribution is a deployment step, not repository evidence.
New governed production families: Faction Offers and 2D Iconic Item.
Faction Offers is a dedicated typed batch procedure—not an alias for the single-character Offers agent. It retains exact faction/member and Jira/Perforce lineage, generates source-backed Photoshop outputs, performs progressive subject-aware visual review, prepares typed Content Bundles rows, and separates Git, remote readback, sheet and Jira effects behind digest-bound approvals. Idempotent reruns verify already completed effects instead of repeating them.
2D Iconic Item is a versioned typed procedure from ticket and SOP grounding through complete Unity artifact-family preparation, deterministic reference-graph validation, catalog/dialog/battle-intro visual review, sealed publication and external-delivery verification. Its contained Unity adapter plans, applies and inspects a create-only clone with fresh GUID and serialized-reference checks. unity.apply_iconic_item_2d_family passed approved disposable-project qualification and independent Ed25519 attestation; the reviewed source release retains the exact request, receipt, physical-evidence, signer and adapter digests. Agent certification, production promotion, commissioning and delivery effects remain separate authorities.
Unity-Skills · qualified quarantine boundary
The reviewed MIT project reports 776 REST skills plus dry-run planning, risk metadata, transactional batches, persistent rollback and audit. Fabric Intelligence pins the reviewed revision and can request reviewed operations only in Standard dry-run mode. Exact revision, transaction-plan, rollback and audit receipts are required; Bypass, embedded code and unknown operations fail closed. Successful receipts still remain hidden, non-executable adapter candidates until Fabric Intelligence implements, live-qualifies and certifies an exact handler.
photoshop-connection · transport only
Its encrypted local socket and transaction dispatcher may be useful behind Fabric Intelligence's typed compiler. Arbitrary ExtendScript execution is never planner-visible and the library does not supply Fabric Intelligence approval, rollback, audit, independent validation or certification. The semantic UXP runtime remains the production direction.
Architecture and proof boundary: Photoshop & Unity autonomy · ADR-0008 · Autonomous Physical Toolsmith · ADR-0009 · Toolsmith Supervisor and Skill Graphs.
5c
Self-review · 7 August 2026
Current rating and honest gaps
The scores below measure different things deliberately. A safe architecture, a registered operation and a commissioned zero-touch workflow are not the same maturity state. Repository evidence currently shows 18 production-ready Photoshop operations plus 30 additional registered UXP candidates; the native provider itself implements 47 exact actions, 66 production-ready Unity operations plus 1 registered candidate and 2 acquisition-only operations, and a 26-node CharacterProductionAutonomy graph that is still an unregistered candidate.
| Area | Score | What earns the score | Why it is not 10/10 |
|---|---|---|---|
| Fabric Intelligence architecture | 9.6/10 | Typed contracts, one runtime-binding authority, guided sealed inputs, live server-attested SOP/application probes, durable execution and explicit lifecycle separation. | Broader multi-host operating proof and real production load evidence remain outstanding. |
| Governance and fail-closed safety | 9.7/10 | Unknown handlers, missing commissions, changed bindings, unavailable live authorities and uncertain completion stop or suspend execution; reconciliation cannot replay. | Needs production chaos, interruption and adversarial exercises across the complete cross-application workflow. |
| Toolsmith capability plane | 9.0/10 | Discovers the canonical manifest, composes exact capabilities, builds and qualifies supported-family adapter candidates, routes generic workbenches back to an exact Studio node and runs commissioned Skill Graph partitions through one supervisor. | Unknown families intentionally remain specifications until a trusted compiler and validators exist; promotion remains governed. |
| Supported Photoshop automation | 9.2/10 | 18 production-ready operations, a 47-action UXP v2 semantic provider, contract-aligned pairing, fail-closed parameters, source-preserving working copies, verified non-empty export receipts and no-replay reconciliation. | Only the provider inventory and representative duplicate/resize/PNG path have live proof. The 30 additional manifest operations need operation-family pilots, Adobe distribution and the accepted release corpus before production promotion. |
| Supported Unity automation | 8.8/10 | 66 production-ready operations cover semantic assets, importers, prefabs, scenes, serialized state, ScriptableObjects, Addressables, tests, screenshots and governed project actions. | Batch execution remains candidate; custom editor extension and menu-allowlist creation remain acquisition-only. Arbitrary project-specific editor behavior is not universal. |
| Character workflow design and runtime | 8.6/10 | The 26-node Photoshop→Unity graph, guided exact ticket contract, supervisor convergence, rollback boundaries, live drift authority and independent final-review gate are implemented. | The graph is not registered, qualified, certified, published or commissioned, and the reference Jira tickets do not yet contain accepted execution values. |
| Studio/operator experience | 9.2/10 | Capability maturity, exact Toolsmith route, provider setup, UXP pairing, no-replay reconciliation, guided character inputs, server-derived SOP evidence, graph lifecycle and drift requalification are visible without conflating authorities. | Real operator usability evidence and Adobe's external install/signing experience remain to be measured. |
| Complete zero-touch production autonomy | 6.5/10 | The control plane and supported execution path exist and fail closed instead of fabricating completion. | No commissioned character graph, signed/live-qualified UXP deployment or accepted 20-ticket end-to-end corpus exists yet. Therefore complete autonomous Photoshop/Unity production is not claimed. |
Bottom line.
Architecture readiness: 9.6/10. Supported-scope execution readiness: 8.9/10. Complete autonomous production readiness: 6.5/10. The code/product gaps identified in the prior review are closed. Fabric Intelligence can autonomously plan and execute operations already proven and commissioned. The production score does not rise from repository work alone: unknown, project-specific and candidate-only operations remain outside production authority, and accepted field evidence was explicitly excluded from this change.
Closed product gaps
The guided authoritative ticket editor, signed live SOP/application drift probes, first-class UXP pairing/health flow, durable no-replay unknown-completion reconciliation and exact Studio route into Toolsmith's supported-family implementation workbench are implemented. None of these actions grants production authority.
Next release gates
Sign and distribute the already installed UXP v2 provider, run family-specific pilots for its 30 additional candidate operations, execute the 20 unique accepted cross-application character tickets with independent final review, then explicitly register, qualify, certify, publish and commission the exact approved graph. These actions remain separate and none is implied by this score.
- P0 · Production evidence: accepted real-ticket corpus, source-preservation, interruption, rollback and multidisciplinary review evidence.
- P0 · Governed activation: explicit registration, no-write qualification, independent certification, publication and scoped commissioning.
- P1 · Photoshop deployment: signed/distributed UXP package, operator pairing, live health and exact-action qualification.
- Done · Operator setup: guided ticket contract builder plus authoritative live SOP/application evidence and status guidance.
- Done · Recovery UX: actual-state inspection and evidence-backed reconciliation for timed-out or disconnected UXP mutations, with no replay.
- P2 · Capability breadth: implement project-specific candidates through Toolsmith's typed workbench; never expose arbitrary C#, JSX or coordinates.
6
Learning Studio
Teach a workflow without granting authority
Fabric Intelligence Learning Studio turns one bounded, cross-application demonstration into reviewable evidence: a signed Task Workspace, human-readable semantic steps, capability matches or gaps, and a candidate procedure. It may retain separately consented, redacted visual evidence, but it is not raw video/mouse replay and is never a shortcut around Toolsmith, certification or commissioning.
Record available evidence
An identified user accepts the disclosure and chooses the task plus application scope. Accessibility retains allowlisted context; typed native adapters retain supported exact operations; an optional second consent enables redacted visual evidence in an encrypted local vault. Git and Perforce add fixed read-only readiness snapshots. Raw keys, passwords and clipboard contents are never retained.
Review what Fabric Intelligence understood
The saved recording library reopens the signed attempt. Each suggestion separates observed, inferred and not captured information. A human can revise, include, exclude or restore steps without mutating the original evidence. App switches and focus changes remain context-only unless an executable capability and target are proven.
Resolve before execution
Analysis performs bounded read-only capability matching and builds an advisory Skill Graph candidate. Existing qualified capabilities may bind; unresolved actions become exact Toolsmith review jobs. Candidate registration in Fabric Studio is separate from qualification, certification, publication and scoped commissioning. One sandbox success never makes a capability production-ready.
Evidence is graded, never guessed.
Exact provider-verified means a trusted installed build and session-native channel proved a typed target, arguments and required before/after/postcondition evidence. Exact provider-observed is typed but still lacks complete native proof. Visual-observed is separately consented, redacted human-review evidence. Context-only is application/focus chronology. Unobserved means Fabric Intelligence has no proof. Recording continues when a selected source degrades, but only exact provider-verified evidence can even enter the later replay checks.
Record and stop
Capture opens only after disclosure consent. Stop drains retained events; Cancel & discard closes the attempt without creating a candidate.
Review the semantic procedure
Keep only steps the evidence supports. A confidence score measures event detection, not understanding of a layer, pivot, scale, export setting or property value.
Analyze capability coverage
Independent read-only matches can run in bounded parallel, while signed Event Spine writes and the final join remain serialized and parent-owned.
Check sandbox readiness
The server re-reads the signed workspace, binds the exact procedure, rejects protected/game-shaped targets and validates without writes. A prepared description is not an authoritative disposable-sandbox attestation and does not contact an application.
Build or release deliberately
Send exact gaps to Toolsmith, register a resolved candidate in Fabric Studio, then Check → Test → Certify → Publish → Commission through the normal governed lifecycle.
Current execution boundary.
Finder, browser and spreadsheet navigation may use a separately approved, selector-based disposable test lane with an overlay and emergency stop. Signed exact-capture contracts/source seams now exist for these apps, but the trusted native products, keys and qualified physical manifests do not; their recordings therefore remain degraded and replay-blocked. Photoshop and Unity read-only checks revalidate exact bindings before contact. Governed writes remain blocked until every included step has exact provider-verified evidence, a commissioned provider binding, exact inputs and an authoritatively attested disposable or approved target.
Exact capture available for new recordings.
Photoshop Fabric Intelligence Provider 2.4.0 retains supported typed image resize/resolution, layer selection/name/visibility/opacity/blend, transform/movement, guide and exact-path export changes. Unity Toolsmith 1.2.0 retains supported typed component, GameObject, ScriptableObject, sprite-pivot and selected TextureImporter changes with stable targets, before/after values and post-import readback. The repository includes both adapter payloads and native-integrity protocols, but a signed installed Photoshop native challenge/hybrid add-on is still an external deployment gate. Historical focus-only recordings cannot be upgraded: if these facts were not captured, delete or retain the attempt as context and record it again after both selected adapters show connected and native verified.
Visual fallback helps review; it does not make replay exact.
With separate consent, the native ScreenCaptureKit lane retains bounded redacted before/after frames and normalized click phases in an encrypted, expiring local vault. Review-only analysis can explain likely visual changes or flag a region for attention. It cannot supply a Photoshop layer ID, Unity GlobalObjectId, path, property or numeric value, and a failure simply marks that interval degraded while the main recording continues.
Skills and specialist agents remain composed and governed.
Capability Center now shows a live physical-operation queue, exact bulk triage for retained learning gaps, the knowledge-only playbooks that still need reviewed execution contracts, and domain-agent profiles for Photoshop, Unity, GOTM character production, simulator validation, source-control integration, feature configuration and Toolsmith. All twelve GOTM playbooks have detached typed contract candidates for owner review; none writes to the game repository or opts a playbook into execution. The seven specialist profiles now have persisted disabled, decommissioned review drafts. A playbook can ground RAG before it is executable, and a draft can be designed before certification. Neither state grants tool, write, publication, commissioning or production authority.
Related gaps are grouped only for operator convenience: every Toolsmith review keeps the exact signed task, gap ID and digest. Evidence-only gaps produce a bounded recapture plan instead of a fake build request. A separate digest-sealed release-evidence projection keeps v3.3–v3.6 amber until the real distribution, corpus, independent-review and commissioning gates close.
Operator audit sequence.
Run tools/fabric_autonomy_inventory.py --format markdown, then generate disabled review batches with tools/fabric_qualification_batches.py --output /tmp/fabric-autonomy-qualification-batches.json. Review every blocker and collect real fixtures, accepted tickets, approvals and independent-review evidence. After an approved signing process has produced an archive, receipt and app, run tools/audit_macos_release.py --archive … --receipt … --app …. These commands inspect and package evidence only; they do not contact providers, qualify a case, enable an agent, commission a graph or authorize distribution.
Independent Unity attestor setup.
Operate the Ed25519 signer outside Fabric and mount only its bounded regular-file JSON feed read-only. Fabric pins FORGE_UNITY_DISPOSABLE_ATTESTATION_FILE, FORGE_UNITY_DISPOSABLE_ATTESTOR_ID and FORGE_UNITY_DISPOSABLE_ATTESTOR_PUBLIC_KEY; no private-key setting exists. For each completed review-ready Unity qualification, the attestor independently verifies the disposable target, isolation, requested operation, readback, package and restored Toolsmith session, then signs one short-lived record bound to the exact Studio job, candidate and receipt digests. A Master submits only the job ID for completion. Valid evidence closes that evidence gap but leaves every execution, publication, commissioning and production flag false. Operator boundary and failure states →
Implementation contract and progress: Fabric Intelligence demonstration learning and cross-application task state · prospective cross-app native capture contract · Fabric Intelligence autonomy buildout roadmap · external-gate audit boundary.
7
Learning
How Fabric Intelligence learns & how you train it
Fabric Intelligence gets sharper two ways: passively, by recording what happens on every run, and actively, when you hand-feed it knowledge in the Train Fabric Intelligence panel. Neither re-trains a neural network — Fabric Intelligence'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 Intelligence
The Train Fabric Intelligence 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 Intelligence 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 Intelligence 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 Intelligence 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 Intelligence 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 Intelligence panel feeds both at once: a document lands in RAG for retrieval, while a note also lands in memory as a durable teaching fact.
Storage and scope are visible, not implied.
Each workspace owns its RAG source list and derived retrieval index; a new workspace does not silently inherit another workspace's cache. Settings → Knowledge shows index readiness, chunks, source buckets, embedding model, build time and collector health. During a safe incremental refresh, healthy sources advance while a temporarily unavailable source retains its exact last verified chunks and is labelled Ready · degraded; a never-indexed source is reported as unavailable. A full rebuild remains fail-closed because it cannot truthfully claim a complete replacement snapshot. Weave working memory is a separate durable, workspace/session-scoped store with bounded verbatim turns, rolling compaction, pins, archives, integrity digests and an audit trail. Durable KB facts and run outcomes are the long-term learning authority; conversational working memory is context, not proof that a production action occurred.
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 Intelligence 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 Intelligence “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.
8
Best practices
How to train Fabric Intelligence well
Fabric Intelligence 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 Intelligence 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 Intelligence 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 Intelligence 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 Intelligence 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 Intelligence. 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.
↗
Current knowledge setup
RAG, memory, skills and Graphify
Source and index setup · Bounded memory · Skill indexing. User-added RAG source kinds are local, web and gsheet; playbook indexing is separate. Finalized runs request a background RAG refresh. Graphify refresh follows the configured repository revision and is distinct from embedding.
Code-review, validation-planning, feature-impact, root-cause and release-risk consumer contracts are implemented. Provider activation, provenance and task-quality evaluation remain explicit; a graph never supplies execution authority.