nsaspy/prolog-rlm

Fork 0

[EPIC][P0] First-class Prolog expert system: registry, routing, specialists, and closed-loop Spec→Plan→Expert→Verify→Repair #422

New issue

Open

opened 2026-09-08 01:29:22 +00:00 by nsaspy · 6 comments

nsaspy commented

2026-09-08 01:29:22 +00:00

Owner

Mission

Make expert systems a first-class intelligence layer in prolog-rlm and carry that architecture all the way through a complete bounded autonomous loop:

operator requirement / existing Frozen Spec
        ↓
normalize + validate requirement
        ↓
acquire coherent symbolic project knowledge
        ↓
construct / refine typed dependency plan
        ↓
select applicable expert(s) in Prolog
        ↓
execute expert reasoning
        ↓
invoke typed tools/effects only when required
        ↓
observe fresh evidence
        ↓
VERIFY exact Frozen Spec
        ↓
 satisfied ───────────────→ structured completion
 violated/unknown/blocked
        ↓
diagnose gap / failure
        ↓
repair / gather evidence / replan
        └──────────────────→ bounded loop

The goal is not another agent framework. The goal is a reusable classical/symbolic expert substrate that existing RLM, plan, graph, tool, source-KB, SPEC and VERIFY machinery can compose with.

Operator decision: experts are free by default

A Prolog expert invocation is ordinary local computation.

pure Prolog inference       -> 0 model calls, $0
local KB / xref / graph     -> 0 model calls, $0
expert -> expert recursion  -> 0 model calls, $0
local deterministic adapter -> 0 model calls, $0
explicit LLM fallback       -> model usage is metered
explicit paid external API  -> that API usage is metered

Do not attach a model-token or monetary charge merely because an expert is invoked or nested.

Experts are still bounded by normal computational/runtime safety controls: cancellation, recursion/depth, inference/work limits, wall time, output limits, concurrency and capability/authority ceilings. These are resource/safety bounds, not a model-usage tax.

Any expert that uses an LLM must do so through an explicit fallback event that is visible in the trace and usage ledger. The expert remains a Prolog expert; the model is a fallback capability, not the identity of the expert.

Canonical architectural boundaries

This epic is compatible with the restored repository boundary in #141:

prolog-rlm owns reusable expert contracts, symbolic algorithms, source/project knowledge APIs, Spec/Plan/Verify integration, capability/authority semantics and generic tool abstractions.
lost-rob0t/agentProlog owns product-specific coding tool implementations, product UX, product presets and concrete filesystem/Git/process/test packs where those are product-specific.
An expert in core may reason over a typed host-supplied capability without owning the concrete downstream implementation.

Do not revive #49/#50's old in-repo concrete coding-tool catalog architecture.

Reuse; do not fork runtime machinery

This epic MUST compose with the existing canonical systems rather than create parallel ones:

#288 typed project-op plan graph / dependency execution;
#355 D6-11 plan-native deterministic operations;
#93 Project / source knowledge / SPEC / VERIFY;
#56 proof/evidence acceptance;
#68–#71 compiler/workflow/continuation loop;
#219 retrieval/source-KB infrastructure;
existing rlm_tool, capabilities, authority, durable effects, async/Futures, cancellation, traces, graphs, context and provider runtime.

There is exactly one scheduler/graph runtime, one capability model, one authority boundary, one durable effect mechanism and one verification truth boundary.

D6-11 is mandatory

The following closed deterministic state-mutating operations remain plan-native, not expert-owned:

sync_remote/1
run/1
index/1
delete/1

They execute through the canonical schema → capability → authority → durable-effect/observation boundary as specified by #355.

Experts may reason about when these operations are needed and may produce typed plan requirements that include them, but they do not become fake "experts" merely to execute deterministic adapters.

edit/2 and create/2 remain write-expert-owned at the reasoning/payload-production layer. The actual filesystem mutation remains behind the canonical tool/effect boundary.

First-class expert contract

Add one reusable expert abstraction with semantics equivalent to:

expert_register(+Registry, +Contract, -Outcome).
expert_unregister(+Registry, +ExpertId, -Outcome).
expert_catalog(+Registry, -Catalog).
expert_applicable(+Registry, +Goal, +Context, -Candidates).
expert_select(+Registry, +Goal, +Context, -Decision).
expert_invoke(+Registry, +ExpertId, +Goal, +Context, -Outcome).
expert_explain(+DecisionOrOutcome, -Explanation).

Exact names/arity follow repository conventions.

A contract should carry normalized, inspectable metadata such as:

stable expert id/version
accepted goal/input schema
output/evidence schema
specialties / applicability rules
required observations
required callable capabilities
possible effect classes
fallback policy
child-expert policy
runtime bounds
trusted handler identity

Callable closures remain host/trusted runtime data. Model-visible catalogs expose sanitized schemas/metadata, never arbitrary executable terms.

Availability != selection != authority

Keep these separate:

expert registered
    != expert applicable
    != expert selected
    != tool available
    != capability possessed
    != authority granted
    != effect admitted

An expert cannot widen its caller's capability/authority ceiling. Expert→expert calls narrow or preserve ceilings according to the existing capability model and may never silently escalate.

Expert selection belongs to Prolog

The runtime should be able to route goals using facts/rules/constraints without a model call.

Conceptual shape:

expert_for(project_knowledge(_), project_knowledge_expert).
expert_for(repository_state(_), git_expert).
expert_for(edit(_, _), write_expert).
expert_for(create(_, _), write_expert).
expert_for(verify(_), verify_expert).
expert_for(repair(_), repair_expert).

Real selection should support more than a flat predicate: preconditions, current evidence, goal type, project state, required capabilities, confidence/priority, conflicts and fallback ordering.

If no expert is applicable, return a structured unsupported/unknown result. Do not silently ask a model to invent an expert.

Expert recursion and cooperation

Experts may call other experts as structured subgoals.

Required semantics:

stable parent/child invocation identity;
bounded recursion/depth/work;
cancellation propagation;
capability narrowing;
no default model charge for nesting;
no hidden independent scheduler;
cycle/repetition detection;
structured result/evidence propagation;
inspectable reason for delegation.

Example:

write expert
  -> project knowledge expert (resolve symbol/span)
  -> git expert (inspect worktree/preimage state)
  -> produce typed edit action
  -> plan-native/index freshness update
  -> verify expert

Expert result contract

Experts should return structured outcomes compatible with the runtime's existing structured result/evidence conventions, at minimum distinguishing:

succeeded(Result, Evidence)
failed(Reason, Evidence)
unknown(Reason, Evidence)
blocked(Reason, Evidence)
unsupported(Reason)
cancelled(Token)
error(Error)

Do not collapse missing evidence into falsehood or model prose into evidence.

Proof and explanation

For every material decision, retain enough inspectable state to answer:

Why was this expert selected?
What facts/rules made it applicable?
What evidence did it consume?
What capabilities/tools did it invoke?
What did it derive versus directly observe?
Did it use an LLM fallback? Why?
What remains unknown?
Why did the loop continue or stop?

This is structured explanation/provenance, not a requirement to expose private model chain-of-thought.

LLM fallback contract

Each expert may declare an explicit fallback policy. Default is none unless the expert genuinely benefits from a model fallback.

Conceptual classes:

no_fallback
nl_normalization_fallback
semantic_generation_fallback
review_fallback
conversation_render_fallback

Fallback MUST:

be triggered for an explicit structured reason;
use the existing provider/model runtime;
preserve capability/authority ceilings;
be separately metered in normal model usage;
emit a trace event linking the fallback call to the expert invocation;
never convert model output directly into trusted executable Prolog;
validate/normalize any model-produced structured data before use.

Full closed loop

The eventual integration target is a canonical reusable expert workflow equivalent to:

1. Requirement/Spec Expert
   normalize requirement; validate/freeze exact obligations

2. Project Knowledge Expert
   acquire coherent fresh project/source state

3. Planner/Coordinator Expert
   construct a typed dependency graph and choose expert responsibilities

4. Specialist execution
   Git / Retrieval / Write / other experts derive actions and evidence
   deterministic plan-native ops execute at plan layer

5. Verify Expert
   verify the exact Frozen Spec against fresh observable evidence

6. If not satisfied:
   Repair/Diagnosis Expert identifies the smallest evidence/action gap
   Planner updates the plan without weakening Frozen Spec
   loop resumes

7. Review/Critic Expert
   adversarially checks changed state/evidence for hidden regressions or unsupported claims

8. Final Verify
   only observable evidence satisfying Frozen Spec closes the run

The loop is bounded by explicit progress/recursion/time/work/tool/effect limits and stops structurally on no-progress, blocked requirements, cancellation or exhausted limits.

Child epics

This parent owns the architecture and integration. Create focused epics for:

canonical expert runtime / registry / selection / invocation;
requirement + SPEC expert;
plan/coordinator expert;
project symbolic knowledge expert;
retrieval/evidence expert;
Git/repository expert;
write/edit/create expert;
VERIFY expert;
repair/diagnosis expert;
review/critic expert.

Each child must remain independently testable and integrate through the shared contract.

Acceptance — expert substrate

Experts are first-class registered/inspectable runtime capabilities.
Pure/nested expert execution performs zero provider calls and incurs zero model-token/cost accounting.
Explicit LLM fallback is separately traced and metered.
Prolog can select an expert from goal/context/evidence without an LLM.
Expert→expert recursion is bounded, cancellable, capability-narrowed and traceable.
Direct/native callers and plan/workflow callers reach the same expert contract rather than separate expert implementations.
D6-11 plan-native operations are rejected from expert registration/mapping where required.
Expert handlers cannot widen authority or bypass canonical tool/effect admission.
Structured explanations identify selection basis, evidence and fallback usage.

Acceptance — full loop

A deterministic fixture must prove a complete loop with zero model calls:

structured requirement
  -> Frozen Spec
  -> project symbolic observations
  -> typed plan
  -> specialist expert selection
  -> one controlled change/action fixture
  -> fresh observation
  -> VERIFY failure
  -> diagnosis/repair subgoal
  -> second action
  -> fresh observation
  -> VERIFY success
  -> final structured evidence-backed completion

Also prove:

a blocked/unknown requirement does not become success;
repair cannot weaken/mutate the Frozen Spec;
repeated no-progress state terminates deterministically;
expert recursion cycles are detected;
stale project/source evidence cannot satisfy final verification;
write effects use expected-state/preimage semantics;
cancellation aborts the loop without further expert/effect dispatch;
an equivalent run with an explicitly enabled model fallback records only the fallback provider usage, not a charge for expert invocations themselves.

Non-goals

No second agent framework.
No model-required expert identity.
No ambient filesystem/Git/shell/network authority in core experts.
No product-specific AgentProlog UI or product tool implementations in this repository.
No expert may mutate a Frozen Spec to manufacture success.
No arbitrary model- or project-generated term passed to unrestricted call/1.

Migration/reconciliation

As the child epics land, reconcile older expert research/issues against this contract. Preserve useful evidence/research, but close or supersede issue-level architecture that assumes experts are inherently model sessions or that expert invocation itself should be token/cost charged.

Refs #141 #288 #355 #93 #56 #68 #69 #70 #71 #219 #353 #354

## Mission Make **expert systems a first-class intelligence layer in `prolog-rlm`** and carry that architecture all the way through a complete bounded autonomous loop: ```text operator requirement / existing Frozen Spec ↓ normalize + validate requirement ↓ acquire coherent symbolic project knowledge ↓ construct / refine typed dependency plan ↓ select applicable expert(s) in Prolog ↓ execute expert reasoning ↓ invoke typed tools/effects only when required ↓ observe fresh evidence ↓ VERIFY exact Frozen Spec ↓ satisfied ───────────────→ structured completion violated/unknown/blocked ↓ diagnose gap / failure ↓ repair / gather evidence / replan └──────────────────→ bounded loop ``` The goal is not another agent framework. The goal is a reusable **classical/symbolic expert substrate** that existing RLM, plan, graph, tool, source-KB, SPEC and VERIFY machinery can compose with. ## Operator decision: experts are free by default A Prolog expert invocation is ordinary local computation. ```text pure Prolog inference -> 0 model calls, $0 local KB / xref / graph -> 0 model calls, $0 expert -> expert recursion -> 0 model calls, $0 local deterministic adapter -> 0 model calls, $0 explicit LLM fallback -> model usage is metered explicit paid external API -> that API usage is metered ``` Do **not** attach a model-token or monetary charge merely because an expert is invoked or nested. Experts are still bounded by normal computational/runtime safety controls: cancellation, recursion/depth, inference/work limits, wall time, output limits, concurrency and capability/authority ceilings. These are resource/safety bounds, not a model-usage tax. Any expert that uses an LLM must do so through an **explicit fallback event** that is visible in the trace and usage ledger. The expert remains a Prolog expert; the model is a fallback capability, not the identity of the expert. ## Canonical architectural boundaries This epic is compatible with the restored repository boundary in #141: - `prolog-rlm` owns reusable expert contracts, symbolic algorithms, source/project knowledge APIs, Spec/Plan/Verify integration, capability/authority semantics and generic tool abstractions. - `lost-rob0t/agentProlog` owns product-specific coding tool implementations, product UX, product presets and concrete filesystem/Git/process/test packs where those are product-specific. - An expert in core may reason over a **typed host-supplied capability** without owning the concrete downstream implementation. Do not revive #49/#50's old in-repo concrete coding-tool catalog architecture. ## Reuse; do not fork runtime machinery This epic MUST compose with the existing canonical systems rather than create parallel ones: - #288 typed project-op plan graph / dependency execution; - #355 D6-11 plan-native deterministic operations; - #93 Project / source knowledge / SPEC / VERIFY; - #56 proof/evidence acceptance; - #68–#71 compiler/workflow/continuation loop; - #219 retrieval/source-KB infrastructure; - existing `rlm_tool`, capabilities, authority, durable effects, async/Futures, cancellation, traces, graphs, context and provider runtime. There is exactly one scheduler/graph runtime, one capability model, one authority boundary, one durable effect mechanism and one verification truth boundary. ## D6-11 is mandatory The following closed deterministic state-mutating operations remain **plan-native**, not expert-owned: ```text sync_remote/1 run/1 index/1 delete/1 ``` They execute through the canonical schema → capability → authority → durable-effect/observation boundary as specified by #355. Experts may reason about when these operations are needed and may produce typed plan requirements that include them, but they do not become fake "experts" merely to execute deterministic adapters. `edit/2` and `create/2` remain **write-expert-owned** at the reasoning/payload-production layer. The actual filesystem mutation remains behind the canonical tool/effect boundary. ## First-class expert contract Add one reusable expert abstraction with semantics equivalent to: ```prolog expert_register(+Registry, +Contract, -Outcome). expert_unregister(+Registry, +ExpertId, -Outcome). expert_catalog(+Registry, -Catalog). expert_applicable(+Registry, +Goal, +Context, -Candidates). expert_select(+Registry, +Goal, +Context, -Decision). expert_invoke(+Registry, +ExpertId, +Goal, +Context, -Outcome). expert_explain(+DecisionOrOutcome, -Explanation). ``` Exact names/arity follow repository conventions. A contract should carry normalized, inspectable metadata such as: ```text stable expert id/version accepted goal/input schema output/evidence schema specialties / applicability rules required observations required callable capabilities possible effect classes fallback policy child-expert policy runtime bounds trusted handler identity ``` Callable closures remain host/trusted runtime data. Model-visible catalogs expose sanitized schemas/metadata, never arbitrary executable terms. ## Availability != selection != authority Keep these separate: ```text expert registered != expert applicable != expert selected != tool available != capability possessed != authority granted != effect admitted ``` An expert cannot widen its caller's capability/authority ceiling. Expert→expert calls narrow or preserve ceilings according to the existing capability model and may never silently escalate. ## Expert selection belongs to Prolog The runtime should be able to route goals using facts/rules/constraints without a model call. Conceptual shape: ```prolog expert_for(project_knowledge(_), project_knowledge_expert). expert_for(repository_state(_), git_expert). expert_for(edit(_, _), write_expert). expert_for(create(_, _), write_expert). expert_for(verify(_), verify_expert). expert_for(repair(_), repair_expert). ``` Real selection should support more than a flat predicate: preconditions, current evidence, goal type, project state, required capabilities, confidence/priority, conflicts and fallback ordering. If no expert is applicable, return a structured unsupported/unknown result. Do not silently ask a model to invent an expert. ## Expert recursion and cooperation Experts may call other experts as structured subgoals. Required semantics: - stable parent/child invocation identity; - bounded recursion/depth/work; - cancellation propagation; - capability narrowing; - no default model charge for nesting; - no hidden independent scheduler; - cycle/repetition detection; - structured result/evidence propagation; - inspectable reason for delegation. Example: ```text write expert -> project knowledge expert (resolve symbol/span) -> git expert (inspect worktree/preimage state) -> produce typed edit action -> plan-native/index freshness update -> verify expert ``` ## Expert result contract Experts should return structured outcomes compatible with the runtime's existing structured result/evidence conventions, at minimum distinguishing: ```text succeeded(Result, Evidence) failed(Reason, Evidence) unknown(Reason, Evidence) blocked(Reason, Evidence) unsupported(Reason) cancelled(Token) error(Error) ``` Do not collapse missing evidence into falsehood or model prose into evidence. ## Proof and explanation For every material decision, retain enough inspectable state to answer: ```text Why was this expert selected? What facts/rules made it applicable? What evidence did it consume? What capabilities/tools did it invoke? What did it derive versus directly observe? Did it use an LLM fallback? Why? What remains unknown? Why did the loop continue or stop? ``` This is structured explanation/provenance, not a requirement to expose private model chain-of-thought. ## LLM fallback contract Each expert may declare an explicit fallback policy. Default is `none` unless the expert genuinely benefits from a model fallback. Conceptual classes: ```text no_fallback nl_normalization_fallback semantic_generation_fallback review_fallback conversation_render_fallback ``` Fallback MUST: 1. be triggered for an explicit structured reason; 2. use the existing provider/model runtime; 3. preserve capability/authority ceilings; 4. be separately metered in normal model usage; 5. emit a trace event linking the fallback call to the expert invocation; 6. never convert model output directly into trusted executable Prolog; 7. validate/normalize any model-produced structured data before use. ## Full closed loop The eventual integration target is a canonical reusable expert workflow equivalent to: ```text 1. Requirement/Spec Expert normalize requirement; validate/freeze exact obligations 2. Project Knowledge Expert acquire coherent fresh project/source state 3. Planner/Coordinator Expert construct a typed dependency graph and choose expert responsibilities 4. Specialist execution Git / Retrieval / Write / other experts derive actions and evidence deterministic plan-native ops execute at plan layer 5. Verify Expert verify the exact Frozen Spec against fresh observable evidence 6. If not satisfied: Repair/Diagnosis Expert identifies the smallest evidence/action gap Planner updates the plan without weakening Frozen Spec loop resumes 7. Review/Critic Expert adversarially checks changed state/evidence for hidden regressions or unsupported claims 8. Final Verify only observable evidence satisfying Frozen Spec closes the run ``` The loop is bounded by explicit progress/recursion/time/work/tool/effect limits and stops structurally on no-progress, blocked requirements, cancellation or exhausted limits. ## Child epics This parent owns the architecture and integration. Create focused epics for: - canonical expert runtime / registry / selection / invocation; - requirement + SPEC expert; - plan/coordinator expert; - project symbolic knowledge expert; - retrieval/evidence expert; - Git/repository expert; - write/edit/create expert; - VERIFY expert; - repair/diagnosis expert; - review/critic expert. Each child must remain independently testable and integrate through the shared contract. ## Acceptance — expert substrate - [ ] Experts are first-class registered/inspectable runtime capabilities. - [ ] Pure/nested expert execution performs zero provider calls and incurs zero model-token/cost accounting. - [ ] Explicit LLM fallback is separately traced and metered. - [ ] Prolog can select an expert from goal/context/evidence without an LLM. - [ ] Expert→expert recursion is bounded, cancellable, capability-narrowed and traceable. - [ ] Direct/native callers and plan/workflow callers reach the same expert contract rather than separate expert implementations. - [ ] D6-11 plan-native operations are rejected from expert registration/mapping where required. - [ ] Expert handlers cannot widen authority or bypass canonical tool/effect admission. - [ ] Structured explanations identify selection basis, evidence and fallback usage. ## Acceptance — full loop A deterministic fixture must prove a complete loop with **zero model calls**: ```text structured requirement -> Frozen Spec -> project symbolic observations -> typed plan -> specialist expert selection -> one controlled change/action fixture -> fresh observation -> VERIFY failure -> diagnosis/repair subgoal -> second action -> fresh observation -> VERIFY success -> final structured evidence-backed completion ``` Also prove: - [ ] a blocked/unknown requirement does not become success; - [ ] repair cannot weaken/mutate the Frozen Spec; - [ ] repeated no-progress state terminates deterministically; - [ ] expert recursion cycles are detected; - [ ] stale project/source evidence cannot satisfy final verification; - [ ] write effects use expected-state/preimage semantics; - [ ] cancellation aborts the loop without further expert/effect dispatch; - [ ] an equivalent run with an explicitly enabled model fallback records only the fallback provider usage, not a charge for expert invocations themselves. ## Non-goals - No second agent framework. - No model-required expert identity. - No ambient filesystem/Git/shell/network authority in core experts. - No product-specific AgentProlog UI or product tool implementations in this repository. - No expert may mutate a Frozen Spec to manufacture success. - No arbitrary model- or project-generated term passed to unrestricted `call/1`. ## Migration/reconciliation As the child epics land, reconcile older expert research/issues against this contract. Preserve useful evidence/research, but close or supersede issue-level architecture that assumes experts are inherently model sessions or that expert invocation itself should be token/cost charged. Refs #141 #288 #355 #93 #56 #68 #69 #70 #71 #219 #353 #354

nsaspy commented

2026-09-08 01:46:19 +00:00

Author

Owner

Child epic map

Created the implementation hierarchy:

#377 — canonical expert runtime / registry / symbolic selection / invocation / recursion / projections
#378 — Requirement / SPEC Expert
#379 — Planner / Coordinator Expert
#380 — Project Symbolic Knowledge Expert
#381 — Retrieval / Evidence Expert
#382 — Git / Repository Expert
#383 — Write / Edit / Create Expert
#384 — VERIFY Expert
#385 — Repair / Diagnosis Expert
#386 — Review / Critic Expert
#387 — closed-loop integration and zero-model end-to-end conformance

Implementation invariant across every child: pure Prolog expert invocation and expert→expert recursion are free local computation (model_calls = 0, no synthetic token/cost charge). Only explicit model fallback or an actually paid external dependency is metered.

## Child epic map Created the implementation hierarchy: - #377 — canonical expert runtime / registry / symbolic selection / invocation / recursion / projections - #378 — Requirement / SPEC Expert - #379 — Planner / Coordinator Expert - #380 — Project Symbolic Knowledge Expert - #381 — Retrieval / Evidence Expert - #382 — Git / Repository Expert - #383 — Write / Edit / Create Expert - #384 — VERIFY Expert - #385 — Repair / Diagnosis Expert - #386 — Review / Critic Expert - #387 — closed-loop integration and zero-model end-to-end conformance Implementation invariant across every child: pure Prolog expert invocation and expert→expert recursion are free local computation (`model_calls = 0`, no synthetic token/cost charge). Only explicit model fallback or an actually paid external dependency is metered.

nsaspy commented

2026-09-08 01:46:20 +00:00

Author

Owner

Added child epic #388 for generic corpus symbolicization / knowledge ingestion. This is intentionally separate from source-code Project Knowledge (#380): arbitrary text, LLM logs, web/research results, reports, chat exports, JSONL/events, etc. become immutable-source, schema-versioned, append-only symbolic knowledge with exact provenance. The model sees only a bounded selected projection; it may choose among host-admitted immutable schemas/projections but cannot mutate/publish trusted schemas or turn extracted text into authority.

nsaspy commented

2026-09-08 01:46:20 +00:00

Author

Owner

Machine Spirit #399D boundary note — semantic compile planning is not a second scheduler

Depth 2D introduces a compiler-local Semantic Build Graph (SBG) for content-addressed analyzer/SCL/SCC/mapping/export work and dynamic discourse dependencies.

This must preserve #376's one-runtime invariant:

SBG nodes are typed work/dependency data, not a new expert registry or autonomous scheduler;
execution uses existing async/Futures/concurrency/cancellation/runtime machinery where present (or synchronous direct-library execution);
semantic analyzer selection may be implemented as ordinary Prolog planning/expert reasoning but does not grant authority;
source/analyzer/model artifacts are semantic evidence only;
compiler caching/replay cannot replay or manufacture host execution authority;
model-backed semantic stages remain explicit provider fallback/induction work and are metered as actual calls.

No other #376-#387 architecture change is required by this research pass; the purpose of this note is to prevent an implementation of #393/#396 from accidentally creating a parallel worker runtime.

## Machine Spirit #399D boundary note — semantic compile planning is not a second scheduler Depth 2D introduces a compiler-local **Semantic Build Graph (SBG)** for content-addressed analyzer/SCL/SCC/mapping/export work and dynamic discourse dependencies. This must preserve #376's one-runtime invariant: - SBG nodes are typed work/dependency data, not a new expert registry or autonomous scheduler; - execution uses existing async/Futures/concurrency/cancellation/runtime machinery where present (or synchronous direct-library execution); - semantic analyzer selection may be implemented as ordinary Prolog planning/expert reasoning but does not grant authority; - source/analyzer/model artifacts are semantic evidence only; - compiler caching/replay cannot replay or manufacture host execution authority; - model-backed semantic stages remain explicit provider fallback/induction work and are metered as actual calls. No other #376-#387 architecture change is required by this research pass; the purpose of this note is to prevent an implementation of #393/#396 from accidentally creating a parallel worker runtime.

nsaspy commented

2026-09-08 01:46:20 +00:00

Author

Owner

MACHINE-SPIRIT #400D handoff — epistemic query plans reuse the canonical runtime

Depth 3D introduces an Epistemic Query Plan (EQP) for demand-driven cross-theory reasoning. This must compose with #376's existing one-runtime/one-scheduler invariant.

EQP nodes may represent local theory evaluation, bridge propagation, SCC fixed-point/search, projected-interface joins, explanation expansion and cache invalidation, but they are typed plan work executed by the canonical runtime. Do not add a parallel epistemic actor scheduler.

Independent SCC-DAG nodes may execute concurrently through existing runtime primitives. Result combination must be deterministic from immutable plan/frontier/interface keys; different safe interleavings cannot change skeptical/credulous/undefined/conflicted/completeness outcomes.

Pure compiled-semantic epistemic reasoning is local expert/runtime computation and must incur zero model/provider calls. Resource exhaustion returns a structured epistemic/runtime status and never silently triggers an LLM fallback.

Epistemic warrant remains data/evidence for experts and VERIFY; it never widens capability/authority or substitutes stale derived state for fresh required observation.

Full execution design is on #400D.

## MACHINE-SPIRIT #400D handoff — epistemic query plans reuse the canonical runtime Depth 3D introduces an **Epistemic Query Plan (EQP)** for demand-driven cross-theory reasoning. This must compose with #376's existing one-runtime/one-scheduler invariant. EQP nodes may represent local theory evaluation, bridge propagation, SCC fixed-point/search, projected-interface joins, explanation expansion and cache invalidation, but they are **typed plan work executed by the canonical runtime**. Do not add a parallel epistemic actor scheduler. Independent SCC-DAG nodes may execute concurrently through existing runtime primitives. Result combination must be deterministic from immutable plan/frontier/interface keys; different safe interleavings cannot change skeptical/credulous/undefined/conflicted/completeness outcomes. Pure compiled-semantic epistemic reasoning is local expert/runtime computation and must incur **zero model/provider calls**. Resource exhaustion returns a structured epistemic/runtime status and never silently triggers an LLM fallback. Epistemic warrant remains data/evidence for experts and VERIFY; it never widens capability/authority or substitutes stale derived state for fresh required observation. Full execution design is on #400D.

nsaspy commented

2026-09-08 01:46:20 +00:00

Author

Owner

Machine Spirit #401A procedural-intelligence handoff

Depth 4A’s classical-AI comparison preserves this epic’s one-runtime / zero-model / authority boundaries and adds one architectural distinction that should guide implementation:

procedural method selection/decomposition
        !=
expert selection/invocation
        !=
plan scheduling
        !=
effect admission

Preferred Procedural Intelligence Fabric (PIF) uses:

HTN-like typed methods + partial-order task networks as reusable know-how;
primitive STRIPS-like operator summaries only as symbolic precondition/predicted-effect knowledge;
production/control rules for method/expert/evidence/recovery applicability;
a blackboard-inspired logical typed coordination board for goals, observations, hypotheses, evidence gaps and proposals — explicitly not a second scheduler;
CBR only for candidate precedent/adaptation proposals, never automatic policy/rule promotion;
explicit model-based diagnosis conflict -> hypotheses -> discriminating evidence -> repair method before blind repair where ambiguity matters.

#379 and #385 have been updated to reflect the two strongest canonical deltas. #288 remains the sole plan graph scheduler; #384 remains the sole final acceptance boundary; #404 later owns experience/case -> generalized rule/method promotion.

Hard invariants added by the research:

procedure/method knowledge != plan instance
blackboard proposal         != scheduled step
operator predicted effect   != observed effect
case precedent              != trusted method/rule
diagnostic hypothesis       != observed fault
repair recommendation       != effect admission

Full source review, candidate designs, complexity analysis and A1-A20 conformance fixtures are preserved on #401. #401 remains open; next subpass is #401B.

## Machine Spirit #401A procedural-intelligence handoff Depth 4A’s classical-AI comparison preserves this epic’s one-runtime / zero-model / authority boundaries and adds one architectural distinction that should guide implementation: ```text procedural method selection/decomposition != expert selection/invocation != plan scheduling != effect admission ``` Preferred **Procedural Intelligence Fabric (PIF)** uses: - HTN-like typed methods + partial-order task networks as reusable know-how; - primitive STRIPS-like operator summaries only as symbolic precondition/predicted-effect knowledge; - production/control rules for method/expert/evidence/recovery applicability; - a blackboard-inspired **logical typed coordination board** for goals, observations, hypotheses, evidence gaps and proposals — explicitly **not a second scheduler**; - CBR only for candidate precedent/adaptation proposals, never automatic policy/rule promotion; - explicit model-based diagnosis `conflict -> hypotheses -> discriminating evidence -> repair method` before blind repair where ambiguity matters. #379 and #385 have been updated to reflect the two strongest canonical deltas. #288 remains the sole plan graph scheduler; #384 remains the sole final acceptance boundary; #404 later owns experience/case -> generalized rule/method promotion. Hard invariants added by the research: ```text procedure/method knowledge != plan instance blackboard proposal != scheduled step operator predicted effect != observed effect case precedent != trusted method/rule diagnostic hypothesis != observed fault repair recommendation != effect admission ``` Full source review, candidate designs, complexity analysis and A1-A20 conformance fixtures are preserved on #401. #401 remains open; next subpass is #401B.

nsaspy commented

2026-09-08 01:46:20 +00:00

Author

Owner

Machine Spirit #405A synthesis handoff

Depth 8A (#405) preserves the current expert architecture as the single execution/control spine of COVENANT-MS:

explicit-profile evidence
 -> admitted procedure/DPEC
 -> Planner method decomposition
 -> #377 expert selection
 -> #288 one scheduler
 -> canonical capability/authority/effect boundary
 -> fresh observations
 -> #384 VERIFY
 -> Repair/Review/final VERIFY

No synthesis-level orchestrator, blackboard scheduler or learned expert mesh is added. ms_run_envelope/conformance receipts only bind the loop to exact Frozen Spec, evidence/world cut, expert-registry, authority, verifier and procedure generations.

Hard cross-depth law retained: expert registered/selected/admitted learned strategy never implies effect capability or authority. Predicted procedural effects never become VERIFY observations. Pure known expert cooperation remains a zero-model target.

Refs #397 #405 #377-#387 #288 #355.

## Machine Spirit #405A synthesis handoff Depth 8A (`#405`) preserves the current expert architecture as the **single execution/control spine** of COVENANT-MS: ```text explicit-profile evidence -> admitted procedure/DPEC -> Planner method decomposition -> #377 expert selection -> #288 one scheduler -> canonical capability/authority/effect boundary -> fresh observations -> #384 VERIFY -> Repair/Review/final VERIFY ``` No synthesis-level orchestrator, blackboard scheduler or learned expert mesh is added. `ms_run_envelope`/conformance receipts only bind the loop to exact Frozen Spec, evidence/world cut, expert-registry, authority, verifier and procedure generations. Hard cross-depth law retained: expert registered/selected/admitted learned strategy **never** implies effect capability or authority. Predicted procedural effects never become VERIFY observations. Pure known expert cooperation remains a zero-model target. Refs #397 #405 #377-#387 #288 #355.

nsaspy referenced this issue

2026-09-16 21:56:26 +00:00

WIP: feat: add bounded symbolic expert registry and selection #461