P1 — build an embedded Prolog RLM proof/repair harness for Zara routing #123

New issue

Closed

opened 2026-08-16 02:42:03 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-08-16 02:42:03 +00:00

(Migrated from github.com)

Goal

Build a Zara-owned embedded Prolog RLM/proof-repair harness inside the Zara repository after the full Prolog LLM client (#124) and bounded utterance rewriter (#122) land.

Do not add a runtime dependency on lost-rob0t/prolog-rlm. That repository may be inspected for ideas, tests, and architecture, but Zara must own the implementation it executes.

Routing order

raw utterance
    |
    v
#122 bounded rewriter
    |
    v
existing deterministic Prolog resolver
    |
    +--> resolved --> existing executor
    |
    +--> unresolved / ambiguous / conflicting
              |
              v
       embedded Zara RLM repair/proof harness
              |
              v
      typed candidate + explicit evidence
              |
              v
       Zara independently validates
              |
              v
          execute / clarify / reject

Foundation

The embedded harness must use #124 as its only LLM/provider boundary. It must not implement another HTTP client, provider adapter stack, async worker pool, or streaming protocol.

The first version should remain intentionally bounded: one repair attempt by default, no uncontrolled recursion, no generated arbitrary Prolog source, and no direct execution authority.

Required architecture

Add a narrow module family under Zara, for example:

modules/rlm/
  router.pl
  context.pl
  plan.pl
  validate.pl
  execute.pl
  trace.pl
  budget.pl

Exact names may differ.

Pass only bounded typed context:

original/canonical utterance;
resolver candidates;
registered intent signatures and slot schemas;
relevant capability facts;
selected runtime state required for disambiguation;
explicit request/turn ID;
explicit budget and cancellation context.

The harness may return only a closed result family such as:

accept(Intent, Args, Evidence)
reject(Reason, Evidence)
clarify(Question, Candidates, Evidence)
fallback_chat(Reason, Evidence)

Zara must independently validate intent existence, argument types, capability availability, and side-effect policy after the RLM returns.

Plan language and authority

Use a typed/allow-listed plan vocabulary. No unrestricted call/1 over model-produced terms. No arbitrary generated Prolog source in the default path. No arbitrary filesystem, process, network, MCP, or tool capability merely because the model requested it.

The RLM reasons about routing/proof; it does not become Zara's executor.

Async/cancellation

Use #124's optional async jobs where useful so the RLM does not have to block the caller while waiting for a provider. Preserve Zara's existing TurnCoordinator cancellation/stale-turn semantics. Cancelling a turn must cancel/drain any RLM-associated #124 job and prevent stale results from being applied.

Evidence and trace

Expose bounded explicit evidence such as:

candidate intents considered;
facts/capabilities checked;
validations passed/failed;
plan steps from the allow-listed vocabulary;
rejection/clarification reason;
model/provider usage metadata from #124;
timing/budget metadata.

Do not expose hidden chain-of-thought.

Tests

exact deterministic commands prove RLM is not invoked;
successfully rewritten commands prove RLM is not invoked;
ambiguous fixtures where the RLM selects only among allowed candidates;
unknown intent fixtures where the RLM cannot invent a capability;
malicious plan outputs attempting arbitrary predicates/tools/process/network/filesystem access;
malformed plan and schema mismatch;
sync and async #124 provider modes;
timeout, cancellation, provider failure, budget exhaustion, stale-turn result;
deterministic fake-model tests only in default CI;
comparison corpus for resolver vs rewriter+resolver vs rewriter+resolver+RLM on accuracy, latency, model calls and false-positive execution.

Acceptance criteria

RLM code is embedded in Zara and uses Zara's #124 Prolog client.
No external prolog-rlm runtime dependency exists.
RLM is a repair/proof fallback, never the first authority over raw input.
Every executable result is independently validated after RLM output.
Exact deterministic commands incur no RLM/provider latency.
RLM failure leaves Zara able to clarify/fallback.
No duplicate provider stack, actor runtime, event bus, or executor is introduced.

Dependencies

#124 embedded full-featured Prolog LLM client.
#122 bounded utterance rewriter.
Existing deterministic Prolog resolver/capability registry.

## Goal Build a **Zara-owned embedded Prolog RLM/proof-repair harness inside the Zara repository** after the full Prolog LLM client (#124) and bounded utterance rewriter (#122) land. Do **not** add a runtime dependency on `lost-rob0t/prolog-rlm`. That repository may be inspected for ideas, tests, and architecture, but Zara must own the implementation it executes. ## Routing order ```text raw utterance | v #122 bounded rewriter | v existing deterministic Prolog resolver | +--> resolved --> existing executor | +--> unresolved / ambiguous / conflicting | v embedded Zara RLM repair/proof harness | v typed candidate + explicit evidence | v Zara independently validates | v execute / clarify / reject ``` ## Foundation The embedded harness must use #124 as its only LLM/provider boundary. It must not implement another HTTP client, provider adapter stack, async worker pool, or streaming protocol. The first version should remain intentionally bounded: one repair attempt by default, no uncontrolled recursion, no generated arbitrary Prolog source, and no direct execution authority. ## Required architecture Add a narrow module family under Zara, for example: ```text modules/rlm/ router.pl context.pl plan.pl validate.pl execute.pl trace.pl budget.pl ``` Exact names may differ. Pass only bounded typed context: - original/canonical utterance; - resolver candidates; - registered intent signatures and slot schemas; - relevant capability facts; - selected runtime state required for disambiguation; - explicit request/turn ID; - explicit budget and cancellation context. The harness may return only a closed result family such as: ```prolog accept(Intent, Args, Evidence) reject(Reason, Evidence) clarify(Question, Candidates, Evidence) fallback_chat(Reason, Evidence) ``` Zara must independently validate intent existence, argument types, capability availability, and side-effect policy after the RLM returns. ## Plan language and authority Use a typed/allow-listed plan vocabulary. No unrestricted `call/1` over model-produced terms. No arbitrary generated Prolog source in the default path. No arbitrary filesystem, process, network, MCP, or tool capability merely because the model requested it. The RLM reasons about routing/proof; it does not become Zara's executor. ## Async/cancellation Use #124's optional async jobs where useful so the RLM does not have to block the caller while waiting for a provider. Preserve Zara's existing TurnCoordinator cancellation/stale-turn semantics. Cancelling a turn must cancel/drain any RLM-associated #124 job and prevent stale results from being applied. ## Evidence and trace Expose bounded explicit evidence such as: - candidate intents considered; - facts/capabilities checked; - validations passed/failed; - plan steps from the allow-listed vocabulary; - rejection/clarification reason; - model/provider usage metadata from #124; - timing/budget metadata. Do not expose hidden chain-of-thought. ## Tests - exact deterministic commands prove RLM is not invoked; - successfully rewritten commands prove RLM is not invoked; - ambiguous fixtures where the RLM selects only among allowed candidates; - unknown intent fixtures where the RLM cannot invent a capability; - malicious plan outputs attempting arbitrary predicates/tools/process/network/filesystem access; - malformed plan and schema mismatch; - sync and async #124 provider modes; - timeout, cancellation, provider failure, budget exhaustion, stale-turn result; - deterministic fake-model tests only in default CI; - comparison corpus for resolver vs rewriter+resolver vs rewriter+resolver+RLM on accuracy, latency, model calls and false-positive execution. ## Acceptance criteria - RLM code is embedded in Zara and uses Zara's #124 Prolog client. - No external `prolog-rlm` runtime dependency exists. - RLM is a repair/proof fallback, never the first authority over raw input. - Every executable result is independently validated after RLM output. - Exact deterministic commands incur no RLM/provider latency. - RLM failure leaves Zara able to clarify/fallback. - No duplicate provider stack, actor runtime, event bus, or executor is introduced. ## Dependencies 1. #124 embedded full-featured Prolog LLM client. 2. #122 bounded utterance rewriter. 3. Existing deterministic Prolog resolver/capability registry.