Integrate RAVEL with the persistent MNCS Fabric controller

README.md

@@ -6,7 +6,7 @@ RAVEL — the **Recursive Adaptive Vector Execution Lattice** — is an experime
 
 RAVEL operates beneath the technical authority of the Machine-Native Complexity Standard (MNCS) and the Machine-Native Complexity Development Standard (MNCDS). It is not intended to replace a language model, compiler, static analyzer, test framework, or the MNCS Forge. Its role is to decide what evidence should be gathered, what action should follow, and what experience should be retained for later use without redefining the governing status of that evidence.
 
-> **Project status:** RAVEL is research software. Historical RAVEL 0.4 and 0.5 results remain development `FAIL`; RAVEL 0.6 candidate-001 now has digest-bound policy/evaluator surfaces, separately compiled checkpoint and world/provider contracts, branching/ring unity parity, a Forge-governed development configuration, official MNCS bundle/receipt adapters, a bounded local Fabric development path, and lifecycle/memory integration. It remains unfrozen and has not been selection-evaluated, independently evaluated, or promoted. **Rust is now the canonical future implementation language** (`crates/`, `ravel-rust-foundation/0.1`); C and Python remain the historical and 0.6 compatibility surfaces. Formal MNCS/MNCDS conformance, independent attestation, protected custody, production safety, and general recursive self-improvement remain `UNKNOWN`.
+> **Project status:** RAVEL is research software. Historical RAVEL 0.4 and 0.5 results remain development `FAIL`; RAVEL 0.6 candidate-001 now has digest-bound policy/evaluator surfaces, separately compiled checkpoint and world/provider contracts, branching/ring unity parity, a Forge-governed development configuration, official MNCS bundle/receipt adapters, bounded local and persistent-controller Fabric development paths, and lifecycle/memory integration. It remains unfrozen and has not been selection-evaluated, independently evaluated, or promoted. **Rust is now the canonical future implementation language** (`crates/`, `ravel-rust-foundation/0.1`); C and Python remain the historical and 0.6 compatibility surfaces. Formal MNCS/MNCDS conformance, independent attestation, protected custody, production safety, and general recursive self-improvement remain `UNKNOWN`.
 
 ## Place in the MNCS ecosystem
 
@@ -114,13 +114,17 @@ algorithmic superiority. The bounded component surfaces in `src/ravel/world.py`,
 `src/ravel/transition.py`, `src/ravel/planning.py`, `src/ravel/checkpoint.py`,
 and `src/ravel/mechanism_state.py` provide deterministic provider substitution
 and checkpoint fixtures; they do not replace the historical 0.5 source.
-`src/ravel/fabric.py` adds the optional public Fabric local-controller path;
+`src/ravel/fabric.py` retains the local/direct-network compatibility paths and
 `tools/ravel_fabric_reference.py` runs branching/ring parity, replication,
 reconciliation, bundle, and replay/negative checks without dispatching selection
-or final material. The Rust crates under `crates/` and the `ravel-rs` CLI are
-the future implementation home; `src/ravel/rust_bridge.py` and
-`tests/test_rust_parity.py` prove discrete C/Python/Rust agreement without
-making either side authoritative. See [`docs/RUST_FOUNDATION.md`](docs/RUST_FOUNDATION.md).
+or final material. `src/ravel/fabric_persistent.py` is the preferred live Fabric
+consumer path: it connects through the persistent controller, delegates bundle
+transport and worker placement to Fabric, and supports detached execution with
+restart-safe RAVEL provenance metadata. The Rust crates under `crates/` and the
+`ravel-rs` CLI are the future implementation home; `src/ravel/rust_bridge.py`
+and `tests/test_rust_parity.py` prove discrete C/Python/Rust agreement without
+making either side authoritative. See [`docs/RUST_FOUNDATION.md`](docs/RUST_FOUNDATION.md)
+and [`docs/FABRIC_INTEGRATION.md`](docs/FABRIC_INTEGRATION.md).
 
 ## Non-goals
 

config/ravel-fabric-persistent.example.toml

@@ -0,0 +1,10 @@
+# RAVEL -> persistent MNCS Fabric consumer configuration.
+#
+# The persistent controller owns worker endpoints, TLS material, TrustStore
+# state, registries, bundle caches, placement, and execution lifecycle.
+# RAVEL receives only the controller consumer socket.
+[fabric]
+mode = "persistent-controller"
+socket_path = "/run/mncs-fabric/controller.sock"
+client_identity = "ravel"
+timeout = 5.0

docs/FABRIC_INTEGRATION.md

@@ -10,6 +10,96 @@ RAVEL semantic question
         -> RAVEL scoped advisory experience
 ```
 
+## Current live integration: persistent controller
+
+`FabricPersistentBackend` in `src/ravel/fabric_persistent.py` is the preferred
+live-development path. It consumes Fabric through the public
+`FabricClient.connect(controller.sock)` boundary and deliberately does **not**
+load or own:
+
+- worker host/port endpoints,
+- CA files, client certificates, or client keys,
+- TrustStore state,
+- worker registry files,
+- worker bundle-cache paths,
+- placement state, or
+- controller execution ledgers.
+
+Those remain Fabric-owned. RAVEL supplies a development-only semantic workload,
+an immutable MNCS execution bundle, required capabilities, and opaque provenance.
+Fabric owns admission, controller-side bundle transfer, placement, worker
+execution, raw records, receipts, and detached execution state.
+
+A minimal configuration is:
+
+```toml
+[fabric]
+mode = "persistent-controller"
+socket_path = "/run/mncs-fabric/controller.sock"
+client_identity = "ravel"
+timeout = 5.0
+```
+
+See
+[`config/ravel-fabric-persistent.example.toml`](../config/ravel-fabric-persistent.example.toml).
+
+The config parser is intentionally narrow. Worker endpoints and trust material
+are rejected if they are added to the persistent config. This prevents RAVEL
+from silently regaining responsibilities that belong to Fabric.
+
+### Synchronous and detached execution
+
+The backend supports both forms:
+
+```python
+from ravel.fabric_persistent import FabricPersistentBackend, FabricPersistentConfig
+
+backend = FabricPersistentBackend(
+    "build/fabric-live",
+    FabricPersistentConfig.load("config/ravel-fabric-persistent.toml"),
+)
+
+report = backend.execute_provider_parity("branching")
+```
+
+For long-running work RAVEL can submit and disconnect:
+
+```python
+submission = backend.submit_provider_parity("branching")
+print(submission.work_id)
+
+status = backend.execution_status(submission)
+report = backend.collect_submission(submission)
+```
+
+Detached submission metadata is written under
+`<workspace>/fabric-submissions/`. A later RAVEL process can recover it with
+`load_submission(work_id)` or collect the final evidence with
+`collect_work_id(work_id)`. Fabric remains the source of truth for execution
+state; the RAVEL metadata is only the provenance needed to interpret the
+returned evidence.
+
+No model is hard-coded into the adapter. `submit_provider_parity()` accepts an
+optional Fabric `model` and `role`, while the default leaves model/worker
+selection to the surrounding MNCS policy and Fabric capability inventory.
+
+### Authority and evidence boundary
+
+Fabric outcomes remain execution evidence. They are never promoted into a RAVEL
+evaluator verdict. Persistent reports therefore keep:
+
+```text
+Fabric execution outcome       PASS / FAIL / UNKNOWN
+Fabric reconciliation          UNKNOWN unless Fabric exposes it publicly
+RAVEL evaluator authority      separate
+promotion / selection authority not asserted
+```
+
+RAVEL explicitly refuses to reimplement Fabric reconciliation in the consumer
+process. If the persistent public API does not expose a Fabric-owned
+reconciliation result, the RAVEL report says `UNKNOWN` rather than fabricating
+independence.
+
 ## Versioned RAVEL contracts
 
 `ravel-fabric-workload/0.1` is RAVEL's semantic request. It binds the candidate,
@@ -30,14 +120,15 @@ The compatibility snapshot is
 [`ravel-0.6-family-compatibility-lock.json`](../ravel_versions/0.6/ravel-0.6-family-compatibility-lock.json);
 it is evidence about inspected public contracts, not an installation lockfile.
 
-## Local reference backend
+## Historical local reference backend
 
-`FabricLocalBackend` uses Fabric's public `FabricService`, `LocalController`,
-`LocalWorker`, manifest, receipt, challenge/replay, and reconciliation APIs. It
-builds a bounded development-only artifact and runs the branching and ring
-provider parity task on two logical workers. These workers share a process and
-host, so the report labels the scope `local-in-process-replication` and keeps
-independence `UNKNOWN`.
+`FabricLocalBackend` remains available for reproducible local development and
+negative-matrix testing. It uses Fabric's public `FabricService`,
+`LocalController`, `LocalWorker`, manifest, receipt, challenge/replay, and
+reconciliation APIs. It builds a bounded development-only artifact and runs the
+branching and ring provider parity task on two logical workers. These workers
+share a process and host, so the report labels the scope
+`local-in-process-replication` and keeps independence `UNKNOWN`.
 
 The local command is:
 
@@ -51,32 +142,27 @@ manifest and corrupt record (`FAIL`), idempotent duplicate request, and
 conflicting replay. A first valid challenge consumption is `PASS`; consuming
 the same challenge again is a Fabric `FAIL` and is retained rather than hidden.
 
-## Network boundary
+## Legacy direct-network boundary
+
+`FabricNetworkBackend` and `FabricNetworkConfig` are retained for historical
+compatibility and targeted network-reference testing. They directly describe
+TLS workers and require pre-staged bundles. They are **not** the preferred live
+fleet path now that Fabric exposes a persistent controller consumer API.
 
-`FabricNetworkBackend` is optional and TLS-only. `FabricNetworkConfig` requires
-operator-supplied CA, client certificate/key, trust store, worker endpoint,
-capabilities, and an exact pre-staged Fabric manifest identity. The checked-in
-[`ravel-fabric.example.toml`](../config/ravel-fabric.example.toml) contains only
-placeholders. RAVEL does not use SSH as a dispatch protocol, does not add a
-plaintext fallback, and does not claim native bundle transfer until Fabric
-exposes and verifies it.
+New live integrations should use `FabricPersistentBackend` instead of teaching
+RAVEL worker endpoints, trust material, or bundle staging.
 
-The report therefore keeps these facts separate:
+The legacy report keeps these facts separate:
 
 ```text
 bundle verified       PASS
 bundle pre-staged     PASS (local artifact root)
 archive executed      UNKNOWN
-receipt/archive probe FAIL (Fabric receipt currently binds its artifact manifest)
+receipt/archive probe FAIL (legacy Fabric receipt binds its artifact manifest)
 Fabric reconciliation PASS (Fabric question only)
 RAVEL evaluator       separate; normally UNKNOWN
 ```
 
-The receipt/archive probe is retained as a negative compatibility observation;
-it is not rewritten as an official execution binding. Native Fabric bundle
-transfer and a receipt adapter that binds the MNCS archive remain a sibling
-capability boundary.
-
 Fabric execution is not a sandbox, independent evaluation, protected custody,
 MNCS/MNCDS conformance, or promotion authority. Selection and future-final
-material are rejected by the workload contract and are not dispatched.
+material remain outside this development adapter.

ravel_versions/0.6/RAVEL_0_6_IMPLEMENTATION_STATUS.md

@@ -82,15 +82,27 @@ This is a development status record, not RAVEL 0.6 evaluation evidence.
   executions remain `UNKNOWN` until governed disposition exists; rejected and
   unavailable outcomes remain negative and deterministic retrieval includes
   them.
-- **Fabric development substrate:** `ravel.fabric` now defines the
+- **Fabric development substrate:** `ravel.fabric` defines the
   `ravel-fabric-workload/0.1` and `ravel-fabric-observation/0.1` boundaries,
   executes a bounded branching/ring provider-parity matrix through Fabric's
   public local controller/worker service, retains Fabric record/receipt/bundle
   identities, exercises challenge/replay and conflicting-request handling, and
   imports observations into advisory negative/`UNKNOWN` memory. Reconciliation
   is explicitly local in-process replication; it is not independence or final
-  evaluation. The TLS-only network adapter is implemented but unavailable
-  without operator trust material and pre-staged bundles.
+  evaluation. The TLS-only direct-network adapter remains available for
+  historical compatibility.
+- **Persistent Fabric consumer path:** `ravel.fabric_persistent` adds the
+  preferred live-development adapter for Fabric's persistent controller public
+  API. It connects through `FabricClient.connect(...)`, leaves worker endpoint
+  and trust material under controller ownership, delegates immutable bundle
+  transfer to Fabric, supports controller-owned placement and execution,
+  supports detached `submit/status/result` lifecycles, and persists only the
+  RAVEL provenance needed to recover a detached submission after a client
+  restart. Persistent Fabric outcomes remain development observations and do
+  not become evaluator, selection, promotion, or conformance authority. The
+  adapter intentionally reports Fabric reconciliation `UNKNOWN` until a
+  Fabric-owned reconciliation result is exposed through the persistent public
+  boundary.
 
 ## Not yet implemented or externally unavailable
 
@@ -119,9 +131,14 @@ This is a development status record, not RAVEL 0.6 evaluation evidence.
   are not declared by the frozen contract. Forge/RAVEL lifecycle mapping is
   reference-only and does not collapse the two state machines. Observation /
   reporting remains the next safe C extraction candidate after dependency review.
-- The project-local Forge configuration now declares Fabric capability,
-  reference, negative-matrix, and family-compatibility-lock workflows. The
-  local Fabric path is optional for package import and ordinary CI.
+- The project-local Forge configuration declares Fabric capability, local
+  reference, negative-matrix, and family-compatibility-lock workflows. A live
+  persistent-controller E2E workflow still needs to be executed on an enrolled
+  multi-worker Fabric fleet; CI cannot claim that external controller evidence.
+- A Rust-native persistent Fabric client is not yet implemented. Python remains
+  the compatibility bridge for the current Fabric public API while the boundary
+  stabilizes; the eventual Rust port must preserve the same authority and
+  provenance semantics and prove parity before replacement.
 - R6-05 selection evaluation and promotion logic have not been consumed. The
   ledger is infrastructure only; no candidate is frozen or selected by it.
 - R6-06 external final custody/evaluation remains unavailable and `UNKNOWN`.

src/ravel/__init__.py

@@ -7,6 +7,7 @@
     "development_evaluator",
     "experience",
     "fabric",
+    "fabric_persistent",
     "knowledge",
     "lifecycle",
     "matched_compute",