Expert: Beagle KB-guided user-message rewrite engine #17

New issue

Open

opened 2026-08-29 12:50:12 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-08-29 12:50:12 +00:00

(Migrated from github.com)

Parent: #8
Depends on: #10, #12

Goal

Create Beagle, an expert system that rewrites user requests using an advanced symbolic KB built from observed user messages, task context, project facts, classifications, prior corrections and explicit durable rules.

Beagle is not a generic prompt-polisher. It is a provenance-preserving symbolic rewrite engine.

Core contract

Input:

original user message, unchanged
current task/session identity
request-classification assertions
bounded relevant user/project/task facts from Tek9
explicit constraints/preferences already represented in the KB
applicable rewrite rules and rule versions

Output:

proposed rewritten message
preserved constraints list
additions/normalizations performed
rule IDs/versions used
evidence/fact IDs used
confidence/decision state
rewrite_id linked to original message/task

The original message is always retained verbatim.

Modes

`off`

No Beagle evaluation.

`shadow`

Run Beagle, persist proposal/provenance, but send the original request unchanged. This is the initial production mode and is required for dataset/evaluation work.

`apply`

After separate conformance evidence, allow the configured rewrite boundary to submit the rewritten request downstream while retaining both original and rewritten forms in the corpus.

No hidden rewrite mode.

Advanced KB

The KB should support reusable rules/facts such as:

user-specified enduring workflow constraints
project/repository ownership boundaries
preferred tool/execution paths
output/artifact conventions
known ambiguity resolutions
task decomposition conventions
validation/test requirements
model/provider constraints
known failed rewrite patterns
known successful rewrite patterns

Rules should be inspectable/versioned Prolog, backed by Tek9 facts/provenance. Do not convert raw conversation history into unconditional rules.

Rewrite behavior

Beagle may:

resolve references when the KB has grounded identity/context;
make implicit known constraints explicit;
normalize task structure;
attach required validation/acceptance constraints;
remove redundant context when safely represented by canonical facts;
make requested artifact/execution target explicit;
preserve user tone/intent rather than sanitizing it into generic assistant prose.

Beagle must not:

invent user requirements;
weaken or remove explicit constraints;
silently change requested action;
grant permissions/authority;
replace uncertainty with fabricated certainty;
expose private KB facts not required for the task.

Learning/evolution

Beagle can improve from outcome data, but rule creation/promotion must remain explicit and versioned. The fail/success expert may provide evidence about rewrite quality; it does not automatically promote arbitrary generated rules to trusted production policy.

Track rewrite -> outcome correlations so later research can identify useful/harmful rules.

RED-first shadow-mode acceptance

Create fixtures proving baseline lacks KB-guided rewrites and that naive rewriting would lose constraints. Required cases should include:

explicit user constraint preservation;
project/repository disambiguation from grounded KB facts;
conflicting KB fact vs current explicit message where the current message wins;
irrelevant/private fact exclusion;
no applicable rule => identity/no-op rewrite;
rule/version/evidence provenance.

Apply-mode gate

Do not enable apply by default in the same slice as initial Beagle implementation. Apply mode requires a separate RED-first conformance gate proving:

semantic/constraint preservation;
deterministic rollback to original request;
shadow-vs-apply comparison dataset;
exact original/rewrite linkage;
expert-plane failure cannot corrupt or drop the original request.

Analysis

Expose queries for:

rewrite frequency
rules used
rewrite cost delta
rewrite outcome delta
models/providers/tasks affected
rewrite failures/corrections

This is intended to become a dataset for improving the symbolic rewriting KB itself.

Parent: #8 Depends on: #10, #12 ## Goal Create **Beagle**, an expert system that rewrites user requests using an advanced symbolic KB built from observed user messages, task context, project facts, classifications, prior corrections and explicit durable rules. Beagle is not a generic prompt-polisher. It is a provenance-preserving symbolic rewrite engine. ## Core contract Input: - original user message, unchanged - current task/session identity - request-classification assertions - bounded relevant user/project/task facts from Tek9 - explicit constraints/preferences already represented in the KB - applicable rewrite rules and rule versions Output: - proposed rewritten message - preserved constraints list - additions/normalizations performed - rule IDs/versions used - evidence/fact IDs used - confidence/decision state - `rewrite_id` linked to original message/task The original message is always retained verbatim. ## Modes ### `off` No Beagle evaluation. ### `shadow` Run Beagle, persist proposal/provenance, but send the original request unchanged. This is the initial production mode and is required for dataset/evaluation work. ### `apply` After separate conformance evidence, allow the configured rewrite boundary to submit the rewritten request downstream while retaining both original and rewritten forms in the corpus. No hidden rewrite mode. ## Advanced KB The KB should support reusable rules/facts such as: - user-specified enduring workflow constraints - project/repository ownership boundaries - preferred tool/execution paths - output/artifact conventions - known ambiguity resolutions - task decomposition conventions - validation/test requirements - model/provider constraints - known failed rewrite patterns - known successful rewrite patterns Rules should be inspectable/versioned Prolog, backed by Tek9 facts/provenance. Do not convert raw conversation history into unconditional rules. ## Rewrite behavior Beagle may: - resolve references when the KB has grounded identity/context; - make implicit known constraints explicit; - normalize task structure; - attach required validation/acceptance constraints; - remove redundant context when safely represented by canonical facts; - make requested artifact/execution target explicit; - preserve user tone/intent rather than sanitizing it into generic assistant prose. Beagle must not: - invent user requirements; - weaken or remove explicit constraints; - silently change requested action; - grant permissions/authority; - replace uncertainty with fabricated certainty; - expose private KB facts not required for the task. ## Learning/evolution Beagle can improve from outcome data, but rule creation/promotion must remain explicit and versioned. The fail/success expert may provide evidence about rewrite quality; it does not automatically promote arbitrary generated rules to trusted production policy. Track rewrite -> outcome correlations so later research can identify useful/harmful rules. ## RED-first shadow-mode acceptance Create fixtures proving baseline lacks KB-guided rewrites and that naive rewriting would lose constraints. Required cases should include: - explicit user constraint preservation; - project/repository disambiguation from grounded KB facts; - conflicting KB fact vs current explicit message where the current message wins; - irrelevant/private fact exclusion; - no applicable rule => identity/no-op rewrite; - rule/version/evidence provenance. ## Apply-mode gate Do not enable `apply` by default in the same slice as initial Beagle implementation. Apply mode requires a separate RED-first conformance gate proving: - semantic/constraint preservation; - deterministic rollback to original request; - shadow-vs-apply comparison dataset; - exact original/rewrite linkage; - expert-plane failure cannot corrupt or drop the original request. ## Analysis Expose queries for: - rewrite frequency - rules used - rewrite cost delta - rewrite outcome delta - models/providers/tasks affected - rewrite failures/corrections This is intended to become a dataset for improving the symbolic rewriting KB itself.