Add lib_directive: dependency-ordered task orchestration#181
Open
MesTTo wants to merge 3 commits into
Open
Conversation
A non-monotonic + normative reasoner — Defeasible Logic DL(d) (Nute; Antoniou et al.), Standard Deontic Logic (Governatori: O/P/F, F p =def O not-p, contrary-to-duty reparation chains, dilemmas), Event Calculus + the 13 Allen interval relations + temporal deadlines, and weakest-link trust. Complements lib_nal/lib_pln: they grade how much a fact is believed; this decides what defeasibly holds and what one ought to do. Theories and plans are ordinary .metta files read by PeTTa's native loader (no bespoke parser; .dfl arrow syntax also accepted). API: dl-run / dl-run-deontic / dl-run-at, deontic-compliance / deontic-dilemmas, the non-monotonic queries (dl-what-if / dl-why-not / dl-abduce / dl-requires), Event Calculus, and trust. Golden test suite under tests/deontic/. Docs: docs/reference-lib-deontic.md.
The same theory runs through either the fast indexed Prolog kernel or the atomspace-native MeTTa engine (ground.metta / reason.metta) with identical conclusions; select with (dl-engine! native) or $OMEGACLAW_DL_ENGINE=native. Native grounding uses a semi-naive frontier fixpoint. prolog stays the default — native grounding is ~4-5x slower on grounding-heavy theories (per-operation MeTTa-eval overhead, see the perf note in ground.metta), while native is ideal for propositional plans and inspection. Docs: docs/deontic/README.md.
Built on lib_deontic. A plan lists tasks and readiness rules; the defeasible engine derives what is actionable and enforces a claim/complete/block lifecycle in dependency order. Readiness and assignment are defeasible rules, so plans express priority, blocking, and reversible (versioned) claims. Lifecycle actions append (claims supervisor:agent ...) blocks to the plan .metta file, so the file is its own durable, auditable state; blocking propagates through the dependency DAG. Includes a process-mining layer (event-log extraction, Alpha footprint, support/confidence rule learning) and plan inspection. API: directive-next / status / board / summary, directive-claim / complete / unclaim / block / unblock, directive-validate / analyze / trace. Tests: tests/integration/ (directive, analyze, inspect, mining). Docs: docs/reference-lib-directive.md.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #180.
This adds lib_directive, a task orchestrator built on lib_deontic. The idea behind it is that coordinating work is really a defeasible reasoning problem. A plan lists tasks and the rules for when each one becomes ready, and those readiness rules are just defeasible rules over the deontic engine. Working out what can be done right now is then nothing more than running the engine over the plan and reading off the tasks whose dependencies are satisfied. Priority, conditional blocking and reversible claims all fall out of the underlying logic instead of needing special-case code.
The lifecycle of claiming, completing and blocking works by appending blocks to the plan file itself. Each block is versioned and outranks the one before it, so the most recent action wins and remains reversible. That makes the plan file its own durable and auditable state, with nothing kept outside it. Blocking also propagates down the dependency graph, so when a task is blocked everything downstream is marked blocked as well and the work can be rerouted.
There is also a small process-mining layer that recovers an event log from those appended blocks and learns directly-follows rules from it. Tests are under tests/integration and the API is documented in docs/reference-lib-directive.md.