J94/bit-vector-tensor-control-policy

Bit/Vector/Tensor Control Policy

Clean product one-liner: a standalone control-system repo with one local graph kernel stack, one conversational API, one orchestrator UX, and first-class control benchmarks driven by bits, vectors, and tensors.

Layman version: this should be one self-contained machine, not a folder of pointers to other machines.

Inference Surface

Clean product one-liner: graph-first reasoning can now be delegated to the local Codex CLI through one repo-root YAML config.

Self-Improve Loop

Clean product one-liner: the repo can now propose one bounded self-improvement through Codex CLI, package it as a manifest, and optionally apply and benchmark it.

What This Is

Pareto read:

Better wording:

This repo is a standalone agent harness that should operate:

• —metacognitively: inspect state, confidence, and reasoning posture
• —metacybernetically: regulate routes, gates, escalation, and proof loops
• —cross-surface adaptively: distill patterns across memory, runtime, API, UX, and benchmarks

It is not yet a classical federated-learning runtime with gradient or weight aggregation. It is closer to receipt-backed policy distillation over a graph-mediated runtime.

Product Boundary

conversation -> control policy -> graph state -> benchmarked runtime -> operator UX

Orchestrator Loop

flowchart LR
  U["User Ask"] --> A["POST /turn"]
  A --> P["Policy: bits, vectors, tensors"]
  P --> R["Runtime route + lane choice"]
  R --> G["Graph state"]
  R --> E["Bounded execution lane"]
  E --> X["Receipt + graph update"]
  G --> A
  X --> A
  A --> V["Chat / Confirm / Inspect UX"]

Cause And Effect

Layman version: emergence comes from consequences feeding back into the same loop, not from hidden magic in the model.

Core Visibility

Start here if you want to understand the machine, not just the file tree:

• —`docs/core_workflows_v0.md`
• —`docs/api_surface_v0.md`
• —`docs/emergent_feature_taxonomy_v0.md`
• —`docs/corpus_reasoning_substrate_v0.md`
• —`docs/adding_benchmarks_v0.md`

This repo is the shipped product surface.

It should contain:

• —one local graph kernel
• —one local product runtime
• —one local control-language pack
• —one local conversational API contract
• —one local orchestrator UX contract
• —one local control benchmark suite

The current cross-repo hotgraph is a bootstrap intake lane only. It helps import and compare source systems, but it is not the long-term shipped boundary.

Why This Is More Than A Chat Agent

Standalone Benchmark Results

Latest standalone run:

• —`runs/benchmark/standalone-control-20260421T104519Z/summary.json`
• —`runs/benchmark/standalone-control-20260421T104519Z/report.md`

Scorecard metrics

Why this is on product

Run it locally:

rtk ./bin/bvtctl benchmark

Vector frontier

Tensor frontier

Layman version: the standalone harness now proves that the same API surface can stay in reasoning mode when authority should stay closed, and switch into receipt-backed execution when authority should open.

Stability frontier

Quickstart

1. Start from one conversational front door

./bin/bvtctl "summarise the current runtime"
./bin/bvtctl chat
./bin/bvtctl ask "run the demo manifest" runtime/examples/demo_manifest.json
./bin/bvtctl context
./bin/bvtctl bootstrap-context

Why in plain English: the product should meet the operator as one sentence-driven CLI first, and it should explain its own lineage and policy without repo spelunking.

2. Bootstrap from the current source field

./scripts/build_hotgraph.sh

Outputs:

• —hotgraph/source_hotgraph.json
• —hotgraph/source_hotgraph.md

3. Generate one bootstrap control packet

./scripts/run_v0.sh migration_brief

Outputs:

• —runs/<timestamp>/control_packet.json
• —runs/<timestamp>/brief.md

4. Read the product slices

Start with:

• —docs/core_workflows_v0.md
• —docs/api_surface_v0.md
• —docs/emergent_feature_taxonomy_v0.md
• —docs/standalone_layout.md
• —docs/runtime_and_cli.md
• —docs/kernel_import_plan.md
• —docs/usecases.md
• —docs/research_and_generation.md
• —hotgraph/source_hotgraph.md

5. Build the corpus reasoning packets

./bin/bvtctl corpus-packets

Why in plain English: this should build one mathematical packet per promoted abstraction so Codex can reason over state packets first and reopen raw evidence only when the packet state says it must.

6. Generate from reduced state

The intended flow is:

1. 1.use the bootstrap hotgraph to decide what to import or vendor
2. 2.move the chosen slice into the local product layout
3. 3.benchmark the local slice through the control language
4. 4.expose it through the conversational API and orchestrator UX

Primary Use Cases

Repo Layout

Product Slices

Pareto read:

Layman version: the benchmark, API, and UX are not sidecars. They are part of the shipped machine.

Bootstrap Intake

The intake field is still:

• —NIX.codecli
• —tmp-meta3-engine-test
• —meta3-graph-core
• —dreaming-kernel
• —nix-star
• —causal-workbench
• —tiny_graph_engine

These are source systems to compare and import from. They are not the final runtime boundary of this repo.

Kernel Stack Target

Layman version: import the best engine, keep one dashboard, and mount the gauges inside the same car.

CLI

Use the current CLI like this:

./bin/bvtctl "summarise the current runtime"
./bin/bvtctl ask "run the demo manifest" runtime/examples/demo_manifest.json
./bin/bvtctl chat
./bin/bvtctl context
./bin/bvtctl bootstrap-context
./bin/bvtctl bootstrap
./bin/bvtctl run migration_brief
./bin/bvtctl execute
./bin/bvtctl kernel-plan
./bin/bvtctl benchmark
./bin/bvtctl packet migration_brief
./bin/bvtctl policy
./bin/bvtctl scorecard
./bin/bvtctl runtime
./bin/bvtctl api
./bin/bvtctl ux

Why in plain English: the sentence form is now the default front door; the named commands are the operator shelf behind the desk.

First Local Imports

The first real local slices are now:

• —policy/control_language_v0.json
• —policy/runtime_profiles_v0.json
• —benchmarks/control_scorecard_v0.json
• —benchmarks/control_scorecard_v0.md
• —runtime/work_manifest_v0.json
• —runtime/work_manifest_packet_v0.json
• —runtime/examples/demo_manifest.json
• —runtime/examples/demo_exec_manifest.json
• —api/conversational_api_v0.json
• —ux/orchestrator_ux_v0.md
• —vendor/meta3-graph-core/schema/receipt_v1.json

Why: the control language and proof surface are the fastest way to make this repo operational before deeper kernel import.

Working Rule

Pareto frontier:

• —do not ship a repo of external path pointers
• —do not invent a new kernel if an off-the-shelf one is already stronger
• —do not let docs become the only state
• —do not treat benchmarks, API, or UX as optional afterthoughts

Instead:

1. 1.compare source systems
2. 2.choose the strongest slice
3. 3.import it into the local layout
4. 4.benchmark it through bits/vectors/tensors
5. 5.expose it through one API and one UX

Current Read

Best direction today:

• —meta3-graph-core = graph kernel import target
• —causal-workbench = product-runtime pattern
• —nix-star = control-language and policy pattern
• —NIX.codecli = conversational API/orchestrator UX reference field
• —local benchmarks/ = mandatory proof surface

That is why this repo exists: to turn the best scattered ideas into one standalone control product.