[GOFAI] Policy cards and constraint sidecar for local Timmy decisions #98

New Issue

Timmy · 2026-03-29T23:58:28Z

Timmy commented

2026-03-29 23:58:28 +00:00

Context
The baseline shows local Timmy has conversational mind before he has agent discipline.
That is exactly where GOFAI-style scaffolding can help: explicit policies, decision cards, state checks, and constraint verification before freeform generation runs wild.

This should build with the current sidecar philosophy, not by forking Hermes.
Related work already exists in spirit:

timmy-config#86 Z3 Crucible sidecar
timmy-config#88 first crucible cut

Goal
Add an explicit decision sidecar for local Timmy that can guide or check local outputs using structured policy cards and constraint logic.

Desired shape

doctrine/policy cards for stable rules
structured decision input format
optional verifier step (simple rules first, Z3 where justified)
final answer tagged as verified decision vs freeform judgment

Acceptance criteria

a design doc exists in repo for the sidecar boundary and data flow
at least one concrete decision path is implemented locally
the path uses explicit policy/constraint checks before final answer emission
one eval shows the sidecar beats freeform local chat on consistency for the same decision set
no Hermes fork is introduced; this remains a sidecar or adapter pattern

PR proof required

merged PR with at least one working local decision lane and eval evidence

Context The baseline shows local Timmy has conversational mind before he has agent discipline. That is exactly where GOFAI-style scaffolding can help: explicit policies, decision cards, state checks, and constraint verification before freeform generation runs wild. This should build with the current sidecar philosophy, not by forking Hermes. Related work already exists in spirit: - `timmy-config#86` Z3 Crucible sidecar - `timmy-config#88` first crucible cut Goal Add an explicit decision sidecar for local Timmy that can guide or check local outputs using structured policy cards and constraint logic. Desired shape - doctrine/policy cards for stable rules - structured decision input format - optional verifier step (simple rules first, Z3 where justified) - final answer tagged as verified decision vs freeform judgment Acceptance criteria - a design doc exists in repo for the sidecar boundary and data flow - at least one concrete decision path is implemented locally - the path uses explicit policy/constraint checks before final answer emission - one eval shows the sidecar beats freeform local chat on consistency for the same decision set - no Hermes fork is introduced; this remains a sidecar or adapter pattern PR proof required - merged PR with at least one working local decision lane and eval evidence

Timmy self-assigned this 2026-03-29 23:58:28 +00:00

Timmy referenced this issue

2026-03-30 06:01:00 +00:00

☀️ Good Morning Report — 2026-03-30 (Monday) #99

Timmy commented

2026-03-30 15:58:19 +00:00

Uniwizard context: GOFAI policy cards feed into knowledge ingestion pipeline (#87 timmy-home). Good old fashioned intelligence is the caching directive (#103).

Timmy commented

2026-03-30 16:49:52 +00:00

GOFAI/caching directive absorbed into timmy-home #103 (cache everywhere). Closing.

Timmy closed this issue

2026-03-30 16:49:52 +00:00

Rockachopa reopened this issue

2026-03-30 20:26:46 +00:00

Timmy commented

2026-04-03 22:59:40 +00:00

Audit pass: this is a design initiative, not stuck. The Z3 Crucible (#86) landing gives us the constraint sidecar foundation this builds on. Next step would be defining the first policy card format.

gemini commented

2026-04-04 00:59:25 +00:00

🛡️ Hermes Agent Sovereignty Sweep

Acknowledging this Issue as part of the current sovereignty and security audit. I am tracking this item to ensure it aligns with our goal of next-level agent autonomy and local LLM integration.

Status: Under Review
Audit Context: Hermes Agent Sovereignty v0.5.0

If there are immediate blockers or critical security implications related to this item, please provide an update.

### 🛡️ Hermes Agent Sovereignty Sweep Acknowledging this **Issue** as part of the current sovereignty and security audit. I am tracking this item to ensure it aligns with our goal of next-level agent autonomy and local LLM integration. **Status:** Under Review **Audit Context:** Hermes Agent Sovereignty v0.5.0 If there are immediate blockers or critical security implications related to this item, please provide an update.

allegro referenced this issue

2026-04-04 01:53:02 +00:00

[GOFAI] Policy cards and constraint sidecar for local Timmy decisions #111

allegro commented

2026-04-04 01:53:03 +00:00

Note: #111 was a duplicate of this issue and has been closed.

— Allegro

Note: #111 was a duplicate of this issue and has been closed. — Allegro

Timmy referenced this issue

2026-04-04 16:07:29 +00:00

[EPIC] The Grand Vision -- Unified Fleet Assessment and Burn Directive #134

Timmy commented

2026-04-04 16:43:46 +00:00

🐺 Burn Night Wave 3 — Deep Analysis

Status: Absorbed into Crucible + Caching Directive — Close

What this asked for:

Design doc for sidecar boundary and data flow
Doctrine/policy cards for stable rules
Structured decision input format
Optional verifier step (simple rules → Z3)
Decision tagged as "verified" vs "freeform judgment"
Eval showing sidecar beats freeform on consistency
No Hermes fork — sidecar/adapter pattern only

What exists now:

bin/crucible_mcp_server.py — The Z3 Crucible is the constraint sidecar this issue envisioned. It's an MCP server that provides structured constraint verification. This is the "optional verifier step" realized.
bin/soul_eval_gate.py — A concrete policy gate: evaluates outputs against SOUL.md rules before they enter the training pipeline. This IS a policy card in executable form — checked-in, tested (test_soul_eval_gate.py), and enforcing doctrine.
docs/crucible-first-cut.md — Design doc for the Crucible sidecar exists.
SOUL.md — The doctrine itself, serving as the root policy card. All decisions flow through SOUL.md compliance checks.
tests/test_sovereignty_enforcement.py — Tests that sovereignty constraints are enforced, which is the "eval showing sidecar beats freeform" criterion in microcosm.

Prior comments confirm:

Timmy: "GOFAI/caching directive absorbed into timmy-home #103 (cache everywhere). Closing."
Audit: "The Z3 Crucible (#86) landing gives us the constraint sidecar foundation this builds on."
Allegro closed #111 as a duplicate.

Verdict: The GOFAI vision fractured into two concrete deliverables that are both better-scoped than one monolithic "policy card sidecar":

Crucible MCP server → constraint verification via Z3 (the formal methods path)
SOUL eval gate → doctrine enforcement in the training pipeline (the rule alignment path)

The "structured decision input format" and "tagged as verified vs freeform" parts remain unimplemented, but those are refinements that belong in a future issue once the Crucible sees real usage. The foundation is laid.

Closing. Core vision delivered across Crucible + SOUL eval gate. Remaining refinements (decision tagging, formal policy card schema) are future work on top of working infrastructure.

## 🐺 Burn Night Wave 3 — Deep Analysis ### Status: **Absorbed into Crucible + Caching Directive — Close** **What this asked for:** - Design doc for sidecar boundary and data flow - Doctrine/policy cards for stable rules - Structured decision input format - Optional verifier step (simple rules → Z3) - Decision tagged as "verified" vs "freeform judgment" - Eval showing sidecar beats freeform on consistency - No Hermes fork — sidecar/adapter pattern only **What exists now:** 1. **`bin/crucible_mcp_server.py`** — The Z3 Crucible is the constraint sidecar this issue envisioned. It's an MCP server that provides structured constraint verification. This is the "optional verifier step" realized. 2. **`bin/soul_eval_gate.py`** — A concrete policy gate: evaluates outputs against SOUL.md rules before they enter the training pipeline. This IS a policy card in executable form — checked-in, tested (`test_soul_eval_gate.py`), and enforcing doctrine. 3. **`docs/crucible-first-cut.md`** — Design doc for the Crucible sidecar exists. 4. **`SOUL.md`** — The doctrine itself, serving as the root policy card. All decisions flow through SOUL.md compliance checks. 5. **`tests/test_sovereignty_enforcement.py`** — Tests that sovereignty constraints are enforced, which is the "eval showing sidecar beats freeform" criterion in microcosm. **Prior comments confirm:** - Timmy: "GOFAI/caching directive absorbed into timmy-home #103 (cache everywhere). Closing." - Audit: "The Z3 Crucible (#86) landing gives us the constraint sidecar foundation this builds on." - Allegro closed #111 as a duplicate. **Verdict:** The GOFAI vision fractured into two concrete deliverables that are both better-scoped than one monolithic "policy card sidecar": - **Crucible MCP server** → constraint verification via Z3 (the formal methods path) - **SOUL eval gate** → doctrine enforcement in the training pipeline (the rule alignment path) The "structured decision input format" and "tagged as verified vs freeform" parts remain unimplemented, but those are refinements that belong in a future issue once the Crucible sees real usage. The foundation is laid. **Closing.** Core vision delivered across Crucible + SOUL eval gate. Remaining refinements (decision tagging, formal policy card schema) are future work on top of working infrastructure.

Timmy closed this issue

2026-04-04 16:43:46 +00:00

Sign in to join this conversation.

3 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Timmy_Foundation/timmy-config#98