[MACHINE-SPIRIT 4/8] Procedural intelligence and expert systems: production rules, blackboards, HTN planning, CBR, diagnosis and repair #397

Closed
opened 2026-09-08 01:29:18 +00:00 by nsaspy · 4 comments
Owner

Parent: #397
Related: #376-#387 #388 #392
Downstream: lost-rob0t/symbolic-memory#4 #6 #7 #9 #10

Distinct research mandate

Treat know-how and autonomous expert behavior as the primary problem: production systems, blackboards, HTN/classical planning, reactive/contingent procedures, workflows/behavior trees, case-based reasoning, diagnosis/repair, procedural knowledge representation, expert coordination, and heterogeneous procedural interoperability.

This depth is research/design only. It does not establish implementation or Machine Spirit acceptance.

Depth 4 status — DESIGN-COMPLETE, IMPLEMENTATION-UNPROVEN

All four required subpasses are durably preserved in this issue's comments.

A — foundations / representative formalisms: COMPLETE

Procedural Intelligence Fabric (PIF).

  • HTN-like methods/task networks are the reusable know-how spine;
  • production/control rules own local applicability/reactivity, not long-horizon procedural meaning;
  • typed logical coordination-board objects enable opportunistic expert cooperation but create no second scheduler;
  • CBR supplies verified precedent/adaptation candidates, never direct rules/authority;
  • model-based diagnosis separates conflicts/hypotheses/discriminators from repair selection;
  • bounded classical/operator search is a fallback for procedural gaps.

Hard distinctions:

procedure/method knowledge != plan instance
method selection            != expert selection
expert applicability        != authority
predicted effect            != observed effect
blackboard proposal         != scheduled work
case precedent              != trusted rule
repair recommendation       != effect admission
procedure success condition != VERIFY success

B — semantic / adversarial deepening: COMPLETE

Monitored Epistemic Procedural Policies (MEPP).

Reusable procedures are policy knowledge over epistemic/temporal/resource state; a plan instance is one admitted execution projection against current evidence.

B adds:

  • epistemic guard outcomes satisfied/refuted/unknown/conflicted/blocked/unsupported;
  • hard guards, observation/branch gates, assumptions, monitored invariants and success conditions;
  • deterministic / weak / strong / strong-cyclic / best-effort guarantee classes with explicit fairness assumptions;
  • sensing/partial observability and contingent branches;
  • live temporal/resource validity, deadlines, invariants, leases and concurrency threats;
  • exogenous-event monitoring and threat-directed repair;
  • separate continuation repair / plan repair / method reselection / inert method-defect candidate;
  • risk/cost/authority-aware discriminators;
  • compatibility-aware CBR transfer.

C — composition / heterogeneity / interoperability: COMPLETE

Procedural Interoperability & Federation Fabric (PIFF).

Native HTN/HDDL, Golog/ConGolog, Behavior Tree, BPMN/workflow, PDDL2.1 and expert-procedure semantics remain first-class. They interoperate through versioned Procedural Semantic Contracts (PSC) plus typed/loss-aware bridges.

Hard C decisions:

common procedure interface
    != common internal semantics
    != common guarantee
    != common host binding
    != common principal
    != common authority

A semantic action is distinct from a host binding, capability, authority and admitted effect. External workflow roles never become local principals by lexical equality. Expert portability is typed goal-contract based. Only an execution-admitted host-specific projection reaches #288; #288 remains the sole scheduler/runtime. Mapping/adapter upgrades create new projection lineage rather than rewriting history.

D — computational realization / scaling / conformance: COMPLETE

Demand-Driven Procedural Execution & Conformance Graph (DPEC).

DPEC is a derived compiler/admission/monitoring graph over PIF + MEPP + PIFF. It does not execute procedures independently. It selects a demanded procedural slice, keeps decomposition/contingent alternatives packed, produces a versioned host projection, validates that projection under formalism-specific reference semantics, and compiles admitted primitive work into the existing #288 graph/runtime.

Frozen goal / current epistemic frontier
               ↓
       demanded procedure slice
 method/case index + PSC/bridge selection
               ↓
      packed decomposition forest
 AND/OR alternatives + guards + constraints
               ↓
    host projection / compatibility
 capability + authority + temporal/resource/
        concurrency admission checks
               ↓
 formalism-specific conformance receipt
               ↓
          admitted #288 graph
               ↓
       one canonical scheduler
               ↓
 incremental monitors + observations
               ↓
 continuation/plan/method repair as needed
               ↓
          fresh #384 VERIFY

D hard decisions

  1. Demand before materialization. Index by goal/task/profile/guard/effect/resource/PSC signature; evaluate only relevant methods, bridges and experts.
  2. Packed decomposition. Share method/task alternatives in an AND/OR + guard/constraint DAG/forest rather than enumerating complete plans.
  3. Recursive HTN semantics are explicit. Hierarchy-cycle/search-incompleteness classification is separate from depth/work safety bounds; depth exhaustion never means no plan.
  4. Dependency-directed invalidation. Native procedure -> PSC -> bridge -> host projection -> applicability -> decomposition -> plan generation -> monitors. Recompute only affected closure; propagation may stop only when the selected profile proves the observable host-interface digest unchanged.
  5. Live state is not cached authority. Epistemic frontier, host bindings, expert registry, resource leases, project generation and authority policy are dependencies. Authority/resource checks are revalidated at dispatch where required.
  6. Missing order != safe concurrency. Causal threats, effect/write interference, resources/leases, temporal invariants and the source formalism's concurrency semantics gate overlap.
  7. Do not globally optimize partial orders by default. Reordering/deordering/makespan optimization is computationally hard and representation-dependent; preserve source constraints and use optional bounded optimization only under an explicit profile.
  8. MEPP monitors compile to derived obligations, not another interpreter. Guards, observation gates, deadlines, resource/causal threats and async lifecycle produce typed deltas consumed by Planner/Repair; #288 still schedules.
  9. Formalism-specific differential conformance. Supported HTN/HDDL, temporal PDDL, BT, workflow/BPMN and Golog/ConGolog adapters declare a reference profile and comparison relation such as exact trace, refinement, stuttering equivalence, preserved safety/terminal status, declared loss or noncomposability.
  10. Native runtimes may be reference validators, not ambient schedulers. Planner/projection self-report is never the sole correctness oracle.
  11. Cancellation is not failure. No dispatch after canonical cancellation; races with external effects retain observed/indeterminate effect state rather than pretending clean rollback.
  12. Replay has classes. Exact trace replay reuses retained observations/effect outcomes and material nondeterministic interaction decisions; deterministic reexecution must normalize to the same semantic outcome; environment-nondeterministic rerun is a new lineage.
  13. Diagnosis/case state is bounded/query-local. Conflict/hitting-set work and CBR ranking are incrementally reusable derived state; concurrency may accelerate them but cannot alter normalized results.
  14. Explicit structural budgets. Bound method candidates, decomposition nodes/cycles, bridge/projection states, temporal/resource constraints, active async work, diagnosis/case candidates, validator work, trace bytes, CPU/wall/memory. Exhaustion returns resource_limited(...); never first-found truth/success and never implicit LLM fallback.
  15. Zero-model known-procedure path. All supported compiled-procedure/expert conformance fixtures must run with providers disabled and model_calls = 0.

DPEC conceptual records

proc_exec_key(...).
proc_candidate(...).
proc_choice(...).              % AND/OR/branch/partial-order/recovery
proc_host_projection(...).     % derived, versioned, loss/guarantee-bearing
proc_monitor(...).
proc_trace_event(...).
proc_conformance_receipt(...).

These are execution/projection concepts. Canonical native procedure/PSC identity stays immutable semantic knowledge; host executable bindings remain trusted runtime configuration rather than semantic authority.

Required Depth-4 conformance direction

The D comment defines D1-D34 fixtures including demanded pruning, guard-local invalidation, stable-interface propagation stop, mapping/registry upgrades, HTN recursion classification, packed-alternative bounds, lifted verification, partial-order preservation, safe/unsafe concurrency, temporal/resource invalidation, BT RUNNING and ReactiveFallback behavior, PDDL2.1 reference validation, workflow join/compensation handling, Golog nondeterminism, cancellation races, exact replay, cold/warm/rebuilt and incremental/full equivalence, bounded deterministic diagnosis, CBR contraindications, stale bindings/authority rechecks, adapter proof receipts, one-scheduler instrumentation and heterogeneous zero-model cooperation.

Canonical handoffs

  • #379 — demanded method indexes, packed decompositions, explicit hierarchy-cycle/search guarantee, PSC/host projection admission, live temporal/resource/concurrency checks, scoped invalidation, structured resource limits.
  • #377 — expert registry/goal-contract generations are projection dependencies; registry changes invalidate only actual consumers; physical concurrency cannot change normalized receipts.
  • #385 — query/run-local bounded incremental diagnosis; explicit repair problem/layer; parallel conflict/hitting-set work may use the existing runtime with deterministic normalization.
  • #387 — heterogeneous zero-model execution + replay/differential integration fixtures and one-scheduler instrumentation.
  • #395 — procedure-adapter reference/differential conformance follows the existing invariant/forbidden-loss evaluation philosophy.
  • symbolic-memory #6 — persist immutable procedure/PSC/bridge/mapping and compact execution/case/VERIFY/replay lineage; DPEC indexes/packed forests/monitor/validator caches remain rebuildable derived state.
  • symbolic-memory #7/#9 — expose represented vs compatible vs projectable vs bound vs currently admissible procedure state plus guarantee/loss/profile/evidence dependencies; queryability never means execution permission.

Reconciled Depth-4 architecture

A: PIF
   reusable know-how roles
        ↓
B: MEPP
   epistemic/reactive/temporal policy semantics
        ↓
C: PIFF
   heterogeneous native procedure contracts + bridges
        ↓
D: DPEC
   demanded incremental execution projection + reference conformance
        ↓
#288 one runtime -> fresh observations -> #384 VERIFY

Unresolved implementation questions

  • exact first HTN/HDDL executable/verification fragment and practical hierarchy-cycle normalization;
  • packed-decomposition data structure and benchmark thresholds;
  • SWI indexing/tabling versus dedicated Rete-style applicability matching thresholds;
  • temporal/resource solver and VAL differential strategy;
  • exact BT, BPMN/workflow and Golog/ConGolog supported reference subsets;
  • host-projection fingerprint granularity;
  • whether #288 needs dedicated live monitor hooks or graph-generation updates suffice;
  • exact trace-retention policy for replay;
  • benchmark-derived default DPEC budgets;
  • distributed/multi-process durable execution interaction belongs primarily to Depth 5;
  • experience-to-method promotion remains Depth 7/#404.

Completion statement

Depth 4 A/B/C/D is design-complete only. No Machine Spirit milestone is claimed. Executable acceptance remains gated by implementation and the final #405D conformance bar.

Next research work: Depth 5 / #402A — durable world-model architecture foundations.

Refs #397 #376 #377 #379 #384 #385 #387 #288 #355 #388 #392 #395 and downstream symbolic-memory#4/#6/#7/#9/#10.

Parent: #397 Related: #376-#387 #388 #392 Downstream: lost-rob0t/symbolic-memory#4 #6 #7 #9 #10 ## Distinct research mandate Treat know-how and autonomous expert behavior as the primary problem: production systems, blackboards, HTN/classical planning, reactive/contingent procedures, workflows/behavior trees, case-based reasoning, diagnosis/repair, procedural knowledge representation, expert coordination, and heterogeneous procedural interoperability. This depth is research/design only. It does not establish implementation or Machine Spirit acceptance. ## Depth 4 status — DESIGN-COMPLETE, IMPLEMENTATION-UNPROVEN All four required subpasses are durably preserved in this issue's comments. ### A — foundations / representative formalisms: COMPLETE **Procedural Intelligence Fabric (PIF).** - HTN-like methods/task networks are the reusable know-how spine; - production/control rules own local applicability/reactivity, not long-horizon procedural meaning; - typed logical coordination-board objects enable opportunistic expert cooperation but create no second scheduler; - CBR supplies verified precedent/adaptation candidates, never direct rules/authority; - model-based diagnosis separates conflicts/hypotheses/discriminators from repair selection; - bounded classical/operator search is a fallback for procedural gaps. Hard distinctions: ```text procedure/method knowledge != plan instance method selection != expert selection expert applicability != authority predicted effect != observed effect blackboard proposal != scheduled work case precedent != trusted rule repair recommendation != effect admission procedure success condition != VERIFY success ``` ### B — semantic / adversarial deepening: COMPLETE **Monitored Epistemic Procedural Policies (MEPP).** Reusable procedures are policy knowledge over epistemic/temporal/resource state; a plan instance is one admitted execution projection against current evidence. B adds: - epistemic guard outcomes `satisfied/refuted/unknown/conflicted/blocked/unsupported`; - hard guards, observation/branch gates, assumptions, monitored invariants and success conditions; - deterministic / weak / strong / strong-cyclic / best-effort guarantee classes with explicit fairness assumptions; - sensing/partial observability and contingent branches; - live temporal/resource validity, deadlines, invariants, leases and concurrency threats; - exogenous-event monitoring and threat-directed repair; - separate continuation repair / plan repair / method reselection / inert method-defect candidate; - risk/cost/authority-aware discriminators; - compatibility-aware CBR transfer. ### C — composition / heterogeneity / interoperability: COMPLETE **Procedural Interoperability & Federation Fabric (PIFF).** Native HTN/HDDL, Golog/ConGolog, Behavior Tree, BPMN/workflow, PDDL2.1 and expert-procedure semantics remain first-class. They interoperate through versioned **Procedural Semantic Contracts (PSC)** plus typed/loss-aware bridges. Hard C decisions: ```text common procedure interface != common internal semantics != common guarantee != common host binding != common principal != common authority ``` A semantic action is distinct from a host binding, capability, authority and admitted effect. External workflow roles never become local principals by lexical equality. Expert portability is typed goal-contract based. Only an execution-admitted host-specific projection reaches #288; #288 remains the sole scheduler/runtime. Mapping/adapter upgrades create new projection lineage rather than rewriting history. ### D — computational realization / scaling / conformance: COMPLETE **Demand-Driven Procedural Execution & Conformance Graph (DPEC).** DPEC is a derived compiler/admission/monitoring graph over PIF + MEPP + PIFF. It does **not** execute procedures independently. It selects a demanded procedural slice, keeps decomposition/contingent alternatives packed, produces a versioned host projection, validates that projection under formalism-specific reference semantics, and compiles admitted primitive work into the existing #288 graph/runtime. ```text Frozen goal / current epistemic frontier ↓ demanded procedure slice method/case index + PSC/bridge selection ↓ packed decomposition forest AND/OR alternatives + guards + constraints ↓ host projection / compatibility capability + authority + temporal/resource/ concurrency admission checks ↓ formalism-specific conformance receipt ↓ admitted #288 graph ↓ one canonical scheduler ↓ incremental monitors + observations ↓ continuation/plan/method repair as needed ↓ fresh #384 VERIFY ``` #### D hard decisions 1. **Demand before materialization.** Index by goal/task/profile/guard/effect/resource/PSC signature; evaluate only relevant methods, bridges and experts. 2. **Packed decomposition.** Share method/task alternatives in an AND/OR + guard/constraint DAG/forest rather than enumerating complete plans. 3. **Recursive HTN semantics are explicit.** Hierarchy-cycle/search-incompleteness classification is separate from depth/work safety bounds; depth exhaustion never means `no plan`. 4. **Dependency-directed invalidation.** Native procedure -> PSC -> bridge -> host projection -> applicability -> decomposition -> plan generation -> monitors. Recompute only affected closure; propagation may stop only when the selected profile proves the observable host-interface digest unchanged. 5. **Live state is not cached authority.** Epistemic frontier, host bindings, expert registry, resource leases, project generation and authority policy are dependencies. Authority/resource checks are revalidated at dispatch where required. 6. **Missing order != safe concurrency.** Causal threats, effect/write interference, resources/leases, temporal invariants and the source formalism's concurrency semantics gate overlap. 7. **Do not globally optimize partial orders by default.** Reordering/deordering/makespan optimization is computationally hard and representation-dependent; preserve source constraints and use optional bounded optimization only under an explicit profile. 8. **MEPP monitors compile to derived obligations, not another interpreter.** Guards, observation gates, deadlines, resource/causal threats and async lifecycle produce typed deltas consumed by Planner/Repair; #288 still schedules. 9. **Formalism-specific differential conformance.** Supported HTN/HDDL, temporal PDDL, BT, workflow/BPMN and Golog/ConGolog adapters declare a reference profile and comparison relation such as exact trace, refinement, stuttering equivalence, preserved safety/terminal status, declared loss or noncomposability. 10. **Native runtimes may be reference validators, not ambient schedulers.** Planner/projection self-report is never the sole correctness oracle. 11. **Cancellation is not failure.** No dispatch after canonical cancellation; races with external effects retain observed/indeterminate effect state rather than pretending clean rollback. 12. **Replay has classes.** Exact trace replay reuses retained observations/effect outcomes and material nondeterministic interaction decisions; deterministic reexecution must normalize to the same semantic outcome; environment-nondeterministic rerun is a new lineage. 13. **Diagnosis/case state is bounded/query-local.** Conflict/hitting-set work and CBR ranking are incrementally reusable derived state; concurrency may accelerate them but cannot alter normalized results. 14. **Explicit structural budgets.** Bound method candidates, decomposition nodes/cycles, bridge/projection states, temporal/resource constraints, active async work, diagnosis/case candidates, validator work, trace bytes, CPU/wall/memory. Exhaustion returns `resource_limited(...)`; never first-found truth/success and never implicit LLM fallback. 15. **Zero-model known-procedure path.** All supported compiled-procedure/expert conformance fixtures must run with providers disabled and `model_calls = 0`. ## DPEC conceptual records ```prolog proc_exec_key(...). proc_candidate(...). proc_choice(...). % AND/OR/branch/partial-order/recovery proc_host_projection(...). % derived, versioned, loss/guarantee-bearing proc_monitor(...). proc_trace_event(...). proc_conformance_receipt(...). ``` These are execution/projection concepts. Canonical native procedure/PSC identity stays immutable semantic knowledge; host executable bindings remain trusted runtime configuration rather than semantic authority. ## Required Depth-4 conformance direction The D comment defines D1-D34 fixtures including demanded pruning, guard-local invalidation, stable-interface propagation stop, mapping/registry upgrades, HTN recursion classification, packed-alternative bounds, lifted verification, partial-order preservation, safe/unsafe concurrency, temporal/resource invalidation, BT `RUNNING` and ReactiveFallback behavior, PDDL2.1 reference validation, workflow join/compensation handling, Golog nondeterminism, cancellation races, exact replay, cold/warm/rebuilt and incremental/full equivalence, bounded deterministic diagnosis, CBR contraindications, stale bindings/authority rechecks, adapter proof receipts, one-scheduler instrumentation and heterogeneous zero-model cooperation. ## Canonical handoffs - #379 — demanded method indexes, packed decompositions, explicit hierarchy-cycle/search guarantee, PSC/host projection admission, live temporal/resource/concurrency checks, scoped invalidation, structured resource limits. - #377 — expert registry/goal-contract generations are projection dependencies; registry changes invalidate only actual consumers; physical concurrency cannot change normalized receipts. - #385 — query/run-local bounded incremental diagnosis; explicit repair problem/layer; parallel conflict/hitting-set work may use the existing runtime with deterministic normalization. - #387 — heterogeneous zero-model execution + replay/differential integration fixtures and one-scheduler instrumentation. - #395 — procedure-adapter reference/differential conformance follows the existing invariant/forbidden-loss evaluation philosophy. - symbolic-memory #6 — persist immutable procedure/PSC/bridge/mapping and compact execution/case/VERIFY/replay lineage; DPEC indexes/packed forests/monitor/validator caches remain rebuildable derived state. - symbolic-memory #7/#9 — expose represented vs compatible vs projectable vs bound vs currently admissible procedure state plus guarantee/loss/profile/evidence dependencies; queryability never means execution permission. ## Reconciled Depth-4 architecture ```text A: PIF reusable know-how roles ↓ B: MEPP epistemic/reactive/temporal policy semantics ↓ C: PIFF heterogeneous native procedure contracts + bridges ↓ D: DPEC demanded incremental execution projection + reference conformance ↓ #288 one runtime -> fresh observations -> #384 VERIFY ``` ## Unresolved implementation questions - exact first HTN/HDDL executable/verification fragment and practical hierarchy-cycle normalization; - packed-decomposition data structure and benchmark thresholds; - SWI indexing/tabling versus dedicated Rete-style applicability matching thresholds; - temporal/resource solver and VAL differential strategy; - exact BT, BPMN/workflow and Golog/ConGolog supported reference subsets; - host-projection fingerprint granularity; - whether #288 needs dedicated live monitor hooks or graph-generation updates suffice; - exact trace-retention policy for replay; - benchmark-derived default DPEC budgets; - distributed/multi-process durable execution interaction belongs primarily to Depth 5; - experience-to-method promotion remains Depth 7/#404. ## Completion statement Depth 4 A/B/C/D is **design-complete only**. No Machine Spirit milestone is claimed. Executable acceptance remains gated by implementation and the final #405D conformance bar. **Next research work: Depth 5 / #402A — durable world-model architecture foundations.** Refs #397 #376 #377 #379 #384 #385 #387 #288 #355 #388 #392 #395 and downstream symbolic-memory#4/#6/#7/#9/#10.
Author
Owner

Machine Spirit Depth 4A — procedural-intelligence foundations

This is subpass A only. It establishes representative formalisms and a baseline procedural architecture. It does not close #401 and does not advance to #402. B/C/D must still independently attack this design.

Research question

Given the already-strong #376–#387 substrate — expert registry, immutable SPEC, typed dependency plans, current evidence, VERIFY, diagnosis/repair, review, one graph runtime and explicit capability/effect boundaries — what should count as procedural knowledge / know-how, how should known know-how decompose goals, how should heterogeneous experts cooperate opportunistically, how should failure trigger diagnosis instead of blind retry, and how can prior successful cases help without turning anecdotes into trusted rules?

The key question is not “which planner should Machine Spirit use?” The classical literature treats several genuinely different problems:

  1. production systems — which locally applicable rule/knowledge source should fire now?
  2. classical planning — which primitive state-changing operators can reach a goal?
  3. HTN planning — which known methods decompose an abstract task into executable subtasks?
  4. blackboard architectures — how can heterogeneous knowledge sources cooperate through shared partial solutions and opportunistic control?
  5. case-based reasoning — which prior episode is sufficiently analogous to propose a reusable/adapted solution?
  6. model-based diagnosis — which hypotheses explain an observed conflict, and which observation discriminates them before repair?

Trying to collapse those into one generic “agent planner” loses useful semantics.


Primary / authoritative sources inspected

Production systems / Rete

  • Charles L. Forgy, “Rete: A Fast Algorithm for the Many Pattern/Many Object Pattern Match Problem”, Artificial Intelligence 19(1), 1982, pp. 17–37, DOI 10.1016/0004-3702(82)90020-0. Bibliographic record: https://cir.nii.ac.jp/crid/1360011145674957312 . Rete is an incremental many-rule/many-object pattern-matching strategy. Its important lesson here is implementation, not semantics: cache shared tests/partial matches so working-memory changes do not rematch every rule from scratch.
  • Forgy & McDermott, “OPS, a domain-independent production system language”, IJCAI 1977, pp. 933–939; indexed in CMU’s historical expert-system repository: https://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/areas/expert/0.html . Production systems make condition/action knowledge explicit and separate working memory from productions and conflict resolution.

Blackboard / opportunistic cooperation

  • H. Penny Nii, “The Blackboard Model of Problem Solving and the Evolution of Blackboard Architectures”, AI Magazine 7(2), 1986, DOI 10.1609/aimag.v7i2.537: https://onlinelibrary.wiley.com/doi/abs/10.1609/aimag.v7i2.537 . Nii explicitly distinguishes the blackboard model of problem solving from concrete control architectures and surveys heterogeneous knowledge sources operating over shared partial solutions.
  • Lee Erman, Frederick Hayes-Roth, Victor Lesser, D. Raj Reddy, “The HEARSAY-II Speech-Understanding System: Integrating Knowledge to Resolve Uncertainty”, ACM Computing Surveys 12(2), 1980, DOI 10.1145/356810.356816: https://dl.acm.org/doi/10.1145/356810.356816 . HEARSAY-II is a canonical demonstration of independent knowledge sources coordinating through common problem-solving state under uncertainty.
  • Nii, “Blackboard Application Systems and a Knowledge Engineering Perspective”, AI Magazine 7(3), 1986, DOI 10.1609/aimag.v7i3.550: https://onlinelibrary.wiley.com/doi/abs/10.1609/aimag.v7i3.550 . Important for the warning that blackboard systems have materially different control strategies; “blackboard” does not itself define a scheduler.

Classical planning / operator models

  • Richard Fikes & Nils Nilsson, “STRIPS: A New Approach to the Application of Theorem Proving to Problem Solving”, Artificial Intelligence 2, 1971, pp. 189–208, DOI 10.1016/0004-3702(71)90010-5: https://cir.nii.ac.jp/crid/1360574094437855616 . STRIPS gives the useful primitive action idea: explicit current state, goal conditions, operators with applicability and state effects.
  • Tom Bylander, “The Computational Complexity of Propositional STRIPS Planning”, Artificial Intelligence 69, 1994, DOI 10.1016/0004-3702(94)90081-7: https://ai.dmi.unibas.ch/research/reading_group/bylander-aij1994.pdf . General propositional STRIPS plan existence is PSPACE-complete; severe restrictions are required for tractability. This is strong evidence against making unrestricted domain-independent search the normal known-procedure path.

Hierarchical task networks

Case-based reasoning

  • Agnar Aamodt & Enric Plaza, “Case-Based Reasoning: Foundational Issues, Methodological Variations, and System Approaches”, AI Communications 7(1), 1994, DOI 10.3233/AIC-1994-7104: https://journals.sagepub.com/doi/10.3233/AIC-1994-7104 . Their canonical cycle is retrieval, reuse/adaptation, solution testing/revision, and retention/learning; they explicitly present CBR as one reasoning method inside integrated architectures rather than a replacement for all other reasoning.

Model-based diagnosis

  • Raymond Reiter, “A Theory of Diagnosis from First Principles”, Artificial Intelligence 32(1), 1987, pp. 57–95. Bibliographic citation is preserved by Wiley here: https://onlinelibrary.wiley.com/doi/10.1111/1467-8640.00211 . Reiter’s central result relates diagnoses to conflict sets under an explicit system description and observations.
  • Johan de Kleer & Brian Williams, “Diagnosing Multiple Faults”, Artificial Intelligence 32(1), 1987, pp. 97–130, DOI 10.1016/0004-3702(87)90063-4. Bibliographic record: https://www.rankless.org/hit-papers/10.1016/0004-3702%2887%2990063-4 . The General Diagnostic Engine tradition incrementally derives candidate diagnoses from conflicts instead of baking a single heuristic fault label into the controller.
  • Systems-theoretic reformulation of Reiter’s framework, IEEE Transactions on Reliability 41(1), 1992, DOI 10.1109/24.126668: https://ieeexplore.ieee.org/document/126668/ . Useful warning: admissible fault models affect which diagnoses are meaningful; “minimal diagnosis” alone does not guarantee useful troubleshooting.

What the current #376–#387 architecture already gets right

The existing repo is ahead of many modern “agent” architectures on several fundamentals:

  • Frozen SPEC is separate from planning (#378): procedure selection/repair cannot redefine success.
  • Experts are ordinary local symbolic computation (#376/#377): expert identity is not a model session.
  • One scheduler / graph runtime (#288/#376/#387): expert cooperation must not create another orchestration engine.
  • Expert applicability is symbolic and explainable (#377).
  • Primitive deterministic mutations can remain plan-native (#355) rather than dressing every operation up as an “agent.”
  • Observed current evidence is distinct from expert/model claims (#380/#384).
  • Diagnosis already contains explicit hypotheses and discriminating evidence requests (#385).
  • Repair and review cannot self-certify success (#384/#386).
  • Zero-model execution is an explicit acceptance requirement (#387).

Those survive this pass.

The main missing piece is that #379 currently compresses several intellectual roles into a single “Planner / Coordinator Expert.” A planner that both knows procedures, invents decompositions, opportunistically coordinates experts, chooses precedent, and diagnoses failure becomes a generic agent loop by another name.


Candidate architecture A — production-system control plane

Represent know-how primarily as productions:

production(r17,
           when([goal(recover(Service)),
                 observed(Service, unhealthy),
                 evidence(config_error(Service))]),
           propose(repair_strategy(reset_config(Service))),
           priority(specificity)).

Working-memory changes incrementally produce an agenda of applicable productions. A Rete-like network can optimize matching.

Strengths

  • excellent for reactive/local expert policy;
  • transparent applicability conditions;
  • natural fit for expert routing and diagnostic triggers;
  • incremental working-memory changes can be processed efficiently;
  • easy zero-LLM path.

Weaknesses

  • a large production set is not itself a good representation of an ordered/partially ordered multi-step procedure;
  • agenda/conflict resolution can become an implicit procedural semantics;
  • rule interactions produce “spaghetti expertise” when long-horizon decomposition is encoded only as local firings;
  • Rete’s memory/time tradeoff is an execution optimization, not a reason to make Rete working memory canonical durable knowledge.

Verdict: keep production rules as applicability/control/reaction knowledge, not the canonical representation of all know-how.


Candidate architecture B — classical/HTN planning as the procedural core

Represent primitive operators plus compound tasks and decomposition methods:

procedure_method(recover_service_default,
                 task(recover_service(Service)),
                 preconditions([unhealthy(Service)]),
                 network(recover_network(Service)),
                 effects([healthy(Service)]),
                 recovery(recover_service_fallback)).

procedure_network(recover_network(Service),
                  [n1:observe(config(Service)),
                   n2:diagnose(Service),
                   n3:repair(Service),
                   n4:verify(healthy(Service))],
                  [before(n1,n2), before(n2,n3), before(n3,n4)]).

Primitive actions use closed STRIPS-like symbolic precondition/effect summaries where useful; actual effects remain capability-mediated.

Strengths

  • directly represents procedural knowledge instead of forcing it into an agenda;
  • methods express domain knowledge about how to accomplish tasks;
  • hierarchy gives an inspectable explanation from abstract goal to concrete subtasks;
  • partial ordering naturally expresses independent branches;
  • known methods sharply reduce search compared with fully domain-independent planning;
  • clean fit with #288: method decomposition can compile to the existing validated dependency graph rather than execute itself.

Weaknesses

  • method choice and decomposition can still be combinatorial;
  • incomplete method libraries leave gaps;
  • static decomposition is awkward for opportunistic discovery and diagnosis unless the procedure can suspend and be refined from new evidence;
  • predicted effects are not observations and must never satisfy VERIFY automatically.

Verdict: strongest candidate for the canonical know-how representation, but insufficient as the whole control architecture.


Candidate architecture C — blackboard-centered procedural intelligence

Make current problem solving a typed shared board. Experts/knowledge sources inspect board state and propose new contributions:

work_item(w17, goal, recover_service(svc_a), open, Provenance).
work_item(w18, hypothesis, config_corrupt(svc_a), proposed, Provenance).
work_item(w19, evidence_gap, config_hash(svc_a), open, Provenance).
work_item(w20, method_candidate, recover_service_default, proposed, Provenance).

Experts become blackboard knowledge sources.

Strengths

  • natural heterogeneous cooperation;
  • supports incremental and opportunistic problem solving;
  • experts need not know every other expert;
  • hypotheses, partial solutions and evidence gaps become explicit shared objects;
  • very good match for diagnosis + retrieval + review interactions.

Weaknesses

  • classical blackboard systems often intertwine blackboard and control mechanisms;
  • a naive implementation would violate the repo’s “one scheduler” invariant;
  • unconstrained proposal generation can explode;
  • “current board contents” are run-local control state, not durable truth.

Verdict: adopt the logical blackboard model, not a second blackboard scheduler/runtime. Board entries are typed proposals/observations/goals consumed by #288/#377; the existing graph/async runtime remains execution authority.


Candidate architecture D — case-based control

Treat prior verified episodes as primary procedural knowledge:

procedure_case(case_44,
               problem_signature([symptom(hash_mismatch), state(clean_repo)]),
               context(...),
               procedure_used(proc_12),
               adaptations([skip(remote_sync)]),
               outcome(success),
               verification_receipt(vr_91),
               provenance(...)).

Retrieve similar cases, adapt, test, and retain.

Strengths

  • useful where procedural expertise is rich in precedents but weak in formal rules;
  • can remember actual outcomes and failed strategies;
  • naturally supplies experience to diagnosis/repair;
  • supports “what worked in a genuinely similar situation?” without another model call.

Weaknesses

  • similarity is not applicability;
  • adaptation is itself a reasoning problem;
  • one success is anecdote, not a universal procedure;
  • stale context, hidden causal differences, and correlated duplicate cases can mislead;
  • naïve nearest-neighbor retrieval can scale poorly and produce false analogies.

Verdict: case retrieval proposes procedural candidates/adaptations; it never directly creates a trusted method, expert mapping, or executable action. Promotion of repeated lessons belongs to Depth 7 / #404.


Candidate architecture E — model-based diagnostic controller

Make diagnosis the main control abstraction: observations inconsistent with an expected system model generate conflict sets; candidate diagnoses explain those conflicts; further observations discriminate candidates; repair follows only after sufficiently useful diagnosis.

Strengths

  • prevents blind retry loops;
  • explicitly separates “what might be wrong?” from “what should we change?”;
  • supports multiple faults/hypotheses;
  • choosing discriminating evidence before mutation can be cheaper and safer;
  • diagnosis receipts can explain why a repair was selected.

Weaknesses

  • useful diagnosis depends on useful behavioral/causal models;
  • minimal diagnoses can still be numerous;
  • candidate enumeration / hitting-set-like reasoning can become combinatorial;
  • not all domains have complete component models.

Verdict: this should strengthen #385, but diagnosis is a procedural subarchitecture, not the universal task planner.


Preferred design — Procedural Intelligence Fabric (PIF)

Adopt a hybrid with explicit semantic roles, not an undifferentiated agent planner:

Frozen goal / obligation
        ↓
PROCEDURAL KNOWLEDGE
  compound tasks + HTN-like methods
  primitive symbolic operators
  pre/post/constraints/recovery
        ↓
method decomposition / candidate task network
        ↓
PRODUCTION / APPLICABILITY RULES
  methods applicable?
  experts applicable?
  evidence gap?
  failure trigger?
        ↓
TYPED COORDINATION BOARD
  goals / hypotheses / observations
  method candidates / evidence gaps
  repair candidates / review findings
        ↓
#288 admitted dependency graph
        ↓
#377 expert invocation + plan-native ops
        ↓
capability / authority / effect boundary
        ↓
fresh observations
        ↓
#384 VERIFY
        ↓
if not satisfied
  MODEL-BASED DIAGNOSIS
     conflicts -> hypotheses
     -> discriminating evidence
     -> repair strategies
        ↓
method/replan candidate

CBR sits beside this path:
verified prior cases -> candidate method/adaptation/strategy
                        (never direct authority)

The important point is that PIF is not a new scheduler. It is a representation and reasoning layer that compiles admitted procedural decisions to the already-existing plan graph/runtime.


Canonical procedural object model

The current #392 sem_procedure/sem_step direction should be refined into a profile capable of representing the following distinctions without requiring a unique core predicate for each domain.

1. Task / goal schema

sem_task(TaskId,
         TaskKind,          % compound | primitive | observe | verify | reasoning
         Signature,
         GoalOrIntent,
         Qualifiers,
         Meta).

A task describes what work means. It is not a scheduled run.

2. Procedure method

sem_method(MethodId,
           CompoundTaskPattern,
           ApplicabilityExpr,
           NetworkRef,
           MethodConstraints,
           ExpectedEffects,
           FailureClasses,
           RecoveryRefs,
           Provenance).

Methods are declarative know-how. Multiple methods may implement one compound task.

3. Partial-order task network

sem_task_network(NetworkId,
                 NodeRefs,
                 OrderConstraints,
                 CausalOrDataLinks,
                 ResourceConstraints,
                 SuccessRef,
                 FailureRefs,
                 Meta).

No forced total order where only dependencies are known.

4. Primitive symbolic operator

sem_operator(OperatorId,
             ActionSchema,
             Preconditions,
             PredictedEffects,
             RequiredCapabilityClass,
             ObservationContract,
             Meta).

Predicted effect != observed effect. The operator says what the procedure expects the action to do. Actual execution still crosses the trusted host boundary, and fresh evidence is required afterward.

5. Control / applicability rule

sem_control_rule(RuleId,
                 Conditions,
                 Proposal,
                 PreferenceOrSpecificity,
                 Context,
                 Provenance).

This is where production-system knowledge belongs: choose/propose methods, experts, evidence requests, or recovery paths. It is not an arbitrary executable callback.

6. Procedural case / precedent

sem_case(CaseId,
         SituationSignature,
         Context,
         GoalRef,
         ProcedureOrPlanRef,
         AdaptationRefs,
         Outcome,
         VerifyReceiptRef,
         FailureOrSuccessFeatures,
         Provenance).

Cases remain episodic evidence. A case is not a rule.

7. Diagnosis

Reuse #392 causal/diagnostic semantics and #400 epistemic machinery rather than inventing a disconnected fault ontology:

sem_diagnostic_problem(DiagnosisId,
                       ExpectedModelRef,
                       ObservationRefs,
                       ConflictRefs,
                       HypothesisRefs,
                       DiscriminatorRefs,
                       Status,
                       Provenance).

A diagnosis hypothesis is a hypothesis, not an observed fault.

8. Execution/run instances stay separate

Hard identity split:

procedure/method knowledge
    != decomposition decision
    != plan graph instance
    != expert invocation
    != tool/effect attempt
    != observed state transition
    != VERIFY result

This is as important for procedural intelligence as proposition/assertion separation was for Depth 1.


Method selection and expert selection are different decisions

Current #379 mostly jumps from goal decomposition to expert assignment. The refined sequence should be:

Goal G
  ↓
applicable procedural methods for G
  ↓
choose/decompose method M
  ↓
obtain typed task network T
  ↓
for each ready expert-owned reasoning task:
    expert_applicable / expert_select
  ↓
for each ready plan-native primitive:
    #288/#355 path

An expert is a knowledge source/solver for a task, not automatically the procedure itself.

That gives reusable procedures independent of which concrete expert/version happens to solve a subgoal.

Example:

procedure: recover_repository_build
  1. establish fresh repository/source state
  2. diagnose failure class
  3. repair selected cause
  4. run admitted verification
  5. if violated, diagnose remaining gap

Step 2 may be served by one diagnosis expert today and a better one later without changing the procedural method’s identity.


Logical blackboard = typed coordination board, not scheduler

Blackboard ideas are useful only if the architecture preserves #376’s one-runtime invariant.

Canonical coordination entries should be run-local typed records such as:

goal
subgoal
observation
hypothesis
evidence_gap
method_candidate
plan_candidate
expert_proposal
diagnostic_conflict
diagnostic_hypothesis
discriminator_request
repair_candidate
review_finding
blocked_reason

Each entry carries producer, supporting evidence, context/frontier, status, and lifecycle.

A knowledge source/expert may propose contributions. The plan/coordinator validates and admits task-network changes. The existing runtime schedules admitted graph work.

Thus:

blackboard proposal != scheduled step
expert proposal     != authority
method selection    != effect admission

Durable storage should retain only materially useful receipts/cases/lessons according to Symbolic Memory policy; transient agenda state remains runtime-derived unless needed for replay.


Diagnosis → discrimination → repair must be explicit

Strengthen #385 around a model-based loop:

VERIFY violation / unexpected observation
        ↓
construct conflict(s)
        ↓
derive candidate diagnostic hypotheses
        ↓
1 hypothesis sufficiently discriminated?
        ├─ yes -> select applicable repair method
        └─ no  -> choose discriminating observation/test
                     ↓
                  fresh evidence
                     ↓
                  update hypotheses

Repair should not be selected solely because a symptom pattern matched a familiar failure string.

Where a system model is weak, heuristic diagnosis rules and prior cases may propose hypotheses, but the proposal provenance must expose that weaker basis.

A useful discriminator may be chosen by expected separation of currently live hypotheses, bounded by cost/authority/time. Exact information-gain mathematics can be profile-specific and belongs in later B/D work; A only establishes that evidence acquisition is a first-class procedural action.


CBR integration: case -> proposal, never instant policy

The CBR cycle maps cleanly into Machine Spirit:

RETRIEVE
  cases similar under a declared situation-feature schema

REUSE / ADAPT
  generate candidate method/parameter/order changes

REVISE
  execute only after normal validation/admission;
  VERIFY actual outcome

RETAIN
  append a new case with context + verification receipt

Important invariants:

similar_case(C) != applicable_method(C)
case_succeeded_once != general_rule
case_count != independent evidence count
adapted_case != trusted executable procedure

Repeated successful cases may become evidence for a candidate generalized method/rule, but promotion is explicitly deferred to #404’s bounded self-improvement gate.


Classical planning’s proper role

Do not use unconstrained classical planning as the default if a known procedure exists. Bylander’s results are a strong warning against assuming domain-independent search is cheap.

Recommended order:

known exact/admitted procedure
        ↓
HTN-like decomposition
        ↓
production/control rules + constraints choose variants
        ↓
CBR can propose an adaptation
        ↓
small bounded classical search over primitive operators IF needed
        ↓
explicit generative/LLM fallback only if enabled

Classical state-space search is valuable for small missing procedural gaps, verification of reachable subgoals, or synthesis inside a tightly bounded operator set. It should not replace accumulated know-how.


Behavior trees / workflows

Behavior trees are useful as a compact reactive execution representation, but adding a separate BT interpreter would duplicate #288’s graph runtime. Therefore:

  • a BT/workflow may be an import/export projection of admitted procedural knowledge;
  • selectors/fallbacks map to explicit method alternatives/recovery/control conditions;
  • sequences/parallel nodes map to dependency/order constraints;
  • execution remains the canonical graph runtime;
  • BT node names never become authority-bearing callbacks.

Rejected as canonical procedural IR/runtime in A.


Repository ownership boundaries

prolog-rlm

Owns:

  • procedural profile / generic task-method-network/operator/control-rule semantics;
  • method applicability/decomposition reasoning;
  • expert knowledge-source applicability and typed proposals;
  • compilation from admitted task networks to the existing #288 plan graph;
  • query-local production matching / optional Rete-style derived match cache;
  • generic diagnosis/conflict/hypothesis/discriminator algorithms;
  • generic case schema + retrieval/adaptation interfaces;
  • authority-neutral procedure/execution receipts;
  • zero-model procedural reasoning APIs.

Existing #288 / runtime

Still owns:

  • scheduling/readiness/concurrency;
  • cancellation and aggregate runtime budgets;
  • plan-native deterministic operations;
  • typed tool/effect dispatch.

Host/downstream applications

Own:

  • concrete operational capabilities and adapters;
  • application-specific methods/rules where not reusable;
  • host authority and policy.

symbolic-memory

Owns durable:

  • accepted procedure/method versions;
  • cases/precedents and outcome/verification receipts;
  • procedure supersession/history;
  • mappings between semantically equivalent/variant procedures where justified;
  • durable success/failure experience and source provenance.

It should not own an independent procedural planner/expert runtime.


API direction

Exact names follow implementation conventions, but the conceptual separation should be visible:

procedure_methods(+Task, +Context, -Candidates).
procedure_applicable(+Method, +Task, +Context, -Outcome).
procedure_decompose(+Method, +Task, +Context, -TaskNetwork).
procedure_validate_network(+TaskNetwork, +Context, -Outcome).
procedure_compile_plan(+TaskNetwork, +RuntimeContext, -PlanGraph).

control_proposals(+WorkingState, +Goal, -Proposals).

procedural_case_retrieve(+ProblemSignature, +Context, +Options, -Cases).
procedural_case_adapt(+Case, +CurrentProblem, +Policy, -Candidate).

diagnosis_begin(+ExpectedModel, +Observations, -DiagnosticState).
diagnosis_hypotheses(+DiagnosticState, -Hypotheses).
diagnosis_next_discriminator(+DiagnosticState, +Policy, -NeedOrDecision).
diagnosis_update(+DiagnosticState, +Observation, -NextState).

No API above directly executes arbitrary host actions.


Complexity / scaling implications

Production rules / Rete

Rete reduces repeated matching work by storing intermediate matches and sharing condition tests. The tradeoff is memory and invalidation complexity. Treat Rete nodes/matches as rebuildable derived state, scoped to active theory/run, not durable semantic truth.

For ordinary Prolog rule sets, indexing/tabling may outperform a literal Rete implementation. A should require the incremental-match contract, not prematurely require one algorithm.

HTN

Erol/Hendler/Nau show that HTN planning complexity depends strongly on restrictions over task networks; hierarchy is not automatic tractability. Practical safety therefore requires:

  • bounded decomposition depth;
  • bounded method alternatives;
  • cycle detection;
  • explicit partial-order network size limits;
  • no-progress fingerprints;
  • deterministic tie/ambiguity semantics;
  • query/task-local decomposition rather than globally expanding every method.

Classical planning

General propositional STRIPS plan existence is PSPACE-complete. Use bounded classical search as a fallback/gap solver, never an implicit unbounded search hidden under “planner.”

Blackboard coordination

Proposal space may blow up even when execution is cheap. Bound:

  • board items;
  • proposals per trigger;
  • active hypotheses;
  • repeated equivalent proposals;
  • method candidate count;
  • stale-board generations.

CBR

Naive retrieval is linear in case count. Scalable implementations need structured indexes/filters before expensive similarity. Adaptation has no general correctness guarantee; success is established only by downstream VERIFY.

Diagnosis

Conflict/diagnosis enumeration can be combinatorial. Query-driven diagnosis should maintain compact conflict/hypothesis structures, rank/select discriminating evidence without enumerating all hypothetical worlds, and stop with resource_limited/undecided instead of guessing.


Epistemic / provenance implications

Depth 3’s ESG/EFF applies directly to procedural intelligence.

Preserve separately:

source states procedure P
compiler reconstructed procedure P
P is an admitted procedural method
method M was selected for run R
case C suggests adapting M
expert E proposed subgoal G
action A was actually admitted/executed
observation O followed
VERIFY found requirement Q satisfied

Those are not one fact.

Predicted postconditions/effects are expectations, not observations.

A diagnosis hypothesis lives under the ordinary hypothesis/evidence semantics from #392/#400. Multiple diagnoses can coexist. A repair attempt supplies new evidence; it does not retroactively turn its diagnosis into a historical fact unless independently supported.

CBR similarity/adaptation scores are retrieval/procedural evidence, not calibrated truth.


Safety / authority implications

Hard invariants:

procedure represented      != procedure trusted
procedure trusted          != method selected
method selected            != plan admitted
plan admitted              != capability granted
action schema known        != executable host mapping
expert applicable          != authority
predicted effect           != observed effect
case precedent             != permission
repair recommendation      != effect admission

A source may contain a procedure called delete_everything, shell, merge, restart, or disable_verification. It remains inert symbolic knowledge.

A learned/imported method cannot map a semantic action to a host capability by name. Trusted host mappings are separate closed configuration/extension objects.

Procedure repair may modify candidate task networks/strategies but cannot mutate the Frozen Spec or authority ceiling.

Blackboard/workboard entries are untrusted coordination data by default; an expert posting approved(effect) does not approve an effect.


Adversarial review

Attack: “Just use the existing #288 dependency graph as the procedure representation.”

Rejected. A plan instance represents one selected execution decomposition. Reusable procedural knowledge needs method applicability, alternatives, abstract tasks, expected effects, recovery and provenance. Conflating method with run graph destroys reusable know-how and makes every run look like a new procedure.

Attack: “The Planner Expert can just invent/decompose everything.”

Rejected as default. That recreates a generic agent. Known procedure methods should dominate; free decomposition is explicit bounded synthesis/fallback.

Attack: “Use production rules for all know-how.”

Rejected. Good local control, poor explicit long-horizon procedural structure. Rule conflict resolution would accidentally become the hidden planning language.

Attack: “Blackboard architecture means we need a blackboard scheduler.”

Rejected. We want the shared typed partial-solution semantics, not another control runtime. #288 remains scheduler.

Attack: “Cases are learned procedures.”

Rejected. A case is evidence that a procedure/adaptation worked in one situation. Promotion requires separate validation across experience; #404 owns that.

Attack: “Postconditions prove an action worked.”

Rejected. Postconditions are predicted transition semantics. Actual effect success must be observed and, where material, independently VERIFY’d.

Attack: “Diagnosis chooses the most likely fault, then repair.”

Too weak as a generic contract. Source confidence/probability may not exist or be calibrated. Competing diagnoses should request discriminating evidence where useful. Guessing under resource exhaustion must remain explicit.

Attack: “HTN makes planning tractable.”

False in general. HTN can be highly expressive and restrictions matter. Bounded procedure profiles are mandatory.

Attack: “Behavior trees are the runtime we need.”

Rejected for core. They would duplicate the graph runtime. Treat them as projection/import where useful.


Falsifiable / conformance fixtures for A

These are design claims later implementation must prove or falsify.

A1 — known method, zero-model

Goal recover(service_x) has exactly one applicable trusted method. It decomposes to observe → diagnose → repair → verify and compiles to #288 with model_calls = 0.

A2 — method ambiguity

Two equally applicable methods with no declared preference return explicit method ambiguity or a deterministic configured policy result; clause/order accident is forbidden.

A3 — partial order preservation

Two independent observations may execute concurrently, but repair depends on both. HTN/task-network decomposition preserves this without inventing total order.

A4 — predicted vs observed effect

Primitive operator predicts running(service_x) after restart. Host returns uncertain/failed result. Current world state MUST NOT assert running(service_x) merely from operator semantics.

A5 — production-control trigger

Fresh evidence makes a more-specific repair method applicable. Control rule proposes it deterministically without an LLM and provides match/explanation receipt.

A6 — logical blackboard only

Two experts post compatible proposals; coordinator admits one network revision; runtime executes through #288. No independent “blackboard worker/scheduler” may dispatch effects.

A7 — diagnosis discrimination

Two live hypotheses explain one failure. The expert selects a read-only discriminating observation rather than arbitrarily choosing a repair. Returned evidence eliminates one hypothesis.

A8 — multi-fault diagnosis

Fixture requires two simultaneous faults; system must preserve the joint diagnosis candidate rather than force exactly one fault.

A9 — authority denial is not a diagnostic fault

Capability/authority denial cannot become “repair permissions” or a system-fault hypothesis; result remains blocked/policy.

A10 — CBR precedent is candidate-only

Nearest prior case proposes a method adaptation. The adaptation must pass ordinary applicability/network validation and cannot execute directly.

A11 — anecdote does not generalize

One verified successful case does not create a global procedural method/rule automatically.

A12 — changed context rejects precedent

A superficially similar case has incompatible resource/version/context constraints. Retrieval may return it, but adaptation/applicability must reject or mark it conditional.

A13 — method recursion cycle

A→B→A compound-task decomposition terminates with a structured cycle/limit result before execution.

A14 — bounded method explosion

Many applicable methods exceed configured decomposition/search bounds. Outcome is resource_limited/undecided with surviving candidates, not first-found success and not implicit model fallback.

A15 — procedure cannot weaken SPEC

Recovery method contains a step that would remove a Frozen-Spec obligation. Validation rejects it.

A16 — semantic action cannot self-bind authority

Remembered procedure step named merge_pr/delete cannot resolve itself to an executable capability by symbol-name coincidence.

A17 — VERIFY owns success

Procedure’s own success condition says “healthy,” but current VERIFY evidence still shows violation. Workflow remains unsatisfied.

A18 — procedure-instance identity

Two runs of the same method produce distinct plan/expert/effect/verify receipts while sharing one immutable method identity/version.

A19 — repair history becomes a case, not a rule

Successful diagnosed repair is retained as an episodic case with evidence. No trusted rule/method is synthesized without the later promotion boundary.

A20 — provider disabled

All A1–A19 fixtures over compiled procedural knowledge run with provider disabled except a separately explicit generative-fallback fixture.


Concrete canonical recommendations

  1. #392 / semantic IR: refine procedure semantics around task, method, task_network, operator, control_rule, case, and diagnostic-problem distinctions. Do not make execution instances part of canonical procedure identity.
  2. #376: adopt Procedural Intelligence Fabric as the conceptual expert/control layer; experts are knowledge sources/solvers over typed procedural tasks. Add the hard identity/authority distinctions.
  3. #379: refine Planner/Coordinator into procedure selection + method decomposition + plan compilation, not a generic decomposition oracle. Known methods first; bounded synthesis/search only when method knowledge is missing. Compile admitted task networks into #288; never execute them independently.
  4. #385: strengthen diagnosis into explicit model/conflict/hypothesis/discriminator state. Diagnosis precedes repair where ambiguity matters; authority denial remains non-diagnostic blocked state.
  5. #387: integration conformance should prove procedure identity/version, decomposition receipt, diagnosis/discriminator decisions, case retention and final VERIFY — not just expert call lineage.
  6. symbolic-memory: persist reusable methods/procedure versions and episodic cases/outcomes/verification receipts separately. Do not persist transient workboard/Rete state as semantic truth. Cross-memory procedure reconciliation must be reversible like entity reconciliation.
  7. #404 later: owns promotion from repeated cases/experience to candidate/admitted procedural methods, rule priorities or expert strategies. Depth 4 must not smuggle self-improvement into procedure execution.

Unresolved questions deliberately preserved for #401B/C/D

  • exact semantics of method preference/specificity when multiple procedures apply;
  • open-world preconditions: how much unknown blocks applicability versus triggers evidence acquisition;
  • conditional/contingent procedures under epistemic uncertainty;
  • procedure repair vs plan repair vs method-version supersession;
  • formal causal links/resource constraints between tasks;
  • temporal procedures, deadlines and concurrent actions;
  • how blackboard proposals interact with #400 epistemic warrant when experts disagree;
  • safe CBR feature schemas, similarity metrics and adaptation operators;
  • diagnosis discriminator selection under cost/risk/information-gain tradeoffs;
  • model-based versus heuristic diagnosis composition;
  • procedure federation across domains/hosts/authority contexts;
  • practical first procedural profile and complexity bounds;
  • Rete vs Prolog tabling/indexing benchmark decision;
  • efficient incremental method applicability after world-state changes;
  • durable execution/case receipts and replay at corpus scale;
  • behavior-tree/workflow import/export loss semantics.

A conclusion

Depth 4A prefers a hybrid Procedural Intelligence Fabric with an HTN-like procedural spine. Production rules supply local applicability/control; a logical blackboard/workboard supplies typed opportunistic cooperation but no scheduler; CBR supplies precedent/adaptation candidates; model-based diagnosis supplies conflict→hypothesis→discriminator→repair reasoning; bounded STRIPS-like search supplies a fallback for small procedural gaps. Every admitted execution still compiles to the single #288 runtime and crosses the existing capability/authority/effect boundaries.

This is a foundations result, not implementation proof. #401B must now adversarially attack the PIF, especially contingent/partial observability, open-world applicability, temporal/concurrent procedures, failure semantics, diagnosis/repair correctness, and authority-sensitive procedural knowledge.

## Machine Spirit Depth 4A — procedural-intelligence foundations This is **subpass A only**. It establishes representative formalisms and a baseline procedural architecture. It does **not** close #401 and does not advance to #402. B/C/D must still independently attack this design. ### Research question Given the already-strong #376–#387 substrate — expert registry, immutable SPEC, typed dependency plans, current evidence, VERIFY, diagnosis/repair, review, one graph runtime and explicit capability/effect boundaries — what should count as **procedural knowledge / know-how**, how should known know-how decompose goals, how should heterogeneous experts cooperate opportunistically, how should failure trigger diagnosis instead of blind retry, and how can prior successful cases help without turning anecdotes into trusted rules? The key question is not “which planner should Machine Spirit use?” The classical literature treats several genuinely different problems: 1. **production systems** — which locally applicable rule/knowledge source should fire now? 2. **classical planning** — which primitive state-changing operators can reach a goal? 3. **HTN planning** — which known methods decompose an abstract task into executable subtasks? 4. **blackboard architectures** — how can heterogeneous knowledge sources cooperate through shared partial solutions and opportunistic control? 5. **case-based reasoning** — which prior episode is sufficiently analogous to propose a reusable/adapted solution? 6. **model-based diagnosis** — which hypotheses explain an observed conflict, and which observation discriminates them before repair? Trying to collapse those into one generic “agent planner” loses useful semantics. --- ## Primary / authoritative sources inspected ### Production systems / Rete - Charles L. Forgy, **“Rete: A Fast Algorithm for the Many Pattern/Many Object Pattern Match Problem”**, *Artificial Intelligence* 19(1), 1982, pp. 17–37, DOI `10.1016/0004-3702(82)90020-0`. Bibliographic record: https://cir.nii.ac.jp/crid/1360011145674957312 . Rete is an incremental many-rule/many-object pattern-matching strategy. Its important lesson here is **implementation**, not semantics: cache shared tests/partial matches so working-memory changes do not rematch every rule from scratch. - Forgy & McDermott, **“OPS, a domain-independent production system language”**, IJCAI 1977, pp. 933–939; indexed in CMU’s historical expert-system repository: https://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/areas/expert/0.html . Production systems make condition/action knowledge explicit and separate working memory from productions and conflict resolution. ### Blackboard / opportunistic cooperation - H. Penny Nii, **“The Blackboard Model of Problem Solving and the Evolution of Blackboard Architectures”**, *AI Magazine* 7(2), 1986, DOI `10.1609/aimag.v7i2.537`: https://onlinelibrary.wiley.com/doi/abs/10.1609/aimag.v7i2.537 . Nii explicitly distinguishes the blackboard *model of problem solving* from concrete control architectures and surveys heterogeneous knowledge sources operating over shared partial solutions. - Lee Erman, Frederick Hayes-Roth, Victor Lesser, D. Raj Reddy, **“The HEARSAY-II Speech-Understanding System: Integrating Knowledge to Resolve Uncertainty”**, *ACM Computing Surveys* 12(2), 1980, DOI `10.1145/356810.356816`: https://dl.acm.org/doi/10.1145/356810.356816 . HEARSAY-II is a canonical demonstration of independent knowledge sources coordinating through common problem-solving state under uncertainty. - Nii, **“Blackboard Application Systems and a Knowledge Engineering Perspective”**, *AI Magazine* 7(3), 1986, DOI `10.1609/aimag.v7i3.550`: https://onlinelibrary.wiley.com/doi/abs/10.1609/aimag.v7i3.550 . Important for the warning that blackboard systems have materially different control strategies; “blackboard” does not itself define a scheduler. ### Classical planning / operator models - Richard Fikes & Nils Nilsson, **“STRIPS: A New Approach to the Application of Theorem Proving to Problem Solving”**, *Artificial Intelligence* 2, 1971, pp. 189–208, DOI `10.1016/0004-3702(71)90010-5`: https://cir.nii.ac.jp/crid/1360574094437855616 . STRIPS gives the useful primitive action idea: explicit current state, goal conditions, operators with applicability and state effects. - Tom Bylander, **“The Computational Complexity of Propositional STRIPS Planning”**, *Artificial Intelligence* 69, 1994, DOI `10.1016/0004-3702(94)90081-7`: https://ai.dmi.unibas.ch/research/reading_group/bylander-aij1994.pdf . General propositional STRIPS plan existence is PSPACE-complete; severe restrictions are required for tractability. This is strong evidence against making unrestricted domain-independent search the normal known-procedure path. ### Hierarchical task networks - Kutluhan Erol, James Hendler, Dana Nau, **“Complexity Results for HTN Planning”**, University of Maryland technical report / AAAI-era work, 1994–1995: https://drum.lib.umd.edu/items/0b87a627-5094-4251-a2c2-3d47889b0eec . The work analyzes how HTN complexity changes with restrictions on task networks and compares HTN with STRIPS-style planning. Critical lesson: hierarchy/domain methods give useful procedural knowledge, but unrestricted HTN is not a free tractability guarantee. - Dana Nau et al., **“SHOP2: An HTN Planning System”**, *JAIR* 20, 2003, pp. 379–404: https://research.ibm.com/publications/shop2-an-htn-planning-system and https://s.aaai.org/Papers/JAIR/Vol20/JAIR-2013.pdf . SHOP2 demonstrates a practical HTN system whose domain methods encode how tasks are normally accomplished, including temporal/metric planning features. ### Case-based reasoning - Agnar Aamodt & Enric Plaza, **“Case-Based Reasoning: Foundational Issues, Methodological Variations, and System Approaches”**, *AI Communications* 7(1), 1994, DOI `10.3233/AIC-1994-7104`: https://journals.sagepub.com/doi/10.3233/AIC-1994-7104 . Their canonical cycle is retrieval, reuse/adaptation, solution testing/revision, and retention/learning; they explicitly present CBR as one reasoning method inside integrated architectures rather than a replacement for all other reasoning. ### Model-based diagnosis - Raymond Reiter, **“A Theory of Diagnosis from First Principles”**, *Artificial Intelligence* 32(1), 1987, pp. 57–95. Bibliographic citation is preserved by Wiley here: https://onlinelibrary.wiley.com/doi/10.1111/1467-8640.00211 . Reiter’s central result relates diagnoses to conflict sets under an explicit system description and observations. - Johan de Kleer & Brian Williams, **“Diagnosing Multiple Faults”**, *Artificial Intelligence* 32(1), 1987, pp. 97–130, DOI `10.1016/0004-3702(87)90063-4`. Bibliographic record: https://www.rankless.org/hit-papers/10.1016/0004-3702%2887%2990063-4 . The General Diagnostic Engine tradition incrementally derives candidate diagnoses from conflicts instead of baking a single heuristic fault label into the controller. - Systems-theoretic reformulation of Reiter’s framework, IEEE Transactions on Reliability 41(1), 1992, DOI `10.1109/24.126668`: https://ieeexplore.ieee.org/document/126668/ . Useful warning: admissible fault models affect which diagnoses are meaningful; “minimal diagnosis” alone does not guarantee useful troubleshooting. --- # What the current #376–#387 architecture already gets right The existing repo is ahead of many modern “agent” architectures on several fundamentals: - **Frozen SPEC is separate from planning** (#378): procedure selection/repair cannot redefine success. - **Experts are ordinary local symbolic computation** (#376/#377): expert identity is not a model session. - **One scheduler / graph runtime** (#288/#376/#387): expert cooperation must not create another orchestration engine. - **Expert applicability is symbolic and explainable** (#377). - **Primitive deterministic mutations can remain plan-native** (#355) rather than dressing every operation up as an “agent.” - **Observed current evidence is distinct from expert/model claims** (#380/#384). - **Diagnosis already contains explicit hypotheses and discriminating evidence requests** (#385). - **Repair and review cannot self-certify success** (#384/#386). - **Zero-model execution is an explicit acceptance requirement** (#387). Those survive this pass. The main missing piece is that #379 currently compresses several intellectual roles into a single “Planner / Coordinator Expert.” A planner that both knows procedures, invents decompositions, opportunistically coordinates experts, chooses precedent, and diagnoses failure becomes a generic agent loop by another name. --- # Candidate architecture A — production-system control plane Represent know-how primarily as productions: ```prolog production(r17, when([goal(recover(Service)), observed(Service, unhealthy), evidence(config_error(Service))]), propose(repair_strategy(reset_config(Service))), priority(specificity)). ``` Working-memory changes incrementally produce an agenda of applicable productions. A Rete-like network can optimize matching. ## Strengths - excellent for reactive/local expert policy; - transparent applicability conditions; - natural fit for expert routing and diagnostic triggers; - incremental working-memory changes can be processed efficiently; - easy zero-LLM path. ## Weaknesses - a large production set is not itself a good representation of an ordered/partially ordered multi-step procedure; - agenda/conflict resolution can become an implicit procedural semantics; - rule interactions produce “spaghetti expertise” when long-horizon decomposition is encoded only as local firings; - Rete’s memory/time tradeoff is an execution optimization, not a reason to make Rete working memory canonical durable knowledge. **Verdict:** keep production rules as applicability/control/reaction knowledge, not the canonical representation of all know-how. --- # Candidate architecture B — classical/HTN planning as the procedural core Represent primitive operators plus compound tasks and decomposition methods: ```prolog procedure_method(recover_service_default, task(recover_service(Service)), preconditions([unhealthy(Service)]), network(recover_network(Service)), effects([healthy(Service)]), recovery(recover_service_fallback)). procedure_network(recover_network(Service), [n1:observe(config(Service)), n2:diagnose(Service), n3:repair(Service), n4:verify(healthy(Service))], [before(n1,n2), before(n2,n3), before(n3,n4)]). ``` Primitive actions use closed STRIPS-like symbolic precondition/effect summaries where useful; actual effects remain capability-mediated. ## Strengths - directly represents procedural knowledge instead of forcing it into an agenda; - methods express domain knowledge about *how* to accomplish tasks; - hierarchy gives an inspectable explanation from abstract goal to concrete subtasks; - partial ordering naturally expresses independent branches; - known methods sharply reduce search compared with fully domain-independent planning; - clean fit with #288: method decomposition can compile to the existing validated dependency graph rather than execute itself. ## Weaknesses - method choice and decomposition can still be combinatorial; - incomplete method libraries leave gaps; - static decomposition is awkward for opportunistic discovery and diagnosis unless the procedure can suspend and be refined from new evidence; - predicted effects are not observations and must never satisfy VERIFY automatically. **Verdict:** strongest candidate for the canonical *know-how* representation, but insufficient as the whole control architecture. --- # Candidate architecture C — blackboard-centered procedural intelligence Make current problem solving a typed shared board. Experts/knowledge sources inspect board state and propose new contributions: ```prolog work_item(w17, goal, recover_service(svc_a), open, Provenance). work_item(w18, hypothesis, config_corrupt(svc_a), proposed, Provenance). work_item(w19, evidence_gap, config_hash(svc_a), open, Provenance). work_item(w20, method_candidate, recover_service_default, proposed, Provenance). ``` Experts become blackboard knowledge sources. ## Strengths - natural heterogeneous cooperation; - supports incremental and opportunistic problem solving; - experts need not know every other expert; - hypotheses, partial solutions and evidence gaps become explicit shared objects; - very good match for diagnosis + retrieval + review interactions. ## Weaknesses - classical blackboard systems often intertwine blackboard and control mechanisms; - a naive implementation would violate the repo’s “one scheduler” invariant; - unconstrained proposal generation can explode; - “current board contents” are run-local control state, not durable truth. **Verdict:** adopt the **logical blackboard model**, not a second blackboard scheduler/runtime. Board entries are typed proposals/observations/goals consumed by #288/#377; the existing graph/async runtime remains execution authority. --- # Candidate architecture D — case-based control Treat prior verified episodes as primary procedural knowledge: ```prolog procedure_case(case_44, problem_signature([symptom(hash_mismatch), state(clean_repo)]), context(...), procedure_used(proc_12), adaptations([skip(remote_sync)]), outcome(success), verification_receipt(vr_91), provenance(...)). ``` Retrieve similar cases, adapt, test, and retain. ## Strengths - useful where procedural expertise is rich in precedents but weak in formal rules; - can remember actual outcomes and failed strategies; - naturally supplies experience to diagnosis/repair; - supports “what worked in a genuinely similar situation?” without another model call. ## Weaknesses - similarity is not applicability; - adaptation is itself a reasoning problem; - one success is anecdote, not a universal procedure; - stale context, hidden causal differences, and correlated duplicate cases can mislead; - naïve nearest-neighbor retrieval can scale poorly and produce false analogies. **Verdict:** case retrieval proposes procedural candidates/adaptations; it never directly creates a trusted method, expert mapping, or executable action. Promotion of repeated lessons belongs to Depth 7 / #404. --- # Candidate architecture E — model-based diagnostic controller Make diagnosis the main control abstraction: observations inconsistent with an expected system model generate conflict sets; candidate diagnoses explain those conflicts; further observations discriminate candidates; repair follows only after sufficiently useful diagnosis. ## Strengths - prevents blind retry loops; - explicitly separates “what might be wrong?” from “what should we change?”; - supports multiple faults/hypotheses; - choosing discriminating evidence before mutation can be cheaper and safer; - diagnosis receipts can explain why a repair was selected. ## Weaknesses - useful diagnosis depends on useful behavioral/causal models; - minimal diagnoses can still be numerous; - candidate enumeration / hitting-set-like reasoning can become combinatorial; - not all domains have complete component models. **Verdict:** this should strengthen #385, but diagnosis is a procedural subarchitecture, not the universal task planner. --- # Preferred design — Procedural Intelligence Fabric (PIF) Adopt a **hybrid with explicit semantic roles**, not an undifferentiated agent planner: ```text Frozen goal / obligation ↓ PROCEDURAL KNOWLEDGE compound tasks + HTN-like methods primitive symbolic operators pre/post/constraints/recovery ↓ method decomposition / candidate task network ↓ PRODUCTION / APPLICABILITY RULES methods applicable? experts applicable? evidence gap? failure trigger? ↓ TYPED COORDINATION BOARD goals / hypotheses / observations method candidates / evidence gaps repair candidates / review findings ↓ #288 admitted dependency graph ↓ #377 expert invocation + plan-native ops ↓ capability / authority / effect boundary ↓ fresh observations ↓ #384 VERIFY ↓ if not satisfied MODEL-BASED DIAGNOSIS conflicts -> hypotheses -> discriminating evidence -> repair strategies ↓ method/replan candidate CBR sits beside this path: verified prior cases -> candidate method/adaptation/strategy (never direct authority) ``` The important point is that **PIF is not a new scheduler**. It is a representation and reasoning layer that compiles admitted procedural decisions to the already-existing plan graph/runtime. --- ## Canonical procedural object model The current #392 `sem_procedure/sem_step` direction should be refined into a profile capable of representing the following distinctions without requiring a unique core predicate for each domain. ### 1. Task / goal schema ```prolog sem_task(TaskId, TaskKind, % compound | primitive | observe | verify | reasoning Signature, GoalOrIntent, Qualifiers, Meta). ``` A task describes *what work means*. It is not a scheduled run. ### 2. Procedure method ```prolog sem_method(MethodId, CompoundTaskPattern, ApplicabilityExpr, NetworkRef, MethodConstraints, ExpectedEffects, FailureClasses, RecoveryRefs, Provenance). ``` Methods are declarative know-how. Multiple methods may implement one compound task. ### 3. Partial-order task network ```prolog sem_task_network(NetworkId, NodeRefs, OrderConstraints, CausalOrDataLinks, ResourceConstraints, SuccessRef, FailureRefs, Meta). ``` No forced total order where only dependencies are known. ### 4. Primitive symbolic operator ```prolog sem_operator(OperatorId, ActionSchema, Preconditions, PredictedEffects, RequiredCapabilityClass, ObservationContract, Meta). ``` **Predicted effect != observed effect.** The operator says what the procedure expects the action to do. Actual execution still crosses the trusted host boundary, and fresh evidence is required afterward. ### 5. Control / applicability rule ```prolog sem_control_rule(RuleId, Conditions, Proposal, PreferenceOrSpecificity, Context, Provenance). ``` This is where production-system knowledge belongs: choose/propose methods, experts, evidence requests, or recovery paths. It is not an arbitrary executable callback. ### 6. Procedural case / precedent ```prolog sem_case(CaseId, SituationSignature, Context, GoalRef, ProcedureOrPlanRef, AdaptationRefs, Outcome, VerifyReceiptRef, FailureOrSuccessFeatures, Provenance). ``` Cases remain episodic evidence. A case is not a rule. ### 7. Diagnosis Reuse #392 causal/diagnostic semantics and #400 epistemic machinery rather than inventing a disconnected fault ontology: ```prolog sem_diagnostic_problem(DiagnosisId, ExpectedModelRef, ObservationRefs, ConflictRefs, HypothesisRefs, DiscriminatorRefs, Status, Provenance). ``` A diagnosis hypothesis is a hypothesis, not an observed fault. ### 8. Execution/run instances stay separate Hard identity split: ```text procedure/method knowledge != decomposition decision != plan graph instance != expert invocation != tool/effect attempt != observed state transition != VERIFY result ``` This is as important for procedural intelligence as proposition/assertion separation was for Depth 1. --- # Method selection and expert selection are different decisions Current #379 mostly jumps from goal decomposition to expert assignment. The refined sequence should be: ```text Goal G ↓ applicable procedural methods for G ↓ choose/decompose method M ↓ obtain typed task network T ↓ for each ready expert-owned reasoning task: expert_applicable / expert_select ↓ for each ready plan-native primitive: #288/#355 path ``` An expert is a **knowledge source/solver for a task**, not automatically the procedure itself. That gives reusable procedures independent of which concrete expert/version happens to solve a subgoal. Example: ```text procedure: recover_repository_build 1. establish fresh repository/source state 2. diagnose failure class 3. repair selected cause 4. run admitted verification 5. if violated, diagnose remaining gap ``` Step 2 may be served by one diagnosis expert today and a better one later without changing the procedural method’s identity. --- # Logical blackboard = typed coordination board, not scheduler Blackboard ideas are useful only if the architecture preserves #376’s one-runtime invariant. Canonical coordination entries should be run-local typed records such as: ```text goal subgoal observation hypothesis evidence_gap method_candidate plan_candidate expert_proposal diagnostic_conflict diagnostic_hypothesis discriminator_request repair_candidate review_finding blocked_reason ``` Each entry carries producer, supporting evidence, context/frontier, status, and lifecycle. A knowledge source/expert may **propose** contributions. The plan/coordinator validates and admits task-network changes. The existing runtime schedules admitted graph work. Thus: ```text blackboard proposal != scheduled step expert proposal != authority method selection != effect admission ``` Durable storage should retain only materially useful receipts/cases/lessons according to Symbolic Memory policy; transient agenda state remains runtime-derived unless needed for replay. --- # Diagnosis → discrimination → repair must be explicit Strengthen #385 around a model-based loop: ```text VERIFY violation / unexpected observation ↓ construct conflict(s) ↓ derive candidate diagnostic hypotheses ↓ 1 hypothesis sufficiently discriminated? ├─ yes -> select applicable repair method └─ no -> choose discriminating observation/test ↓ fresh evidence ↓ update hypotheses ``` Repair should not be selected solely because a symptom pattern matched a familiar failure string. Where a system model is weak, heuristic diagnosis rules and prior cases may propose hypotheses, but the proposal provenance must expose that weaker basis. A useful discriminator may be chosen by expected separation of currently live hypotheses, bounded by cost/authority/time. Exact information-gain mathematics can be profile-specific and belongs in later B/D work; A only establishes that evidence acquisition is a first-class procedural action. --- # CBR integration: case -> proposal, never instant policy The CBR cycle maps cleanly into Machine Spirit: ```text RETRIEVE cases similar under a declared situation-feature schema REUSE / ADAPT generate candidate method/parameter/order changes REVISE execute only after normal validation/admission; VERIFY actual outcome RETAIN append a new case with context + verification receipt ``` Important invariants: ```text similar_case(C) != applicable_method(C) case_succeeded_once != general_rule case_count != independent evidence count adapted_case != trusted executable procedure ``` Repeated successful cases may become evidence for a candidate generalized method/rule, but promotion is explicitly deferred to #404’s bounded self-improvement gate. --- # Classical planning’s proper role Do **not** use unconstrained classical planning as the default if a known procedure exists. Bylander’s results are a strong warning against assuming domain-independent search is cheap. Recommended order: ```text known exact/admitted procedure ↓ HTN-like decomposition ↓ production/control rules + constraints choose variants ↓ CBR can propose an adaptation ↓ small bounded classical search over primitive operators IF needed ↓ explicit generative/LLM fallback only if enabled ``` Classical state-space search is valuable for small missing procedural gaps, verification of reachable subgoals, or synthesis inside a tightly bounded operator set. It should not replace accumulated know-how. --- # Behavior trees / workflows Behavior trees are useful as a compact reactive execution representation, but adding a separate BT interpreter would duplicate #288’s graph runtime. Therefore: - a BT/workflow may be an **import/export projection** of admitted procedural knowledge; - selectors/fallbacks map to explicit method alternatives/recovery/control conditions; - sequences/parallel nodes map to dependency/order constraints; - execution remains the canonical graph runtime; - BT node names never become authority-bearing callbacks. Rejected as canonical procedural IR/runtime in A. --- # Repository ownership boundaries ## `prolog-rlm` Owns: - procedural profile / generic task-method-network/operator/control-rule semantics; - method applicability/decomposition reasoning; - expert knowledge-source applicability and typed proposals; - compilation from admitted task networks to the existing #288 plan graph; - query-local production matching / optional Rete-style derived match cache; - generic diagnosis/conflict/hypothesis/discriminator algorithms; - generic case schema + retrieval/adaptation interfaces; - authority-neutral procedure/execution receipts; - zero-model procedural reasoning APIs. ## Existing #288 / runtime Still owns: - scheduling/readiness/concurrency; - cancellation and aggregate runtime budgets; - plan-native deterministic operations; - typed tool/effect dispatch. ## Host/downstream applications Own: - concrete operational capabilities and adapters; - application-specific methods/rules where not reusable; - host authority and policy. ## `symbolic-memory` Owns durable: - accepted procedure/method versions; - cases/precedents and outcome/verification receipts; - procedure supersession/history; - mappings between semantically equivalent/variant procedures where justified; - durable success/failure experience and source provenance. It should **not** own an independent procedural planner/expert runtime. --- # API direction Exact names follow implementation conventions, but the conceptual separation should be visible: ```prolog procedure_methods(+Task, +Context, -Candidates). procedure_applicable(+Method, +Task, +Context, -Outcome). procedure_decompose(+Method, +Task, +Context, -TaskNetwork). procedure_validate_network(+TaskNetwork, +Context, -Outcome). procedure_compile_plan(+TaskNetwork, +RuntimeContext, -PlanGraph). control_proposals(+WorkingState, +Goal, -Proposals). procedural_case_retrieve(+ProblemSignature, +Context, +Options, -Cases). procedural_case_adapt(+Case, +CurrentProblem, +Policy, -Candidate). diagnosis_begin(+ExpectedModel, +Observations, -DiagnosticState). diagnosis_hypotheses(+DiagnosticState, -Hypotheses). diagnosis_next_discriminator(+DiagnosticState, +Policy, -NeedOrDecision). diagnosis_update(+DiagnosticState, +Observation, -NextState). ``` No API above directly executes arbitrary host actions. --- # Complexity / scaling implications ## Production rules / Rete Rete reduces repeated matching work by storing intermediate matches and sharing condition tests. The tradeoff is memory and invalidation complexity. Treat Rete nodes/matches as **rebuildable derived state**, scoped to active theory/run, not durable semantic truth. For ordinary Prolog rule sets, indexing/tabling may outperform a literal Rete implementation. A should require the *incremental-match contract*, not prematurely require one algorithm. ## HTN Erol/Hendler/Nau show that HTN planning complexity depends strongly on restrictions over task networks; hierarchy is not automatic tractability. Practical safety therefore requires: - bounded decomposition depth; - bounded method alternatives; - cycle detection; - explicit partial-order network size limits; - no-progress fingerprints; - deterministic tie/ambiguity semantics; - query/task-local decomposition rather than globally expanding every method. ## Classical planning General propositional STRIPS plan existence is PSPACE-complete. Use bounded classical search as a fallback/gap solver, never an implicit unbounded search hidden under “planner.” ## Blackboard coordination Proposal space may blow up even when execution is cheap. Bound: - board items; - proposals per trigger; - active hypotheses; - repeated equivalent proposals; - method candidate count; - stale-board generations. ## CBR Naive retrieval is linear in case count. Scalable implementations need structured indexes/filters before expensive similarity. Adaptation has no general correctness guarantee; success is established only by downstream VERIFY. ## Diagnosis Conflict/diagnosis enumeration can be combinatorial. Query-driven diagnosis should maintain compact conflict/hypothesis structures, rank/select discriminating evidence without enumerating all hypothetical worlds, and stop with `resource_limited/undecided` instead of guessing. --- # Epistemic / provenance implications Depth 3’s ESG/EFF applies directly to procedural intelligence. Preserve separately: ```text source states procedure P compiler reconstructed procedure P P is an admitted procedural method method M was selected for run R case C suggests adapting M expert E proposed subgoal G action A was actually admitted/executed observation O followed VERIFY found requirement Q satisfied ``` Those are not one fact. Predicted postconditions/effects are **expectations**, not observations. A diagnosis hypothesis lives under the ordinary hypothesis/evidence semantics from #392/#400. Multiple diagnoses can coexist. A repair attempt supplies new evidence; it does not retroactively turn its diagnosis into a historical fact unless independently supported. CBR similarity/adaptation scores are retrieval/procedural evidence, not calibrated truth. --- # Safety / authority implications Hard invariants: ```text procedure represented != procedure trusted procedure trusted != method selected method selected != plan admitted plan admitted != capability granted action schema known != executable host mapping expert applicable != authority predicted effect != observed effect case precedent != permission repair recommendation != effect admission ``` A source may contain a procedure called `delete_everything`, `shell`, `merge`, `restart`, or `disable_verification`. It remains inert symbolic knowledge. A learned/imported method cannot map a semantic action to a host capability by name. Trusted host mappings are separate closed configuration/extension objects. Procedure repair may modify candidate task networks/strategies but cannot mutate the Frozen Spec or authority ceiling. Blackboard/workboard entries are untrusted coordination data by default; an expert posting `approved(effect)` does not approve an effect. --- # Adversarial review ### Attack: “Just use the existing #288 dependency graph as the procedure representation.” Rejected. A plan instance represents one selected execution decomposition. Reusable procedural knowledge needs method applicability, alternatives, abstract tasks, expected effects, recovery and provenance. Conflating method with run graph destroys reusable know-how and makes every run look like a new procedure. ### Attack: “The Planner Expert can just invent/decompose everything.” Rejected as default. That recreates a generic agent. Known procedure methods should dominate; free decomposition is explicit bounded synthesis/fallback. ### Attack: “Use production rules for all know-how.” Rejected. Good local control, poor explicit long-horizon procedural structure. Rule conflict resolution would accidentally become the hidden planning language. ### Attack: “Blackboard architecture means we need a blackboard scheduler.” Rejected. We want the shared typed partial-solution semantics, not another control runtime. #288 remains scheduler. ### Attack: “Cases are learned procedures.” Rejected. A case is evidence that a procedure/adaptation worked in one situation. Promotion requires separate validation across experience; #404 owns that. ### Attack: “Postconditions prove an action worked.” Rejected. Postconditions are predicted transition semantics. Actual effect success must be observed and, where material, independently VERIFY’d. ### Attack: “Diagnosis chooses the most likely fault, then repair.” Too weak as a generic contract. Source confidence/probability may not exist or be calibrated. Competing diagnoses should request discriminating evidence where useful. Guessing under resource exhaustion must remain explicit. ### Attack: “HTN makes planning tractable.” False in general. HTN can be highly expressive and restrictions matter. Bounded procedure profiles are mandatory. ### Attack: “Behavior trees are the runtime we need.” Rejected for core. They would duplicate the graph runtime. Treat them as projection/import where useful. --- # Falsifiable / conformance fixtures for A These are design claims later implementation must prove or falsify. ### A1 — known method, zero-model Goal `recover(service_x)` has exactly one applicable trusted method. It decomposes to observe → diagnose → repair → verify and compiles to #288 with `model_calls = 0`. ### A2 — method ambiguity Two equally applicable methods with no declared preference return explicit method ambiguity or a deterministic configured policy result; clause/order accident is forbidden. ### A3 — partial order preservation Two independent observations may execute concurrently, but repair depends on both. HTN/task-network decomposition preserves this without inventing total order. ### A4 — predicted vs observed effect Primitive operator predicts `running(service_x)` after restart. Host returns uncertain/failed result. Current world state MUST NOT assert `running(service_x)` merely from operator semantics. ### A5 — production-control trigger Fresh evidence makes a more-specific repair method applicable. Control rule proposes it deterministically without an LLM and provides match/explanation receipt. ### A6 — logical blackboard only Two experts post compatible proposals; coordinator admits one network revision; runtime executes through #288. No independent “blackboard worker/scheduler” may dispatch effects. ### A7 — diagnosis discrimination Two live hypotheses explain one failure. The expert selects a read-only discriminating observation rather than arbitrarily choosing a repair. Returned evidence eliminates one hypothesis. ### A8 — multi-fault diagnosis Fixture requires two simultaneous faults; system must preserve the joint diagnosis candidate rather than force exactly one fault. ### A9 — authority denial is not a diagnostic fault Capability/authority denial cannot become “repair permissions” or a system-fault hypothesis; result remains blocked/policy. ### A10 — CBR precedent is candidate-only Nearest prior case proposes a method adaptation. The adaptation must pass ordinary applicability/network validation and cannot execute directly. ### A11 — anecdote does not generalize One verified successful case does not create a global procedural method/rule automatically. ### A12 — changed context rejects precedent A superficially similar case has incompatible resource/version/context constraints. Retrieval may return it, but adaptation/applicability must reject or mark it conditional. ### A13 — method recursion cycle A→B→A compound-task decomposition terminates with a structured cycle/limit result before execution. ### A14 — bounded method explosion Many applicable methods exceed configured decomposition/search bounds. Outcome is `resource_limited/undecided` with surviving candidates, not first-found success and not implicit model fallback. ### A15 — procedure cannot weaken SPEC Recovery method contains a step that would remove a Frozen-Spec obligation. Validation rejects it. ### A16 — semantic action cannot self-bind authority Remembered procedure step named `merge_pr`/`delete` cannot resolve itself to an executable capability by symbol-name coincidence. ### A17 — VERIFY owns success Procedure’s own success condition says “healthy,” but current VERIFY evidence still shows violation. Workflow remains unsatisfied. ### A18 — procedure-instance identity Two runs of the same method produce distinct plan/expert/effect/verify receipts while sharing one immutable method identity/version. ### A19 — repair history becomes a case, not a rule Successful diagnosed repair is retained as an episodic case with evidence. No trusted rule/method is synthesized without the later promotion boundary. ### A20 — provider disabled All A1–A19 fixtures over compiled procedural knowledge run with provider disabled except a separately explicit generative-fallback fixture. --- # Concrete canonical recommendations 1. **#392 / semantic IR:** refine procedure semantics around `task`, `method`, `task_network`, `operator`, `control_rule`, `case`, and diagnostic-problem distinctions. Do not make execution instances part of canonical procedure identity. 2. **#376:** adopt Procedural Intelligence Fabric as the conceptual expert/control layer; experts are knowledge sources/solvers over typed procedural tasks. Add the hard identity/authority distinctions. 3. **#379:** refine Planner/Coordinator into **procedure selection + method decomposition + plan compilation**, not a generic decomposition oracle. Known methods first; bounded synthesis/search only when method knowledge is missing. Compile admitted task networks into #288; never execute them independently. 4. **#385:** strengthen diagnosis into explicit model/conflict/hypothesis/discriminator state. Diagnosis precedes repair where ambiguity matters; authority denial remains non-diagnostic blocked state. 5. **#387:** integration conformance should prove procedure identity/version, decomposition receipt, diagnosis/discriminator decisions, case retention and final VERIFY — not just expert call lineage. 6. **symbolic-memory:** persist reusable methods/procedure versions and episodic cases/outcomes/verification receipts separately. Do not persist transient workboard/Rete state as semantic truth. Cross-memory procedure reconciliation must be reversible like entity reconciliation. 7. **#404 later:** owns promotion from repeated cases/experience to candidate/admitted procedural methods, rule priorities or expert strategies. Depth 4 must not smuggle self-improvement into procedure execution. --- # Unresolved questions deliberately preserved for #401B/C/D - exact semantics of method preference/specificity when multiple procedures apply; - open-world preconditions: how much unknown blocks applicability versus triggers evidence acquisition; - conditional/contingent procedures under epistemic uncertainty; - procedure repair vs plan repair vs method-version supersession; - formal causal links/resource constraints between tasks; - temporal procedures, deadlines and concurrent actions; - how blackboard proposals interact with #400 epistemic warrant when experts disagree; - safe CBR feature schemas, similarity metrics and adaptation operators; - diagnosis discriminator selection under cost/risk/information-gain tradeoffs; - model-based versus heuristic diagnosis composition; - procedure federation across domains/hosts/authority contexts; - practical first procedural profile and complexity bounds; - Rete vs Prolog tabling/indexing benchmark decision; - efficient incremental method applicability after world-state changes; - durable execution/case receipts and replay at corpus scale; - behavior-tree/workflow import/export loss semantics. ## A conclusion **Depth 4A prefers a hybrid Procedural Intelligence Fabric with an HTN-like procedural spine.** Production rules supply local applicability/control; a logical blackboard/workboard supplies typed opportunistic cooperation but no scheduler; CBR supplies precedent/adaptation candidates; model-based diagnosis supplies conflict→hypothesis→discriminator→repair reasoning; bounded STRIPS-like search supplies a fallback for small procedural gaps. Every admitted execution still compiles to the single #288 runtime and crosses the existing capability/authority/effect boundaries. This is a foundations result, not implementation proof. **#401B must now adversarially attack the PIF**, especially contingent/partial observability, open-world applicability, temporal/concurrent procedures, failure semantics, diagnosis/repair correctness, and authority-sensitive procedural knowledge.
Author
Owner

Machine Spirit Depth 4B — adversarial procedural semantics under uncertainty, time, concurrency, repair, and authority

This is subpass B only. It attacks the Depth-4A Procedural Intelligence Fabric (PIF) under conditions where static HTN decomposition is not enough: unknown facts, sensing, nondeterministic outcomes, partial observability, temporal/resource constraints, exogenous change, conflicting methods, risky diagnosis, and misleading precedents. It does not close #401 or advance to #402. C/D remain required.

Research questions

  1. What does a method precondition mean when its truth is unknown, conflicted, time-sensitive, or only attributed rather than world-warranted?
  2. When must a procedure be a policy over observations/belief state rather than a static task network?
  3. What guarantees do we require for nondeterministic procedures: weak, strong, strong-cyclic, or something explicitly fairness-qualified?
  4. How should duration, deadlines, concurrent actions, invariants, shared resources, and exogenous events constrain method admission and execution?
  5. When a run diverges from predicted state, what is repaired: the current plan instance, the selected method binding, the reusable method itself, or only the world state?
  6. How should multiple diagnostic hypotheses select discriminators when tests themselves have cost, risk, authority requirements, and possible side effects?
  7. How can CBR precedents and blackboard proposals remain useful without smuggling stale context, unsafe authority, or epistemically disputed claims into execution?

Primary / authoritative sources inspected

Nondeterministic / contingent planning

  • Alessandro Cimatti, Marco Pistore, Marco Roveri, Paolo Traverso, “Weak, Strong, and Strong Cyclic Planning via Symbolic Model Checking,” Artificial Intelligence 147(1–2), 2003, DOI 10.1016/S0004-3702(02)00374-0. Institutional record: https://iris.unitn.it/handle/11572/74586 . The key distinction is semantic, not merely algorithmic: weak plans may have a successful execution; strong plans guarantee goal achievement; strong-cyclic policies may rely on iterative retry under fairness assumptions.
  • Piergiorgio Bertoli, Alessandro Cimatti, Marco Roveri, Paolo Traverso, “Planning in Nondeterministic Domains under Partial Observability via Symbolic Model Checking,” IJCAI 2001: https://iris.unitn.it/handle/11572/258842 . Conditional plans are policies over a partially observed belief state; sensing/observations determine branches, and the state space can blow up exponentially.
  • Blai Bonet, “Conformant Plans and Beyond: Principles and Complexity,” Artificial Intelligence 174(3–4), 2010, DOI 10.1016/j.artint.2009.11.001: https://doi.org/10.1016/j.artint.2009.11.001 . Useful for the spectrum from linear/conformant plans to bounded-branching and fully contingent plans, and for the fact that partially observable planning reasons over belief state rather than ordinary world state.
  • Dillon Chen & Pascal Bercher, “Fully Observable Nondeterministic HTN Planning — Formalisation and Complexity Results,” ICAPS 2021: https://ojs.aaai.org/index.php/ICAPS/article/view/15949 and “Flexible FOND HTN Planning: A Complexity Analysis,” ICAPS 2022: https://ojs.aaai.org/index.php/ICAPS/article/view/19782 . HTN methods can be extended to nondeterministic domains, but uncertainty changes both solution criteria and complexity; hierarchy does not remove the need to define policy semantics.
  • Alberto Camacho & Sheila McIlraith, “Strong-Cyclic Planning when Fairness is Not a Valid Assumption,” KnowProS 2016: https://ceur-ws.org/Vol-1648/paper11.pdf . Strong-cyclic guarantees depend on fairness assumptions; those assumptions must be explicit rather than hidden in a retry loop.

High-level procedures, sensing, exogenous change

  • Hector Levesque, Raymond Reiter, Yves Lespérance, Fangzhen Lin, Richard Scherl, GOLOG (Journal of Logic Programming, 1997), plus Giuseppe De Giacomo, Yves Lespérance, Hector Levesque, ConGolog (Artificial Intelligence 121, 2000). University of Toronto bibliography/resources: https://www.cs.toronto.edu/cogrobo/BibTex/bibcogroba_bib.html and https://www.cs.toronto.edu/~fritz/golog/ . ConGolog/IndiGolog separate high-level procedural programs from primitive execution while supporting concurrency, sensing, interrupts and exogenous actions.
  • Giuseppe De Giacomo, Ray Reiter, Mikhail Soutchanski, “Execution Monitoring of High-Level Robot Programs,” KR 1998: https://www.cs.ryerson.ca/~mes/publications/kr98correct.pdf . Execution monitoring explicitly compares physical observations to predicted state and performs recovery from exogenous events before resuming a program. This directly supports keeping procedure semantics, predicted effects, observed state, and recovery distinct.
  • Robert Goldman, “A Semantics for HTN Methods,” ICAPS 2009: https://ojs.aaai.org/index.php/ICAPS/article/view/13377 . HTN methods need an execution semantics; the paper relates SHOP2 methods to ConGolog/situation calculus precisely because decomposition syntax alone is insufficient for a reliable executive.

Time, concurrency, resources, deadlines

  • Maria Fox & Derek Long, “PDDL2.1: An Extension to PDDL for Expressing Temporal Planning Domains,” JAIR 20, 2003, DOI 10.1613/jair.1129: https://www.cs.cmu.edu/afs/cs/project/jair/pub/volume20/fox03a-html/JAIRpddl.html . Formal semantics for durative actions, numeric resources, invariants, concurrency and plan validation. This is strong evidence that temporal/resource conditions belong to plan validity, not ad-hoc runtime metadata.
  • Michael Cashmore et al., “Temporal Planning while the Clock Ticks,” ICAPS 2018: https://ojs.aaai.org/index.php/ICAPS/article/view/13878 . Planning latency itself can invalidate deadline-sensitive plans; deadlines must be checked against current time at admission/execution, not only at method-authoring time.
  • Alessandro Umbrico et al., “Integrating Resource Management and Timeline-Based Planning,” ICAPS 2018: https://ojs.aaai.org/index.php/ICAPS/article/view/13905 . Explicit temporal/resource reasoning is needed for real plan feasibility.
  • James Boerkoel et al., “Distributed Algorithms for Incrementally Maintaining Multiagent Simple Temporal Networks,” ICAPS 2013: https://ojs.aaai.org/index.php/ICAPS/article/view/13551 . New constraints/exogenous events require incremental re-propagation of temporal consistency rather than assuming an originally valid schedule remains valid.

Execution repair / partial order

  • Oscar Lima et al., “Robust Plan Execution with Unexpected Observations,” 2020: https://strathprints.strath.ac.uk/71950/ . Unexpected state can make a fixed total ordering unnecessarily brittle; adaptable partial-order execution can preserve plan validity while exploiting benign world differences.
  • Robert Young, Martha Pollack, Johanna Moore, “Decomposition and Causality in Partial-Order Planning,” AIPS 1994: https://publications.ri.cmu.edu/decomposition-and-causality-in-partial-order-planning . Partial decompositions and causal links support filling procedural gaps in context; causal structure is needed to know what an execution deviation actually threatens.

Diagnostic test selection / case maintenance

  • Paul Glasziou & Jørgen Hilden, “Test Selection Measures,” Medical Decision Making 9(2), 1989, DOI 10.1177/0272989X8900900208: https://journals.sagepub.com/doi/10.1177/0272989X8900900208 . Discriminator choice must account for risk and cost, not only information gain.
  • Barry Smyth & Elizabeth McKenna, “Competence Models and the Maintenance Problem,” Computational Intelligence 17(2), 2001/2002, DOI 10.1111/0824-7935.00142: https://onlinelibrary.wiley.com/doi/abs/10.1111/0824-7935.00142 . A CBR system's competence depends not just on case retrieval but on the case base, similarity knowledge, adaptation knowledge and their maintenance as the environment changes.

What Depth 4A gets right — and where it breaks

A's explicit separation of HTN methods, production applicability, logical blackboard proposals, CBR candidates, diagnosis, #288 scheduling, authority/effects and VERIFY survives.

The break is this implicit A-shaped assumption:

method applicability can be decided from one current world state
        ↓
decompose once
        ↓
execute a mostly static partial-order plan

That is not valid under open-world knowledge, sensing, nondeterministic effects, deadlines, exogenous changes, or authority-dependent actions.

The required refinement is:

A procedure is reusable policy knowledge over epistemic/temporal/resource state; a plan instance is one admitted execution projection of that policy against a frozen evidence frontier.


Candidate architecture A — static HTN + replan-on-any-surprise

Keep A's method semantics unchanged. If a precondition is unknown or an effect differs from prediction, stop and run #385/#379 again.

Strengths

  • simple;
  • preserves one #288 scheduler;
  • no belief-policy explosion in ordinary paths;
  • easy to explain.

Failures

  • conflates unknown with not applicable unless carefully guarded;
  • sensing-heavy procedures degenerate into repeated planner calls;
  • retry/replan may implicitly assume fairness;
  • loses intentional contingent branches already known by the procedure author;
  • expensive/disruptive for benign exogenous changes;
  • cannot state strong guarantees over nondeterministic outcomes.

Verdict: retain as a cheap profile for deterministic, fully observed procedures; reject as universal semantics.


Candidate architecture B — full belief-state contingent planner

Every method is compiled into a policy over belief states and observations. The executor follows the policy until the goal is guaranteed.

Strengths

  • principled semantics for partial observability;
  • naturally represents sensing and observation-conditioned branches;
  • can state weak/strong/strong-cyclic guarantee classes;
  • correctly treats unknown state as a set/distribution of possible worlds rather than false.

Failures

  • belief-state branching can be exponential;
  • generating full policies for mundane known work is absurdly expensive;
  • probabilistic/POMDP semantics introduce numerical assumptions the canonical system does not universally possess;
  • full policy generation would duplicate responsibilities already split across #379/#288/#385.

Verdict: the semantic model is useful; full global contingent planning is not the default runtime architecture.


Candidate architecture C — monitored procedural policy with bounded belief obligations (preferred)

Extend PIF so a method can declare observation gates, outcome alternatives, temporal/resource invariants, and recovery/continuation policies without forcing the entire world into one global contingent planner.

Conceptually:

sem_method_policy(Method,
    task(Task),
    admission(AdmissionProfile),
    initial_guards(GuardRefs),
    network(TaskNetwork),
    observation_points(ObservationRefs),
    outcome_model(OutcomeRefs),
    temporal_contract(TemporalRef),
    resource_contract(ResourceRef),
    guarantee(GuaranteeClass),
    fairness(FairnessRef),
    recovery(RecoveryRefs),
    provenance(Provenance)).

A running plan has an explicit execution frontier:

plan instance + method/version
current admitted task-network frontier
frozen/relevant evidence generation
live epistemic support status for required guards
open observation obligations
active temporal/resource constraints
observed primitive outcomes
exogenous events since last frontier
remaining guarantee assumptions/budget

At each relevant transition:

observe / receive event
        ↓
update current evidence
        ↓
re-evaluate only affected guards/invariants/causal links
        ↓
continue admitted network
OR follow declared contingent branch
OR request discriminator
OR bounded plan-instance repair
OR method re-selection
OR blocked/unknown/resource-limited

This keeps ordinary deterministic procedures cheap while allowing explicit conditional policies where the domain needs them.


Major semantic decision 1 — preconditions are epistemic predicates, not Prolog failure

A method/operator guard must be evaluated against #400 epistemic semantics and return at least:

satisfied
refuted
unknown
conflicted
blocked
unsupported_query

Never interpret ordinary failure-to-prove as refuted unless the method explicitly references an admitted closed-world predicate/profile.

Classify procedural conditions:

hard_guard
    must be warranted before admission/execution

observation_gate
    unknown triggers a typed evidence/sensing obligation

branch_guard
    result selects an explicit policy branch

assumption
    allowed only under an explicit assumption/environment receipt

monitor_invariant
    must remain warranted throughout a durative/execution interval

success_condition
    predicted by planning but ultimately decided only by #384 VERIFY/current evidence

Safety default: unknown/conflicted security-, authority-, resource-, destructive-effect-, or irreversible-action preconditions cannot be guessed true. They become evidence/blocked decisions.


Major semantic decision 2 — method applicability != execution safety

A method may be conceptually applicable while a particular binding/run is not executable now.

Keep separate:

method_applicable(Method, Task, SemanticContext)
method_admissible(Method, FrozenSpec, EpistemicProfile)
plan_instance_valid(Network, CurrentEvidence, Time, Resources)
action_authorized(Action, Principal, CapabilityContext)
action_ready(Action, SchedulerFrontier)

This prevents authority/resource/time failures from being misdiagnosed as “method not applicable” and prevents a good generic method from being globally discredited because one host lacks a capability.


Major semantic decision 3 — nondeterministic procedures need explicit guarantee classes

A policy/result should not just say procedure works.

Represent a guarantee class such as:

deterministic
weak
strong
strong_cyclic
best_effort
unsupported_guarantee

For strong_cyclic, preserve the fairness assumption/profile explicitly. Camacho/McIlraith show that classical strong-cyclic soundness depends on fairness assumptions that can fail in real domains.

Therefore:

retry until success

is not an unconditional guarantee.

A retry/recovery loop needs at least:

progress measure or changing evidence
bounded attempts/work
fairness/environment assumption if semantically required
no-progress fingerprint
exit state when assumption is violated/exhausted

A weak plan/policy is not eligible for unattended high-risk effects unless an explicit policy admits weak guarantees.


Major semantic decision 4 — predicted effects become outcome hypotheses

A primitive operator's predicted effect is not one future fact. Under uncertainty it is an outcome model:

operator_outcome(Action, OutcomeClass,
                 Conditions, PredictedEffects, ProbabilityOrNone, Provenance).

After execution:

predicted outcome
    !=
observed outcome

An unexpected observation may mean:

  • primitive action failure;
  • expected nondeterministic outcome;
  • exogenous world change;
  • stale precondition evidence;
  • incorrect/obsolete operator model;
  • concurrent interference;
  • partial effect;
  • observation error.

#385 must diagnose among these classes instead of assuming the action or method is defective.


Major semantic decision 5 — time/resources are live validity constraints

Depth 4A's partial ordering is necessary but insufficient.

A procedural network may include:

before / after
start_before / finish_before
min/max delay
deadline
duration interval
during invariant
mutual exclusion
required concurrency
renewable/nonrenewable resource capacity
resource calendar / lease
time-window validity

PDDL2.1's formal treatment of durative actions/concurrency and STN work both reinforce that these constraints require validation, not informal annotations.

Important split:

method temporal/resource contract
        !=
plan-instance schedule
        !=
runtime resource lease/availability

A valid method can produce an invalid current plan because the clock moved, another plan consumed a resource, or an exogenous event invalidated an invariant.

Planning latency counts: if the deadline passes while decomposing/diagnosing, admission must fail/replan rather than execute a stale plan.


Major semantic decision 6 — concurrency is semantic only when dependencies permit it

Do not infer safety from “no explicit ordering edge.”

Two tasks may overlap only when all relevant constraints allow it:

causal support / threats
resource compatibility
temporal invariants
effect interference
authority/lease conflicts
shared preimage requirements
explicit mutex/required-concurrency constraints

#288 may schedule independent ready nodes concurrently, but the procedural compiler must emit the constraints that make independence meaningful.

A runtime ordering chosen by thread scheduling must never change the declared procedural semantics.


Major semantic decision 7 — exogenous change triggers threat-directed repair

GOLOG/ConGolog/IndiGolog and execution-monitoring work are strong precedent for treating exogenous actions/events as first-class changes during a running procedure.

Do not automatically restart the whole method.

Classify the change against the current execution frontier:

irrelevant
beneficial
threatens_future_guard
threatens_causal_link
violates_monitor_invariant
consumes_required_resource
invalidates_identity/target
changes_authority/capability
changes_goal/Frozen-Spec evidence (cannot mutate spec itself)

Then repair the smallest layer whose invariant is actually broken.


Major semantic decision 8 — four distinct repair layers

Depth 4A says “replan,” but that is too coarse. Preserve:

1. execution continuation/dispatch repair
   reorder still-valid independent pending tasks; reacquire lease; refresh observation

2. plan-instance repair
   change this run's bindings/order/optional branch while retaining method identity

3. method re-selection
   current admitted method no longer applicable/viable; choose another admitted method

4. method knowledge repair/supersession candidate
   evidence suggests the reusable method itself is wrong/incomplete
   -> record candidate defect/counterexample
   -> NEVER mutate/promote trusted method automatically; #404 promotion/governance owns that

A failed run does not imply method invalidity. Conversely, repeatedly “repairing the plan” must not hide evidence that the method model is systematically wrong.

Every layer gets distinct provenance and no-progress fingerprints.


Major semantic decision 9 — diagnosis chooses tests by discriminative utility subject to risk/authority

#385 already makes discriminators first-class. B strengthens selection semantics.

For each candidate discriminator preserve:

which live diagnoses it separates
expected possible observations
cost/work/time
risk / destructiveness
authority/capability requirement
resource requirement
reversibility
freshness requirement
expected information class

No universal scalar utility is required. A profile can use a lexicographic/partial policy such as:

mandatory safety
  > authority admissibility
  > avoid irreversible mutation
  > diagnostic discrimination
  > cost/time

The system may return a Pareto set / non-dominated discriminator set rather than inventing a fake universal score.

A destructive repair should not be used merely as a “test” when a lower-risk admissible observation can distinguish the same hypotheses.


Major semantic decision 10 — blackboard proposals are epistemically typed

The logical coordination board must not become a bag of equally trusted assertions.

Every proposal carries:

kind
content ref
proposer/expert/version
semantic/epistemic theory
support/counterevidence
assumptions
validity/freshness
authority relevance
status: proposed/admitted/rejected/superseded

Conflicting method/repair/expert proposals remain ordinary #400 epistemic plurality until an explicit decision policy selects among applicable candidates.

Decision selection is not truth:

selected(method_A)
    !=
true(method_A_is_best_in_all_contexts)

Major semantic decision 11 — method preferences are typed and defeasible

Do not use one magic numeric method priority.

Candidate preference dimensions:

specificity of applicability
explicit operator/user policy
safety class
expected guarantee class
resource/temporal feasibility
verified historical competence
reversibility
cost/work
recency/validity of method version
case-derived contextual fit

Preferences are partial/scoped and may conflict. If two methods remain incomparable and the choice matters materially, return ambiguity or use an explicitly configured tie policy; do not let source file/clause order silently decide.

A more specific method is not automatically safer or authorized.


Major semantic decision 12 — CBR transfer requires a semantic adaptation contract

Similarity retrieves candidates; it does not prove transferability.

Before adapting a prior case, compare at least:

goal/spec compatibility
relevant precondition entailment
negative differences / contraindications
host/tool/capability compatibility
authority principal/context
resource/temporal regime
software/data/schema versions
observability assumptions
failure/outcome model
source/case independence
verification strength of prior outcome

Classify adaptation:

exact_reuse
safe_parameter_substitution
validated_structural_adaptation
requires_new_reasoning
contraindicated
insufficient_evidence

The dangerous case is high superficial similarity with one hidden causal/safety mismatch. Therefore the CBR layer should retain difference features and adaptation rationale, not only nearest-neighbor distance.

A stale case remains history; it may stop being an admissible precedent under current method/profile versions.


Preferred B architecture — Monitored Epistemic Procedural Policy (MEPP)

Depth 4A's PIF survives, but its executable procedural unit is refined from a mostly static method/network into a Monitored Epistemic Procedural Policy when uncertainty requires it.

Frozen obligation
      ↓
select admitted method/policy
      ↓
EPISTEMIC ADMISSION
  hard guards / unknowns / conflicts
  evidence & observation obligations
      ↓
TEMPORAL/RESOURCE ADMISSION
  current clock / deadlines / invariants / leases
      ↓
policy projection to bounded task-network frontier
      ↓
#288 canonical graph runtime
      ↓
primitive/expert execution under ordinary authority/effects
      ↓
fresh observation + exogenous events
      ↓
MONITOR
  expected vs observed outcome
  affected guards / causal links / invariants
      ↓
continue
or declared contingent branch
or discriminator
or plan-instance repair
or method re-selection
or method-defect candidate
      ↓
#384 VERIFY remains sole success boundary

The key architectural property is selective contingency. Deterministic fully observed methods remain cheap HTN-like networks. Only procedures whose declared profiles require sensing/nondeterminism/time/resource monitoring carry those extra semantics.


Proposed typed API/data refinements

Conceptual only; exact #392 schema remains fixture-driven.

procedure_condition(ConditionId, Method,
                    Kind, PropositionRef,
                    EpistemicRequirement,
                    OnUnknown,
                    Validity,
                    Provenance).

procedure_observation(ObsId, Method,
                      Trigger, EvidenceClass,
                      BranchMap,
                      CostRiskRef,
                      Provenance).

procedure_outcome(ActionRef, OutcomeId,
                  Conditions, Effects,
                  GuaranteeMetadata,
                  Provenance).

procedure_temporal_contract(Method,
                            Constraints,
                            Invariants,
                            Deadlines,
                            Provenance).

procedure_resource_contract(Method,
                            ResourceRequirements,
                            MutexOrConcurrency,
                            Provenance).

procedure_guarantee(Method,
                    GuaranteeClass,
                    FairnessAssumptions,
                    EnvironmentAssumptions,
                    Provenance).

procedure_execution_frontier(Run,
                             MethodVersion,
                             EvidenceGeneration,
                             OpenTasks,
                             OpenObservations,
                             ActiveConstraints,
                             ObservedOutcomes,
                             ExogenousEvents,
                             Status).

procedure_repair_decision(Decision,
                          Layer,   % continuation | plan | method-selection | method-defect-candidate
                          ThreatRefs,
                          ProposedChange,
                          PreservedInvariants,
                          Provenance).

Repository ownership boundaries

prolog-rlm / #392 / #394

Own inert semantic representation of procedural guards, outcomes, branches, guarantee/fairness assumptions, temporal/resource constraints, execution-frontier receipts, and typed decision provenance. Unknown semantic action names remain inert.

#379 Planner / Coordinator

Own query-local method/policy selection, epistemic/temporal/resource admission, bounded policy projection/decomposition, threat-directed plan-instance repair, and compilation into #288. No second scheduler.

#288 graph runtime

Own actual readiness/order/cancellation/concurrency/bounds for admitted graph nodes. It does not decide semantic method truth or silently infer resource/authority compatibility.

#377 / #355 / capability-effect layer

Own expert selection / deterministic plan-native execution and effect authority. Procedural knowledge can never widen these permissions.

#384 VERIFY

Own final success. Procedure branches/expected effects cannot certify themselves.

#385 Repair / Diagnosis

Own diagnostic conflicts/hypotheses, discriminator selection under risk/cost/authority policy, and classification of unexpected outcomes. It proposes repair-layer decisions; effects still route normally.

symbolic-memory

Persist immutable method/policy versions, cases, verified run receipts, unexpected outcomes, exogenous events, method-defect/counterexample candidates, and adaptation rationale. Runtime frontiers/schedules are normally rebuildable/run-local unless retained as an execution receipt. No automatic case → trusted method mutation.

#404

Own later promotion/supersession policy for learned procedure/method knowledge.


Complexity / scaling implications

  1. Full partial-observability policy generation is potentially exponential in belief state; therefore MEPP uses bounded observation obligations and selective contingent regions, not global belief-policy compilation by default.
  2. FOND/strong/strong-cyclic policy search remains combinatorial. Guarantee class and search bounds are explicit; a timeout is not a weak/strong failure proof.
  3. Temporal/resource feasibility adds STN/constraint propagation and, with richer resource scheduling, NP-hard subproblems. Keep tractable temporal fragments/profile declarations explicit and return resource-limited/unsupported when outside them.
  4. Method alternatives × observation branches × diagnostic hypotheses can multiply. Factor these structures and share common network prefixes rather than materializing full trees.
  5. Execution monitoring should invalidate/re-evaluate affected guards/causal links/resource constraints rather than re-run every expert/method after each observation.
  6. CBR candidate retrieval may be indexed/vector-assisted, but semantic compatibility/adaptation checks remain symbolic and bounded; ANN similarity never admits execution by itself.

Epistemic / provenance implications

Preserve separate provenance for:

method source/version
method-selection decision
precondition warrant
assumptions/closure profile
observation/sensing result
predicted outcome model
actual observed outcome
exogenous event
resource/temporal admission
repair-layer decision
diagnostic hypothesis/discriminator
CBR source case + adaptation rationale
VERIFY result

A later method repair must be able to ask why the method looked applicable, what assumptions were active, what actually happened, and whether the failure came from the method or the environment.


Safety / authority implications

Hard invariants:

unknown safety guard            != satisfied
case similarity                 != authority
method selected                 != capability granted
contingent branch represented   != branch authorized
strong-cyclic retry             != permission to retry forever
predicted resource availability != acquired lease
method-specific priority        != security priority
exogenous event                 != excuse to weaken Frozen Spec
successful repair               != permission to rewrite trusted method

Authority/capability loss during a run produces blocked/replan semantics. It is not an implementation fault unless separate evidence says so.

Methods learned from manuals, logs, cases, or models remain inert procedural knowledge until their primitive actions map to trusted capabilities through the existing boundary.


Adversarial failures this design is meant to catch

  1. not provable(can_delete) is treated as can_delete=false, causing wrong branch semantics.
  2. not provable(safe_to_delete) is treated as safe because a negated precondition succeeds under raw Prolog NAF.
  3. A retry loop is labeled guaranteed even though its “eventually succeeds” fairness assumption is false.
  4. A method's deadline expires while the planner is still decomposing it.
  5. Two individually safe actions overlap and violate a shared resource invariant.
  6. A plan is repaired by reordering tasks, but the new ordering breaks a causal link.
  7. A nondeterministic but expected outcome is misdiagnosed as tool failure.
  8. An exogenous event makes predicted state stale, but repair keeps retrying the same effect.
  9. A capability denial is treated as a system fault and triggers increasingly aggressive repair.
  10. A destructive mutation is selected as a diagnostic test despite a cheap read-only discriminator.
  11. A case from a previous software/schema version is nearest-neighbor similar but causally incompatible.
  12. A high-success case cluster is actually duplicated/correlated evidence from one original run.
  13. Method specificity silently overrides a safer general method.
  14. A board proposal from an untrusted/model-derived expert is treated as observed fact.
  15. A failed plan instance causes destructive in-place mutation of the canonical method.
  16. An observed repair success is mistaken for proof that the original diagnosis was correct.
  17. A temporal/resource solver times out and the planner treats the plan as feasible.
  18. Concurrent runtime scheduling changes the semantic outcome of an allegedly partial-order-safe method.
  19. A contingent branch contains an effect for which the current principal lacks authority.
  20. A method's predicted postcondition is used to satisfy VERIFY without fresh observation.

Falsifiable / conformance fixtures for Depth 4B

B1 — OWA guard: unknown configured(service) yields evidence obligation/unknown, not false or true.

B2 — explicit closure: declared closed predicate permits NAF only inside the admitted profile/scope.

B3 — conflicted guard: simultaneous support/refutation blocks a safety-sensitive effect and preserves both evidence paths.

B4 — sensing branch: observation at a declared gate chooses branch A/B with zero model calls.

B5 — bounded branching: branch budget exhaustion returns resource_limited, not arbitrary first branch.

B6 — strong policy: all admitted nondeterministic outcomes reach the goal under a strong fixture.

B7 — weak policy rejection: a weak-only policy is rejected for a profile requiring guaranteed completion.

B8 — fairness receipt: strong-cyclic policy exposes the exact fairness assumption and fails/adapts when it is not admitted.

B9 — no blind infinite retry: unchanged outcome/evidence hits progress/bound termination.

B10 — deadline drift: plan valid at decomposition start but deadline expired before admission => stale/invalid, no effect.

B11 — durative invariant: exogenous event violates a during invariant and triggers monitoring/repair before next dependent action.

B12 — resource mutex: two otherwise-ready nodes requiring exclusive resource are never scheduled concurrently.

B13 — required concurrency: method requiring overlap preserves the requirement through #288 compilation or returns unsupported.

B14 — threat-directed exogenous repair: unrelated exogenous event does not cause global replan; causal-threat event invalidates only dependent frontier.

B15 — nondeterministic expected effect: alternative declared outcome does not become tool_failure automatically.

B16 — plan vs method repair: run-specific binding repair leaves canonical method/version unchanged.

B17 — method defect candidate: repeated verified counterexamples create an inert supersession/repair candidate, never in-place trusted method mutation.

B18 — multi-fault diagnosis: joint diagnosis remains possible; discriminator targets hypotheses rather than forcing one fault.

B19 — risk-aware discriminator: read-only test outranks destructive test when both distinguish the same diagnoses under policy.

B20 — authority-sensitive discriminator: diagnostically useful but unauthorized test returns blocked and is not executed.

B21 — blackboard disagreement: conflicting method proposals remain epistemically distinct; selection receipt does not rewrite the loser as false.

B22 — CBR contraindication: nearest case is rejected because a relevant negative difference violates a hard guard.

B23 — case authority isolation: case recorded under privileged principal cannot transfer that authority to current run.

B24 — stale case/version: old verified case remains history but fails current compatibility profile.

B25 — predicted-vs-observed: method predicted goal effect cannot satisfy #384 without fresh admissible evidence.

B26 — concurrency determinism: legal scheduler interleavings produce equivalent declared semantic outcomes or the method is marked interference-sensitive/unsupported.

B27 — solver incompleteness: temporal/resource timeout is resource_limited, not plan_valid=false or true.

B28 — zero-model known policy: all above deterministic compiled fixtures execute with model_calls = 0.


Rejected alternatives

“Unknown preconditions just fail”

Rejected: violates the established open-world/explicit-negation semantics and can create both false negatives and catastrophic false positives around negated guards.

“Always replan from scratch after observations”

Rejected: destroys procedural continuity, ignores known contingency structure, and scales poorly. Threat-directed continuation/repair is preferable.

“Convert everything to a POMDP”

Rejected as universal substrate: demands probabilities/rewards not present in ordinary symbolic sources and would erase useful qualitative guarantees. Probabilistic profiles may exist later as optional extensions.

“Strong-cyclic means safe retry forever”

Rejected: fairness assumptions are semantic and may be invalid. Retry also remains bounded by runtime/authority policy.

“Method failure means update the method”

Rejected: run-specific state, exogenous events, capability denial, bad binding, or primitive failure can all explain failure. Method repair requires accumulated counterevidence and later promotion/governance.

“Use one utility score for method/test choice”

Rejected as mandatory semantics: safety, authority, risk, discrimination, time and cost are not naturally commensurate. Profiles may define explicit scalarization, but partial/lexicographic policies are first-class.


Concrete canonical changes recommended

  1. #379 Planner/Coordinator: add epistemic guard statuses, observation gates, nondeterministic guarantee/fairness classes, live temporal/resource admission, execution-frontier monitoring, threat-directed plan repair and explicit plan-vs-method repair distinction.
  2. #385 Repair/Diagnosis: distinguish expected nondeterministic outcomes/exogenous change/model defects; add discriminator risk/authority/resource semantics and four repair layers.
  3. #384 VERIFY: make monitoring/checkpoint observations reusable during execution while preserving final independent Frozen-Spec acceptance; predicted outcome/model state never counts as observation.
  4. #392: extend procedural profile semantics to represent condition kind + epistemic requirement, observation branches, outcome alternatives, temporal/resource contracts, guarantee/fairness assumptions, and repair-layer receipts as inert symbolic data.
  5. symbolic-memory #6: persist method/policy versions, cases, observed outcomes/exogenous events, counterexamples/method-defect candidates and CBR adaptation rationale append-only; do not persist a mutable “current best procedure” as truth.
  6. #397/#401: mark B complete only, queue C; do not advance to #402.

Unresolved questions preserved for C/D

  • How exactly do PIF/MEPP policies interoperate with external BT/BPMN/PDDL/HTN/Golog-style procedural formalisms without semantic flattening? (#401C)
  • Cross-host capability/authority portability: can one method be mapped safely across different execution substrates? (#401C)
  • How should two domain method libraries compose when their temporal/resource/epistemic assumptions conflict? (#401C)
  • Which tractable temporal/resource fragments are mandatory in v1 (STN, STNU, CLP(FD), richer scheduling)? (#401D)
  • Incremental indexing/matching for guards, observation gates and method alternatives. (#401D)
  • Compact/factorized contingent policy representation under large branch spaces. (#401D)
  • Deterministic concurrency/replay receipts for partial-order monitored execution. (#401D)
  • Exact performance budgets and conformance corpus across diagnosis × policy × resource interactions. (#401D)
  • Method/case learning and safe promotion remain #404, not Depth 4.

B decision

PIF survives, but static method decomposition is not sufficient. Adopt MEPP — Monitored Epistemic Procedural Policies — as the semantic deepening: known deterministic methods remain cheap HTN-like task networks; procedures that need sensing/nondeterminism/time/resources explicitly carry epistemic guards, observation branches, outcome/guarantee assumptions, live invariants and bounded monitoring/repair semantics. All admitted work still compiles to #288; #384 remains the only success boundary; no procedural representation gains authority.

Depth-4B is design-complete, implementation-unproven. Next subpass must be #401C, not #402.

## Machine Spirit Depth 4B — adversarial procedural semantics under uncertainty, time, concurrency, repair, and authority This is **subpass B only**. It attacks the Depth-4A Procedural Intelligence Fabric (PIF) under conditions where static HTN decomposition is not enough: unknown facts, sensing, nondeterministic outcomes, partial observability, temporal/resource constraints, exogenous change, conflicting methods, risky diagnosis, and misleading precedents. It does **not** close #401 or advance to #402. C/D remain required. ### Research questions 1. What does a method precondition mean when its truth is unknown, conflicted, time-sensitive, or only attributed rather than world-warranted? 2. When must a procedure be a **policy over observations/belief state** rather than a static task network? 3. What guarantees do we require for nondeterministic procedures: weak, strong, strong-cyclic, or something explicitly fairness-qualified? 4. How should duration, deadlines, concurrent actions, invariants, shared resources, and exogenous events constrain method admission and execution? 5. When a run diverges from predicted state, what is repaired: the current plan instance, the selected method binding, the reusable method itself, or only the world state? 6. How should multiple diagnostic hypotheses select discriminators when tests themselves have cost, risk, authority requirements, and possible side effects? 7. How can CBR precedents and blackboard proposals remain useful without smuggling stale context, unsafe authority, or epistemically disputed claims into execution? --- ## Primary / authoritative sources inspected ### Nondeterministic / contingent planning - Alessandro Cimatti, Marco Pistore, Marco Roveri, Paolo Traverso, **“Weak, Strong, and Strong Cyclic Planning via Symbolic Model Checking,”** *Artificial Intelligence* 147(1–2), 2003, DOI `10.1016/S0004-3702(02)00374-0`. Institutional record: https://iris.unitn.it/handle/11572/74586 . The key distinction is semantic, not merely algorithmic: weak plans may have a successful execution; strong plans guarantee goal achievement; strong-cyclic policies may rely on iterative retry under fairness assumptions. - Piergiorgio Bertoli, Alessandro Cimatti, Marco Roveri, Paolo Traverso, **“Planning in Nondeterministic Domains under Partial Observability via Symbolic Model Checking,”** IJCAI 2001: https://iris.unitn.it/handle/11572/258842 . Conditional plans are policies over a partially observed belief state; sensing/observations determine branches, and the state space can blow up exponentially. - Blai Bonet, **“Conformant Plans and Beyond: Principles and Complexity,”** *Artificial Intelligence* 174(3–4), 2010, DOI `10.1016/j.artint.2009.11.001`: https://doi.org/10.1016/j.artint.2009.11.001 . Useful for the spectrum from linear/conformant plans to bounded-branching and fully contingent plans, and for the fact that partially observable planning reasons over belief state rather than ordinary world state. - Dillon Chen & Pascal Bercher, **“Fully Observable Nondeterministic HTN Planning — Formalisation and Complexity Results,”** ICAPS 2021: https://ojs.aaai.org/index.php/ICAPS/article/view/15949 and **“Flexible FOND HTN Planning: A Complexity Analysis,”** ICAPS 2022: https://ojs.aaai.org/index.php/ICAPS/article/view/19782 . HTN methods can be extended to nondeterministic domains, but uncertainty changes both solution criteria and complexity; hierarchy does not remove the need to define policy semantics. - Alberto Camacho & Sheila McIlraith, **“Strong-Cyclic Planning when Fairness is Not a Valid Assumption,”** KnowProS 2016: https://ceur-ws.org/Vol-1648/paper11.pdf . Strong-cyclic guarantees depend on fairness assumptions; those assumptions must be explicit rather than hidden in a retry loop. ### High-level procedures, sensing, exogenous change - Hector Levesque, Raymond Reiter, Yves Lespérance, Fangzhen Lin, Richard Scherl, **GOLOG** (*Journal of Logic Programming*, 1997), plus Giuseppe De Giacomo, Yves Lespérance, Hector Levesque, **ConGolog** (*Artificial Intelligence* 121, 2000). University of Toronto bibliography/resources: https://www.cs.toronto.edu/cogrobo/BibTex/bibcogroba_bib.html and https://www.cs.toronto.edu/~fritz/golog/ . ConGolog/IndiGolog separate high-level procedural programs from primitive execution while supporting concurrency, sensing, interrupts and exogenous actions. - Giuseppe De Giacomo, Ray Reiter, Mikhail Soutchanski, **“Execution Monitoring of High-Level Robot Programs,”** KR 1998: https://www.cs.ryerson.ca/~mes/publications/kr98correct.pdf . Execution monitoring explicitly compares physical observations to predicted state and performs recovery from exogenous events before resuming a program. This directly supports keeping *procedure semantics*, *predicted effects*, *observed state*, and *recovery* distinct. - Robert Goldman, **“A Semantics for HTN Methods,”** ICAPS 2009: https://ojs.aaai.org/index.php/ICAPS/article/view/13377 . HTN methods need an execution semantics; the paper relates SHOP2 methods to ConGolog/situation calculus precisely because decomposition syntax alone is insufficient for a reliable executive. ### Time, concurrency, resources, deadlines - Maria Fox & Derek Long, **“PDDL2.1: An Extension to PDDL for Expressing Temporal Planning Domains,”** JAIR 20, 2003, DOI `10.1613/jair.1129`: https://www.cs.cmu.edu/afs/cs/project/jair/pub/volume20/fox03a-html/JAIRpddl.html . Formal semantics for durative actions, numeric resources, invariants, concurrency and plan validation. This is strong evidence that temporal/resource conditions belong to plan validity, not ad-hoc runtime metadata. - Michael Cashmore et al., **“Temporal Planning while the Clock Ticks,”** ICAPS 2018: https://ojs.aaai.org/index.php/ICAPS/article/view/13878 . Planning latency itself can invalidate deadline-sensitive plans; deadlines must be checked against *current* time at admission/execution, not only at method-authoring time. - Alessandro Umbrico et al., **“Integrating Resource Management and Timeline-Based Planning,”** ICAPS 2018: https://ojs.aaai.org/index.php/ICAPS/article/view/13905 . Explicit temporal/resource reasoning is needed for real plan feasibility. - James Boerkoel et al., **“Distributed Algorithms for Incrementally Maintaining Multiagent Simple Temporal Networks,”** ICAPS 2013: https://ojs.aaai.org/index.php/ICAPS/article/view/13551 . New constraints/exogenous events require incremental re-propagation of temporal consistency rather than assuming an originally valid schedule remains valid. ### Execution repair / partial order - Oscar Lima et al., **“Robust Plan Execution with Unexpected Observations,”** 2020: https://strathprints.strath.ac.uk/71950/ . Unexpected state can make a fixed total ordering unnecessarily brittle; adaptable partial-order execution can preserve plan validity while exploiting benign world differences. - Robert Young, Martha Pollack, Johanna Moore, **“Decomposition and Causality in Partial-Order Planning,”** AIPS 1994: https://publications.ri.cmu.edu/decomposition-and-causality-in-partial-order-planning . Partial decompositions and causal links support filling procedural gaps in context; causal structure is needed to know what an execution deviation actually threatens. ### Diagnostic test selection / case maintenance - Paul Glasziou & Jørgen Hilden, **“Test Selection Measures,”** *Medical Decision Making* 9(2), 1989, DOI `10.1177/0272989X8900900208`: https://journals.sagepub.com/doi/10.1177/0272989X8900900208 . Discriminator choice must account for risk and cost, not only information gain. - Barry Smyth & Elizabeth McKenna, **“Competence Models and the Maintenance Problem,”** *Computational Intelligence* 17(2), 2001/2002, DOI `10.1111/0824-7935.00142`: https://onlinelibrary.wiley.com/doi/abs/10.1111/0824-7935.00142 . A CBR system's competence depends not just on case retrieval but on the case base, similarity knowledge, adaptation knowledge and their maintenance as the environment changes. --- # What Depth 4A gets right — and where it breaks A's explicit separation of HTN methods, production applicability, logical blackboard proposals, CBR candidates, diagnosis, #288 scheduling, authority/effects and VERIFY survives. The break is this implicit A-shaped assumption: ```text method applicability can be decided from one current world state ↓ decompose once ↓ execute a mostly static partial-order plan ``` That is not valid under open-world knowledge, sensing, nondeterministic effects, deadlines, exogenous changes, or authority-dependent actions. The required refinement is: > **A procedure is reusable policy knowledge over epistemic/temporal/resource state; a plan instance is one admitted execution projection of that policy against a frozen evidence frontier.** --- # Candidate architecture A — static HTN + replan-on-any-surprise Keep A's method semantics unchanged. If a precondition is unknown or an effect differs from prediction, stop and run #385/#379 again. ### Strengths - simple; - preserves one #288 scheduler; - no belief-policy explosion in ordinary paths; - easy to explain. ### Failures - conflates `unknown` with `not applicable` unless carefully guarded; - sensing-heavy procedures degenerate into repeated planner calls; - retry/replan may implicitly assume fairness; - loses intentional contingent branches already known by the procedure author; - expensive/disruptive for benign exogenous changes; - cannot state strong guarantees over nondeterministic outcomes. **Verdict:** retain as a cheap profile for deterministic, fully observed procedures; reject as universal semantics. --- # Candidate architecture B — full belief-state contingent planner Every method is compiled into a policy over belief states and observations. The executor follows the policy until the goal is guaranteed. ### Strengths - principled semantics for partial observability; - naturally represents sensing and observation-conditioned branches; - can state weak/strong/strong-cyclic guarantee classes; - correctly treats unknown state as a set/distribution of possible worlds rather than false. ### Failures - belief-state branching can be exponential; - generating full policies for mundane known work is absurdly expensive; - probabilistic/POMDP semantics introduce numerical assumptions the canonical system does not universally possess; - full policy generation would duplicate responsibilities already split across #379/#288/#385. **Verdict:** the semantic model is useful; full global contingent planning is not the default runtime architecture. --- # Candidate architecture C — monitored procedural policy with bounded belief obligations **(preferred)** Extend PIF so a method can declare observation gates, outcome alternatives, temporal/resource invariants, and recovery/continuation policies without forcing the entire world into one global contingent planner. Conceptually: ```prolog sem_method_policy(Method, task(Task), admission(AdmissionProfile), initial_guards(GuardRefs), network(TaskNetwork), observation_points(ObservationRefs), outcome_model(OutcomeRefs), temporal_contract(TemporalRef), resource_contract(ResourceRef), guarantee(GuaranteeClass), fairness(FairnessRef), recovery(RecoveryRefs), provenance(Provenance)). ``` A running plan has an explicit **execution frontier**: ```text plan instance + method/version current admitted task-network frontier frozen/relevant evidence generation live epistemic support status for required guards open observation obligations active temporal/resource constraints observed primitive outcomes exogenous events since last frontier remaining guarantee assumptions/budget ``` At each relevant transition: ```text observe / receive event ↓ update current evidence ↓ re-evaluate only affected guards/invariants/causal links ↓ continue admitted network OR follow declared contingent branch OR request discriminator OR bounded plan-instance repair OR method re-selection OR blocked/unknown/resource-limited ``` This keeps ordinary deterministic procedures cheap while allowing explicit conditional policies where the domain needs them. --- # Major semantic decision 1 — preconditions are epistemic predicates, not Prolog failure A method/operator guard must be evaluated against #400 epistemic semantics and return at least: ```text satisfied refuted unknown conflicted blocked unsupported_query ``` Never interpret ordinary failure-to-prove as `refuted` unless the method explicitly references an admitted closed-world predicate/profile. Classify procedural conditions: ```text hard_guard must be warranted before admission/execution observation_gate unknown triggers a typed evidence/sensing obligation branch_guard result selects an explicit policy branch assumption allowed only under an explicit assumption/environment receipt monitor_invariant must remain warranted throughout a durative/execution interval success_condition predicted by planning but ultimately decided only by #384 VERIFY/current evidence ``` **Safety default:** unknown/conflicted security-, authority-, resource-, destructive-effect-, or irreversible-action preconditions cannot be guessed true. They become evidence/blocked decisions. --- # Major semantic decision 2 — method applicability != execution safety A method may be *conceptually applicable* while a particular binding/run is not executable now. Keep separate: ```text method_applicable(Method, Task, SemanticContext) method_admissible(Method, FrozenSpec, EpistemicProfile) plan_instance_valid(Network, CurrentEvidence, Time, Resources) action_authorized(Action, Principal, CapabilityContext) action_ready(Action, SchedulerFrontier) ``` This prevents authority/resource/time failures from being misdiagnosed as “method not applicable” and prevents a good generic method from being globally discredited because one host lacks a capability. --- # Major semantic decision 3 — nondeterministic procedures need explicit guarantee classes A policy/result should not just say `procedure works`. Represent a guarantee class such as: ```text deterministic weak strong strong_cyclic best_effort unsupported_guarantee ``` For `strong_cyclic`, preserve the fairness assumption/profile explicitly. Camacho/McIlraith show that classical strong-cyclic soundness depends on fairness assumptions that can fail in real domains. Therefore: ```text retry until success ``` is **not** an unconditional guarantee. A retry/recovery loop needs at least: ```text progress measure or changing evidence bounded attempts/work fairness/environment assumption if semantically required no-progress fingerprint exit state when assumption is violated/exhausted ``` A weak plan/policy is not eligible for unattended high-risk effects unless an explicit policy admits weak guarantees. --- # Major semantic decision 4 — predicted effects become outcome hypotheses A primitive operator's predicted effect is not one future fact. Under uncertainty it is an **outcome model**: ```prolog operator_outcome(Action, OutcomeClass, Conditions, PredictedEffects, ProbabilityOrNone, Provenance). ``` After execution: ```text predicted outcome != observed outcome ``` An unexpected observation may mean: - primitive action failure; - expected nondeterministic outcome; - exogenous world change; - stale precondition evidence; - incorrect/obsolete operator model; - concurrent interference; - partial effect; - observation error. #385 must diagnose among these classes instead of assuming the action or method is defective. --- # Major semantic decision 5 — time/resources are live validity constraints Depth 4A's partial ordering is necessary but insufficient. A procedural network may include: ```text before / after start_before / finish_before min/max delay deadline duration interval during invariant mutual exclusion required concurrency renewable/nonrenewable resource capacity resource calendar / lease time-window validity ``` PDDL2.1's formal treatment of durative actions/concurrency and STN work both reinforce that these constraints require validation, not informal annotations. Important split: ```text method temporal/resource contract != plan-instance schedule != runtime resource lease/availability ``` A valid method can produce an invalid current plan because the clock moved, another plan consumed a resource, or an exogenous event invalidated an invariant. Planning latency counts: if the deadline passes while decomposing/diagnosing, admission must fail/replan rather than execute a stale plan. --- # Major semantic decision 6 — concurrency is semantic only when dependencies permit it Do not infer safety from “no explicit ordering edge.” Two tasks may overlap only when all relevant constraints allow it: ```text causal support / threats resource compatibility temporal invariants effect interference authority/lease conflicts shared preimage requirements explicit mutex/required-concurrency constraints ``` #288 may schedule independent ready nodes concurrently, but the *procedural compiler* must emit the constraints that make independence meaningful. A runtime ordering chosen by thread scheduling must never change the declared procedural semantics. --- # Major semantic decision 7 — exogenous change triggers threat-directed repair GOLOG/ConGolog/IndiGolog and execution-monitoring work are strong precedent for treating exogenous actions/events as first-class changes during a running procedure. Do not automatically restart the whole method. Classify the change against the current execution frontier: ```text irrelevant beneficial threatens_future_guard threatens_causal_link violates_monitor_invariant consumes_required_resource invalidates_identity/target changes_authority/capability changes_goal/Frozen-Spec evidence (cannot mutate spec itself) ``` Then repair the smallest layer whose invariant is actually broken. --- # Major semantic decision 8 — four distinct repair layers Depth 4A says “replan,” but that is too coarse. Preserve: ```text 1. execution continuation/dispatch repair reorder still-valid independent pending tasks; reacquire lease; refresh observation 2. plan-instance repair change this run's bindings/order/optional branch while retaining method identity 3. method re-selection current admitted method no longer applicable/viable; choose another admitted method 4. method knowledge repair/supersession candidate evidence suggests the reusable method itself is wrong/incomplete -> record candidate defect/counterexample -> NEVER mutate/promote trusted method automatically; #404 promotion/governance owns that ``` A failed run does not imply method invalidity. Conversely, repeatedly “repairing the plan” must not hide evidence that the method model is systematically wrong. Every layer gets distinct provenance and no-progress fingerprints. --- # Major semantic decision 9 — diagnosis chooses tests by discriminative utility subject to risk/authority #385 already makes discriminators first-class. B strengthens selection semantics. For each candidate discriminator preserve: ```text which live diagnoses it separates expected possible observations cost/work/time risk / destructiveness authority/capability requirement resource requirement reversibility freshness requirement expected information class ``` No universal scalar utility is required. A profile can use a lexicographic/partial policy such as: ```text mandatory safety > authority admissibility > avoid irreversible mutation > diagnostic discrimination > cost/time ``` The system may return a Pareto set / non-dominated discriminator set rather than inventing a fake universal score. A destructive repair should not be used merely as a “test” when a lower-risk admissible observation can distinguish the same hypotheses. --- # Major semantic decision 10 — blackboard proposals are epistemically typed The logical coordination board must not become a bag of equally trusted assertions. Every proposal carries: ```text kind content ref proposer/expert/version semantic/epistemic theory support/counterevidence assumptions validity/freshness authority relevance status: proposed/admitted/rejected/superseded ``` Conflicting method/repair/expert proposals remain ordinary #400 epistemic plurality until an explicit **decision policy** selects among applicable candidates. Decision selection is not truth: ```text selected(method_A) != true(method_A_is_best_in_all_contexts) ``` --- # Major semantic decision 11 — method preferences are typed and defeasible Do not use one magic numeric method priority. Candidate preference dimensions: ```text specificity of applicability explicit operator/user policy safety class expected guarantee class resource/temporal feasibility verified historical competence reversibility cost/work recency/validity of method version case-derived contextual fit ``` Preferences are partial/scoped and may conflict. If two methods remain incomparable and the choice matters materially, return ambiguity or use an explicitly configured tie policy; do not let source file/clause order silently decide. A more specific method is not automatically safer or authorized. --- # Major semantic decision 12 — CBR transfer requires a semantic adaptation contract Similarity retrieves candidates; it does not prove transferability. Before adapting a prior case, compare at least: ```text goal/spec compatibility relevant precondition entailment negative differences / contraindications host/tool/capability compatibility authority principal/context resource/temporal regime software/data/schema versions observability assumptions failure/outcome model source/case independence verification strength of prior outcome ``` Classify adaptation: ```text exact_reuse safe_parameter_substitution validated_structural_adaptation requires_new_reasoning contraindicated insufficient_evidence ``` The dangerous case is high superficial similarity with one hidden causal/safety mismatch. Therefore the CBR layer should retain **difference features and adaptation rationale**, not only nearest-neighbor distance. A stale case remains history; it may stop being an admissible precedent under current method/profile versions. --- # Preferred B architecture — Monitored Epistemic Procedural Policy (MEPP) Depth 4A's PIF survives, but its executable procedural unit is refined from a mostly static method/network into a **Monitored Epistemic Procedural Policy** when uncertainty requires it. ```text Frozen obligation ↓ select admitted method/policy ↓ EPISTEMIC ADMISSION hard guards / unknowns / conflicts evidence & observation obligations ↓ TEMPORAL/RESOURCE ADMISSION current clock / deadlines / invariants / leases ↓ policy projection to bounded task-network frontier ↓ #288 canonical graph runtime ↓ primitive/expert execution under ordinary authority/effects ↓ fresh observation + exogenous events ↓ MONITOR expected vs observed outcome affected guards / causal links / invariants ↓ continue or declared contingent branch or discriminator or plan-instance repair or method re-selection or method-defect candidate ↓ #384 VERIFY remains sole success boundary ``` The key architectural property is **selective contingency**. Deterministic fully observed methods remain cheap HTN-like networks. Only procedures whose declared profiles require sensing/nondeterminism/time/resource monitoring carry those extra semantics. --- ## Proposed typed API/data refinements Conceptual only; exact #392 schema remains fixture-driven. ```prolog procedure_condition(ConditionId, Method, Kind, PropositionRef, EpistemicRequirement, OnUnknown, Validity, Provenance). procedure_observation(ObsId, Method, Trigger, EvidenceClass, BranchMap, CostRiskRef, Provenance). procedure_outcome(ActionRef, OutcomeId, Conditions, Effects, GuaranteeMetadata, Provenance). procedure_temporal_contract(Method, Constraints, Invariants, Deadlines, Provenance). procedure_resource_contract(Method, ResourceRequirements, MutexOrConcurrency, Provenance). procedure_guarantee(Method, GuaranteeClass, FairnessAssumptions, EnvironmentAssumptions, Provenance). procedure_execution_frontier(Run, MethodVersion, EvidenceGeneration, OpenTasks, OpenObservations, ActiveConstraints, ObservedOutcomes, ExogenousEvents, Status). procedure_repair_decision(Decision, Layer, % continuation | plan | method-selection | method-defect-candidate ThreatRefs, ProposedChange, PreservedInvariants, Provenance). ``` --- # Repository ownership boundaries ### `prolog-rlm` / #392 / #394 Own inert semantic representation of procedural guards, outcomes, branches, guarantee/fairness assumptions, temporal/resource constraints, execution-frontier receipts, and typed decision provenance. Unknown semantic action names remain inert. ### #379 Planner / Coordinator Own query-local method/policy selection, epistemic/temporal/resource admission, bounded policy projection/decomposition, threat-directed plan-instance repair, and compilation into #288. **No second scheduler.** ### #288 graph runtime Own actual readiness/order/cancellation/concurrency/bounds for admitted graph nodes. It does not decide semantic method truth or silently infer resource/authority compatibility. ### #377 / #355 / capability-effect layer Own expert selection / deterministic plan-native execution and effect authority. Procedural knowledge can never widen these permissions. ### #384 VERIFY Own final success. Procedure branches/expected effects cannot certify themselves. ### #385 Repair / Diagnosis Own diagnostic conflicts/hypotheses, discriminator selection under risk/cost/authority policy, and classification of unexpected outcomes. It proposes repair-layer decisions; effects still route normally. ### `symbolic-memory` Persist immutable method/policy versions, cases, verified run receipts, unexpected outcomes, exogenous events, method-defect/counterexample candidates, and adaptation rationale. Runtime frontiers/schedules are normally rebuildable/run-local unless retained as an execution receipt. **No automatic case → trusted method mutation.** ### #404 Own later promotion/supersession policy for learned procedure/method knowledge. --- # Complexity / scaling implications 1. Full partial-observability policy generation is potentially exponential in belief state; therefore MEPP uses **bounded observation obligations and selective contingent regions**, not global belief-policy compilation by default. 2. FOND/strong/strong-cyclic policy search remains combinatorial. Guarantee class and search bounds are explicit; a timeout is not a weak/strong failure proof. 3. Temporal/resource feasibility adds STN/constraint propagation and, with richer resource scheduling, NP-hard subproblems. Keep tractable temporal fragments/profile declarations explicit and return resource-limited/unsupported when outside them. 4. Method alternatives × observation branches × diagnostic hypotheses can multiply. Factor these structures and share common network prefixes rather than materializing full trees. 5. Execution monitoring should invalidate/re-evaluate **affected** guards/causal links/resource constraints rather than re-run every expert/method after each observation. 6. CBR candidate retrieval may be indexed/vector-assisted, but semantic compatibility/adaptation checks remain symbolic and bounded; ANN similarity never admits execution by itself. --- # Epistemic / provenance implications Preserve separate provenance for: ```text method source/version method-selection decision precondition warrant assumptions/closure profile observation/sensing result predicted outcome model actual observed outcome exogenous event resource/temporal admission repair-layer decision diagnostic hypothesis/discriminator CBR source case + adaptation rationale VERIFY result ``` A later method repair must be able to ask **why** the method looked applicable, what assumptions were active, what actually happened, and whether the failure came from the method or the environment. --- # Safety / authority implications Hard invariants: ```text unknown safety guard != satisfied case similarity != authority method selected != capability granted contingent branch represented != branch authorized strong-cyclic retry != permission to retry forever predicted resource availability != acquired lease method-specific priority != security priority exogenous event != excuse to weaken Frozen Spec successful repair != permission to rewrite trusted method ``` Authority/capability loss during a run produces blocked/replan semantics. It is not an implementation fault unless separate evidence says so. Methods learned from manuals, logs, cases, or models remain inert procedural knowledge until their primitive actions map to trusted capabilities through the existing boundary. --- # Adversarial failures this design is meant to catch 1. `not provable(can_delete)` is treated as `can_delete=false`, causing wrong branch semantics. 2. `not provable(safe_to_delete)` is treated as safe because a negated precondition succeeds under raw Prolog NAF. 3. A retry loop is labeled guaranteed even though its “eventually succeeds” fairness assumption is false. 4. A method's deadline expires while the planner is still decomposing it. 5. Two individually safe actions overlap and violate a shared resource invariant. 6. A plan is repaired by reordering tasks, but the new ordering breaks a causal link. 7. A nondeterministic but expected outcome is misdiagnosed as tool failure. 8. An exogenous event makes predicted state stale, but repair keeps retrying the same effect. 9. A capability denial is treated as a system fault and triggers increasingly aggressive repair. 10. A destructive mutation is selected as a diagnostic test despite a cheap read-only discriminator. 11. A case from a previous software/schema version is nearest-neighbor similar but causally incompatible. 12. A high-success case cluster is actually duplicated/correlated evidence from one original run. 13. Method specificity silently overrides a safer general method. 14. A board proposal from an untrusted/model-derived expert is treated as observed fact. 15. A failed plan instance causes destructive in-place mutation of the canonical method. 16. An observed repair success is mistaken for proof that the original diagnosis was correct. 17. A temporal/resource solver times out and the planner treats the plan as feasible. 18. Concurrent runtime scheduling changes the semantic outcome of an allegedly partial-order-safe method. 19. A contingent branch contains an effect for which the current principal lacks authority. 20. A method's predicted postcondition is used to satisfy VERIFY without fresh observation. --- # Falsifiable / conformance fixtures for Depth 4B **B1 — OWA guard:** unknown `configured(service)` yields evidence obligation/unknown, not false or true. **B2 — explicit closure:** declared closed predicate permits NAF only inside the admitted profile/scope. **B3 — conflicted guard:** simultaneous support/refutation blocks a safety-sensitive effect and preserves both evidence paths. **B4 — sensing branch:** observation at a declared gate chooses branch A/B with zero model calls. **B5 — bounded branching:** branch budget exhaustion returns `resource_limited`, not arbitrary first branch. **B6 — strong policy:** all admitted nondeterministic outcomes reach the goal under a `strong` fixture. **B7 — weak policy rejection:** a weak-only policy is rejected for a profile requiring guaranteed completion. **B8 — fairness receipt:** strong-cyclic policy exposes the exact fairness assumption and fails/adapts when it is not admitted. **B9 — no blind infinite retry:** unchanged outcome/evidence hits progress/bound termination. **B10 — deadline drift:** plan valid at decomposition start but deadline expired before admission => stale/invalid, no effect. **B11 — durative invariant:** exogenous event violates a `during` invariant and triggers monitoring/repair before next dependent action. **B12 — resource mutex:** two otherwise-ready nodes requiring exclusive resource are never scheduled concurrently. **B13 — required concurrency:** method requiring overlap preserves the requirement through #288 compilation or returns unsupported. **B14 — threat-directed exogenous repair:** unrelated exogenous event does not cause global replan; causal-threat event invalidates only dependent frontier. **B15 — nondeterministic expected effect:** alternative declared outcome does not become `tool_failure` automatically. **B16 — plan vs method repair:** run-specific binding repair leaves canonical method/version unchanged. **B17 — method defect candidate:** repeated verified counterexamples create an inert supersession/repair candidate, never in-place trusted method mutation. **B18 — multi-fault diagnosis:** joint diagnosis remains possible; discriminator targets hypotheses rather than forcing one fault. **B19 — risk-aware discriminator:** read-only test outranks destructive test when both distinguish the same diagnoses under policy. **B20 — authority-sensitive discriminator:** diagnostically useful but unauthorized test returns blocked and is not executed. **B21 — blackboard disagreement:** conflicting method proposals remain epistemically distinct; selection receipt does not rewrite the loser as false. **B22 — CBR contraindication:** nearest case is rejected because a relevant negative difference violates a hard guard. **B23 — case authority isolation:** case recorded under privileged principal cannot transfer that authority to current run. **B24 — stale case/version:** old verified case remains history but fails current compatibility profile. **B25 — predicted-vs-observed:** method predicted goal effect cannot satisfy #384 without fresh admissible evidence. **B26 — concurrency determinism:** legal scheduler interleavings produce equivalent declared semantic outcomes or the method is marked interference-sensitive/unsupported. **B27 — solver incompleteness:** temporal/resource timeout is `resource_limited`, not `plan_valid=false` or `true`. **B28 — zero-model known policy:** all above deterministic compiled fixtures execute with `model_calls = 0`. --- # Rejected alternatives ### “Unknown preconditions just fail” Rejected: violates the established open-world/explicit-negation semantics and can create both false negatives and catastrophic false positives around negated guards. ### “Always replan from scratch after observations” Rejected: destroys procedural continuity, ignores known contingency structure, and scales poorly. Threat-directed continuation/repair is preferable. ### “Convert everything to a POMDP” Rejected as universal substrate: demands probabilities/rewards not present in ordinary symbolic sources and would erase useful qualitative guarantees. Probabilistic profiles may exist later as optional extensions. ### “Strong-cyclic means safe retry forever” Rejected: fairness assumptions are semantic and may be invalid. Retry also remains bounded by runtime/authority policy. ### “Method failure means update the method” Rejected: run-specific state, exogenous events, capability denial, bad binding, or primitive failure can all explain failure. Method repair requires accumulated counterevidence and later promotion/governance. ### “Use one utility score for method/test choice” Rejected as mandatory semantics: safety, authority, risk, discrimination, time and cost are not naturally commensurate. Profiles may define explicit scalarization, but partial/lexicographic policies are first-class. --- # Concrete canonical changes recommended 1. **#379 Planner/Coordinator:** add epistemic guard statuses, observation gates, nondeterministic guarantee/fairness classes, live temporal/resource admission, execution-frontier monitoring, threat-directed plan repair and explicit plan-vs-method repair distinction. 2. **#385 Repair/Diagnosis:** distinguish expected nondeterministic outcomes/exogenous change/model defects; add discriminator risk/authority/resource semantics and four repair layers. 3. **#384 VERIFY:** make monitoring/checkpoint observations reusable during execution while preserving final independent Frozen-Spec acceptance; predicted outcome/model state never counts as observation. 4. **#392:** extend procedural profile semantics to represent condition kind + epistemic requirement, observation branches, outcome alternatives, temporal/resource contracts, guarantee/fairness assumptions, and repair-layer receipts as inert symbolic data. 5. **symbolic-memory #6:** persist method/policy versions, cases, observed outcomes/exogenous events, counterexamples/method-defect candidates and CBR adaptation rationale append-only; do not persist a mutable “current best procedure” as truth. 6. **#397/#401:** mark B complete only, queue C; do not advance to #402. --- # Unresolved questions preserved for C/D - How exactly do PIF/MEPP policies interoperate with external BT/BPMN/PDDL/HTN/Golog-style procedural formalisms without semantic flattening? (#401C) - Cross-host capability/authority portability: can one method be mapped safely across different execution substrates? (#401C) - How should two domain method libraries compose when their temporal/resource/epistemic assumptions conflict? (#401C) - Which tractable temporal/resource fragments are mandatory in v1 (STN, STNU, CLP(FD), richer scheduling)? (#401D) - Incremental indexing/matching for guards, observation gates and method alternatives. (#401D) - Compact/factorized contingent policy representation under large branch spaces. (#401D) - Deterministic concurrency/replay receipts for partial-order monitored execution. (#401D) - Exact performance budgets and conformance corpus across diagnosis × policy × resource interactions. (#401D) - Method/case learning and safe promotion remain #404, not Depth 4. ## B decision **PIF survives, but static method decomposition is not sufficient. Adopt MEPP — Monitored Epistemic Procedural Policies — as the semantic deepening:** known deterministic methods remain cheap HTN-like task networks; procedures that need sensing/nondeterminism/time/resources explicitly carry epistemic guards, observation branches, outcome/guarantee assumptions, live invariants and bounded monitoring/repair semantics. All admitted work still compiles to #288; #384 remains the only success boundary; no procedural representation gains authority. **Depth-4B is design-complete, implementation-unproven. Next subpass must be #401C, not #402.**
Author
Owner

Machine Spirit Depth 4C — heterogeneous procedural federation without semantic flattening

This is subpass C only. It composes Depth-4A PIF and Depth-4B MEPP across heterogeneous procedural formalisms, hosts, experts, observability models, temporal/resource semantics, recovery semantics and authority regimes. It does not close #401 or advance to #402. Depth 4D remains mandatory.

Research questions / scope

  1. Can HTN/HDDL methods, production/control rules, Golog/ConGolog programs, Behavior Trees, BPMN/workflow fragments, temporal PDDL models and domain expert procedures cooperate without pretending they have one execution semantics?
  2. Which properties map exactly, which are refinements/abstractions, and which must remain preservation-only/noncomposable?
  3. How can a procedure imported from host A be reused on host B without transferring A's principal identity, action bindings, capabilities or authority?
  4. How should expert-owned tasks remain portable when concrete expert implementations differ by host/version?
  5. What must mapping receipts preserve about sensing, unknowns, nondeterminism, guarantees, fairness, concurrency, interrupts, cancellation, compensation, deadlines, resources and recovery?
  6. Where does composition stop and the existing #288 scheduler / #377 expert registry / capability-authority-effect boundary begin?

Primary / authoritative sources

  • Höller et al., HDDL: An Extension to PDDL for Expressing Hierarchical Planning Problems, AAAI 2020, published 2020-04-03, DOI 10.1609/aaai.v34i06.6542: https://ojs.aaai.org/index.php/AAAI/article/view/6542 . HDDL exists because planner-specific languages damaged interoperability; it deliberately standardizes a shared/basic HTN feature set, not every planner's semantics.
  • Fox & Long, PDDL2.1: An Extension to PDDL for Expressing Temporal Planning Domains, JAIR 20, 2003, DOI 10.1613/jair.1129: https://strathprints.strath.ac.uk/1846/ . Durative actions, numeric/resource constraints and concurrent plan-validity semantics are material meaning, not optional metadata.
  • Levesque, Reiter, Lespérance, Lin, Scherl, GOLOG: A Logic Programming Language for Dynamic Domains, Journal of Logic Programming 31, 1997: https://www.cs.toronto.edu/kr/papers/GOLOGlang.pdf . GOLOG maintains explicit dynamic-world semantics from action precondition/effect axioms.
  • De Giacomo, Lespérance, Levesque, ConGolog, a concurrent programming language based on the situation calculus, Artificial Intelligence 121(1–2), August 2000, DOI 10.1016/S0004-3702(00)00031-X: https://doi.org/10.1016/S0004-3702(00)00031-X . Concurrency, prioritized interrupts and exogenous actions cannot generally be flattened to a static HTN DAG.
  • Colledanchise & Ögren, Behavior Trees in Robotics and AI, CRC Press, 2018/2019: https://www.routledge.com/Behavior-Trees-in-Robotics-and-AI-An-Introduction/Colledanchise-Ogren/p/book/9780367571337 . BTs are reactive hierarchical controllers with explicit success/failure/running behavior.
  • BehaviorTree.CPP official docs, inspected 2026-09-05: https://www.behaviortree.dev/docs/nodes-library/FallbackNode/ . Fallback and ReactiveFallback differ after RUNNING; current implementations make clear that a generic branch edge does not preserve BT semantics.
  • Object Management Group, BPMN 2.0.2, formal version January 2014: https://www.omg.org/spec/BPMN/2.0.2 . Normative specification + machine-readable schemas; typed gateways/events/subprocesses are richer than an ordered step list.
  • van der Aalst et al., Workflow Patterns, Distributed and Parallel Databases 14(1), July 2003, DOI 10.1023/A:1022883727209: https://doi.org/10.1023/A:1022883727209 . Different workflow languages support materially different control-flow capabilities.
  • van der Aalst et al., Soundness of workflow nets: classification, decidability, and analysis, Formal Aspects of Computing 23, 2011, published online 2010-08-03, DOI 10.1007/s00165-010-0161-4: https://link.springer.com/article/10.1007/s00165-010-0161-4 . Eight soundness notions are decidable for ordinary workflow nets, while most examined expressive extensions make them undecidable.
  • de Alfaro & Henzinger, Interface Automata, ESEC/FSE 2001, DOI 10.1145/503209.503226: https://doi.org/10.1145/503209.503226 . Compatibility/refinement should compare behavioral interfaces and assumptions/guarantees rather than implementation internals.
  • Benveniste, Caillaud, Passerone, A Generic Model of Contracts for Embedded Systems, INRIA RR-6214 / arXiv:0706.1456, June 2007: https://arxiv.org/abs/0706.1456 . Rich components can expose multiple behavioral/non-functional contracts; composition is contract-relative.

Prior-subpass/current-repo comparison

#401A established:

procedure/method knowledge != plan instance
method selection != expert selection
expert applicability != authority
predicted effect != observation
case precedent != trusted rule

#401B added epistemic guards, sensing/contingency, nondeterministic guarantee classes, temporal/resource validity, exogenous events, risk-aware diagnosis and layered repair.

Current source confirms the execution boundary is real: prolog/rlm_plan_graph.pl owns a closed op graph, validates structure/capability/budget, keeps model data inert, uses rlm_plan as the sole step executor, and explicitly separates plan-native D6-11 ops from expert mappings. C must not introduce a second workflow interpreter/scheduler.

Candidate 1 — one Universal Workflow Graph

Translate everything to task/action/condition nodes plus before/branch/retry edges.

Rejected as canonical. It loses or obscures BT RUNNING/tick/restart behavior, ConGolog interrupts/exogenous actions, BPMN compensation/message/event semantics, PDDL2.1 duration/resource invariants and MEPP guarantee/fairness classes. It remains acceptable only as a declared execution/visualization projection for a supported subset.

Candidate 2 — one executable Golog/situation-calculus kernel

Translate HTN/BT/BPMN/PDDL into Golog/ConGolog and run one common interpreter.

Rejected as ambient execution architecture. A powerful target does not prove semantics-preserving translations. It would also pull core toward a second interpreter/scheduler and broaden the trusted surface. Golog/ConGolog should instead remain first-class native procedural profiles.

Candidate 3 — native-formalism federation through contracts

Preferred: Procedural Interoperability & Federation Fabric (PIFF).

native HTN/HDDL ─────┐
native Golog/ConGolog ┤
native BT ────────────┤
native BPMN/workflow ─┼─> Procedural Semantic Contract (PSC)
native PDDL2.1 ───────┤        + typed bridges
production/expert rules┘        + loss/guarantee receipts
                                     ↓
                           compatibility/admission
                                     ↓
                         host-specific projection
                                     ↓
                            #288 plan graph
                                     ↓
                    #377 experts / #355 native ops
                                     ↓
                      capability/authority/effects

The durable artifact keeps its native formalism/version. Interoperability happens through explicit contracts/mappings, not flattening.

Native procedural artifact

Conceptual IR:

sem_procedure_artifact(
    ArtifactId,
    Formalism,
    FormalismVersion,
    NativeRef,
    ContractRef,
    Provenance).

Profiles may include htn_hddl, production_rules, golog, congolog, behavior_tree, bpmn_workflow, workflow_net, pddl21_temporal, machine_spirit_mepp, and preservation_only_external.

Unknown formalisms remain inert data until a trusted adapter/profile exists.

Procedural Semantic Contract (PSC)

sem_procedure_contract(
    ContractId,
    ArtifactId,
    goal_schema(GoalSchema),
    input_schema(Inputs),
    observation_schema(Observations),
    guard_semantics(GuardProfile),
    outcome_model(OutcomeProfile),
    temporal_model(TemporalProfile),
    resource_model(ResourceProfile),
    concurrency_model(ConcurrencyProfile),
    interrupt_model(InterruptProfile),
    cancellation_model(CancelProfile),
    recovery_model(RecoveryProfile),
    guarantee(GuaranteeClass),
    fairness(FairnessAssumptions),
    authority_requirements(AuthorityReqs),
    effect_classes(EffectClasses),
    portability(PortabilityScope),
    provenance(Provenance)).

A PSC is a behavioral/semantic contract, not capability possession.

Typed bridges; no equivalent=true

Mapping relations need forms such as:

exact_on(Profile)
refines
abstracts
implements
simulates_under(Assumptions)
projects_to
preserves_guarantee(Class)
weakens_guarantee(From,To)
strengthens_guard
weakens_guard
preserves_traces(ObservableSet)
approximates
lossy
incompatible
unknown
sem_procedure_bridge(
    BridgeId, FromArtifact, ToArtifact, Relation,
    DimensionMap, Assumptions, Preserved, Lost,
    EvidenceOrProof, MappingVersion, Status, Provenance).

Schema-valid mapping != semantics-preserving mapping.

Common observable trace = transport, not universal semantics

Cross-formalism comparison/projection may use a narrow declared observable interface:

observation/input
condition -> satisfied/refuted/unknown/conflicted
semantic action requested
admitted/blocked
attempt started
outcome observed
running/waiting
branch selected
interrupt/cancel
resource lease acquire/release
invariant/deadline event
recovery/compensation entered
subprocedure succeeded/failed/unknown/blocked/cancelled

Two artifacts can be equivalent on this declared observable set without claiming identical internal semantics.

Formalism-specific conclusions

HTN/HDDL

Shared tasks/methods/preconditions/order map cleanly into PIF for the common core. HDDL parsing does not imply MEPP sensing, runtime monitors, strong-cyclic fairness, authority or exogenous-event semantics exist.

Golog/ConGolog

A native Golog program can back a procedural-policy contract. ConGolog concurrency/interrupt/exogenous-action semantics remain explicit. Static HTN projection is allowed only for a restricted profile with required observable/guarantee preservation; otherwise preserve native semantics or return noncomposable.

Behavior Trees

Adapters must preserve SUCCESS/FAILURE/RUNNING, sequence/fallback, reactive-vs-memoryful behavior, halt/cancel, decorator retry bounds and async-leaf lifecycle. RUNNING != failure. ReactiveFallback restart != continue-current-child.

BPMN/workflow

Basic sequence/parallel split/join can often project to task networks. Inclusive gateways, event subprocesses, boundary events, messages, compensation/transactions and cancellation require richer support. Adapter manifests declare supported workflow patterns. Unsupported constructs produce preservation_only, lossy or incompatible rather than fake-valid DAGs.

PDDL2.1

Primitive operators may map, but durations, numeric/resource constraints, invariants and concurrency semantics must survive. A temporal PDDL plan is not automatically a MEPP policy under partial observability/exogenous change.

Host/action portability is a separate trusted binding layer

Hard distinction:

semantic action identity
    != host action binding
    != capability availability
    != principal authority
    != effect admission

Conceptual binding:

sem_action_binding(
    BindingId, SemanticActionRef, HostRef,
    AdapterId, AdapterVersion,
    RequiredCapability, AuthorityTemplate,
    EffectSchema, ObservationSchema,
    Preconditions, Status, Provenance).

A procedure may be semantically portable to host B yet remain unbound there. Ordinary semantic/procedure mappings cannot manufacture host bindings.

External roles (administrator, on-call lead, BPMN lane Operations, etc.) are semantic roles, not local principals. Role→principal mapping is a separate trusted identity/authority decision; lexical equality cannot do it.

Expert portability uses goal contracts, not expert IDs

Procedures refer to typed solver roles/goals such as diagnose_failure, resolve_project_symbol, produce_edit, verify_requirement. At runtime #377 selects a local compatible registered expert. Method identity stays constant if another compatible expert implementation/version is selected.

A remote/imported procedure therefore never imports executable expert closures.

Status mappings are loss-sensitive

Never flatten:

succeeded / failed / unknown / blocked / unsupported / cancelled / error

or BT RUNNING into Boolean success/failure unless a declared use permits it.

blocked(authority) != failed(method)
unknown(evidence)  != failed(action)
cancelled          != failed
RUNNING             != failed

Otherwise diagnosis learns false method defects.

Composition admission levels

Expose distinct states:

represented
schema_validated
semantic_contract_known
mapping_available
semantic_compatible(Context)
execution_projectable(Context)
host_bound
capability_available
authority_admissible_now
plan_valid_now
scheduled

Representation never implies execution readiness.

Projection API direction

procedure_compatible(+A,+B,+Context,+Profile,-Compatibility).
procedure_compose(+Artifacts,+Bridges,+Context,+Options,-Candidate).
procedure_project(+ArtifactOrComposition,+HostContext,+Options,-Projection,-Receipt).
procedure_explain_mapping(+BridgeOrProjection,-Explanation).

Projection receipts carry artifact/contract/bridge/binding versions; assumptions; preserved/lost dimensions; source vs projected guarantee; fairness/closure assumptions; unbound tasks/actions; status mappings; and #288 graph fingerprint if admitted.

Repository ownership

prolog-rlm: procedural artifact/PSC/bridge semantics; trusted profile/adapters; compatibility/projection; #377 goal-role selection; compile admitted projections to #288; mapping/loss/guarantee receipts; safe binding interface types.

#288 runtime: remains the only scheduler/execution graph.

host/AgentProlog/product: concrete trusted action adapters/capabilities where product-specific.

symbolic-memory: append-only history of native procedure artifacts, PSC versions, admitted/rejected bridge/mapping records, loss receipts, identity/alignment hypotheses, retained projection/execution receipts and episodic outcomes. Live capability/authority remains host/runtime state, not memory truth.

Complexity / scaling

  • Do not require general cross-formalism behavioral equivalence. Workflow-net results show even useful soundness notions become undecidable under expressive extensions.
  • Prefer dimension-specific contract checks; structural compatibility is usually cheap relative to full behavior checking. Use deeper simulation/trace/model checks only for supported bounded profiles.
  • Mapping discovery may be combinatorial; prefer explicit/versioned mapping bundles plus bounded candidate alignment. Model-proposed mappings remain inert candidates.
  • Avoid a global product of HTN alternatives × BT states × workflow markings × Golog situations. Compose bridge-visible procedural interfaces first and expand only the admitted/current slice.
  • Cache compatibility/projection by artifact fingerprint + PSC + bridge + host-binding generation + context/profile. Mapping upgrades create new projection generations.
  • Exact incremental matching, compact contingent policies and runtime performance belong to #401D.

Epistemic / provenance implications

  • imported procedure remains source-attributed knowledge;
  • source says this works != trusted method admitted;
  • native artifact semantics, adapter interpretation, mapping decision, host binding and runtime observation are separate provenance classes;
  • competing mappings survive; no destructive winner;
  • host-A success is a case under host-A context, not proof of host-B portability;
  • mapping upgrades do not rewrite historical receipts;
  • lossy projections may be useful for retrieval/visualization while explicitly non-executable.

Safety / authority invariants

procedure mapping               != authority mapping
external role                   != local principal
semantic action name            != host predicate/tool binding
host-A binding                  != host-B binding
expert goal compatibility       != expert authority
BPMN service task               != service permission
BT action leaf                  != callable host closure
Golog action symbol             != Prolog call/1 target
PDDL operator                   != effect admission
semantically portable           != executable here
lossy projection                != execution-admitted projection
weak guarantee                  != strong guarantee
fairness assumption             != runtime guarantee

No adapter may silently strengthen guarantee, weaken a destructive/safety guard, erase authority prerequisites, turn unknown into satisfied, or map external principals by name.

Adversarial failure cases

  1. HDDL adapter drops sensing/monitor extension.
  2. Golog nondeterministic choice becomes first HTN branch.
  3. ConGolog interrupt becomes ordinary edge.
  4. BT RUNNING becomes failure.
  5. ReactiveFallback becomes memoryful Fallback.
  6. Unbounded BT retry becomes unconditional guarantee.
  7. BPMN inclusive gateway becomes exclusive.
  8. BPMN boundary/compensation disappears.
  9. BPMN lane admin becomes local admin principal.
  10. PDDL2.1 durative invariant disappears.
  11. Resource lease becomes static precondition.
  12. No-order edge is mistaken for safe concurrency.
  13. Host-A action binding is reused on host B by name.
  14. Expert output-schema match hides status/evidence incompatibility.
  15. blocked(authority) becomes failed method.
  16. Open-world unknown becomes false through closed workflow semantics without closure contract.
  17. best_effort becomes strong after mapping.
  18. Strong-cyclic fairness assumption disappears.
  19. Old run replays under a newer adapter version.
  20. External workflow engine schedules alongside #288.
  21. First lexical action mapping wins silently.
  22. Lossy visualization projection is executed.
  23. Imported procedure embeds remote expert closure/id.
  24. Model-generated mapping reaches executable Prolog.

Falsifiable conformance fixtures

C1 HDDL common-core round trip preserves tasks/methods/preconditions/partial order + method identity.

C2 unsupported HDDL sensing/monitor extension returns declared loss/noncomposable.

C3 Golog nondeterministic alternatives survive; no top-1 branch.

C4 ConGolog interrupt projection is rejected unless the profile preserves required interrupt behavior.

C5 exogenous action can invalidate/redirect active policy under its contract.

C6 BT SUCCESS/FAILURE/RUNNING survives round trip.

C7 ReactiveFallback and memoryful Fallback remain behaviorally distinguishable.

C8 retry bound/fairness survives; no unconditional-guarantee promotion.

C9 BPMN parallel split/join preserves synchronization.

C10 inclusive gateway cannot become exclusive choice without explicit lossy/non-executable receipt.

C11 unsupported boundary/compensation blocks executable projection.

C12 supported workflow-net fragment returns named soundness result; unsupported expressive extension returns unsupported/unknown.

C13 PDDL2.1 duration + over-all invariant survive or projection fails.

C14 resource conflict prevents unsafe concurrent projection.

C15 missing dependency edge alone does not authorize overlap.

C16 same native procedure projects differently on hosts with different bindings while artifact identity stays stable.

C17 host-A binding cannot appear on host B without explicit trusted binding.

C18 identical role names across hosts do not imply same principal/authority.

C19 imported privileged procedure remains queryable while effects stay unbound/blocked.

C20 same method can bind to different compatible local experts without changing method identity.

C21 missing compatible expert yields blocked/unsupported; no invented expert.

C22 unknown/blocked/cancelled/RUNNING statuses cannot collapse to success/failure.

C23 projected guarantee may weaken with explicit receipt; it cannot strengthen without proof/trusted refinement.

C24 fairness assumption is preserved and may block admission if host cannot supply it.

C25 old run resolves exact old artifact/PSC/bridge/binding versions after mapping upgrades.

C26 malicious action names call, shell, delete_all, restart remain inert and never bind by name to call/1/tools.

C27 adapters may propose/project work but scheduling occurs only through #288.

C28 supported known-procedure compatibility + projection completes with providers disabled and model_calls = 0 once artifacts/contracts/bridges/bindings exist.

For finite supported subsets, differential conformance compares declared observable traces/properties against native reference semantics where available—not serializer equality.

Canonical handoffs

  • #392: distinguish native procedure artifact, PSC, procedure bridge/mapping, host action binding and host-specific projection/receipt.
  • #379: consume only execution-admitted host projections; never directly flatten foreign control programs into #288.
  • #377: expert portability is goal-contract based; imported procedures cannot persist trusted expert closures or assume stable expert IDs across hosts.
  • #376/#387: one scheduler/runtime remains hard; external engines can be reference evaluators/adapters, not competing authoritative orchestrators.
  • symbolic-memory #6: persist artifact/PSC/bridge/mapping versions + retained projection/execution receipts append-only.
  • symbolic-memory #10: reversible reconciliation should cover procedure/action/goal identity mappings with exact/narrower/broader/overlap/approximate/incompatible relations.
  • symbolic-memory #7/#9: expose represented vs compatible vs projectable vs host-bound vs currently authority-admissible states.

Rejected shortcuts

  • Everything is a DAG.
  • Everything is Golog.
  • BPMN as universal AI procedure IR.
  • Behavior Tree as universal procedure IR.
  • String/action names bind tools.
  • Best-effort guarantee inferred stronger after translation.
  • Import remote expert IDs.
  • External workflow runtime executes alongside #288.

Unresolved for #401D / later depths

  1. First adapter/profile matrix (likely MEPP + restricted HDDL/HTN + bounded BT subset before BPMN/ConGolog execution adapters).
  2. Concrete PSC normalization/fingerprint.
  3. Exact finite observable-trace schema/reference interpreters.
  4. Structural vs solver/model-checker compatibility checks.
  5. Incremental method/guard/contract matching + invalidation.
  6. Compact contingent/reactive representation without state-product explosion.
  7. Whether workflow-net/Petri-net checking backend is worth shipping.
  8. Whether Golog reference interpreter is test-only or optional trusted profile.
  9. Empirical bridge/mapping/trace-check bounds.
  10. Distributed/remote execution must not weaken the single scheduler/effect boundary.
  11. Learned mapping/promotion remains #404 territory.
  12. Executable heterogeneous-cooperation proof remains later conformance work; this is design, not Machine Spirit acceptance.

C conclusion

Depth 4C prefers PIFF: preserve native procedural formalisms, expose versioned Procedural Semantic Contracts, compose through typed/loss-aware bridges, keep host action/expert bindings separate, and compile only an execution-admitted host-specific projection into #288.

common procedure interface
    != common internal semantics
    != common guarantee
    != common host binding
    != common principal
    != common authority

Next research subpass: #401D — computational realization / scaling / deterministic conformance. #401 remains open until D is complete and A/B/C/D are reconciled.

## Machine Spirit Depth 4C — heterogeneous procedural federation without semantic flattening This is **subpass C only**. It composes Depth-4A **PIF** and Depth-4B **MEPP** across heterogeneous procedural formalisms, hosts, experts, observability models, temporal/resource semantics, recovery semantics and authority regimes. It does **not** close #401 or advance to #402. Depth 4D remains mandatory. ### Research questions / scope 1. Can HTN/HDDL methods, production/control rules, Golog/ConGolog programs, Behavior Trees, BPMN/workflow fragments, temporal PDDL models and domain expert procedures cooperate without pretending they have one execution semantics? 2. Which properties map exactly, which are refinements/abstractions, and which must remain preservation-only/noncomposable? 3. How can a procedure imported from host A be reused on host B without transferring A's principal identity, action bindings, capabilities or authority? 4. How should expert-owned tasks remain portable when concrete expert implementations differ by host/version? 5. What must mapping receipts preserve about sensing, unknowns, nondeterminism, guarantees, fairness, concurrency, interrupts, cancellation, compensation, deadlines, resources and recovery? 6. Where does composition stop and the existing #288 scheduler / #377 expert registry / capability-authority-effect boundary begin? ## Primary / authoritative sources - Höller et al., **HDDL: An Extension to PDDL for Expressing Hierarchical Planning Problems**, AAAI 2020, published 2020-04-03, DOI `10.1609/aaai.v34i06.6542`: https://ojs.aaai.org/index.php/AAAI/article/view/6542 . HDDL exists because planner-specific languages damaged interoperability; it deliberately standardizes a shared/basic HTN feature set, not every planner's semantics. - Fox & Long, **PDDL2.1: An Extension to PDDL for Expressing Temporal Planning Domains**, JAIR 20, 2003, DOI `10.1613/jair.1129`: https://strathprints.strath.ac.uk/1846/ . Durative actions, numeric/resource constraints and concurrent plan-validity semantics are material meaning, not optional metadata. - Levesque, Reiter, Lespérance, Lin, Scherl, **GOLOG: A Logic Programming Language for Dynamic Domains**, Journal of Logic Programming 31, 1997: https://www.cs.toronto.edu/kr/papers/GOLOGlang.pdf . GOLOG maintains explicit dynamic-world semantics from action precondition/effect axioms. - De Giacomo, Lespérance, Levesque, **ConGolog, a concurrent programming language based on the situation calculus**, Artificial Intelligence 121(1–2), August 2000, DOI `10.1016/S0004-3702(00)00031-X`: https://doi.org/10.1016/S0004-3702(00)00031-X . Concurrency, prioritized interrupts and exogenous actions cannot generally be flattened to a static HTN DAG. - Colledanchise & Ögren, **Behavior Trees in Robotics and AI**, CRC Press, 2018/2019: https://www.routledge.com/Behavior-Trees-in-Robotics-and-AI-An-Introduction/Colledanchise-Ogren/p/book/9780367571337 . BTs are reactive hierarchical controllers with explicit success/failure/running behavior. - **BehaviorTree.CPP official docs**, inspected 2026-09-05: https://www.behaviortree.dev/docs/nodes-library/FallbackNode/ . Fallback and ReactiveFallback differ after `RUNNING`; current implementations make clear that a generic branch edge does not preserve BT semantics. - Object Management Group, **BPMN 2.0.2**, formal version January 2014: https://www.omg.org/spec/BPMN/2.0.2 . Normative specification + machine-readable schemas; typed gateways/events/subprocesses are richer than an ordered step list. - van der Aalst et al., **Workflow Patterns**, Distributed and Parallel Databases 14(1), July 2003, DOI `10.1023/A:1022883727209`: https://doi.org/10.1023/A:1022883727209 . Different workflow languages support materially different control-flow capabilities. - van der Aalst et al., **Soundness of workflow nets: classification, decidability, and analysis**, Formal Aspects of Computing 23, 2011, published online 2010-08-03, DOI `10.1007/s00165-010-0161-4`: https://link.springer.com/article/10.1007/s00165-010-0161-4 . Eight soundness notions are decidable for ordinary workflow nets, while most examined expressive extensions make them undecidable. - de Alfaro & Henzinger, **Interface Automata**, ESEC/FSE 2001, DOI `10.1145/503209.503226`: https://doi.org/10.1145/503209.503226 . Compatibility/refinement should compare behavioral interfaces and assumptions/guarantees rather than implementation internals. - Benveniste, Caillaud, Passerone, **A Generic Model of Contracts for Embedded Systems**, INRIA RR-6214 / arXiv:0706.1456, June 2007: https://arxiv.org/abs/0706.1456 . Rich components can expose multiple behavioral/non-functional contracts; composition is contract-relative. ## Prior-subpass/current-repo comparison #401A established: ```text procedure/method knowledge != plan instance method selection != expert selection expert applicability != authority predicted effect != observation case precedent != trusted rule ``` #401B added epistemic guards, sensing/contingency, nondeterministic guarantee classes, temporal/resource validity, exogenous events, risk-aware diagnosis and layered repair. Current source confirms the execution boundary is real: `prolog/rlm_plan_graph.pl` owns a closed op graph, validates structure/capability/budget, keeps model data inert, uses `rlm_plan` as the sole step executor, and explicitly separates plan-native D6-11 ops from expert mappings. C must not introduce a second workflow interpreter/scheduler. # Candidate 1 — one Universal Workflow Graph Translate everything to `task/action/condition` nodes plus `before/branch/retry` edges. **Rejected as canonical.** It loses or obscures BT `RUNNING`/tick/restart behavior, ConGolog interrupts/exogenous actions, BPMN compensation/message/event semantics, PDDL2.1 duration/resource invariants and MEPP guarantee/fairness classes. It remains acceptable only as a declared execution/visualization projection for a supported subset. # Candidate 2 — one executable Golog/situation-calculus kernel Translate HTN/BT/BPMN/PDDL into Golog/ConGolog and run one common interpreter. **Rejected as ambient execution architecture.** A powerful target does not prove semantics-preserving translations. It would also pull core toward a second interpreter/scheduler and broaden the trusted surface. Golog/ConGolog should instead remain first-class native procedural profiles. # Candidate 3 — native-formalism federation through contracts **Preferred: Procedural Interoperability & Federation Fabric (PIFF).** ```text native HTN/HDDL ─────┐ native Golog/ConGolog ┤ native BT ────────────┤ native BPMN/workflow ─┼─> Procedural Semantic Contract (PSC) native PDDL2.1 ───────┤ + typed bridges production/expert rules┘ + loss/guarantee receipts ↓ compatibility/admission ↓ host-specific projection ↓ #288 plan graph ↓ #377 experts / #355 native ops ↓ capability/authority/effects ``` The durable artifact keeps its native formalism/version. Interoperability happens through explicit contracts/mappings, not flattening. ## Native procedural artifact Conceptual IR: ```prolog sem_procedure_artifact( ArtifactId, Formalism, FormalismVersion, NativeRef, ContractRef, Provenance). ``` Profiles may include `htn_hddl`, `production_rules`, `golog`, `congolog`, `behavior_tree`, `bpmn_workflow`, `workflow_net`, `pddl21_temporal`, `machine_spirit_mepp`, and `preservation_only_external`. Unknown formalisms remain inert data until a trusted adapter/profile exists. ## Procedural Semantic Contract (PSC) ```prolog sem_procedure_contract( ContractId, ArtifactId, goal_schema(GoalSchema), input_schema(Inputs), observation_schema(Observations), guard_semantics(GuardProfile), outcome_model(OutcomeProfile), temporal_model(TemporalProfile), resource_model(ResourceProfile), concurrency_model(ConcurrencyProfile), interrupt_model(InterruptProfile), cancellation_model(CancelProfile), recovery_model(RecoveryProfile), guarantee(GuaranteeClass), fairness(FairnessAssumptions), authority_requirements(AuthorityReqs), effect_classes(EffectClasses), portability(PortabilityScope), provenance(Provenance)). ``` A PSC is a behavioral/semantic contract, **not capability possession**. ## Typed bridges; no `equivalent=true` Mapping relations need forms such as: ```text exact_on(Profile) refines abstracts implements simulates_under(Assumptions) projects_to preserves_guarantee(Class) weakens_guarantee(From,To) strengthens_guard weakens_guard preserves_traces(ObservableSet) approximates lossy incompatible unknown ``` ```prolog sem_procedure_bridge( BridgeId, FromArtifact, ToArtifact, Relation, DimensionMap, Assumptions, Preserved, Lost, EvidenceOrProof, MappingVersion, Status, Provenance). ``` Schema-valid mapping != semantics-preserving mapping. ## Common observable trace = transport, not universal semantics Cross-formalism comparison/projection may use a narrow declared observable interface: ```text observation/input condition -> satisfied/refuted/unknown/conflicted semantic action requested admitted/blocked attempt started outcome observed running/waiting branch selected interrupt/cancel resource lease acquire/release invariant/deadline event recovery/compensation entered subprocedure succeeded/failed/unknown/blocked/cancelled ``` Two artifacts can be equivalent **on this declared observable set** without claiming identical internal semantics. ## Formalism-specific conclusions ### HTN/HDDL Shared tasks/methods/preconditions/order map cleanly into PIF for the common core. HDDL parsing does **not** imply MEPP sensing, runtime monitors, strong-cyclic fairness, authority or exogenous-event semantics exist. ### Golog/ConGolog A native Golog program can back a procedural-policy contract. ConGolog concurrency/interrupt/exogenous-action semantics remain explicit. Static HTN projection is allowed only for a restricted profile with required observable/guarantee preservation; otherwise preserve native semantics or return noncomposable. ### Behavior Trees Adapters must preserve `SUCCESS/FAILURE/RUNNING`, sequence/fallback, reactive-vs-memoryful behavior, halt/cancel, decorator retry bounds and async-leaf lifecycle. `RUNNING` != failure. ReactiveFallback restart != continue-current-child. ### BPMN/workflow Basic sequence/parallel split/join can often project to task networks. Inclusive gateways, event subprocesses, boundary events, messages, compensation/transactions and cancellation require richer support. Adapter manifests declare supported workflow patterns. Unsupported constructs produce `preservation_only`, `lossy` or `incompatible` rather than fake-valid DAGs. ### PDDL2.1 Primitive operators may map, but durations, numeric/resource constraints, invariants and concurrency semantics must survive. A temporal PDDL plan is not automatically a MEPP policy under partial observability/exogenous change. ## Host/action portability is a separate trusted binding layer Hard distinction: ```text semantic action identity != host action binding != capability availability != principal authority != effect admission ``` Conceptual binding: ```prolog sem_action_binding( BindingId, SemanticActionRef, HostRef, AdapterId, AdapterVersion, RequiredCapability, AuthorityTemplate, EffectSchema, ObservationSchema, Preconditions, Status, Provenance). ``` A procedure may be semantically portable to host B yet remain **unbound** there. Ordinary semantic/procedure mappings cannot manufacture host bindings. External roles (`administrator`, `on-call lead`, BPMN lane `Operations`, etc.) are semantic roles, not local principals. Role→principal mapping is a separate trusted identity/authority decision; lexical equality cannot do it. ## Expert portability uses goal contracts, not expert IDs Procedures refer to typed solver roles/goals such as `diagnose_failure`, `resolve_project_symbol`, `produce_edit`, `verify_requirement`. At runtime #377 selects a local compatible registered expert. Method identity stays constant if another compatible expert implementation/version is selected. A remote/imported procedure therefore never imports executable expert closures. ## Status mappings are loss-sensitive Never flatten: ```text succeeded / failed / unknown / blocked / unsupported / cancelled / error ``` or BT `RUNNING` into Boolean success/failure unless a declared use permits it. ```text blocked(authority) != failed(method) unknown(evidence) != failed(action) cancelled != failed RUNNING != failed ``` Otherwise diagnosis learns false method defects. ## Composition admission levels Expose distinct states: ```text represented schema_validated semantic_contract_known mapping_available semantic_compatible(Context) execution_projectable(Context) host_bound capability_available authority_admissible_now plan_valid_now scheduled ``` Representation never implies execution readiness. ## Projection API direction ```prolog procedure_compatible(+A,+B,+Context,+Profile,-Compatibility). procedure_compose(+Artifacts,+Bridges,+Context,+Options,-Candidate). procedure_project(+ArtifactOrComposition,+HostContext,+Options,-Projection,-Receipt). procedure_explain_mapping(+BridgeOrProjection,-Explanation). ``` Projection receipts carry artifact/contract/bridge/binding versions; assumptions; preserved/lost dimensions; source vs projected guarantee; fairness/closure assumptions; unbound tasks/actions; status mappings; and #288 graph fingerprint if admitted. ## Repository ownership **prolog-rlm:** procedural artifact/PSC/bridge semantics; trusted profile/adapters; compatibility/projection; #377 goal-role selection; compile admitted projections to #288; mapping/loss/guarantee receipts; safe binding interface types. **#288 runtime:** remains the only scheduler/execution graph. **host/AgentProlog/product:** concrete trusted action adapters/capabilities where product-specific. **symbolic-memory:** append-only history of native procedure artifacts, PSC versions, admitted/rejected bridge/mapping records, loss receipts, identity/alignment hypotheses, retained projection/execution receipts and episodic outcomes. Live capability/authority remains host/runtime state, not memory truth. ## Complexity / scaling - Do **not** require general cross-formalism behavioral equivalence. Workflow-net results show even useful soundness notions become undecidable under expressive extensions. - Prefer dimension-specific contract checks; structural compatibility is usually cheap relative to full behavior checking. Use deeper simulation/trace/model checks only for supported bounded profiles. - Mapping discovery may be combinatorial; prefer explicit/versioned mapping bundles plus bounded candidate alignment. Model-proposed mappings remain inert candidates. - Avoid a global product of HTN alternatives × BT states × workflow markings × Golog situations. Compose bridge-visible procedural interfaces first and expand only the admitted/current slice. - Cache compatibility/projection by artifact fingerprint + PSC + bridge + host-binding generation + context/profile. Mapping upgrades create new projection generations. - Exact incremental matching, compact contingent policies and runtime performance belong to #401D. ## Epistemic / provenance implications - imported procedure remains source-attributed knowledge; - `source says this works` != `trusted method admitted`; - native artifact semantics, adapter interpretation, mapping decision, host binding and runtime observation are separate provenance classes; - competing mappings survive; no destructive winner; - host-A success is a case under host-A context, not proof of host-B portability; - mapping upgrades do not rewrite historical receipts; - lossy projections may be useful for retrieval/visualization while explicitly non-executable. ## Safety / authority invariants ```text procedure mapping != authority mapping external role != local principal semantic action name != host predicate/tool binding host-A binding != host-B binding expert goal compatibility != expert authority BPMN service task != service permission BT action leaf != callable host closure Golog action symbol != Prolog call/1 target PDDL operator != effect admission semantically portable != executable here lossy projection != execution-admitted projection weak guarantee != strong guarantee fairness assumption != runtime guarantee ``` No adapter may silently strengthen guarantee, weaken a destructive/safety guard, erase authority prerequisites, turn unknown into satisfied, or map external principals by name. ## Adversarial failure cases 1. HDDL adapter drops sensing/monitor extension. 2. Golog nondeterministic choice becomes first HTN branch. 3. ConGolog interrupt becomes ordinary edge. 4. BT `RUNNING` becomes failure. 5. ReactiveFallback becomes memoryful Fallback. 6. Unbounded BT retry becomes unconditional guarantee. 7. BPMN inclusive gateway becomes exclusive. 8. BPMN boundary/compensation disappears. 9. BPMN lane `admin` becomes local admin principal. 10. PDDL2.1 durative invariant disappears. 11. Resource lease becomes static precondition. 12. No-order edge is mistaken for safe concurrency. 13. Host-A action binding is reused on host B by name. 14. Expert output-schema match hides status/evidence incompatibility. 15. `blocked(authority)` becomes failed method. 16. Open-world unknown becomes false through closed workflow semantics without closure contract. 17. `best_effort` becomes `strong` after mapping. 18. Strong-cyclic fairness assumption disappears. 19. Old run replays under a newer adapter version. 20. External workflow engine schedules alongside #288. 21. First lexical action mapping wins silently. 22. Lossy visualization projection is executed. 23. Imported procedure embeds remote expert closure/id. 24. Model-generated mapping reaches executable Prolog. ## Falsifiable conformance fixtures **C1** HDDL common-core round trip preserves tasks/methods/preconditions/partial order + method identity. **C2** unsupported HDDL sensing/monitor extension returns declared loss/noncomposable. **C3** Golog nondeterministic alternatives survive; no top-1 branch. **C4** ConGolog interrupt projection is rejected unless the profile preserves required interrupt behavior. **C5** exogenous action can invalidate/redirect active policy under its contract. **C6** BT `SUCCESS/FAILURE/RUNNING` survives round trip. **C7** ReactiveFallback and memoryful Fallback remain behaviorally distinguishable. **C8** retry bound/fairness survives; no unconditional-guarantee promotion. **C9** BPMN parallel split/join preserves synchronization. **C10** inclusive gateway cannot become exclusive choice without explicit lossy/non-executable receipt. **C11** unsupported boundary/compensation blocks executable projection. **C12** supported workflow-net fragment returns named soundness result; unsupported expressive extension returns unsupported/unknown. **C13** PDDL2.1 duration + over-all invariant survive or projection fails. **C14** resource conflict prevents unsafe concurrent projection. **C15** missing dependency edge alone does not authorize overlap. **C16** same native procedure projects differently on hosts with different bindings while artifact identity stays stable. **C17** host-A binding cannot appear on host B without explicit trusted binding. **C18** identical role names across hosts do not imply same principal/authority. **C19** imported privileged procedure remains queryable while effects stay unbound/blocked. **C20** same method can bind to different compatible local experts without changing method identity. **C21** missing compatible expert yields blocked/unsupported; no invented expert. **C22** unknown/blocked/cancelled/RUNNING statuses cannot collapse to success/failure. **C23** projected guarantee may weaken with explicit receipt; it cannot strengthen without proof/trusted refinement. **C24** fairness assumption is preserved and may block admission if host cannot supply it. **C25** old run resolves exact old artifact/PSC/bridge/binding versions after mapping upgrades. **C26** malicious action names `call`, `shell`, `delete_all`, `restart` remain inert and never bind by name to `call/1`/tools. **C27** adapters may propose/project work but scheduling occurs only through #288. **C28** supported known-procedure compatibility + projection completes with providers disabled and `model_calls = 0` once artifacts/contracts/bridges/bindings exist. For finite supported subsets, differential conformance compares declared observable traces/properties against native reference semantics where available—not serializer equality. ## Canonical handoffs - **#392:** distinguish native procedure artifact, PSC, procedure bridge/mapping, host action binding and host-specific projection/receipt. - **#379:** consume only execution-admitted host projections; never directly flatten foreign control programs into #288. - **#377:** expert portability is goal-contract based; imported procedures cannot persist trusted expert closures or assume stable expert IDs across hosts. - **#376/#387:** one scheduler/runtime remains hard; external engines can be reference evaluators/adapters, not competing authoritative orchestrators. - **symbolic-memory #6:** persist artifact/PSC/bridge/mapping versions + retained projection/execution receipts append-only. - **symbolic-memory #10:** reversible reconciliation should cover procedure/action/goal identity mappings with exact/narrower/broader/overlap/approximate/incompatible relations. - **symbolic-memory #7/#9:** expose represented vs compatible vs projectable vs host-bound vs currently authority-admissible states. ## Rejected shortcuts - Everything is a DAG. - Everything is Golog. - BPMN as universal AI procedure IR. - Behavior Tree as universal procedure IR. - String/action names bind tools. - Best-effort guarantee inferred stronger after translation. - Import remote expert IDs. - External workflow runtime executes alongside #288. ## Unresolved for #401D / later depths 1. First adapter/profile matrix (likely MEPP + restricted HDDL/HTN + bounded BT subset before BPMN/ConGolog execution adapters). 2. Concrete PSC normalization/fingerprint. 3. Exact finite observable-trace schema/reference interpreters. 4. Structural vs solver/model-checker compatibility checks. 5. Incremental method/guard/contract matching + invalidation. 6. Compact contingent/reactive representation without state-product explosion. 7. Whether workflow-net/Petri-net checking backend is worth shipping. 8. Whether Golog reference interpreter is test-only or optional trusted profile. 9. Empirical bridge/mapping/trace-check bounds. 10. Distributed/remote execution must not weaken the single scheduler/effect boundary. 11. Learned mapping/promotion remains #404 territory. 12. Executable heterogeneous-cooperation proof remains later conformance work; this is design, not Machine Spirit acceptance. ## C conclusion **Depth 4C prefers PIFF: preserve native procedural formalisms, expose versioned Procedural Semantic Contracts, compose through typed/loss-aware bridges, keep host action/expert bindings separate, and compile only an execution-admitted host-specific projection into #288.** ```text common procedure interface != common internal semantics != common guarantee != common host binding != common principal != common authority ``` **Next research subpass: #401D — computational realization / scaling / deterministic conformance.** #401 remains open until D is complete and A/B/C/D are reconciled.
Author
Owner

Machine Spirit Depth 4D — computational realization / scaling / conformance

This is subpass D only. It closes the Depth-4 research sequence only after reconciling A/B/C with the computational conclusions below. It does not establish implementation or Machine Spirit acceptance.

Research questions / scope

Depth 4A/B/C established PIF + MEPP + PIFF: reusable HTN-like procedural know-how, epistemic/reactive monitoring, and non-flattening interoperability through PSCs. D asks the computational questions A/B/C intentionally left open:

  1. How do we select only the procedures/methods/bridges relevant to a current goal instead of materializing a universal executable workflow graph?
  2. How do method applicability, epistemic guards, PSC compatibility, host bindings, expert availability, authority state and runtime observations invalidate incrementally?
  3. How do we retain contingent/reactive alternatives without a Cartesian product of HTN decompositions × BT states × workflow markings × Golog situations × temporal/resource alternatives?
  4. What is the executable boundary between reusable procedure semantics and the existing #288 scheduler?
  5. How do temporal/resource/concurrency constraints get validated without assuming that lack of a dependency edge means safe parallelism?
  6. How do diagnosis/case/procedure indexes remain bounded and deterministic?
  7. How can supported cross-formalism adapters be tested against independent/reference semantics rather than merely checking that a projected run terminated?
  8. What exact trace is sufficient to replay concurrent/reactive execution deterministically?
  9. What complexity/resource limits are structural, and what must happen when they are exceeded?
  10. How do already-known procedures and expert cooperation execute with model_calls = 0?

Current repository state inspected

The live repository already has a strong runtime boundary that D must preserve. prolog/rlm_plan_graph.pl currently parses/normalizes/validates a closed inert graph; checks IDs/dependencies/cycles/op vocabulary/capabilities/aggregate budgets; computes ready nodes; delegates each admitted step through rlm_plan; preserves cancellation as cancellation rather than ordinary failure; and keeps D6-11 plan-native operations separate from expert mapping. The module explicitly says rlm_plan remains the only step executor and that model/project data never becomes a callable goal.

That means D should not invent a new procedure scheduler or native BT/BPMN/Golog executor. It should compile/admit/monitor procedural semantics into the existing runtime.

Canonical constraints from #376/#377/#379/#384/#385/#387 also survive: one scheduler, one capability/authority/effect boundary, Frozen SPEC immutability, VERIFY as the only final success boundary, structured expert outcomes, bounded recursion/work/cancellation, diagnosis separated from repair, and zero-model local expert execution.


Primary / authoritative sources inspected

HTN verification, search and recursion

  • Mohammad Yousefi, Mario Schmautz, Patrik Haslum, Pascal Bercher, “How Good is Perfect? On the Incompleteness of A for Total-Order HTN Planning”*, ICAPS 2025, published 2025-09-16, DOI 10.1609/icaps.v35i1.36107: https://ojs.aaai.org/index.php/ICAPS/article/view/36107 . Even totally ordered HTN planning can make A* incomplete because hierarchy-induced cycles interact badly with tree/graph search; the paper gives a polynomial cycle test and a semantics-preserving normal-form direction. This means depth_limit alone is not a correctness story for recursive methods.
  • Pascal Lauer, Songtuan Lin, Pascal Bercher, “Tight Bounds for Lifted HTN Plan Verification and Bounded Plan Existence”, ICAPS 2025, published 2025-09-16, DOI 10.1609/icaps.v35i1.36102: https://ojs.aaai.org/index.php/ICAPS/article/view/36102 . Verification/bounded existence complexity depends materially on method ordering/decomposition restrictions, and lifted verification can avoid unnecessary grounding.
  • Songtuan Lin, Conny Olz, Malte Helmert, Pascal Bercher, “On the Computational Complexity of Plan Verification, (Bounded) Plan-Optimality Verification, and Bounded Plan Existence”, AAAI 2024, published 2024-03-24, DOI 10.1609/aaai.v38i18.30000: https://ojs.aaai.org/index.php/AAAI/article/view/30000 . Verification can itself be nontrivial/NP-hard in HTN fragments; D therefore needs declared supported verification profiles rather than promising cheap universal validation.
  • Victor Scherer Putrich, Felipe Meneguzzi, André Grahl Pereira, “Landmark Generation in HTN Planning Revisited”, ICAPS 2025, published 2025-09-16, DOI 10.1609/icaps.v35i1.36123: https://ojs.aaai.org/index.php/ICAPS/article/view/36123 . Sound (though incomplete) AND/OR hierarchical landmarks provide cheap demanded relevance/pruning without pretending to solve full plan existence.
  • Paul Zaidins, Robert Goldman, Ugur Kuter, Dana Nau, Mark Roberts, “HTN Plan Repair Algorithms Compared: Strengths and Weaknesses of Different Methods”, ICAPS 2025, published 2025-09-16, DOI 10.1609/icaps.v35i1.36131: https://ojs.aaai.org/index.php/ICAPS/article/view/36131 . SHOPFIXER/IPYHOPPER/REWRITE embody different repair problem definitions/search spaces. This directly supports B's distinction among continuation repair, plan repair, method reselection and reusable-method defect.

Partial order / concurrency

  • Meysam Aghighi, Christer Bäckström, “Plan Reordering and Parallel Execution — A Parameterized Complexity View”, AAAI 2017, DOI 10.1609/aaai.v31i1.11025: https://ojs.aaai.org/index.php/AAAI/article/view/11025 . Minimum deordering/reordering and minimum parallel execution length are NP-complete; several parameterizations remain hard.
  • Harrison Oates, Pascal Bercher, “Makespan Investigations of Sequential, Parallel, PO, and POCL Plans”, AAAI 2026, published 2026-03-14, DOI 10.1609/aaai.v40i43.40953: https://ojs.aaai.org/index.php/AAAI/article/view/40953 . Sequential/parallel/PO/POCL plan representations are not freely interchangeable; conversion asymmetries and NP-complete optimal representation results kill the assumption that concurrency can be normalized to one generic ordering model.

Temporal plan validation

  • Maria Fox, Derek Long, “PDDL2.1: An Extension to PDDL for Expressing Temporal Planning Domains”, JAIR 20, 2003. PDDL2.1 defines durative actions, temporal conditions/effects and numeric/resource semantics. Canonical article: https://www.jair.org/index.php/jair/article/view/10321 .
  • Richard Howey, Derek Long, Maria Fox, “VAL: Automatic Plan Validation, Continuous Effects and Mixed Initiative Planning Using PDDL”, 2004. VAL provides an independent validator for advanced PDDL2.1 plans rather than trusting the planner's own execution story. This is the correct precedent for PIFF adapter conformance.

Behavior Trees

Workflow nets / process validation

  • Wil van der Aalst, “Verification of Workflow Nets”, 1997. Workflow-net/Petri-net semantics make soundness amenable to formal analysis; later workflow-net work classifies soundness notions and their decidability. A useful bibliographic/source entry is https://research.tue.nl/en/publications/verification/ . The important computational lesson is that restricted workflow-net soundness is decidable, while richer workflow extensions can cross into undecidable territory.

Diagnosis

  • Dietmar Jannach, Thomas Schmitz, Kostyantyn Shchekotykhin, “Parallelized Hitting Set Computation for Model-Based Diagnosis”, AAAI 2015, DOI 10.1609/aaai.v29i1.9389: https://ojs.aaai.org/index.php/AAAI/article/view/9389 . Hitting-set diagnosis can exploit parallel tree construction without losing diagnoses, but remains combinatorial.
  • Patrick Rodler, Manuel Herold, “StaticHS: A Variant of Reiter’s Hitting Set Tree for Efficient Sequential Diagnosis”, SoCS, DOI 10.1609/socs.v9i1.18449: https://ojs.aaai.org/index.php/SOCS/article/view/18449 . Sequential diagnosis can avoid wasteful recomputation/measurement choices under useful assumptions; diagnosis state should be query-local and incrementally reusable, not globally enumerated.

Deterministic replay under concurrency

  • Lars Tveito, Einar Broch Johnsen, Martin Schlatte, “Global Reproducibility Through Local Control for Distributed Active Objects”, FASE 2020: https://link.springer.com/chapter/10.1007/978-3-030-45234-6_7 . Recording interactions/local transitions at stable states can be sufficient for globally reproducible replay while still allowing replay-time parallelism. The lesson for #288 is to persist semantically relevant nondeterministic interaction/scheduling choices, not every CPU interleaving.

Candidate architecture 1 — eager universal executable materialization

Compile every admitted method, imported workflow and native formalism into a persistent universal executable graph. Precompute all method applicability, bridge combinations, temporal/resource alternatives and expert bindings.

Strengths

  • fast lookup if the exact execution context matches the materialization;
  • simple mental model for hosts;
  • straightforward graph visualization.

Failure modes

  • host binding, authority, resource leases, current evidence and expert registry are live state, so persistent executable materialization becomes stale quickly;
  • HTN alternatives × reactive states × workflow markings × temporal branches cause combinatorial materialization;
  • flattening foreign formalisms to one graph loses semantics already preserved by C;
  • replacing one mapping/adapter can invalidate huge swaths even when observable behavior is unchanged;
  • durable executable graphs blur reusable method identity and run-specific plan identity.

Reject as canonical architecture. A persistent cache may exist, but it must be derived, fingerprinted and demand-driven.


Candidate architecture 2 — polyglot native runtime federation

Run HTN, Golog/ConGolog, BehaviorTree.CPP and BPMN engines natively and federate them at runtime.

Strengths

  • high native semantic fidelity;
  • existing mature runtimes can execute their own constructs directly;
  • less translation work for some formalisms.

Failure modes

  • creates multiple schedulers/cancellation models and effect dispatch paths;
  • makes capability/authority admission inconsistent across engines;
  • replay becomes a federation of unrelated scheduler traces;
  • native workflow roles/actions risk being confused with local principals/capabilities;
  • violates #376/#288's one-runtime rule.

Reject as ambient execution architecture. Native implementations are still valuable as reference validators / differential conformance oracles for supported subsets.


Candidate architecture 3 — preferred: DPEC

Adopt a Demand-Driven Procedural Execution & Conformance Graph (DPEC).

DPEC is a derived compiler/admission/monitoring graph over PIF + MEPP + PIFF. It selects only the relevant procedural slice, keeps alternatives packed, produces a host-specific execution projection, validates that projection against the selected procedural semantic profile, and compiles admitted primitive work into the existing #288 plan graph.

Frozen goal / current epistemic frontier
               ↓
       demanded procedure slice
  method index / case candidate / PSC bridge
               ↓
      packed decomposition forest
 AND/OR method alternatives + guards + constraints
               ↓
  host projection / binding compatibility
 capability availability + authority preflight
 temporal/resource/concurrency validation
               ↓
   reference-profile conformance receipt
               ↓
          admitted #288 graph
               ↓
      one canonical scheduler/runtime
               ↓
 incremental monitors / observations
               ↓
 threat-directed continuation/plan/method repair
               ↓
          fresh #384 VERIFY

DPEC is not another scheduler. It is derived planning/admission state plus conformance/replay metadata.


DPEC typed symbolic model

Conceptual records; exact names follow implementation conventions.

proc_exec_key(Key,
              GoalSignature,
              ProcedureVersionSet,
              PSCVersionSet,
              BridgeVersionSet,
              HostProfile,
              BindingGeneration,
              ExpertRegistryGeneration,
              EpistemicFrontier,
              ResourcePolicyVersion,
              AuthorityPolicyVersion).

proc_candidate(CandidateId,
               GoalRef,
               MethodOrArtifactRef,
               ApplicabilityStatus,
               GuardDeps,
               CostClass,
               Provenance).

proc_choice(NodeId, Kind, Children, GuardRefs, ConstraintRefs).
% Kind = and | or | sequence | partial_order | observation_branch | recovery

proc_host_projection(ProjectionId,
                     NativeArtifactRef,
                     PSCRef,
                     BridgeRefs,
                     HostProfile,
                     BindingRefs,
                     ObservableInterface,
                     Guarantee,
                     LossProfile,
                     Fingerprint).

proc_monitor(MonitorId,
             ProjectionId,
             Kind,
             ConditionRef,
             DependencyRefs,
             FailureClass,
             RepairLayer).

proc_trace_event(EventId,
                 RunId,
                 FrontierId,
                 EventClass,
                 SubjectRef,
                 ObservedOutcome,
                 OrderingKey,
                 EvidenceRefs).

proc_conformance_receipt(ReceiptId,
                         NativeProfile,
                         ProjectionRef,
                         Relation,
                         ComparedTraceRefs,
                         PreservedProperties,
                         DeclaredLosses,
                         Status).

Important: proc_host_projection is derived state. Native procedure/PSC identity remains immutable semantic knowledge. Host bindings remain trusted host configuration/runtime data, not persisted executable authority in the semantic ledger.


1. Demanded method / bridge / expert selection

Index procedural knowledge by coarse symbolic signatures before expensive reasoning:

goal/task type
formalism/profile
method head / action class
required observation classes
guard dimensions
required effect classes
required resource kinds
PSC input/output/observation signature
host compatibility

Selection pipeline:

exact/specific method index
   ↓
cheap profile/host incompatibility pruning
   ↓
epistemic guard evaluation
   ↓
PSC/bridge compatibility
   ↓
expert goal-contract availability
   ↓
case candidates / bounded operator gap search only if needed

Do not globally evaluate every guard or every PSC mapping after each world-model update. Record exact dependencies used by each candidate/admission decision.

Production-rule/Rete-like caching may optimize large local applicability sets, but it remains derived cache state; Prolog indexing/tabling is the default implementation direction unless benchmarks justify a dedicated Rete network.


2. Packed decomposition instead of complete-plan enumeration

Method alternatives form a shared AND/OR decomposition DAG/forest:

OR  = alternative methods / contingent branches
AND = required subtasks / independent constraint sets
GUARD = epistemic/observation condition
LINK = partial-order / causal / resource / temporal relation
NOGOOD = known incompatible choice combination

Identical subtask/decomposition signatures may share nodes when their context/assumption fingerprints match.

Use sound hierarchical landmarks and inevitable-refinement/look-ahead techniques for pruning where applicable, but never interpret an incomplete landmark heuristic as completeness proof.

Recursive/cyclic methods

The 2025 A* incompleteness result makes this a hard D invariant:

recursive method detected
    != simply “allow until max_depth”

Before search/admission, classify decomposition cycles under the selected HTN/profile semantics. For fragments where a known cycle test/normalization guarantees termination/completeness, use it. Otherwise the result must explicitly carry one of:

cyclic_supported_under_profile
cyclic_requires_runtime_bound
cyclic_search_incomplete
resource_limited
unsupported

A depth/work limit is a safety mechanism, not a proof that the search semantics were complete.


3. Incremental applicability / projection invalidation

DPEC records dependency edges equivalent to:

native procedure/version
        ↓
PSC/version
        ↓
bridge/mapping/version
        ↓
host projection
        ↓
applicability / guard decisions
        ↓
packed decomposition fragment
        ↓
#288 plan generation
        ↓
runtime monitor obligations
        ↓
diagnosis / case outcome index

Other invalidators include:

epistemic frontier / known_at / valid_at
host binding generation
expert registry generation
capability availability
authority policy generation
resource/lease state
current project/source generation

Invalidation follows actual dependency closure. If recomputation yields the same observable host-projection/interface digest, propagation stops there.

This is the same useful principle Depth 2/3 discovered for semantic/epistemic computation, but applied to procedure semantics rather than copied blindly: internal native-artifact changes are allowed to be invisible downstream only when the selected PSC/profile proves the relevant observable interface unchanged.


4. Concurrency / temporal / resource admission

Absence of a task-order edge is not proof of safe concurrency.

Before two ready tasks may overlap, the selected procedural profile must admit concurrency after considering at least:

causal/precondition threats
write/effect-set interference
resource capacity / exclusive leases
durative invariants
temporal windows/deadlines
authority/capability interaction constraints
explicit formalism concurrency semantics

DPEC preserves source partial ordering rather than globally optimizing it. Optional bounded reordering/deordering may be a separate optimization because exact minimization/reordering/parallel length is NP-hard in general.

The result is a validated partial order + live constraints, not a promise that a missing edge always means parallel-safe.


5. Runtime monitoring without another interpreter

Compile MEPP semantics into monitor obligations attached to #288 execution state:

hard guard monitor
observation gate
branch discriminator
resource lease monitor
deadline/temporal invariant
causal-link threat monitor
async lifecycle/cancellation monitor
success-condition observation request

A monitor consumes structured observations/events and emits a typed delta:

unchanged
branch_enabled
branch_disabled
invariant_threatened
invariant_violated
resource_invalidated
authority_changed
exogenous_event
needs_observation
needs_plan_repair
needs_method_reselection

It does not itself schedule work. Planner/Repair turns a valid delta into a #288 graph revision/generation.

Predicted effects remain predictions; they never satisfy VERIFY.


6. Formalism-specific reference / differential conformance

A single plan finished test is inadequate. Each supported PIFF adapter must declare a reference profile and a comparison relation.

Candidate relation classes:

exact_trace
trace_refinement
stuttering_equivalent
preserves_terminal_status
preserves_safety_property
preserves_guarantee_under(Assumptions)
declared_lossy
noncomposable

Required initial conformance lanes:

HTN/HDDL restricted subset

Validate that selected primitive plan/task decomposition is admitted by the original task/method network under the declared bounded profile. Prefer lifted verification where practical instead of grounding the entire method library.

PDDL2.1 temporal subset

Cross-check temporal/resource/invariant behavior against an independent VAL-like reference validator on fixtures. Planner/projection output cannot self-certify temporal validity.

Behavior Tree subset

Reference traces preserve SUCCESS/FAILURE/RUNNING, reactive-vs-memoryful fallback semantics, async start/poll/halt and bounded retry/decorator behavior. A projected #288 trace that maps RUNNING to failure is a conformance failure even if the final task eventually succeeded.

Workflow/BPMN restricted subset

For supported workflow patterns, use token/Petri-net-style reference semantics and soundness/termination checks where the chosen subset permits them. Cancellation, compensation, transactions or richer constructs that lack a proven adapter are preservation_only, lossy, or noncomposable, not silently ignored.

Golog/ConGolog restricted subset

Use an explicit small-step/trace oracle for the subset actually claimed by the adapter: tests, sequence, nondeterministic choice, iteration, concurrency/interrupt/exogenous actions only where semantics are implemented. No universal Golog equivalence claim.

Adapter upgrade = new mapping/projection generation + rerun relevant conformance; never rewrite old projection history.


7. Cancellation and deterministic replay

Cancellation is a first-class trace event, not failure and not implicit retry authorization.

For any running async action:

cancel requested
  -> no new child/effect dispatch
  -> propagate canonical cancellation token
  -> request adapter/handler halt where supported
  -> observe halt/indeterminate outcome
  -> preserve effect uncertainty where cancellation races an external side effect

DPEC replay modes should distinguish:

exact_trace_replay
    reuse retained observations/effect outcomes + nondeterministic interaction decisions

deterministic_reexecution
    rerun deterministic admitted operations under same canonical inputs; normalized trace must match

semantic_reexecution
    environment/external nondeterminism allowed; creates new run lineage, not “exact replay”

The concurrent replay literature suggests recording stable-state interaction/scheduling choices is enough to reproduce semantic outcomes without serializing every internal CPU step. For #288, a replay receipt should therefore bind at least:

Frozen SPEC fingerprint
procedure/method/native artifact versions
PSC/bridge/binding versions
host/expert registry generation
plan/replan generations
frontier-ready sets
actual dispatch/interaction ordering where nondeterministic and material
observed external/effect outcomes
cancellation events
resource/authority decisions
verification evidence refs
budgets/policy versions

Replay may execute independent deterministic work in parallel, but normalized semantic outcome/receipt must be invariant to harmless scheduler interleavings.


8. Bounded diagnosis / discriminator / CBR state

Global enumeration is forbidden by default.

Diagnosis

Maintain query/run-local conflict/hypothesis structure. Use incremental conflict reuse and bounded hitting-set/dual search. Parallel branches may use the existing runtime, but canonical results are normalized independently of thread completion order.

Bounds include:

max conflicts
max diagnosis cardinality
max live diagnoses
max discriminator candidates
max measurements/tests
max diagnosis work

Exhaustion returns unresolved/resource-limited diagnosis, not the first hypothesis found.

CBR

Two-stage candidate generation:

  1. hard symbolic compatibility/contraindication filters;
  2. bounded similarity ranking over survivors (symbolic/indexed, optional ANN/vector sensor).

A case result is still only an adaptation candidate. Cache keys include case corpus generation + compatibility policy + goal/context signature.


9. Explicit structural budgets / failure behavior

DPEC needs first-class budgets for at least:

selected procedure artifacts
method candidates per compound task
decomposition nodes / OR alternatives
method recursion depth + cycle/SCC work
PSC/bridge candidates
host projection bytes/states
active observation branches
temporal constraints / numeric resource vars
ready frontier width / active async actions
monitor count/events
case candidates
diagnostic conflicts/live diagnoses
reference-validator work
trace/receipt bytes
CPU / wall / memory
provider calls (must remain 0 for known symbolic fixtures)

Canonical exhaustion:

resource_limited(Dimension, Used, Limit, PartialReceipt)

Never:

budget ran out -> choose first method
budget ran out -> declare unknown as false
budget ran out -> silently ask an LLM

An explicitly configured fallback may be proposed after a structured unsupported/resource-limited result, but that is a new metered fallback event and cannot strengthen guarantees by fiat.


Complexity / performance implications

  1. Do not promise complete unrestricted HTN search. Even decidable total-order HTN search has non-obvious incompleteness traps under common algorithms; expressive planning can cross into very high complexity/undecidability. Advertise supported fragments/profile guarantees.
  2. Verification is cheaper than unrestricted generation only in useful fragments. Keep known-method-first and validate a small admitted projection instead of searching the entire procedural theory.
  3. Keep representations lifted/packed. Ground only demanded bindings. The 2025 HTN verification work explicitly supports the value of lifted representations.
  4. Partial order is a compact execution contract. One partial-order node can stand for many linearizations, but optimal reordering/deordering remains expensive. Preserve source order constraints and optimize only under explicit bounded policy.
  5. Reactive state is interface-factored. Do not cross-product every native internal state. Carry only bridge/host-visible control state unless a validator needs deeper state.
  6. Diagnosis/case reasoning is top-k/query-local. Complete enumeration is a conformance mode for small fixtures, not the production default.
  7. Incremental invalidation is the main scaling lever. A changed guard observation should not rebuild an unrelated method library; an adapter upgrade should not re-run source parsing; a registry change should not invalidate procedures that do not depend on the changed expert contract.

Epistemic / provenance implications

DPEC decisions are derived from the exact epistemic frontier they consumed. A host projection/admission receipt must preserve:

which evidence made guards satisfied/unknown/conflicted
which procedure/PSC/bridge versions were used
which assumptions/fairness conditions were admitted
which host bindings/expert contracts were selected
which losses/guarantee weakenings occurred
which resource/authority policy versions were checked
which observations changed the execution frontier

Changing evidence does not mutate historical decisions. It creates a new execution/projection generation.

A successful run is an episodic case with exact procedural/execution/VERIFY provenance. It does not auto-promote a method; #404 remains the promotion boundary.


Safety / authority implications

Hard invariants surviving D:

represented procedure       != executable projection
compatible procedure        != locally bound procedure
locally bound               != capability granted
authority preflight success != future authority forever
predicted effect            != observed effect
adapter conformance         != host authority
case similarity             != permission
repair candidate            != effect admission
method success              != Frozen-SPEC success

Authority/resource validity is checked again at the point where an admitted step would dispatch. Cached authority decisions cannot grant stale authority.

Host binding lookup is by trusted IDs/contracts, never by lexical equality with source action/role names.


Rejected alternatives

  1. Eager universal executable graph: rejected for stale live-state assumptions, Cartesian blow-up and semantic flattening.
  2. Polyglot native runtime federation: rejected as ambient architecture because it creates multiple schedulers/cancellation/effect paths; retained only for reference validation where useful.
  3. One universal Golog interpreter: rejected from C and still rejected; expressive target semantics do not prove source-language preservation and would duplicate runtime authority.
  4. One Boolean status vocabulary: rejected; BT RUNNING, epistemic unknown/conflicted, policy blocked, cancellation and failure remain distinct.
  5. Global optimal reordering/makespan: rejected as normal execution path; computationally hard and semantics-dependent.
  6. Depth-limit-as-cycle-correctness: rejected by current HTN results. Bounds are safety, not completeness proofs.
  7. Planner self-validation: rejected; supported adapters require independent/reference differential semantics and final task success still belongs to #384 VERIFY.
  8. Persist all Rete/search/diagnosis state as truth: rejected; these are rebuildable execution indexes/caches.
  9. Fallback to LLM on resource exhaustion: rejected; failure is explicit unless an independently configured fallback policy starts a new metered event.

Falsifiable D conformance fixtures

D1 — demanded method pruning

100 unrelated procedures + 2 matching goal signatures. Assert only relevant candidates/bridge dependencies are evaluated.

D2 — guard-local invalidation

Change evidence for one guard. Assert only candidates/monitor nodes depending on that guard recompute.

D3 — unchanged-interface stop

Upgrade a native artifact internally while PSC-visible host behavior stays identical. Assert downstream projection/plan invalidation stops at the stable interface digest.

D4 — bridge/mapping upgrade

Same procedure, new PIFF bridge version. New projection lineage must be created; historical projection remains reproducible.

D5 — expert registry upgrade isolation

Change unrelated expert contract. Procedure projections without that goal contract remain cache hits.

D6 — recursive HTN cycle classification

Fixture containing hierarchy-induced recursion. Assert cycle class/declared search guarantee is explicit; depth exhaustion cannot masquerade as “no plan”.

D7 — packed alternative bound

Large method-OR tree. Assert shared decomposition stays within node budget or returns resource_limited; no top-1 silent selection.

D8 — lifted verification

Bounded HTN fixture verifies without eagerly grounding the entire method library; result agrees with a clean reference verification.

D9 — partial-order preservation

Two independent tasks remain unordered through projection; no arbitrary total-order fingerprint becomes canonical semantics.

D10 — unsafe-concurrency rejection

No explicit dependency edge but shared exclusive resource/effect conflict exists. Assert overlap is rejected.

D11 — safe-concurrency determinism

Two independent ready steps execute in either physical interleaving. Normalized semantic result/receipt is identical.

D12 — temporal invariant violation

Durative task starts validly, exogenous observation violates invariant. Monitor must stop/repair appropriately; predicted completion cannot satisfy success.

D13 — deadline drift

Plan was valid at projection time but execution delay crosses deadline. Live validation blocks/stales the step rather than trusting cached admission.

D14 — resource lease invalidation

Lease disappears after plan construction. Dispatch is blocked/replanned; cached resource assumption is not authority.

D15 — BT RUNNING preservation

Reference BT emits RUNNING -> RUNNING -> SUCCESS. #288 projection must not emit failure/cancel/retry semantics during RUNNING.

D16 — ReactiveFallback interruption

Earlier condition changes while async child is RUNNING. Projected trace must halt/interupt the child and restart according to declared reactive semantics.

D17 — PDDL2.1 validator differential

Temporal/resource fixture projected to #288. Compare normalized projection trace/interval constraints against independent VAL-like reference. Any undeclared invariant/resource difference fails.

D18 — workflow token/join semantics

Restricted parallel split/join workflow. Reference token semantics and projected observable completion must agree; premature join completion fails.

D19 — unsupported BPMN compensation

Adapter lacking compensation semantics must return preservation-only/noncomposable; it cannot drop compensation and produce executable projection.

D20 — Golog nondeterministic-choice preservation

Reference admits alternatives A/B; projection must preserve allowed alternatives/declared refinement, not fabricate deterministic equivalence.

D21 — cancellation before dispatch

Cancel while nodes are ready but not dispatched. Assert zero later expert/tool/effect dispatch.

D22 — cancellation race with external effect

Effect dispatch occurred before cancellation acknowledgment. Outcome remains observed/indeterminate according to effect ledger; cannot be rewritten as clean cancellation.

D23 — exact trace replay

Retain interaction/frontier/effect observations, destroy rebuildable DPEC caches, replay. Normalized trace/result/receipt must match.

D24 — warm/cold/cache-rebuilt equivalence

Same procedure/evidence/host/profile inputs: cold == warm-cache == cache-rebuilt under normalized comparison.

D25 — incremental/full equivalence

After one evidence/method change, incrementally maintained projection/result must equal fresh full demanded recomputation for the same canonical inputs.

D26 — diagnosis bound

Combinatorial multi-fault fixture hits live-diagnosis ceiling. Result is resource_limited, never arbitrary first diagnosis.

D27 — diagnosis parallel determinism

Parallel hitting-set/conflict work may complete in different physical order; normalized bounded diagnosis set/ordering/receipt remains deterministic.

D28 — CBR contraindication before similarity

Near-neighbor case violates hard host/version/authority precondition. It is rejected before adaptation regardless of similarity score.

D29 — stale host binding

Host action binding generation changes after projection. Old projection is stale/unbound; semantic procedure remains intact.

D30 — authority recheck

Authority was admitted during planning then revoked. Step cannot dispatch from cached approval.

D31 — adapter trace proof receipt

Every executable heterogeneous projection carries formalism/profile/version + comparison relation + preserved properties + declared losses.

D32 — one-scheduler enforcement

Instrument execution. All executable task dispatch must pass through #288/rlm_plan; no native procedural runtime starts an independent scheduler.

D33 — zero-model heterogeneous cooperation

Known procedure combines at least two procedure/formalism adapter paths and multiple Prolog experts, includes one observation branch and one repair/monitor path, reaches fresh VERIFY, with provider disabled and exactly:

model_calls = 0

D34 — resource exhaustion does not trigger model

Exhaust decomposition/diagnosis/conformance budget with provider fallback configured but not explicitly selected. Assert no model/provider call occurs automatically.


Concrete canonical deltas

#401

Mark D complete and reconcile Depth 4 as:

A PIF  — reusable know-how roles
B MEPP — epistemic/reactive/temporal policy semantics
C PIFF — heterogeneous procedure contracts/bridges
D DPEC — demanded incremental execution + reference/differential conformance

Depth 4 becomes DESIGN-COMPLETE, IMPLEMENTATION-UNPROVEN.

#379 Planner/Coordinator

Add DPEC as the computational realization of procedure selection/decomposition:

  • demanded method indexes before decomposition;
  • packed AND/OR task-decomposition structure;
  • explicit hierarchy-cycle/search-completeness status;
  • PSC/host-projection conformance before #288 admission;
  • live temporal/resource/concurrency admission;
  • dependency-directed projection invalidation;
  • no global optimal reordering requirement;
  • structured resource_limited rather than arbitrary first result.

#377 Expert Runtime

Expert registry generation and goal-contract compatibility become dependencies of host projections. Registry changes invalidate only projections that depended on changed contracts. Physical expert concurrency must not alter normalized result ordering/receipts.

#385 Diagnosis/Repair

Diagnosis state is query/run-local, bounded and incrementally reusable; parallel conflict/hitting-set computation is allowed through the existing runtime but normalized results are deterministic. Repair strategy is explicitly typed by repair problem definition/layer; successful repair still does not prove diagnosis.

#387 Integration

Add a Depth-4 D heterogeneous zero-model fixture plus replay differentials:

cold == warm == rebuilt
incremental == full
recorded trace replay == original normalized outcome

and require one-scheduler instrumentation.

#395 conformance

Procedure adapter differential lanes should reuse the general conformance philosophy: positive preservation invariants + forbidden semantic collapses, with reference traces for supported PIFF profiles.

symbolic-memory #6

Persist immutable native procedure/PSC/bridge/mapping versions and execution/case/VERIFY lineage needed for historical explanation. DPEC indexes, packed forests, applicability caches, monitor state and native-validator caches remain rebuildable derived state. A completed run/case may persist a compact replay receipt, never ambient executable authority.

symbolic-memory #7

Procedure queries should be able to return represented/compatible/projectable/bound/currently admissible, plus declared guarantee/loss/profile and current evidence dependencies. Querying “how do I do X?” does not imply host-executable permission.


Unresolved questions handed forward

Depth 4 intentionally leaves these unresolved rather than pretending implementation evidence exists:

  1. exact first HTN/HDDL fragment and verification algorithm;
  2. whether hierarchy-cycle normalization from current HTN research is practical for the chosen method representation;
  3. exact packed decomposition representation (custom DAG vs solver-backed alternatives);
  4. empirical threshold where dedicated Rete matching beats SWI indexing/tabling;
  5. exact temporal/resource constraint solver and VAL interoperability strategy;
  6. exact supported BT profile and whether BehaviorTree.CPP becomes a test-only differential dependency or fixtures implement a small independent reference semantics;
  7. exact BPMN/workflow subset and Petri-net validator implementation;
  8. restricted Golog/ConGolog reference semantics and concurrency subset;
  9. optimal fingerprint granularity for host projection/interface invalidation;
  10. whether #288 needs first-class live temporal/resource monitor hooks or can consume monitor events entirely through graph generations;
  11. trace retention policy/size thresholds for exact replay versus compact semantic replay;
  12. benchmark-derived defaults for all DPEC structural budgets;
  13. distributed/multi-process execution remains primarily Depth 5 durable-world-model/runtime integration territory;
  14. learned procedure/method promotion remains Depth 7/#404.

D conclusion

Depth 4's computational architecture is coherent only if procedural knowledge remains immutable/native, execution projections are demanded/versioned/derived, #288 remains the only scheduler, and correctness is checked against formalism-specific reference semantics rather than planner self-report.

The design is now ready to be reconciled as Depth-4 design-complete. That is not implementation and not Machine Spirit acceptance.

## Machine Spirit Depth 4D — computational realization / scaling / conformance This is **subpass D only**. It closes the Depth-4 research sequence only after reconciling A/B/C with the computational conclusions below. It does **not** establish implementation or Machine Spirit acceptance. ## Research questions / scope Depth 4A/B/C established PIF + MEPP + PIFF: reusable HTN-like procedural know-how, epistemic/reactive monitoring, and non-flattening interoperability through PSCs. D asks the computational questions A/B/C intentionally left open: 1. How do we select only the procedures/methods/bridges relevant to a current goal instead of materializing a universal executable workflow graph? 2. How do method applicability, epistemic guards, PSC compatibility, host bindings, expert availability, authority state and runtime observations invalidate incrementally? 3. How do we retain contingent/reactive alternatives without a Cartesian product of HTN decompositions × BT states × workflow markings × Golog situations × temporal/resource alternatives? 4. What is the executable boundary between reusable procedure semantics and the existing #288 scheduler? 5. How do temporal/resource/concurrency constraints get validated without assuming that lack of a dependency edge means safe parallelism? 6. How do diagnosis/case/procedure indexes remain bounded and deterministic? 7. How can supported cross-formalism adapters be tested against independent/reference semantics rather than merely checking that a projected run terminated? 8. What exact trace is sufficient to replay concurrent/reactive execution deterministically? 9. What complexity/resource limits are structural, and what must happen when they are exceeded? 10. How do already-known procedures and expert cooperation execute with `model_calls = 0`? ## Current repository state inspected The live repository already has a strong runtime boundary that D must preserve. `prolog/rlm_plan_graph.pl` currently parses/normalizes/validates a closed inert graph; checks IDs/dependencies/cycles/op vocabulary/capabilities/aggregate budgets; computes ready nodes; delegates each admitted step through `rlm_plan`; preserves cancellation as cancellation rather than ordinary failure; and keeps D6-11 plan-native operations separate from expert mapping. The module explicitly says `rlm_plan` remains the **only step executor** and that model/project data never becomes a callable goal. That means D should not invent a new procedure scheduler or native BT/BPMN/Golog executor. It should compile/admit/monitor procedural semantics *into* the existing runtime. Canonical constraints from #376/#377/#379/#384/#385/#387 also survive: one scheduler, one capability/authority/effect boundary, Frozen SPEC immutability, VERIFY as the only final success boundary, structured expert outcomes, bounded recursion/work/cancellation, diagnosis separated from repair, and zero-model local expert execution. --- # Primary / authoritative sources inspected ## HTN verification, search and recursion - Mohammad Yousefi, Mario Schmautz, Patrik Haslum, Pascal Bercher, **“How Good is Perfect? On the Incompleteness of A* for Total-Order HTN Planning”**, ICAPS 2025, published 2025-09-16, DOI `10.1609/icaps.v35i1.36107`: https://ojs.aaai.org/index.php/ICAPS/article/view/36107 . Even totally ordered HTN planning can make A* incomplete because hierarchy-induced cycles interact badly with tree/graph search; the paper gives a polynomial cycle test and a semantics-preserving normal-form direction. This means `depth_limit` alone is not a correctness story for recursive methods. - Pascal Lauer, Songtuan Lin, Pascal Bercher, **“Tight Bounds for Lifted HTN Plan Verification and Bounded Plan Existence”**, ICAPS 2025, published 2025-09-16, DOI `10.1609/icaps.v35i1.36102`: https://ojs.aaai.org/index.php/ICAPS/article/view/36102 . Verification/bounded existence complexity depends materially on method ordering/decomposition restrictions, and lifted verification can avoid unnecessary grounding. - Songtuan Lin, Conny Olz, Malte Helmert, Pascal Bercher, **“On the Computational Complexity of Plan Verification, (Bounded) Plan-Optimality Verification, and Bounded Plan Existence”**, AAAI 2024, published 2024-03-24, DOI `10.1609/aaai.v38i18.30000`: https://ojs.aaai.org/index.php/AAAI/article/view/30000 . Verification can itself be nontrivial/NP-hard in HTN fragments; D therefore needs declared supported verification profiles rather than promising cheap universal validation. - Victor Scherer Putrich, Felipe Meneguzzi, André Grahl Pereira, **“Landmark Generation in HTN Planning Revisited”**, ICAPS 2025, published 2025-09-16, DOI `10.1609/icaps.v35i1.36123`: https://ojs.aaai.org/index.php/ICAPS/article/view/36123 . Sound (though incomplete) AND/OR hierarchical landmarks provide cheap demanded relevance/pruning without pretending to solve full plan existence. - Paul Zaidins, Robert Goldman, Ugur Kuter, Dana Nau, Mark Roberts, **“HTN Plan Repair Algorithms Compared: Strengths and Weaknesses of Different Methods”**, ICAPS 2025, published 2025-09-16, DOI `10.1609/icaps.v35i1.36131`: https://ojs.aaai.org/index.php/ICAPS/article/view/36131 . SHOPFIXER/IPYHOPPER/REWRITE embody different repair problem definitions/search spaces. This directly supports B's distinction among continuation repair, plan repair, method reselection and reusable-method defect. ## Partial order / concurrency - Meysam Aghighi, Christer Bäckström, **“Plan Reordering and Parallel Execution — A Parameterized Complexity View”**, AAAI 2017, DOI `10.1609/aaai.v31i1.11025`: https://ojs.aaai.org/index.php/AAAI/article/view/11025 . Minimum deordering/reordering and minimum parallel execution length are NP-complete; several parameterizations remain hard. - Harrison Oates, Pascal Bercher, **“Makespan Investigations of Sequential, Parallel, PO, and POCL Plans”**, AAAI 2026, published 2026-03-14, DOI `10.1609/aaai.v40i43.40953`: https://ojs.aaai.org/index.php/AAAI/article/view/40953 . Sequential/parallel/PO/POCL plan representations are not freely interchangeable; conversion asymmetries and NP-complete optimal representation results kill the assumption that concurrency can be normalized to one generic ordering model. ## Temporal plan validation - Maria Fox, Derek Long, **“PDDL2.1: An Extension to PDDL for Expressing Temporal Planning Domains”**, JAIR 20, 2003. PDDL2.1 defines durative actions, temporal conditions/effects and numeric/resource semantics. Canonical article: https://www.jair.org/index.php/jair/article/view/10321 . - Richard Howey, Derek Long, Maria Fox, **“VAL: Automatic Plan Validation, Continuous Effects and Mixed Initiative Planning Using PDDL”**, 2004. VAL provides an independent validator for advanced PDDL2.1 plans rather than trusting the planner's own execution story. This is the correct precedent for PIFF adapter conformance. ## Behavior Trees - **BehaviorTree.CPP official documentation**, current 2026-09-05: https://www.behaviortree.dev/ and https://behaviortree.dev/docs/guides/asynchronous_nodes/ . Async actions may return `RUNNING`; they must remain haltable, and reactive control can interrupt them. Official Fallback/ReactiveFallback semantics also distinguish “tick same child again” from restarting the control node: https://www.behaviortree.dev/docs/3.8/nodes-library/FallbackNode/ . D therefore must validate observable BT lifecycle/trace semantics, not flatten statuses to Boolean success/failure. - Michele Colledanchise, Petter Ögren, **Behavior Trees in Robotics and AI: An Introduction**, 2018/2019, arXiv/book: https://arxiv.org/abs/1709.00084 . Provides formal state-space/safety/robustness analysis useful for defining restricted reference semantics. ## Workflow nets / process validation - Wil van der Aalst, **“Verification of Workflow Nets”**, 1997. Workflow-net/Petri-net semantics make soundness amenable to formal analysis; later workflow-net work classifies soundness notions and their decidability. A useful bibliographic/source entry is https://research.tue.nl/en/publications/verification/ . The important computational lesson is that restricted workflow-net soundness is decidable, while richer workflow extensions can cross into undecidable territory. ## Diagnosis - Dietmar Jannach, Thomas Schmitz, Kostyantyn Shchekotykhin, **“Parallelized Hitting Set Computation for Model-Based Diagnosis”**, AAAI 2015, DOI `10.1609/aaai.v29i1.9389`: https://ojs.aaai.org/index.php/AAAI/article/view/9389 . Hitting-set diagnosis can exploit parallel tree construction without losing diagnoses, but remains combinatorial. - Patrick Rodler, Manuel Herold, **“StaticHS: A Variant of Reiter’s Hitting Set Tree for Efficient Sequential Diagnosis”**, SoCS, DOI `10.1609/socs.v9i1.18449`: https://ojs.aaai.org/index.php/SOCS/article/view/18449 . Sequential diagnosis can avoid wasteful recomputation/measurement choices under useful assumptions; diagnosis state should be query-local and incrementally reusable, not globally enumerated. ## Deterministic replay under concurrency - Lars Tveito, Einar Broch Johnsen, Martin Schlatte, **“Global Reproducibility Through Local Control for Distributed Active Objects”**, FASE 2020: https://link.springer.com/chapter/10.1007/978-3-030-45234-6_7 . Recording interactions/local transitions at stable states can be sufficient for globally reproducible replay while still allowing replay-time parallelism. The lesson for #288 is to persist semantically relevant nondeterministic interaction/scheduling choices, not every CPU interleaving. --- # Candidate architecture 1 — eager universal executable materialization Compile every admitted method, imported workflow and native formalism into a persistent universal executable graph. Precompute all method applicability, bridge combinations, temporal/resource alternatives and expert bindings. ### Strengths - fast lookup if the exact execution context matches the materialization; - simple mental model for hosts; - straightforward graph visualization. ### Failure modes - host binding, authority, resource leases, current evidence and expert registry are live state, so persistent executable materialization becomes stale quickly; - HTN alternatives × reactive states × workflow markings × temporal branches cause combinatorial materialization; - flattening foreign formalisms to one graph loses semantics already preserved by C; - replacing one mapping/adapter can invalidate huge swaths even when observable behavior is unchanged; - durable executable graphs blur reusable method identity and run-specific plan identity. **Reject as canonical architecture.** A persistent cache may exist, but it must be derived, fingerprinted and demand-driven. --- # Candidate architecture 2 — polyglot native runtime federation Run HTN, Golog/ConGolog, BehaviorTree.CPP and BPMN engines natively and federate them at runtime. ### Strengths - high native semantic fidelity; - existing mature runtimes can execute their own constructs directly; - less translation work for some formalisms. ### Failure modes - creates multiple schedulers/cancellation models and effect dispatch paths; - makes capability/authority admission inconsistent across engines; - replay becomes a federation of unrelated scheduler traces; - native workflow roles/actions risk being confused with local principals/capabilities; - violates #376/#288's one-runtime rule. **Reject as ambient execution architecture.** Native implementations are still valuable as **reference validators / differential conformance oracles** for supported subsets. --- # Candidate architecture 3 — preferred: DPEC Adopt a **Demand-Driven Procedural Execution & Conformance Graph (DPEC)**. DPEC is a derived compiler/admission/monitoring graph over PIF + MEPP + PIFF. It selects only the relevant procedural slice, keeps alternatives packed, produces a host-specific execution projection, validates that projection against the selected procedural semantic profile, and compiles admitted primitive work into the existing #288 plan graph. ```text Frozen goal / current epistemic frontier ↓ demanded procedure slice method index / case candidate / PSC bridge ↓ packed decomposition forest AND/OR method alternatives + guards + constraints ↓ host projection / binding compatibility capability availability + authority preflight temporal/resource/concurrency validation ↓ reference-profile conformance receipt ↓ admitted #288 graph ↓ one canonical scheduler/runtime ↓ incremental monitors / observations ↓ threat-directed continuation/plan/method repair ↓ fresh #384 VERIFY ``` DPEC is **not another scheduler**. It is derived planning/admission state plus conformance/replay metadata. --- # DPEC typed symbolic model Conceptual records; exact names follow implementation conventions. ```prolog proc_exec_key(Key, GoalSignature, ProcedureVersionSet, PSCVersionSet, BridgeVersionSet, HostProfile, BindingGeneration, ExpertRegistryGeneration, EpistemicFrontier, ResourcePolicyVersion, AuthorityPolicyVersion). proc_candidate(CandidateId, GoalRef, MethodOrArtifactRef, ApplicabilityStatus, GuardDeps, CostClass, Provenance). proc_choice(NodeId, Kind, Children, GuardRefs, ConstraintRefs). % Kind = and | or | sequence | partial_order | observation_branch | recovery proc_host_projection(ProjectionId, NativeArtifactRef, PSCRef, BridgeRefs, HostProfile, BindingRefs, ObservableInterface, Guarantee, LossProfile, Fingerprint). proc_monitor(MonitorId, ProjectionId, Kind, ConditionRef, DependencyRefs, FailureClass, RepairLayer). proc_trace_event(EventId, RunId, FrontierId, EventClass, SubjectRef, ObservedOutcome, OrderingKey, EvidenceRefs). proc_conformance_receipt(ReceiptId, NativeProfile, ProjectionRef, Relation, ComparedTraceRefs, PreservedProperties, DeclaredLosses, Status). ``` Important: `proc_host_projection` is derived state. Native procedure/PSC identity remains immutable semantic knowledge. Host bindings remain trusted host configuration/runtime data, not persisted executable authority in the semantic ledger. --- # 1. Demanded method / bridge / expert selection Index procedural knowledge by coarse symbolic signatures before expensive reasoning: ```text goal/task type formalism/profile method head / action class required observation classes guard dimensions required effect classes required resource kinds PSC input/output/observation signature host compatibility ``` Selection pipeline: ```text exact/specific method index ↓ cheap profile/host incompatibility pruning ↓ epistemic guard evaluation ↓ PSC/bridge compatibility ↓ expert goal-contract availability ↓ case candidates / bounded operator gap search only if needed ``` Do **not** globally evaluate every guard or every PSC mapping after each world-model update. Record exact dependencies used by each candidate/admission decision. Production-rule/Rete-like caching may optimize large local applicability sets, but it remains derived cache state; Prolog indexing/tabling is the default implementation direction unless benchmarks justify a dedicated Rete network. --- # 2. Packed decomposition instead of complete-plan enumeration Method alternatives form a shared AND/OR decomposition DAG/forest: ```text OR = alternative methods / contingent branches AND = required subtasks / independent constraint sets GUARD = epistemic/observation condition LINK = partial-order / causal / resource / temporal relation NOGOOD = known incompatible choice combination ``` Identical subtask/decomposition signatures may share nodes when their context/assumption fingerprints match. Use sound hierarchical landmarks and inevitable-refinement/look-ahead techniques for pruning where applicable, but **never interpret an incomplete landmark heuristic as completeness proof**. ### Recursive/cyclic methods The 2025 A* incompleteness result makes this a hard D invariant: ```text recursive method detected != simply “allow until max_depth” ``` Before search/admission, classify decomposition cycles under the selected HTN/profile semantics. For fragments where a known cycle test/normalization guarantees termination/completeness, use it. Otherwise the result must explicitly carry one of: ```text cyclic_supported_under_profile cyclic_requires_runtime_bound cyclic_search_incomplete resource_limited unsupported ``` A depth/work limit is a safety mechanism, not a proof that the search semantics were complete. --- # 3. Incremental applicability / projection invalidation DPEC records dependency edges equivalent to: ```text native procedure/version ↓ PSC/version ↓ bridge/mapping/version ↓ host projection ↓ applicability / guard decisions ↓ packed decomposition fragment ↓ #288 plan generation ↓ runtime monitor obligations ↓ diagnosis / case outcome index ``` Other invalidators include: ```text epistemic frontier / known_at / valid_at host binding generation expert registry generation capability availability authority policy generation resource/lease state current project/source generation ``` Invalidation follows actual dependency closure. If recomputation yields the **same observable host-projection/interface digest**, propagation stops there. This is the same useful principle Depth 2/3 discovered for semantic/epistemic computation, but applied to procedure semantics rather than copied blindly: internal native-artifact changes are allowed to be invisible downstream only when the selected PSC/profile proves the relevant observable interface unchanged. --- # 4. Concurrency / temporal / resource admission Absence of a task-order edge is **not proof of safe concurrency**. Before two ready tasks may overlap, the selected procedural profile must admit concurrency after considering at least: ```text causal/precondition threats write/effect-set interference resource capacity / exclusive leases durative invariants temporal windows/deadlines authority/capability interaction constraints explicit formalism concurrency semantics ``` DPEC preserves source partial ordering rather than globally optimizing it. Optional bounded reordering/deordering may be a separate optimization because exact minimization/reordering/parallel length is NP-hard in general. The result is a **validated partial order + live constraints**, not a promise that a missing edge always means parallel-safe. --- # 5. Runtime monitoring without another interpreter Compile MEPP semantics into monitor obligations attached to #288 execution state: ```text hard guard monitor observation gate branch discriminator resource lease monitor deadline/temporal invariant causal-link threat monitor async lifecycle/cancellation monitor success-condition observation request ``` A monitor consumes structured observations/events and emits a typed delta: ```text unchanged branch_enabled branch_disabled invariant_threatened invariant_violated resource_invalidated authority_changed exogenous_event needs_observation needs_plan_repair needs_method_reselection ``` It does not itself schedule work. Planner/Repair turns a valid delta into a #288 graph revision/generation. Predicted effects remain predictions; they never satisfy VERIFY. --- # 6. Formalism-specific reference / differential conformance A single `plan finished` test is inadequate. Each supported PIFF adapter must declare a **reference profile** and a comparison relation. Candidate relation classes: ```text exact_trace trace_refinement stuttering_equivalent preserves_terminal_status preserves_safety_property preserves_guarantee_under(Assumptions) declared_lossy noncomposable ``` Required initial conformance lanes: ### HTN/HDDL restricted subset Validate that selected primitive plan/task decomposition is admitted by the original task/method network under the declared bounded profile. Prefer lifted verification where practical instead of grounding the entire method library. ### PDDL2.1 temporal subset Cross-check temporal/resource/invariant behavior against an independent VAL-like reference validator on fixtures. Planner/projection output cannot self-certify temporal validity. ### Behavior Tree subset Reference traces preserve `SUCCESS/FAILURE/RUNNING`, reactive-vs-memoryful fallback semantics, async start/poll/halt and bounded retry/decorator behavior. A projected #288 trace that maps `RUNNING` to failure is a conformance failure even if the final task eventually succeeded. ### Workflow/BPMN restricted subset For supported workflow patterns, use token/Petri-net-style reference semantics and soundness/termination checks where the chosen subset permits them. Cancellation, compensation, transactions or richer constructs that lack a proven adapter are `preservation_only`, `lossy`, or `noncomposable`, not silently ignored. ### Golog/ConGolog restricted subset Use an explicit small-step/trace oracle for the subset actually claimed by the adapter: tests, sequence, nondeterministic choice, iteration, concurrency/interrupt/exogenous actions only where semantics are implemented. No universal Golog equivalence claim. Adapter upgrade = new mapping/projection generation + rerun relevant conformance; never rewrite old projection history. --- # 7. Cancellation and deterministic replay Cancellation is a first-class trace event, not failure and not implicit retry authorization. For any running async action: ```text cancel requested -> no new child/effect dispatch -> propagate canonical cancellation token -> request adapter/handler halt where supported -> observe halt/indeterminate outcome -> preserve effect uncertainty where cancellation races an external side effect ``` DPEC replay modes should distinguish: ```text exact_trace_replay reuse retained observations/effect outcomes + nondeterministic interaction decisions deterministic_reexecution rerun deterministic admitted operations under same canonical inputs; normalized trace must match semantic_reexecution environment/external nondeterminism allowed; creates new run lineage, not “exact replay” ``` The concurrent replay literature suggests recording **stable-state interaction/scheduling choices** is enough to reproduce semantic outcomes without serializing every internal CPU step. For #288, a replay receipt should therefore bind at least: ```text Frozen SPEC fingerprint procedure/method/native artifact versions PSC/bridge/binding versions host/expert registry generation plan/replan generations frontier-ready sets actual dispatch/interaction ordering where nondeterministic and material observed external/effect outcomes cancellation events resource/authority decisions verification evidence refs budgets/policy versions ``` Replay may execute independent deterministic work in parallel, but normalized semantic outcome/receipt must be invariant to harmless scheduler interleavings. --- # 8. Bounded diagnosis / discriminator / CBR state Global enumeration is forbidden by default. ### Diagnosis Maintain query/run-local conflict/hypothesis structure. Use incremental conflict reuse and bounded hitting-set/dual search. Parallel branches may use the existing runtime, but canonical results are normalized independently of thread completion order. Bounds include: ```text max conflicts max diagnosis cardinality max live diagnoses max discriminator candidates max measurements/tests max diagnosis work ``` Exhaustion returns unresolved/resource-limited diagnosis, not the first hypothesis found. ### CBR Two-stage candidate generation: 1. hard symbolic compatibility/contraindication filters; 2. bounded similarity ranking over survivors (symbolic/indexed, optional ANN/vector sensor). A case result is still only an adaptation candidate. Cache keys include case corpus generation + compatibility policy + goal/context signature. --- # 9. Explicit structural budgets / failure behavior DPEC needs first-class budgets for at least: ```text selected procedure artifacts method candidates per compound task decomposition nodes / OR alternatives method recursion depth + cycle/SCC work PSC/bridge candidates host projection bytes/states active observation branches temporal constraints / numeric resource vars ready frontier width / active async actions monitor count/events case candidates diagnostic conflicts/live diagnoses reference-validator work trace/receipt bytes CPU / wall / memory provider calls (must remain 0 for known symbolic fixtures) ``` Canonical exhaustion: ```prolog resource_limited(Dimension, Used, Limit, PartialReceipt) ``` Never: ```text budget ran out -> choose first method budget ran out -> declare unknown as false budget ran out -> silently ask an LLM ``` An explicitly configured fallback may be proposed *after* a structured unsupported/resource-limited result, but that is a new metered fallback event and cannot strengthen guarantees by fiat. --- # Complexity / performance implications 1. **Do not promise complete unrestricted HTN search.** Even decidable total-order HTN search has non-obvious incompleteness traps under common algorithms; expressive planning can cross into very high complexity/undecidability. Advertise supported fragments/profile guarantees. 2. **Verification is cheaper than unrestricted generation only in useful fragments.** Keep known-method-first and validate a small admitted projection instead of searching the entire procedural theory. 3. **Keep representations lifted/packed.** Ground only demanded bindings. The 2025 HTN verification work explicitly supports the value of lifted representations. 4. **Partial order is a compact execution contract.** One partial-order node can stand for many linearizations, but optimal reordering/deordering remains expensive. Preserve source order constraints and optimize only under explicit bounded policy. 5. **Reactive state is interface-factored.** Do not cross-product every native internal state. Carry only bridge/host-visible control state unless a validator needs deeper state. 6. **Diagnosis/case reasoning is top-k/query-local.** Complete enumeration is a conformance mode for small fixtures, not the production default. 7. **Incremental invalidation is the main scaling lever.** A changed guard observation should not rebuild an unrelated method library; an adapter upgrade should not re-run source parsing; a registry change should not invalidate procedures that do not depend on the changed expert contract. --- # Epistemic / provenance implications DPEC decisions are derived from the exact epistemic frontier they consumed. A host projection/admission receipt must preserve: ```text which evidence made guards satisfied/unknown/conflicted which procedure/PSC/bridge versions were used which assumptions/fairness conditions were admitted which host bindings/expert contracts were selected which losses/guarantee weakenings occurred which resource/authority policy versions were checked which observations changed the execution frontier ``` Changing evidence does not mutate historical decisions. It creates a new execution/projection generation. A successful run is an episodic case with exact procedural/execution/VERIFY provenance. It does not auto-promote a method; #404 remains the promotion boundary. --- # Safety / authority implications Hard invariants surviving D: ```text represented procedure != executable projection compatible procedure != locally bound procedure locally bound != capability granted authority preflight success != future authority forever predicted effect != observed effect adapter conformance != host authority case similarity != permission repair candidate != effect admission method success != Frozen-SPEC success ``` Authority/resource validity is checked again at the point where an admitted step would dispatch. Cached authority decisions cannot grant stale authority. Host binding lookup is by trusted IDs/contracts, never by lexical equality with source action/role names. --- # Rejected alternatives 1. **Eager universal executable graph:** rejected for stale live-state assumptions, Cartesian blow-up and semantic flattening. 2. **Polyglot native runtime federation:** rejected as ambient architecture because it creates multiple schedulers/cancellation/effect paths; retained only for reference validation where useful. 3. **One universal Golog interpreter:** rejected from C and still rejected; expressive target semantics do not prove source-language preservation and would duplicate runtime authority. 4. **One Boolean status vocabulary:** rejected; BT `RUNNING`, epistemic `unknown/conflicted`, policy `blocked`, cancellation and failure remain distinct. 5. **Global optimal reordering/makespan:** rejected as normal execution path; computationally hard and semantics-dependent. 6. **Depth-limit-as-cycle-correctness:** rejected by current HTN results. Bounds are safety, not completeness proofs. 7. **Planner self-validation:** rejected; supported adapters require independent/reference differential semantics and final task success still belongs to #384 VERIFY. 8. **Persist all Rete/search/diagnosis state as truth:** rejected; these are rebuildable execution indexes/caches. 9. **Fallback to LLM on resource exhaustion:** rejected; failure is explicit unless an independently configured fallback policy starts a new metered event. --- # Falsifiable D conformance fixtures ### D1 — demanded method pruning 100 unrelated procedures + 2 matching goal signatures. Assert only relevant candidates/bridge dependencies are evaluated. ### D2 — guard-local invalidation Change evidence for one guard. Assert only candidates/monitor nodes depending on that guard recompute. ### D3 — unchanged-interface stop Upgrade a native artifact internally while PSC-visible host behavior stays identical. Assert downstream projection/plan invalidation stops at the stable interface digest. ### D4 — bridge/mapping upgrade Same procedure, new PIFF bridge version. New projection lineage must be created; historical projection remains reproducible. ### D5 — expert registry upgrade isolation Change unrelated expert contract. Procedure projections without that goal contract remain cache hits. ### D6 — recursive HTN cycle classification Fixture containing hierarchy-induced recursion. Assert cycle class/declared search guarantee is explicit; depth exhaustion cannot masquerade as “no plan”. ### D7 — packed alternative bound Large method-OR tree. Assert shared decomposition stays within node budget or returns `resource_limited`; no top-1 silent selection. ### D8 — lifted verification Bounded HTN fixture verifies without eagerly grounding the entire method library; result agrees with a clean reference verification. ### D9 — partial-order preservation Two independent tasks remain unordered through projection; no arbitrary total-order fingerprint becomes canonical semantics. ### D10 — unsafe-concurrency rejection No explicit dependency edge but shared exclusive resource/effect conflict exists. Assert overlap is rejected. ### D11 — safe-concurrency determinism Two independent ready steps execute in either physical interleaving. Normalized semantic result/receipt is identical. ### D12 — temporal invariant violation Durative task starts validly, exogenous observation violates invariant. Monitor must stop/repair appropriately; predicted completion cannot satisfy success. ### D13 — deadline drift Plan was valid at projection time but execution delay crosses deadline. Live validation blocks/stales the step rather than trusting cached admission. ### D14 — resource lease invalidation Lease disappears after plan construction. Dispatch is blocked/replanned; cached resource assumption is not authority. ### D15 — BT `RUNNING` preservation Reference BT emits `RUNNING -> RUNNING -> SUCCESS`. #288 projection must not emit failure/cancel/retry semantics during RUNNING. ### D16 — ReactiveFallback interruption Earlier condition changes while async child is RUNNING. Projected trace must halt/interupt the child and restart according to declared reactive semantics. ### D17 — PDDL2.1 validator differential Temporal/resource fixture projected to #288. Compare normalized projection trace/interval constraints against independent VAL-like reference. Any undeclared invariant/resource difference fails. ### D18 — workflow token/join semantics Restricted parallel split/join workflow. Reference token semantics and projected observable completion must agree; premature join completion fails. ### D19 — unsupported BPMN compensation Adapter lacking compensation semantics must return preservation-only/noncomposable; it cannot drop compensation and produce executable projection. ### D20 — Golog nondeterministic-choice preservation Reference admits alternatives A/B; projection must preserve allowed alternatives/declared refinement, not fabricate deterministic equivalence. ### D21 — cancellation before dispatch Cancel while nodes are ready but not dispatched. Assert zero later expert/tool/effect dispatch. ### D22 — cancellation race with external effect Effect dispatch occurred before cancellation acknowledgment. Outcome remains observed/indeterminate according to effect ledger; cannot be rewritten as clean cancellation. ### D23 — exact trace replay Retain interaction/frontier/effect observations, destroy rebuildable DPEC caches, replay. Normalized trace/result/receipt must match. ### D24 — warm/cold/cache-rebuilt equivalence Same procedure/evidence/host/profile inputs: cold == warm-cache == cache-rebuilt under normalized comparison. ### D25 — incremental/full equivalence After one evidence/method change, incrementally maintained projection/result must equal fresh full demanded recomputation for the same canonical inputs. ### D26 — diagnosis bound Combinatorial multi-fault fixture hits live-diagnosis ceiling. Result is `resource_limited`, never arbitrary first diagnosis. ### D27 — diagnosis parallel determinism Parallel hitting-set/conflict work may complete in different physical order; normalized bounded diagnosis set/ordering/receipt remains deterministic. ### D28 — CBR contraindication before similarity Near-neighbor case violates hard host/version/authority precondition. It is rejected before adaptation regardless of similarity score. ### D29 — stale host binding Host action binding generation changes after projection. Old projection is stale/unbound; semantic procedure remains intact. ### D30 — authority recheck Authority was admitted during planning then revoked. Step cannot dispatch from cached approval. ### D31 — adapter trace proof receipt Every executable heterogeneous projection carries formalism/profile/version + comparison relation + preserved properties + declared losses. ### D32 — one-scheduler enforcement Instrument execution. All executable task dispatch must pass through #288/`rlm_plan`; no native procedural runtime starts an independent scheduler. ### D33 — zero-model heterogeneous cooperation Known procedure combines at least two procedure/formalism adapter paths and multiple Prolog experts, includes one observation branch and one repair/monitor path, reaches fresh VERIFY, with provider disabled and exactly: ```text model_calls = 0 ``` ### D34 — resource exhaustion does not trigger model Exhaust decomposition/diagnosis/conformance budget with provider fallback configured but not explicitly selected. Assert no model/provider call occurs automatically. --- # Concrete canonical deltas ## #401 Mark D complete and reconcile Depth 4 as: ```text A PIF — reusable know-how roles B MEPP — epistemic/reactive/temporal policy semantics C PIFF — heterogeneous procedure contracts/bridges D DPEC — demanded incremental execution + reference/differential conformance ``` Depth 4 becomes **DESIGN-COMPLETE, IMPLEMENTATION-UNPROVEN**. ## #379 Planner/Coordinator Add DPEC as the computational realization of procedure selection/decomposition: - demanded method indexes before decomposition; - packed AND/OR task-decomposition structure; - explicit hierarchy-cycle/search-completeness status; - PSC/host-projection conformance before #288 admission; - live temporal/resource/concurrency admission; - dependency-directed projection invalidation; - no global optimal reordering requirement; - structured `resource_limited` rather than arbitrary first result. ## #377 Expert Runtime Expert registry generation and goal-contract compatibility become dependencies of host projections. Registry changes invalidate only projections that depended on changed contracts. Physical expert concurrency must not alter normalized result ordering/receipts. ## #385 Diagnosis/Repair Diagnosis state is query/run-local, bounded and incrementally reusable; parallel conflict/hitting-set computation is allowed through the existing runtime but normalized results are deterministic. Repair strategy is explicitly typed by repair problem definition/layer; successful repair still does not prove diagnosis. ## #387 Integration Add a Depth-4 D heterogeneous zero-model fixture plus replay differentials: ```text cold == warm == rebuilt incremental == full recorded trace replay == original normalized outcome ``` and require one-scheduler instrumentation. ## #395 conformance Procedure adapter differential lanes should reuse the general conformance philosophy: positive preservation invariants + forbidden semantic collapses, with reference traces for supported PIFF profiles. ## symbolic-memory #6 Persist immutable native procedure/PSC/bridge/mapping versions and execution/case/VERIFY lineage needed for historical explanation. DPEC indexes, packed forests, applicability caches, monitor state and native-validator caches remain rebuildable derived state. A completed run/case may persist a compact replay receipt, never ambient executable authority. ## symbolic-memory #7 Procedure queries should be able to return `represented/compatible/projectable/bound/currently admissible`, plus declared guarantee/loss/profile and current evidence dependencies. Querying “how do I do X?” does not imply host-executable permission. --- # Unresolved questions handed forward Depth 4 intentionally leaves these unresolved rather than pretending implementation evidence exists: 1. exact first HTN/HDDL fragment and verification algorithm; 2. whether hierarchy-cycle normalization from current HTN research is practical for the chosen method representation; 3. exact packed decomposition representation (custom DAG vs solver-backed alternatives); 4. empirical threshold where dedicated Rete matching beats SWI indexing/tabling; 5. exact temporal/resource constraint solver and VAL interoperability strategy; 6. exact supported BT profile and whether BehaviorTree.CPP becomes a test-only differential dependency or fixtures implement a small independent reference semantics; 7. exact BPMN/workflow subset and Petri-net validator implementation; 8. restricted Golog/ConGolog reference semantics and concurrency subset; 9. optimal fingerprint granularity for host projection/interface invalidation; 10. whether #288 needs first-class live temporal/resource monitor hooks or can consume monitor events entirely through graph generations; 11. trace retention policy/size thresholds for exact replay versus compact semantic replay; 12. benchmark-derived defaults for all DPEC structural budgets; 13. distributed/multi-process execution remains primarily Depth 5 durable-world-model/runtime integration territory; 14. learned procedure/method promotion remains Depth 7/#404. ## D conclusion Depth 4's computational architecture is coherent only if **procedural knowledge remains immutable/native, execution projections are demanded/versioned/derived, #288 remains the only scheduler, and correctness is checked against formalism-specific reference semantics rather than planner self-report**. The design is now ready to be reconciled as Depth-4 design-complete. That is **not implementation and not Machine Spirit acceptance**.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
nsaspy/prolog-rlm#397
No description provided.