[EPIC] Conversational policy programming — compile spoken rules to verified Prolog policy #341

New issue

Open

opened 2026-09-08 02:03:35 +00:00 by nsaspy · 0 comments

nsaspy commented

2026-09-08 02:03:35 +00:00

Owner

Goal

Let a principal change Zara's behavior policy through ordinary conversation while keeping the resulting behavior inspectable, testable, versioned and fail-closed.

Example:

Whenever I tell you to merge a PR, wait for green CI unless I explicitly say force it.

Target outcome is not another prompt-memory sentence. Zara proposes a typed declarative policy equivalent to:

allow_merge(PR) :-
    ci_status(PR, green).

allow_merge(PR) :-
    explicit_force_override(PR).

The exact representation is research-owned and must reuse the reviewed Prolog/configuration authority rather than expose arbitrary source execution.

Authoring lifecycle

Natural-language policy request -> typed policy proposal -> static validation -> conflict analysis -> generated deterministic tests/replay -> user-visible diff/impact -> explicit commit where required -> atomic activation.

Required operations:

create policy;
inspect/explain policy;
edit/disable/re-enable/delete;
dry-run against a proposed action;
show conflicting/higher-priority rules;
version history and rollback;
replay historical synthetic/redacted cases to show changed decisions.

Safety boundary

user speech cannot inject arbitrary Prolog goals, file consults, shell, Python or capability names outside reviewed schemas;
compiled policies can constrain/route/require confirmation but cannot grant authority the principal does not possess;
protected system/security invariants cannot be shadowed by user policy;
model/Prolog-RLM-generated policy is untrusted until parsed into the closed schema, statically validated, tested/replayed and committed;
RLM/model execution is bounded and cannot invoke arbitrary tools as part of policy compilation.

Relationship to #151

#151 remains the owner of user-authored commands/macros composed from typed capabilities. This epic adds a different layer: durable behavioral predicates governing when/how those commands and built-in capabilities may execute. Do not close #151 as superseded.

Replay / verification

Before activation, run deterministic policy fixtures and optionally replay a privacy-safe projection of prior relevant decisions. Report behavior changes as old decision -> new decision without exposing hidden model reasoning.

Tests

Cover rule creation/edit/delete, precedence, contradictory rules, protected invariants, capability escalation attempts, malformed/model-invented policy, RLM/model failure, schema/version migration, atomic reload, stale writers, cross-principal isolation, replay determinism, and rollback after a bad policy.

Acceptance

A user can conversationally define a meaningful behavioral rule, inspect the exact bounded policy Zara will enforce, see test/replay evidence, activate it atomically, and later explain/rollback that rule without relying on prompt wording or model/RLM output as the authorization layer.

Parent architecture: #624 Builds on: #150 semantic/capability architecture and #151 principal-scoped programmable commands. Does not replace unfinished #151 work. Current master permits bounded pinned Prolog-RLM direct-mode assistance (#233); any RLM/model output here is proposal-only and must pass the policy compiler/validator. ## Goal Let a principal change Zara's **behavior policy** through ordinary conversation while keeping the resulting behavior inspectable, testable, versioned and fail-closed. Example: ```text Whenever I tell you to merge a PR, wait for green CI unless I explicitly say force it. ``` Target outcome is not another prompt-memory sentence. Zara proposes a typed declarative policy equivalent to: ```prolog allow_merge(PR) :- ci_status(PR, green). allow_merge(PR) :- explicit_force_override(PR). ``` The exact representation is research-owned and must reuse the reviewed Prolog/configuration authority rather than expose arbitrary source execution. ## Authoring lifecycle Natural-language policy request -> typed policy proposal -> static validation -> conflict analysis -> generated deterministic tests/replay -> user-visible diff/impact -> explicit commit where required -> atomic activation. Required operations: - create policy; - inspect/explain policy; - edit/disable/re-enable/delete; - dry-run against a proposed action; - show conflicting/higher-priority rules; - version history and rollback; - replay historical synthetic/redacted cases to show changed decisions. ## Safety boundary - user speech cannot inject arbitrary Prolog goals, file consults, shell, Python or capability names outside reviewed schemas; - compiled policies can constrain/route/require confirmation but cannot grant authority the principal does not possess; - protected system/security invariants cannot be shadowed by user policy; - model/Prolog-RLM-generated policy is untrusted until parsed into the closed schema, statically validated, tested/replayed and committed; - RLM/model execution is bounded and cannot invoke arbitrary tools as part of policy compilation. ## Relationship to #151 #151 remains the owner of user-authored **commands/macros composed from typed capabilities**. This epic adds a different layer: durable behavioral predicates governing when/how those commands and built-in capabilities may execute. Do not close #151 as superseded. ## Replay / verification Before activation, run deterministic policy fixtures and optionally replay a privacy-safe projection of prior relevant decisions. Report behavior changes as `old decision -> new decision` without exposing hidden model reasoning. ## Tests Cover rule creation/edit/delete, precedence, contradictory rules, protected invariants, capability escalation attempts, malformed/model-invented policy, RLM/model failure, schema/version migration, atomic reload, stale writers, cross-principal isolation, replay determinism, and rollback after a bad policy. ## Acceptance A user can conversationally define a meaningful behavioral rule, inspect the exact bounded policy Zara will enforce, see test/replay evidence, activate it atomically, and later explain/rollback that rule without relying on prompt wording or model/RLM output as the authorization layer.