These are bounded maintenance tasks, supporting the research program and its continuity charter. Choose research experiments from existing evidence, equivalent controls, and falsifiers; do not infer comparative advantage from these engineering lanes.
These are the best next tasks for a contributor who wants to ship something real instead of only studying the architecture.
Use this board when deciding what to do next.
Before starting a new lane, run it through
spec/rfcs/RFC-00D2-daios-target-architecture-and-sequencing.md:
If those answers are unclear, narrow the work before starting it.
docs/reference/RFC_00D1_CONTRACT_REVIEW_CHECKLIST.md when touching the
current build-against boundarysafetensors-first intake path that treats model files as
auditable execution inputs; prefer CanonFS-backed manifests, tensor identity,
and reproducible import/report behavior over broad “AI runtime” expansion;
current framing memo:
docs/explanation/MODEL_ARTIFACT_STRATEGY.md
Current prototype contract:
docs/contracts/MODEL_IMPORT_V1_CONTRACT.md
Current pipeline contracts:
docs/contracts/MODEL_MANIFEST_V1_CONTRACT.md,
docs/contracts/MODEL_DIFF_V1_CONTRACT.mdt81 ai ..., weights ..., and internal llama-run documentation
aligned with what currently executes versus what is still scaffoldedWork these in order unless an active regression or CI failure is blocking the repo.
examples/.
Current seed example: examples/storage-and-canonfs/canonfs-interchange/.safetensors / gguf model-artifact intake wedge as a narrow,
buildable extension of CanonFS provenance and import/export behavior.
Current reference:
docs/explanation/MODEL_ARTIFACT_STRATEGY.md
Current JSON contract:
docs/contracts/MODEL_IMPORT_V1_CONTRACT.md
The first practical step should be a safetensors-first import/report path,
not a broad runtime or OS claim.
Current next question:
decide whether to keep model diff representation-sensitive or add a
normalization-aware comparison mode for cross-format pairs like
.gguf versus safetensors.
Current design sketch:
docs/explanation/MODEL_DIFF_NORMALIZATION_SKETCH.md
Current reviewer walkthrough:
examples/ai-and-inference/model-artifact-review/README.md
Current smoke helper:
scripts/ci/run_model_artifact_review_smoke.shdocs/explanation/DETERMINISTIC_AI_OS_OBJECT_SUBSTRATE_REFERENCE_MEMO.md
should be the standard check before broadening external language about
DAIOS, AI operating systems, or generalized deterministic AI claims.docs/status/BOUNDED_AI_OS_OBJECT_FAMILY_STATUS.md,
docs/reference/AI_OS_OBJECT_FAMILY_ADMISSION_CONTRACT.md,
and docs/reference/AI_OS_OBJECT_CHAIN_CATALOG.md.
The next work on this lane should be stabilization and misuse-path
hardening, not a fourth composition unless a concrete consumer justifies it.kind, code, reason, and
messageprovenance_schema and
manifest_schemadraftThe practical result is that a contributor can now tell which interchange fields are the current v1 candidate surface and which questions are still intentionally deferred.
t81 ai inference run lane into a reusable runtime state path.
Current state:
the strict deterministic t81_reference_vm lane is already real. It now
runs a bounded native Llama-shaped probe with tokenizer-aware candidate
selection, row-wise logits scoring, explicit readiness posture, checked-in
ready / guarded / degraded examples, and a bounded decode path with
real carried hidden-tensor, q/k, forward-state, and combined
architecture-state evidence. That lane now reaches a bounded 4-step
horizon, has a distinct deep fourth-step architecture-state mode, and
emits explicit horizon metadata such as bounded_horizon_steps,
bounded_horizon_remaining, bounded_horizon_utilization, and
termination_reason: "deep_architecture_state_horizon_reached".
This means the old “replace the synthetic payload” task is effectively
complete for the strict deterministic reference-VM path.
It also now has:
t81::vm::Decoder)The practical result is that the old extraction/convergence task is done enough that it should not stay on the active board unless a new concrete consumer appears.
Additional progress now completed on this lane:
(DONE) Add another non-CLI consumer of the public decode/probe path by
exercising the shared request-builder and intermediate-state handoff
directly in VM-side tests, alongside the public Decoder.
llama-dense-v1 architecture, reusing the public
decode/probe surfaces and IntermediateDecodeState continuation
contract rather than creating a parallel stack.If this lane is revisited later, the next worthwhile work is:
benchmark run and policy test out of scope for this lane until
their current scaffolded behavior is explicitly being replaced.reason values in interchange error objectskind / code mapping derived from those reasonscanonfs import / canonfs export JSON rendering in core and CLIexamples/storage-and-canonfs/canonfs-interchange/The practical result is that CanonFS interchange is now much closer to a contributor-facing contract surface than an implementation detail.
If this lane is revisited next, the highest-value work is:
(DONE) Make the built-in RFC-00D1 policy-profile surface explicit.
Current state:
the four shipped built-in interchange policy profiles now have a reusable
core description, user-visible CLI help text, example coverage, and direct
core plus CLI tests. The repo now says plainly what permissive,
import-only, export-only, and deny-all do instead of leaving those
semantics implicit in code and denials.
It now has:
t81 canonfs help text that explains the built-in profiles directlydeny-allThe practical result is that the built-in profile surface is now a real, contributor-facing contract instead of maintainer memory.
Additional progress now completed on this lane:
(DONE) Add a small checked-in policy-document example that shows how an
explicit policy file can narrow an otherwise allowed built-in profile
into a real partial import/export result.
Current state:
the CanonFS interchange example now includes an alpha-only checked-in
policy file plus CLI contract coverage that demonstrates:
partial when one path is admitted
and another is denied by policypolicy_denied evidenceThe practical result is that a contributor can now learn the current
ok / partial / error interchange posture from checked-in examples
instead of inferring it from implementation details.
If this lane is revisited next, the highest-value work is:
t81::vm decode/probe path rather than reopening the
just-finished CLI extraction work.Why this matters:
Concrete work:
partial import/export resultKey files:
Definition of done:
partial result, without reading the
implementationWhy this matters:
Concrete work:
draftKey files:
Definition of done:
Suggested first read:
Why this matters:
Concrete work:
Key files:
fs/, tools/, or a future net/ moduleDefinition of done:
Suggested first read:
Why this matters:
Concrete work:
Key files:
Definition of done:
Why this matters:
Concrete work:
Key files:
Definition of done:
Current workflow audit:
ci.yml as the main integration lane, cross-platform-determinism.yml as the
multi-OS hash-verification lane, qemu-boot.yml / qemu-boot-x86.yml as
architecture-specific boot capture lanes, and python-wheels.yml /
release.yml as packaging lanes.First safe consolidation candidate:
(DONE) fold deterministic-profile-enforcement.yml into a named job inside
ci.yml.
Current state:
the deterministic-profile static/file checks now live in the main CI
workflow as product / deterministic profile enforcement, while the
duplicate standalone workflow and duplicate rebuild/test path are gone.
runtime-contract.yml should remain standalone or
become a narrow ci.yml job.bench.yml,
benchmark_packed_trit_vector.yml, inference-bench.yml, and
repro-ledger.yml by centralizing shared benchmark setup and keeping only one
PR-sensitive regression gate. The rest should stay manual or scheduled unless
they protect a current product contract.Recommended order:
ci.yml.runtime-contract.yml standalone for now.
Current state:
this lane has materially different coupling from the main CI path:
t81-vm repository rather than only this repoworkflow_dispatch approval input for intentional
contract-marker drift (allow_contract_change)The practical result is that folding it into ci.yml right now would mix a
cross-repo approval gate into the main integration lane without obviously
reducing maintainer load.
scripts/ci/, so the remaining work is no longer
basic CMake duplication. The next decision is which single PR-sensitive
benchmark regression gate should remain prominent once workflow purposes are
compared side by side.
Additional progress now completed:
bench.yml remains the primary benchmark-sensitive lane because it owns
the current VM workload guardrailbenchmark_packed_trit_vector.yml has been narrowed to scheduled/manual
specialist coverage instead of remaining a second push / pull_request
benchmark workflowinference-bench.yml has been narrowed to scheduled/manual plus release
publishing because it refreshes a benchmark report rather than protecting a
single narrow PR regression contract