DEV Community: Dariusz Newecki

When My Governance System Governed Itself Wrong

Dariusz Newecki — Tue, 14 Apr 2026 20:08:04 +0000

I built a sensor to detect import order violations. It found 152. The fixer found 0. One of them was lying.

Background

CORE is a deterministic governance runtime I'm building around AI code generation. The core idea is simple: AI produces code, but AI is never trusted. Every output passes through constitutional rules, audit engines, and remediation loops before anything touches the codebase.

One of those loops works like this:

AuditViolationSensor detects violation
    → posts finding to Blackboard
ViolationRemediatorWorker claims finding
    → dispatches AtomicAction (fix.imports, fix.ids, fix.headers, etc.)
Sensor runs again
    → confirms violation gone or re-posts

This is the convergence loop. The goal is that the Blackboard empties over time as violations get fixed. That's what I call A3 — the daemon runs continuously and the codebase converges without me touching anything.

This session I was closing sensor coverage gaps. Several fix actions in dev sync had no corresponding sensor, meaning the daemon was blind to those violations and a human had to run dev sync manually to keep things clean. Not autonomous. Not A3.

One of the gaps was style.import_order. I wrote the sensor, wired it up, restarted the daemon.

152 findings.

The Problem

The sensor was using an AST-based implementation — check_import_order — that classifies imports into groups: future, stdlib, third_party, internal. It then checks that the groups appear in the right order.

The fixer uses ruff --select I, which does the same job but reads its configuration from pyproject.toml:

[tool.ruff.lint.isort]
known-first-party = ["api", "body", "cli", "features", "mind", "services", "shared", "will"]
section-order = ["future", "standard-library", "third-party", "first-party", "local-folder"]

I ran fix.imports --write to clean up before activating the sensor. Zero violations after. Then I activated the sensor. 152 violations.

The sensor and the fixer disagreed on what "correctly ordered imports" means.

Finding the Root Cause

I picked the simplest failing file — src/cli/resources/admin/patterns.py — violation at line 7:

import typer                              # third_party → idx 2
from shared.cli_utils import core_command # internal   → idx 3
from .hub import app                      # ???

The sensor's _classify_root function takes the module name and classifies it. For from .hub import app, a relative import, stmt.module is "hub". "hub" is not in stdlib_names and not in internal_roots, so it falls through to third_party — index 2.

But shared was classified as internal — index 3.

Index 2 after index 3 → violation.

Ruff treats relative imports as local-folder, which comes after first-party in the section order. So ruff considers this file clean. The sensor considers it broken.

Two problems:

Problem 1 — relative imports. The sensor had no concept of them. Any from .something import X got classified as third_party because the module name (something) didn't match any known root. Fix: detect stmt.level > 0 in ast.ImportFrom and classify as local with the highest order index.

Problem 2 — internal roots mismatch. The sensor hardcoded ["shared", "mind", "body", "will", "features"]. Ruff's known-first-party includes ["api", "body", "cli", "features", "mind", "services", "shared", "will"]. Missing: api, cli, services. When a file imports from cli after importing from body, ruff sees two first-party imports in any order — fine. The sensor sees third_party after internal — violation.

Fix: pass internal_roots as a parameter in the enforcement mapping so the sensor reads from configuration rather than hardcoding.

After both fixes: 0 violations. Sensor and fixer agreed.

The Architectural Lesson

This is an instrument qualification problem.

In GxP-regulated environments (pharma, medical devices), before you trust a measurement instrument, you qualify it. You verify that it measures what it claims to measure, using a known reference. An unqualified instrument is not a trusted instrument — even if it produces numbers.

I deployed a sensor without qualifying it against the fixer. The sensor was measuring something real (import order), but measuring it differently than the tool that fixes it. The result was 152 false positives — governance debt that looked real but wasn't.

A sensor that disagrees with its corresponding fixer is worse than no sensor. It creates noise, erodes trust in the Blackboard, and — if the remediator were running — would dispatch fix actions that produce no change, loop, and dispatch again.

The correct pattern before activating any new sensor:

Run the fixer in dry-run mode. Collect what it would change.
Run the sensor. Collect what it would flag.
Verify the two sets agree on the same files.
Only then activate.

CORE doesn't enforce this yet. The gap is now in the backlog as governance.sensor_fixer_coherence — a meta-rule that validates governance components against each other before they're trusted.

What Got Fixed

Three separate changes at three separate levels:

AST logic (src/mind/logic/engines/ast_gate/checks/import_checks.py):

# Before: relative imports fell through to third_party
# After: detect stmt.level > 0 and classify as local (idx=4)
if isinstance(stmt, ast.ImportFrom) and stmt.level > 0:
    grp = "local"
    idx = 4  # always last — after internal

Configuration (.intent/enforcement/mappings/code/style.yaml):

style.import_order:
  engine: ast_gate
  params:
    check_type: import_order
    internal_roots: ["api", "body", "cli", "features", "mind", "services", "shared", "will"]

Tooling — a new core-admin workers blackboard purge command to clear stale findings when a sensor produces false positives before a fix is applied.

Current State

7 sensors active. 52 rules. 0 findings. Blackboard clean.

The convergence loop is running. The daemon detects violations, the remediator dispatches fixes, the sensor confirms they're gone. That's A3.

The sensor-fixer coherence check doesn't exist yet. Until it does, every new sensor I add needs manual qualification before activation. That's a human step where CORE should eventually do the work itself.

Which is the point of the whole project.

CORE is open source: github.com/DariuszNewecki/CORE
Previous posts in this series cover the constitutional model, the autonomous loop, and the ViolationExecutor implementation.

PASSED with 252 findings. FAILED with 78. Which audit would you trust?

Dariusz Newecki — Tue, 07 Apr 2026 21:00:32 +0000

A story about instrument qualification, false positives, and why honest governance sometimes means failing on purpose.

The paradox

This morning, CORE's audit system reported 252 findings and returned a verdict of PASSED.

This evening, it reported 78 findings and returned a verdict of FAILED.

Nothing in production changed. No bugs were introduced. No architecture was violated.

The sensors were fixed.

Finding	Befr	Aftr	Delta
Total findings	252	78	-174
Orphan files	91	0	-91
Modularity (blunt score)	100	0	-100
needs_split	—	19	new
needs_refactor	—	27	new
File size (redundant rule)	29	0	-29
Verdict	PASS	FAIL	honest

The FAILED verdict is the correct one. The PASSED verdict was a compliance illusion.

The instrument qualification problem

In GxP-regulated environments — pharmaceutical manufacturing, medical devices, clinical software — you do not run an assay on an uncalibrated instrument and trust the result. Before any measurement is taken seriously, the instrument must be qualified: it must demonstrably measure what it claims to measure, within defined tolerances, under defined conditions.

This principle is so fundamental that it precedes any discussion of the data itself. Bad data from a qualified instrument is a finding. Bad data from an unqualified instrument is noise — and acting on noise has a name: it is a deviation.

Software governance systems face the same problem. An audit engine that produces findings is an instrument. If that instrument has not been qualified — if its detectors produce false positives, if its thresholds are miscalibrated, if its rules conflate distinct problem classes — then the findings it produces are not evidence. They are noise with a compliance label.

Acting on that noise with automated remediation is not governance. It is confident, expensive, wrong work.

Case 1: The orphan file detector

CORE uses a static import graph traversal to detect source files unreachable from any declared entry point. The principle is sound: if no entry point can reach a file, that file is dead code and should be removed.

The detector flagged 91 files as orphans.

All 91 were false positives.

Static import graph traversal is a deliberate choice — deterministic, auditable, no runtime dependency. The tradeoff is that dynamically-loaded components must be explicitly declared as entry points. That declaration is itself a governance artifact: it makes the implicit loading contract explicit and versioned. The detector was not wrong — the contract was incomplete.

An automated agent pointed at those 91 findings would have deleted live production code. The agent would have been operating correctly within its mandate. The mandate was wrong.

The fix was not to make the detector smarter. It was to declare the dynamically-loaded directories as explicit entry points — converting an implicit runtime convention into a versioned, governed contract. Functionally this resembles static linking. Constitutionally it is different: the declaration is law, subject to change control, with documented rationale. The detector enforces the contract. The contract is owned by governance, not by the build system.

entry_points:
  - "src/will/self_healing/"
  - "src/will/test_generation/"
  - "src/shared/infrastructure/"
  # ... 10 more directories

After the fix: zero orphan findings. Zero code deleted. The codebase did not change. The instrument was qualified.

Case 2: The modularity score

Four rules were producing 100 findings collectively:

modularity.single_responsibility
modularity.semantic_cohesion
modularity.import_coupling
modularity.refactor_score_threshold

All four were proxies for a single composite score. All four mapped to the same remediation action: fix.modularity. All four carried the same enforcement level: reporting.

The problem is that they were measuring two fundamentally different things and treating them identically.

Problem class A: a file is too long with a single coherent responsibility.
This is a mechanical problem. The file does one thing but does too much of it. The solution is splitting — redistributing logic across smaller files along natural seams. No discipline boundaries are crossed. No architectural judgment is required. An automated system can propose and execute this split safely, subject to a Logic Conservation Gate that verifies no logic was lost.

Problem class B: a file mixes distinct architectural disciplines.
A file that combines CLI rendering, database access, and business logic in 300 lines is not a size problem. It is an architectural violation. Resolving it requires a human to decide where each responsibility belongs in the constitutional layer structure. An automated system cannot make that decision safely — not because AI is incapable of generating a proposal, but because the decision carries architectural authority that must remain with a human until the boundaries are formally established.

Conflating these two problems in a single score means the governance system cannot distinguish between what it is allowed to fix autonomously and what it must escalate. That distinction is not a technical nicety. In regulated environments, it is the difference between an approved automated action and an unauthorized architectural change.

The fix was to retire the four proxy rules and replace them with two precise sensors:

{
  "id": "modularity.needs_split",
  "enforcement": "reporting",
  "rationale": "Automatable. Mechanical redistribution, no discipline boundaries crossed."
},
{
  "id": "modularity.needs_refactor",
  "enforcement": "blocking",
  "rationale": "Requires human judgment. Autonomous action prohibited until architectural decision is approved."
}

The blocking enforcement on needs_refactor is the point. It is not a warning. It is a constitutional stop. The system will not proceed autonomously until a human has reviewed and authorized the architectural boundary decision.

This is why the audit now returns FAILED. Twenty-seven files contain mixed-discipline violations. They are real findings. They require real decisions. The system is correctly refusing to act without authorization.

The verdict paradox

A governance system that always passes is not a governance system. It is a reporting system with a green checkbox.

PASSED with 252 findings meant: the system detected many things, none of them were classified as blocking, therefore no action is required. The 91 false positives contributed to a picture of busyness without actionability. The composite modularity score produced findings that the automated remediator could not distinguish from each other. Everything was flagged, nothing was escalated.

FAILED with 78 findings means: the system has detected 27 architectural violations that require human decisions before any automated action proceeds. It has identified 19 files that can be split autonomously, subject to validation gates. Every finding in the report corresponds to a specific, actionable condition.

The failure verdict is evidence that the governance system is functioning correctly. It is not a regression. It is an honest measurement.

The principle

Governance quality is not measured by finding count. It is measured by finding accuracy.

In regulated environments, the difference between a false positive acted upon and a true positive ignored is not a technical footnote. It is a compliance failure. Instrument qualification is not overhead — it is the precondition for trusting any measurement that follows.

Before you ask what your audit found, ask whether your audit can be trusted.

CORE is an open-source constitutional governance runtime for AI-assisted software development. Architecture, governance rules, and enforcement mappings are public.

github.com/DariuszNewecki/CORE

I Spent a Saturday Cleaning My Own Repo. CORE Made Me.

Dariusz Newecki — Sat, 04 Apr 2026 19:42:23 +0000

Not because I wanted to.

Because the system I built demands that everything it touches is defensible. And when I looked honestly at my own repository — the README, the docs, the .gitignore — they weren't.

So I fixed them.

The broken command nobody noticed

It started with a README.

The Quick Start section told anyone who cloned CORE to run:

poetry run core-admin check audit

That command doesn't exist. The correct command is:

poetry run core-admin code audit

One word difference. But anyone who followed that instruction would get an error on their very first interaction with the project. First impression: broken.

The CLI had evolved. The legacy verb-first pattern (check audit) was purged months ago when CORE's command structure was redesigned around resource-first architecture. The README hadn't kept up. It was documenting a command that no longer existed.

"If the docs lie, the system lies."

This is the thing about building a governance runtime: you can't enforce standards on AI-generated code while your own documentation ships broken commands.

CORE's entire thesis is:

Never produce software you cannot defend.

Not rhetorically. Technically, legally, epistemically, historically.

If I can't defend my own README — if the first thing someone tries doesn't work — then I'm not living by the standard I built into the system.

That's not a philosophical problem. It's a credibility problem. And a consistency problem. And those are exactly the problems CORE exists to solve.

What a Saturday of self-governance looks like

Here's what actually got done:

README:

Fixed the broken audit command (check → code)
Removed a stale metric (0 blocking violations) that may or may not have been current
Removed an acknowledgment that no longer reflected the project's direction
Replaced a buried, collapsible workflow diagram with a cleaner conceptual flow — visible immediately, no click required

CONTRIBUTING.md:

Updated the CI description (it had said "smoke testing" — it does more than that now)
Added the audit command so contributors know how to verify compliance locally before opening a PR

.gitignore:

Found that logs/* was missing — only !logs/.gitkeep existed, with no corresponding exclusion rule. Any non-.log file landing in logs/ would have been tracked silently.
Added proper logs/* and reports/* exclusions with the same pattern used for var/ and work/

docs/ — complete rewrite:

The docs site had 111 files across 30 directories, most of them written at various stages of development, not reflecting current architecture
I replaced all of it with six files: index.md, how-it-works.md, autonomy-ladder.md, getting-started.md, cli-reference.md, contributing.md
Every CLI command in the reference was verified against the actual source code — not inferred, not remembered, not guessed

That last point matters. The first draft of cli-reference.md was written by an AI assistant — from inference, not from source. I caught it, pushed back, and made it search the actual command registrations before writing anything. Same standard I apply to everything else.

The CLI reference problem is the whole problem in miniature

The first draft of cli-reference.md was written by an AI assistant — from inference, not from source.

It had wrong subcommands. Plausible ones, but wrong.

core-admin proposals inspect <id> — doesn't exist. It's show.

core-admin inspect status — legacy verb-first pattern, purged months ago. It's core-admin admin status.

core-admin governance coverage — wrong group entirely. It's core-admin constitution status.

Three wrong commands in one file. All confident. All wrong.

I caught it. Pushed back. Asked the assistant to search the actual source code before writing anything. It did. The commands got fixed.

The irony was not subtle: an AI assistant producing plausible but unverified output, in documentation for a system that exists specifically to prevent AI from producing plausible but unverified output.

That's not a documentation problem. That's an epistemic problem. And it's the same one that lives in .intent/northstar/core_northstar.md:

Nothing is assumed silently. All assumptions must be explicit, owned, and traceable. Reasoning requires citation. If CORE cannot point to evidence, it cannot act.

What this has to do with autonomy

CORE is currently at A2+ — governed generation, universal workflow pattern. I'm working toward A3 — strategic autonomy, where CORE identifies and proposes architectural improvements without being asked.

For A3 to be trustworthy, the system has to be clean. Not just the code — the whole project. The README someone reads before cloning. The docs they follow when getting started. The .gitignore that determines what gets committed.

If those are wrong, the foundation is wrong. And you can't build autonomous operation on a wrong foundation.

Cleaning the repo isn't glamorous. It doesn't advance the autonomy ladder. But it's the kind of work the system's own philosophy demands — and that I'd been quietly deferring.

The self-referential part

There's something almost uncomfortable about this.

I built a system that enforces: you cannot ship what you cannot defend. And then I had a README with a broken command, a .gitignore with a missing rule, and a documentation site with 111 files of outdated content.

The system couldn't enforce standards on its own repository — it doesn't govern Markdown files. That's a human responsibility.

Which means the human has to do it.

That's not a failure of CORE. That's the design. .intent/ is human-authored and immutable at runtime. CORE can never write to it. The constitution is mine to maintain.

The same is true for everything outside the autonomy lanes — the README, the docs, the project presentation. CORE governs the code. I govern the rest.

And today I did.

If you're curious

The repo is at github.com/DariuszNewecki/CORE.

If you've looked before and bounced — the docs are cleaner now. The commands in the Quick Start actually work.

If you're new: read .intent/ before the source. That's where the law lives.

Previous in this series: My AI Has 22 Workers, 2,470 Resolved Violations, and Still Can't Call Itself Autonomous. Here's the Gap.

The AI That Refused To Ship Its Own Fix

Dariusz Newecki — Wed, 01 Apr 2026 18:15:43 +0000

Or: what constitutional governance actually looks like in practice

I spent today doing something unusual. I was improving an AI system — and the system kept stopping me from making mistakes.

Not because it was clever. Because it was governed.

The Setup

CORE is a constitutional governance runtime for AI coding agents. The short version: instead of letting AI write code freely and checking quality afterwards, CORE requires every decision to be traceable to declared law before execution begins.

Every rule lives in .intent/. Every action requires authority. Every mutation is defensible or it doesn't happen.

Today's session was about advancing CORE toward A3 — full autonomous operation on Tier 1 violations. Eight items on the A3 readiness checklist were marked ❌. By end of session: one remained.

Here's what the path looked like.

The Gate That Wasn't Wired

Early in the session I wanted to promote two entries in the autonomous remediation map from PENDING to ACTIVE. The Logic Conservation Gate had been implemented — a protection against AI refactors that delete more than 50% of a file's logic. The comment in the YAML said "gated until Logic Conservation Gate implemented." Gate implemented. Promote.

I gave Claude Code the prompt.

It came back with a finding I hadn't expected:

"The gate exists in ComplexityRemediationService. ModularityRemediationService — the actual handler these entries call — never touches it. The comment in the YAML is still accurate."

The gate was implemented. Just not in the right place.

We wired it. Then we promoted.

That's not a dramatic story. That's exactly how it should work. The system forced verification before the claim. No amount of "the gate exists somewhere" was sufficient. It had to exist here, in this path, or the promotion was a lie.

83 Silent Failures, Now Loud

Overnight, 83 proposals failed. Each showed execution_results: {} — empty. The handlers were running but returning nothing.

Three months ago this would have been invisible. The handlers returned ok=True unconditionally. Internal errors were swallowed. The proposal consumer would mark everything COMPLETED and move on.

Yesterday we fixed that. Wrapped every handler in try/except. Derived ok from actual outcomes instead of hardcoding success.

So this morning: 83 failures instead of 83 false completions.

That's progress. Honest failure is worth more than dishonest success. CORE's constitution says exactly this:

"CORE must never produce software it cannot defend."

A system that lies about its own outcomes cannot defend them.

319 Stuck Findings

The blackboard showed 319 entries in claimed status. All with claimed_by = NULL.

Legacy entries — claimed before we added atomic claiming with worker identity. The fix was one SQL statement. But finding it required reading the blackboard, querying claimed_by, and tracing the pattern.

No amount of assuming "the system is fine" would have found this. The evidence had to be read. The constitution demands it:

"Memory without evidence is forbidden."

After the fix, a new batch of 319 appeared — this time with a real UUID. The worker was claiming findings, finding no handler for them in the remediation map, and leaving them stuck.

Another fix: release unmappable findings immediately at claim time.

Each fix revealed by the system's own honesty about its state.

What Makes This Different

Most AI coding tools measure success by output volume. Lines written, tickets closed, PRs merged.

CORE measures success by defensibility. Can you explain why this change was made? Under what authority? With what evidence? What happens if it's wrong?

Today we made 14 commits. Each traceable to a checklist item. Each verified by the system before and after. The daemon either ran clean or it didn't. The blackboard either showed stuck entries or it didn't.

The AI didn't just write code. It was governed while writing code. And when the governance caught a mistake — the gate that wasn't wired, the handler that lied about success, the findings that stayed claimed forever — we fixed the governance, not just the symptom.

That's the mind shift. Not "AI writes code faster." But:

"Law governs intelligence. Defensibility outranks productivity."

Who This Is For

CORE is not for everyone. It's explicitly not for casual app builders or speed-only workflows.

It's for regulated environments. Safety-critical systems. Teams where "the AI decided" is not an acceptable answer in a post-mortem.

If that's your world — the architecture is open. The constitution is public.

🔗 github.com/DariuszNewecki/CORE

And if you think in terms of governance rather than just generation — I'm looking for collaborators. Not necessarily programmers. People who understand that software systems need to be able to explain themselves.

Written the same day the session happened. The daemon is running clean as I type this.

Your Agent Has Two Logs. One of Them Doesn't Exist Yet.

Dariusz Newecki — Mon, 30 Mar 2026 20:38:06 +0000

Earlier this week I read Daniel Nwaneri's piece on induced authorization — the observation that agents don't just do unauthorized things, they cause humans to do unauthorized things. His central example: an agent gives advice, an engineer widens a permission based on that advice, the agent's action log shows nothing unusual. The exposure is real. The log is clean.

He named this the induced-edge problem, and the framing is sharp enough to deserve a concrete answer.

Here's the answer CORE gives — and the gap it still doesn't close. And why that gap is not an oversight, but a frontier.

Two Logs, Not One

Most agent governance architectures assume one audit object: the action log. What did the agent do?

The induced-edge problem reveals that this is the wrong unit. There are actually two logs:

Log 1 — The action log. What the agent executed directly. This exists. For CORE, it's the blackboard: every worker posts findings, proposals, and outcomes to a PostgreSQL append-only record. Nothing is retracted. Nothing is amended. The audit trail is a fact of the architecture, not a feature someone remembered to add.

Log 2 — The consequence log. What happened in the world as a result of the agent's output. This doesn't fully exist yet. Not in CORE. Not in most systems.

The distinction matters because these two logs decay differently. Direct edges — things the agent did itself — are trackable and can be pruned when unused. Induced edges — state changes that the agent's output caused a human to make — don't decay on the same clock. A widened permission persists independently of whether the agent keeps referencing it. It's effectively permanent until someone explicitly reconciles it.

What CORE Gets Right

Before the gap, what the design actually solves.

CORE's blackboard is append-only by architecture. Workers post findings; they cannot revise or retract them. This matters because of a question Daniel raised that I think is underappreciated: what keeps the audit history honest while a materiality classifier is being trained on it?

His concern: if the classifier's training data can be gamed — even slowly, even unintentionally — you don't just end up with a gameable threshold. You end up with a corrupted evidence base. The reconciliation record loses its value at the same rate the classifier loses its integrity.

CORE's append-only constraint answers this structurally. The blackboard accumulates an honest history not because workers are trustworthy, but because the architecture makes revision impossible.

The proposal lifecycle adds another layer. When a proposal requires human approval, CORE records the approver identity and timestamp against the proposal record. approved_by, approved_at — persisted to the database, queryable, part of the chain. This isn't incidental. A dangerous proposal that executes without a recorded approver fails validation. The authorization chain is a first-class fact.

This is what Daniel meant when he argued the reconciliation record is the primary value — more important than whatever threshold sits on top of it. CORE was built around this conviction. The Final Invariant — CORE must never produce software it cannot defend — is not about catching violations. It's about maintaining a record from which any decision can be reconstructed and justified. The defense is the record.

Where The Gap Actually Lives

CORE logs that I approved a proposal, and when. What it doesn't log is what I did as a consequence of that approval.

If applying a proposal required me to also amend a .intent/ rule, add a new service account, or widen a scope — those downstream actions are outside the perimeter. CORE's record ends at "approved by Dariusz at timestamp X." The induced state change that followed is not in the log.

But here's the thing: that gap is not an oversight in CORE's design. It's a consequence of something more fundamental.

`.intent/` Is a Shim

.intent/ — CORE's constitutional layer, the directory of rules, worker declarations, and workflow stages that governs everything CORE does — is currently hand-authored YAML. Every file in it was written by me, under time pressure, as a working approximation of what a proper governance-policy tool would generate.

The CORE-policy-governance-writer doesn't exist yet. I haven't had time to build it. What exists instead is a shim: YAML that holds the shape of the intended thing while the tooling catches up.

This matters because of what .intent/ is in the architecture. It's not configuration for CORE. It's the constitutional layer that CORE is. The rules, the worker mandates, the workflow invariants — these are the law CORE enforces. And the Final Invariant applies there with equal force:

Every change to .intent/ must be as traceable, as defensible, as auditable as any change to src/.

Right now, it isn't. A change to .intent/ is a git commit I made. It's not a governed action. It's not logged against a finding. It's not traceable to a rule that authorized it. The authorization chain that CORE enforces rigorously for code changes simply doesn't exist yet for the policy layer itself.

That's the induced-edge gap, stated precisely. It's not that CORE fails to track what humans do after approving proposals. It's that the policy layer that would make human decisions about governance trackable hasn't been built yet. The two-log problem is the symptom. The missing tool is the cure.

The Architecture Is Self-Similar By Design

What the CORE-policy-governance-writer would be, once built, is exactly this: CORE, applied one layer up.

The same principle that governs src/ — every change must be authorized, logged, traceable, defensible — applies to .intent/. The governance writer would produce .intent/ changes as governed artifacts: triggered by a finding, authorized by a rule, logged to the blackboard, approvable or rejectable through the same proposal lifecycle that code changes use.

This is the architecture completing itself. Not a new feature bolted on, but the same invariant applied consistently at every layer. CORE governing code. A governance writer governing CORE's constitution. The loop closes.

Until that tool exists, the current .intent/ captures intent without capturing the consequences of acting on it. The authorization graph — declared scopes, permitted scope changes, human decisions that modified them — is implicit in my head and in git history, not in any structure CORE can reason over.

Daniel asked whether runtime constitutional enforcement shrinks the attack surface for induced risks. The honest answer: completely, for direct edges. Structurally, for induced edges — once the policy layer is expressive enough to represent scope changes as first-class governed events. That work is ahead of me, not behind.

What The Thread Built

Daniel's induced-edge framing gave me precise language for something I knew was missing but hadn't named cleanly. The two-log problem. The different decay rates of direct versus induced edges. The irreversible-by-default bootstrap.

CORE's append-only blackboard and proposal authorization chain solve the honest-history problem for direct edges. The CORE-policy-governance-writer — when it exists — will extend the same guarantee to the policy layer itself. Every action traceable. Every authorization defensible. Including the ones that write the law.

One person building it. Logic is consistent. The shim holds.

Daniel's piece: Agents Don't Just Do Unauthorized Things. They Cause Humans to Do Unauthorized Things.

CORE on GitHub: github.com/DariuszNewecki/CORE

The Day CORE's Author Finally Followed CORE's Own Rules

Dariusz Newecki — Sun, 29 Mar 2026 19:52:50 +0000

I spent my Sunday not writing a single line of code.

It was the most productive day I've had in months.

A bit of honest backstory

I am not a programmer. I'm more of an architect. Maybe a philosopher who ended up with a codebase.

I built CORE because I got angry. Angry at LLMs that hallucinate. Angry at context drift. Angry at tools that produce output nobody can defend. I wasn't trying to disrupt an industry — I was trying to solve my own problem.

I built it for myself. On a server called lira. In Antwerp. With PostgreSQL and local embeddings because I couldn't afford to throw GPU clusters at the problem.

Necessity is the best creativity source. Eastern Europe will teach you that.

Somewhere along the way the thing I built for myself started looking like something real. Something that might matter beyond my own island.

But today I realised something uncomfortable.

CORE demands something from every project it touches

CORE has a rule. Actually, it's stronger than a rule — it's a constitutional requirement:

Constitution before code. Always.

When CORE encounters a repository — whether it's a half-finished mess or a five-million line enterprise codebase — it doesn't start writing. It starts understanding. It maps. It asks. It surfaces contradictions. It refuses to proceed on guesswork.

And before any implementation begins, CORE produces a constitution for the target system. A .intent/ directory. A set of requirements. A statement of what the software must do and why.

CORE will not write a single line until that exists.

I wrote this rule. I enforce this rule. I believe in this rule deeply enough to build an entire governance system around it.

So guess what I had never written for CORE itself.

Yeah.

CORE had a NorthStar document — a philosophical manifesto about why it exists, what it believes, what it will never do. Beautiful document. I'm proud of it.

But a User Requirements document? Stating concretely what CORE must deliver to a user?

Not written.

I had been violating my own constitution. Quietly. For months.

How I finally got there

It didn't happen the way I expected.

I wasn't sitting at a desk with a blank document thinking "right, requirements time." I was having a conversation. A rambling, honest, philosophical Sunday conversation about CORE, about the industry, about building things on a shoestring from Eastern Europe, about my mother telling me decades ago that she couldn't follow what I was thinking.

And somewhere in that conversation, someone asked: "If a stranger landed on your GitHub right now, what would they understand in three seconds?"

I had to think about it.

The answer, when it came, was embarrassingly simple:

A thing that uses AI to write perfect applications.

Seven words. Obvious. To me. Completely invisible to everyone else because I had been leading with the architecture instead of the purpose.

My mother would have told you the same thing. She did, in fact. Many times.

Writing the requirements properly

Once I started actually articulating requirements — not philosophy, not principles, but obligations — eight of them emerged:

UR-01: Universal Input Acceptance
CORE accepts anything. Conversation. Spec. Single file. Enormous repository. No assumptions about quality or structure.

UR-02: Comprehension Before Action
CORE must be able to say "I know what this does and I understand it" — backed by evidence — before taking any action. Not assumed. Earned and declared.

UR-03: Gap and Contradiction Reporting
CORE asks when things are missing. CORE stops when things contradict. CORE never guesses.

UR-04: Constitution Before Code
The target system's .intent/ is CORE's first deliverable. Not a byproduct. A precondition. Implementation without an established constitution is malpractice.

UR-05: Output is Working Software
Working means: satisfies the stated requirements. Stack is the user's choice. Perfection is a quality indicator, not a deliverable. Correctness against declared intent is the only measure.

UR-06: Continuous Constitutional Governance
CORE does not distinguish between "build" and "maintain." That's an industry distinction — two teams, two budgets, two problems. CORE asks one question continuously: does this satisfy what you said you wanted?

UR-07: Defensibility is Non-Negotiable
Every output traces to a requirement, a rule, or an explicit human decision. If none exist, CORE stops and asks. CORE never produces software it cannot defend — technically, legally, epistemically, historically.

UR-08: Judgement Belongs to the Human
CORE enforces coherence, not morality. What the software is for is the user's responsibility. CORE flags contradictions. CORE surfaces missing decisions. CORE does not judge purpose.

Where does the document live?

This is the part that made me genuinely happy.

The answer was obvious. It could only go in one place: .intent/northstar/

Not constitution/ — it's not a foundational principle.
Not papers/ — it's not philosophy.
Not rules/ — it's not enforcement law.

northstar/ — because the User Requirements document is the NorthStar made concrete. Same authority. Same scope. Same rule: human-authored, runtime-immutable. CORE can read it. Reason from it. Vector-search it for context. Never touch it.

When your architecture tells you where something belongs without you having to think about it — that's good constitutional design.

The irony isn't lost on me

CORE demands constitution before code from every project it touches.

Today its own author finally wrote the requirements document that should have anchored CORE's own constitution from the beginning.

I was the user. The conversation was CORE. Messy, human, philosophical input went in. Precise, defensible, constitutionally-placed output came out.

No code written. Real progress made.

The governing invariant

All eight requirements trace back to one line, declared in the NorthStar:

CORE must never produce software it cannot defend.

Not defend emotionally. Not defend rhetorically.

Defend technically, legally, epistemically, and historically.

Everything else is a consequence of that one sentence.

If any of this resonates — or if you want to tell me I'm doing it wrong — the repo is at github.com/DariuszNewecki/CORE.

CORE is picky. CORE is honest. CORE is written to survive audits, post-mortems, and time.

If that makes it unsuitable for most people, so be it.

I did not build CORE to be liked. I built it to be right.

How one missing line broke months of autonomous self-improvement — and what fixing it revealed about constitutional software governance

Dariusz Newecki — Sat, 28 Mar 2026 15:09:23 +0000

CORE is a system I've been building for over a year. Its purpose is to govern and autonomously improve software codebases using constitutional rules—not loose AI reasoning, but deterministic policies enforced by auditors and workers in a layered architecture (Mind/Body/Will).

The self-improvement loop is straightforward:

AuditViolationSensor detects violation
  → posts finding to blackboard
    → ViolationRemediatorWorker creates proposal
      → ProposalConsumerWorker executes fix
        → AuditViolationSensor confirms resolved

For months, every proposal failed silently with the message: Actions failed: fix.logging. The autonomous pipeline—the core feature—was completely broken, and the failure left almost no useful trace.

The Investigation

The first red flag was that execution_results on every failed proposal was an empty dict {}. This meant the failure occurred before ActionExecutor even ran. Proposals were created correctly, approved correctly, and then died in the execution path.

Working backwards:

ProposalConsumerWorker picked up approved proposals.
It called ProposalExecutor.execute().
ActionExecutor.execute("fix.logging") crashed with: AttributeError: 'NoneType' object has no attribute 'write_runtime_text'

write_runtime_text belongs to FileHandler, which meant file_handler was None.

I checked the daemon startup code in src/will/commands/daemon.py. It wired up git_service, knowledge_service, cognitive_service, and qdrant_service—but file_handler was never set. CoreContext defaults it to None.

The CLI path worked fine because the @core_command decorator wires the full CoreContext (including FileHandler). The daemon startup simply forgot it.

Root cause: one missing line. Months of silent failure.

The Fix That Got Rejected

The obvious patch looked like this:

# In src/will/commands/daemon.py
from shared.infrastructure.storage.file_handler import FileHandler
ctx.file_handler = FileHandler(str(BootstrapRegistry.get_repo_path()))

CORE's own audit immediately rejected it:

ERROR | architecture.boundary.file_handler_access
src/will/commands/daemon.py:199 — Forbidden import:
'from shared.infrastructure.storage.file_handler import FileHandler'

daemon.py lives in the Will layer. FileHandler lives in shared.infrastructure.storage—Body layer territory. The Will layer is not allowed to import Body infrastructure directly.

The system enforced its own architectural boundaries against its author.

The Correct Fix

Add get_file_handler() to ServiceRegistry (in the Body layer, where it belongs), then call it from the daemon:

# Proper approach
ctx.file_handler = service_registry.get_file_handler()

The import now lives where the constitution says it should.

What Happened Next

Once the pipeline started running, two more bugs surfaced:

Double write argument — ProposalExecutor passed write=True explicitly and unpacked {"write": True} from proposal parameters → TypeError: got multiple values for keyword argument 'write'.

Fixed by stripping write from parameters before unpacking.
Layer detection in LoggingFixer — The autonomous fixer converted console.print() to logger.info() in CLI-layer files because its path detection only checked for body/cli, missing src/cli/. It was breaking its own rendering.

Fixed by updating the path detection logic.

First Autonomous Completion

After the fixes:

status: completed
fixes_applied: 28
files_modified: 4
dry_run: False

No human approval. No human review. The governance pipeline ran end-to-end for the first time.

What This Revealed About Constitutional Governance

Three lessons stood out:

Silent failures are a design smell.

The fix.logging action returned ActionResult(ok=True) unconditionally, regardless of outcome. The pipeline reported success even when it wasn't. Observability isn't optional—it's a constitutional requirement.
Layer boundaries matter at runtime, not just during review.

The daemon missed file_handler because the bootstrap path (used by CLI) was never wired into the daemon path. Two code paths, one constitutional contract, and one path that didn't honour it.
The governance system catching your own mistake is the point.

The audit rejection of the wrong-layer import wasn't an obstacle. It was the system working as designed. The constitution exists precisely for moments when you're moving fast and tempted to "just make it work." The system slowed that impulse and enforced the right fix.

Where CORE Stands Now

We're not at full A3 autonomy yet. There's still an honest checklist of 8 remaining gaps—including rollback safety on partial execution failures, DB-level concurrency constraints, and the Logic Conservation Gate from an earlier test.

But Tier 1 autonomous actions now work. The loop has closed.

The system that was broken used its own constitutional rules to enforce the fix that unblocked it.

GitHub: https://github.com/DariuszNewecki/CORE

Previous posts in the series:

My AI Has 22 Workers, 2,470 Resolved Violations, and Still Can't Call Itself Autonomous. Here's the Gap.
My AI Governance System Passed Its Own Audit. Then I Wrote One Rule. Now It Fails. That's the Point. (and the rest of the CORE series)

This version should slot right into your series. It's around 4–5 min read, maintains your voice, and emphasizes the self-referential governance aspect that readers seem to engage with. The code blocks are focused and helpful without overwhelming the narrative.

If you want any tweaks (e.g., more/less detail on a specific bug, different emphasis on a lesson, or adjusting the previous posts links), just say the word.

My AI Has 22 Workers, 2,470 Resolved Violations, and Still Can't Call Itself Autonomous. Here's the Gap.

Dariusz Newecki — Mon, 23 Mar 2026 15:41:46 +0000

Or: what it actually takes to close the loop.

I've been building CORE for a while now. It's a constitutional governance system for AI agents — the thing that gives them law instead of vibes. Workers, a Blackboard, a Constitution, autonomous remediation. The full picture.

This week I sat down and did something I'd been avoiding: I honestly assessed whether CORE is ready to declare A3 — strategic autonomy. Zero blocking violations. Zero constitutional violations. Continuous self-audit. No human in the loop except at the beginning and the end.

The answer was no. But the reason why taught me more about autonomous systems than six months of building did.

What's Actually Running

First, the good news. Here's the live runtime health dashboard from this morning:

Workers:          22 active / 24 total
Blackboard:       2,470 resolved  |  1,369 open
Open findings:    1,367
Recent crawls:    3 × completed clean (1,410 files each)

Twenty-two workers heartbeating. An audit→remediate→execute pipeline that actually closes. Workers that detect constitutional violations, post them to a shared Blackboard, claim them, generate fixes via LLM, validate through a Crate/Canary ceremony, and commit to git — all without a human touching anything.

That's real. It took months to get there. The loop runs.

And yet.

The Gap Nobody Talks About

Here's what the Observer reported alongside those numbers:

Stale entries:      1,258
Orphaned symbols:   1,193
Silent workers:     8

The open finding count, before I truncated the Blackboard to get a clean baseline, was growing at +1,268 per night despite +2,755 resolutions. The sensors were posting faster than the remediator could close. The system was working — and losing ground simultaneously.

This is the thing nobody warns you about when you start building autonomous systems: activity is not the same as progress. A system can be busy, healthy, heartbeating, resolving thousands of items — and still be drifting in the wrong direction. Without a way to observe the trend, you only ever have a snapshot. Snapshots lie.

That's Gap #1: the Reporter. Not a scanner. A reader. Something that looks at accumulated history and tells you: is this system getting healthier, or is it slowly drowning?

The Validator Problem

Gap #2 is scarier.

Right now, when a Worker generates a fix and creates a Proposal, that Proposal can reach live code without passing through a deterministic gate. There's no component that checks, before execution:

Does this file start with a path comment? (trivially checkable)
Does it violate layer boundaries? (AST check)
Does the Blackboard entry carry a valid registered Worker UUID? (DB lookup)

These are not intelligence problems. They're rule problems. And the architecture explicitly calls for them — I wrote it into the implementation plan months ago as Phase 4. They just... haven't been built yet.

The absence of a Validator Chain means the system's integrity is currently dependent on the LLM getting things right. That's not a governance model. That's hope.

Smart systems get manipulated. Rules do not.

A Validator should be as dumb and reliable as possible. The whole point is that it doesn't need to understand anything — it just checks the rule. Deterministic. Unambiguous. Unbypassable.

The Deepest Gap: Logic Conservation

This one I knew about but kept deprioritising.

My own notes from a session two weeks ago read:

Phase 3.2 (Logic Conservation Gate): NOT IMPLEMENTED — Octopus A3 NOT READY for complex infrastructure refactors

The Logic Conservation Gate is the thing that prevents the autonomous loop from "fixing" something in a way that is structurally valid but semantically wrong. The code compiles. The tests pass. The logic is broken.

Without it, A3 is not autonomy. It's a very confident system making mistakes at scale and committing them to git.

This is the gate that has to exist before I'm willing to declare the loop closed. Not because the system is untrustworthy — but because the architecture must not require trust. The chain enforces integrity regardless of the quality of the model's reasoning on any given day.

What This Has to Do With LangChain

(You knew this was coming.)

The reason I'm building CORE instead of using an agent framework is precisely this: every framework I looked at gives you capability without governance. You can make the agent do impressive things. You cannot make it accountable.

When something goes wrong — and it will — you have no paper trail. No constitutional record. No way to audit what the agent decided and why. No way to know whether the fix it applied was within its declared mandate or a creative interpretation of "just fix it."

CORE's Workers are constitutional officers. Their authority comes from their declaration, not their intelligence. The LLM inside a Worker is labour. The Worker's constitution is the law.

That inversion is the whole idea.

The Actual Roadmap to A3

Here's what needs to happen, in order, before I'm willing to say the words:

Safety gates (non-negotiable):

Logic Conservation Gate — the autonomous loop cannot corrupt logic
Validator Chain — four deterministic checks before any Proposal reaches live code
WorkerAuditor hardening — governance cannot silently fail during its own cycle errors

Stability (required for sustained operation):

Test Writer Worker — a real autonomous worker, not the stub that currently logs "not yet implemented" with confidence: 0.5
Reporter with trend data — snapshots are not enough; direction is what matters

Each of these is individually deployable. Each closes a portion of the loop.

The Vision Behind All of This

I have a slogan for CORE: "last programmer you will ever need."

I mean that with complete respect for every programmer reading this. But the dynamic is changing. AI wins on raw intelligence. Humans still win on discipline — because most AI agents are brilliant but lawless.

CORE's edge is disciplined intelligence. A constitutional AI that cannot skip steps, cannot forget its mandate, cannot act without a paper trail.

The end state: you hand CORE a document — a spec, a brief, a half-finished repo, a conversation. CORE talks back until it can say: "I understand." You confirm. CORE goes quiet and delivers. No human in the loop except at the beginning (intent) and end (review).

You have an idea? CORE asks questions until it has a constitutional Intent Document you've signed off on. Then it works from that document. If it hits ambiguity it resolves it constitutionally — not by guessing and not by interrupting you.

You have a half-baked repo? CORE reads everything — code, comments, README, commit history, test names. It builds a model of intent. It tells you: "I understand this. Here is what I think it intends. Here are the gaps. Here is what I can and cannot deliver." You confirm or correct. Then it works.

That's not a feature. That's a different category of thing.

Why the Gap Is Actually Good News

Here's what struck me when I laid all this out honestly:

The nervous system is nearly done. Twenty-two workers running. The audit loop closing. Constitutional enforcement working. That took the hard part — the architecture, the law, the infrastructure.

What's missing is five specific, well-defined, individually deployable items. Not "figure out how autonomous AI governance works." Not "invent a new architecture." Five implementation tasks with clear definitions of done.

The gap between A2 and A3 is no longer philosophical. It's a checklist.

Rome was not built in one day. But at some point you stop laying foundations and start counting the remaining columns.

I'm counting columns.

CORE is an open development — I write about it here and on X as it happens, including the parts that break and the parts that block themselves. If the constitutional governance angle interests you, check my previous posts.

DariuszNewecki / CORE

Governance runtime enforcing immutable constitutional rules on AI coding agents

CORE

Executable constitutional governance for AI-assisted software development.

The Problem

AI coding tools generate code fast. Too fast to stay sane.

Without enforcement, AI-assisted codebases accumulate invisible debt — layer violations, broken architectural contracts, files that grow unbounded. And agents, left unconstrained, will eventually do something like this:

Agent: "I'll delete the production database to fix this bug"
System: Executes.
You:    😱

CORE makes that impossible — not detectable after the fact. Impossible.

Agent: "I'll delete the production database to fix this bug"
Constitution: BLOCKED — Violates data.ssot.database_primacy
System: Execution halted. Violation logged.
You:    😌

CORE is a governance runtime that constrains AI agents with machine-enforced constitutional law — enforcing architectural invariants, blocking invalid mutations automatically, and making autonomous workflows auditable and deterministic.

LLMs operate inside CORE. Never above it.

🎬 Live Enforcement Demo

Blocking rule → targeted drilldown → automated remediation → verified compliance.

This demo shows:

A structural…

View on GitHub

My AI Governance System Passed Its Own Audit. Then I Wrote One Rule. Now It Fails. That's the Point.

Dariusz Newecki — Mon, 16 Mar 2026 16:11:01 +0000

This morning CORE's audit looked like this:

Rules declared: 115    Rules executed: 99
Total findings: 349

Final Verdict: PASSED ✅

By afternoon:

Rules declared: 116    Rules executed: 100
Total findings: 380    Errors: 31

Final Verdict: FAILED ❌

I didn't break anything. I wrote two files. Here's what happened.

The Gap

CORE has a cognitive role system. Every AI call must go through a PromptModel artifact that declares which role handles the invocation. The rule is written in the constitution:

"Cognitive role must be read from model.manifest.role, never hardcoded."

The correct pattern:

pm = PromptModel.load("my_artifact")
client = await self.cognitive_service.aget_client_for_role(pm.manifest.role)

The wrong pattern:

client = await self.cognitive_service.aget_client_for_role("Coder")

The constitution said this was illegal. But there was no rule enforcing it. So the audit couldn't see it.

A quick grep confirmed what was hiding:

grep -rn 'aget_client_for_role("' src/ | grep -v 'manifest\.role'

32 violations. 28 files. Including the ViolationRemediator — the worker that fixes other violations.

Two Files

.intent/rules/ai/cognitive_role_governance.json — the rule:

{
    "id": "ai.cognitive_role.no_hardcoded_string",
    "statement": "All calls to aget_client_for_role() MUST pass the role from model.manifest.role. String literals are PROHIBITED.",
    "enforcement": "blocking",
    "rationale": "A hardcoded role string bypasses the PromptModel governance layer entirely. Ungoverned, untestable, invisible to audit."
}

.intent/enforcement/mappings/ai/cognitive_role_governance.yaml — the enforcement:

mappings:
  ai.cognitive_role.no_hardcoded_string:
    engine: regex_gate
    params:
      forbidden_patterns:
        - "aget_client_for_role\\(\"[A-Za-z]"
    scope:
      applies_to:
        - "src/**/*.py"
      excludes:
        - "src/will/orchestration/cognitive_service.py"  # IS the implementation

Ran the audit. 31 blocking errors.

Why FAILED Is the Right Answer

These violations didn't appear today. They were there for months — silent, invisible, passing every audit.

The audit was passing because the law hadn't been written yet.

A passing audit against an incomplete constitution isn't a clean bill of health. It's an unknown. Writing the rule didn't create the problem. It revealed it.

Before touching a single file, I committed:

git add -A && git commit -m "feat(governance): add ai.cognitive_role.no_hardcoded_string

31 blocking violations now visible. Previously silent.
Constitutional act: new law, enforcement active."

Now 31 files need remediation. CORE already generated the commands. One file at a time.

CORE is open source: github.com/DariuszNewecki/CORE

The PromptModel pattern was inspired by Ruben Hassid — worth following.

My Constitutional Auditor Missed Dead Code. Here's Why — and What I'm Doing About It.

Dariusz Newecki — Tue, 10 Mar 2026 20:23:31 +0000

A live investigation. This post will be updated as I dig deeper, fix it, and reflect on what it means.

The Discovery

Today I deleted a file called llm_api_client.py.

It had no imports pointing to it anywhere in the codebase. Pure orphan. Dead code by any definition.

The problem: CORE's constitutional auditor didn't catch it.

CORE has a rule called purity.no_dead_code:

{
  "id": "purity.no_dead_code",
  "statement": "Production code MUST NOT contain unreachable or dead symbols as identified by static analysis.",
  "enforcement": "reporting"
}

The rule exists. The audit runs it on every core-admin code audit call. It produced exactly 1 warning in recent runs — but not for llm_api_client.py.

I only found the dead file manually, while working through a separate compliance task.

That's a problem worth understanding.

The Investigation: What Is the Auditor Actually Doing?

CORE's enforcement model separates what the law says from how it's enforced. The rule lives in .intent/rules/, the enforcement mechanism lives in .intent/enforcement/mappings/.

Here's the full enforcement declaration for purity.no_dead_code:

purity.no_dead_code:
  engine: workflow_gate
  params:
    check_type: dead_code_check
    tool: "vulture"
    confidence: 80

Vulture. A solid static analysis tool — but one with a specific scope. Vulture finds unused symbols within files: functions that are defined but never called, variables assigned but never read, classes that are never instantiated.

What vulture does not do: traverse the import graph to find files that nothing imports.

llm_api_client.py likely had internal symbols that appeared "used" within the file itself. From vulture's perspective: no violations. From reality's perspective: the entire file was unreachable from the rest of the system.

The rule says: "unreachable or dead symbols"

The enforcement checks: unused symbols inside files

These are two different things. The enforcement is a subset of what the rule claims to guarantee. The constitution was shallow.

The Insight

This is, I think, the most honest thing I can say about constitutional AI governance:

The constitution is only as strong as its enforcement mechanisms. A rule that exists but enforces shallowly is not a guarantee — it's an aspiration.

CORE did exactly what it was told. No more, no less. The law declared "no dead code." The enforcement mechanism checked for unused symbols. The file slipped through the gap between what the law said and what the enforcement did.

This isn't a criticism of the approach. It's the nature of any governance system — constitutional law included. The text of the law and the apparatus that enforces it are always two separate things. The gap between them is where violations live.

What matters is: can the system correct itself when the gap is found?

In CORE's model, the fix is a .intent/ declaration change. Not Python. Not a code patch. A policy update that changes enforcement behavior system-wide.

What the Fix Looks Like (Conceptually)

True dead file detection requires import graph traversal — building a dependency graph of the entire codebase and identifying files that no entry point can reach.

Tools that can do this: pydeps, custom AST graph traversal, or a knowledge_gate that queries CORE's own symbol database (which already tracks file-level relationships via core.symbols).

The declaration change would look something like:

purity.no_dead_code:
  engine: workflow_gate
  params:
    check_type: dead_code_check
    tool: "vulture"          # symbol-level: keep this
    confidence: 80
  # ADD:
  additional_checks:
    - check_type: orphan_file_check
      engine: knowledge_gate
      params:
        check_type: unreachable_files
        entry_points:
          - "src/cli/"
          - "src/body/atomic/"

I checked. CORE's knowledge_gate currently supports:

capability_assignment
ast_duplication
semantic_duplication
duplicate_ids
table_has_records

No orphan file detection. No import graph traversal.

The gap goes deeper than a declaration change. A new check_type implementation is needed — which means extending knowledge_gate itself, or building a dedicated engine. The .intent/ declaration is the easy part. The enforcement mechanism has to exist first.

This is the rabbit hole.

Status

[x] Dead file discovered manually (llm_api_client.py)
[x] Root cause identified (vulture scope vs. import graph traversal)
[x] Constitutional gap diagnosed (rule vs. enforcement mismatch)
[x] Investigation: knowledge_gate does not support orphan file detection — new engine needed
[ ] Design: new check_type for import graph traversal
[ ] Implementation: extend knowledge_gate or build dedicated engine
[ ] Declaration: update .intent/enforcement/mappings/code/purity.yaml
[ ] Verify: audit now catches what it missed
[ ] Reflection: what this means for CORE's autonomy claims

[UPDATE 1 — coming soon: designing the orphan file check — declaration-first, engine second]

[UPDATE 2 — coming soon: implementation and proof it works]

[UPDATE 3 — coming soon: the philosophical reflection on constitutional blind spots]

CORE is open source: github.com/DariuszNewecki/CORE

Credit: the PromptModel artifact pattern was inspired by Ruben Hassid's prompt engineering work.

How CORE Used Its Own Pipeline to Eliminate 36 Constitutional Violations — Including Its Own

Dariusz Newecki — Tue, 10 Mar 2026 14:21:56 +0000

Or: what happens when the enforcer has to obey its own law.

I've written before about CORE blocking itself — that single moment when constitutional governance catches a violation in real time. This post is about something harder: systematically eliminating 36 violations across the codebase, using CORE's own autonomous workers to do it.

The milestone: BLOCKING: 0. Zero. After 36.

Here's how it happened, and what it revealed.

The Rule

CORE has a constitutional rule called ai.prompt.model_required. It's declared in .intent/rules/ai/prompt_governance.json and enforced as blocking — meaning any audit run with a violation fails unconditionally.

The rule is simple: every LLM call in CORE must flow through PromptModel.invoke(). No direct calls to make_request_async(). Anywhere. Ever.

{
  "id": "ai.prompt.model_required",
  "level": "blocking",
  "description": "All AI invocations must use PromptModel.invoke(). Direct make_request_async() calls are prohibited."
}

The reasoning is architectural. If you can call an LLM directly from anywhere in the codebase, you get:

Inline prompts scattered across files (ungoverned, unversioned, untestable)
No input contract — any string can be passed
No output validation — any response is accepted
No visibility into what the system is actually asking AI to do

PromptModel solves this by requiring every AI invocation to declare itself in var/prompts/<name>/:

var/prompts/docstring_writer/
    model.yaml     # id, role, input contract, output contract
    system.txt     # constitutional system prompt
    user.txt       # user-turn template with {placeholders}

Before the audit runs, 36 places in the codebase were bypassing this entirely.

The Pipeline

Rather than fix them manually, I built a 4-worker autonomous pipeline:

AuditIngestWorker → PromptExtractorWorker → PromptArtifactWriter → CallSiteRewriter

Each worker posts findings to a shared blackboard. The next worker claims and processes them.

AuditIngestWorker runs core-admin code audit, parses the output, and posts one blackboard entry per violation with file path and line number.

PromptExtractorWorker reads each violation, fetches the source, and uses an LLM (via PromptModel — yes, the pipeline is itself constitutional) to extract the inline prompt and identify its inputs.

PromptArtifactWriter materialises the var/prompts/<name>/ directory: model.yaml, system.txt, user.txt.

CallSiteRewriter rewrites the Python file — replaces the direct make_request_async() call with PromptModel.load(...).invoke(context={...}).

Result after one pipeline run: 36 → 10 violations.

The remaining 10 had patterns the pipeline couldn't handle automatically (complex conditional prompts, unusual call sites). Those required manual fixes, which I'll come back to.

The Irony: The Enforcer Had to Obey Its Own Law

Here's where it gets interesting.

One of the remaining violations was in llm_gate.py — the engine that enforces ai.prompt.model_required. It contained a direct make_request_async() call to perform its LLM-based semantic check.

The temptation was to add an exclusion. But that would be duck tape. The principle is: law outranks intelligence. If the rule applies everywhere, it applies to the enforcer.

The fix required two things:

Rename the protocol method from make_request to invoke_semantic_check — killing the false positive at the source, not via exclusion
Give llm_gate.py its own PromptModel artifact at var/prompts/llm_gate/

# Before (constitutional violation)
response = await client.make_request_async(prompt, user_id="llm_gate")

# After (constitutional compliance)
model = PromptModel.load("llm_gate")
response = await model.invoke(
    context={"instruction": rule.instruction, "rationale": rule.rationale, "code_content": code},
    client=client,
    user_id="llm_gate",
)

The principle this enforces: no exceptions, no exclusions, no "this one is special". Every AI call is governed. The enforcer is not exempt.

The Manual Fixes

The pipeline abandoned 10 violations. I worked through them one by one. A few patterns worth noting:

Branch-dependent prompts (llm_correction.py) — the file had two different prompts chosen at runtime based on syntax_only. This required two separate artifacts: llm_correction_syntax and llm_correction_structural. The branch logic stayed in Python; the prompts moved to var/prompts/.

if syntax_only:
    model = PromptModel.load("llm_correction_syntax")
else:
    model = PromptModel.load("llm_correction_structural")

response = await model.invoke(context={...}, client=client, user_id="self_correction")

Module-level prompt constants (body_contracts_fixer.py) — a textwrap.dedent() string defined at module level, concatenated with runtime data in the worker. The constant became system.txt, the dynamic parts became {placeholders} in user.txt.

Dead code (llm_api_client.py) — one file had no imports anywhere. Deleted entirely. Violation gone.

The Audit Progression

State	Blocking violations
Start	36
After dead code deletion + llm_gate fix	33
After pipeline (22 files rewritten)	10
After manual fixes batch 1	8
After manual fixes batch 2	3
After final 3	0

What Zero Blocking Violations Actually Means

PASSED in the audit output now means something concrete. Every LLM invocation in CORE:

Has a declared identity (id in model.yaml)
Has a role (Coder, Architect, CodeReviewer — resolved by CognitiveService)
Has a validated input contract (missing required inputs raise before the call is made)
Has a versioned, reviewable prompt (in var/prompts/, not scattered across source files)
Has an output contract (optional, but available)

The codebase went from "AI calls happen somewhere, somehow" to "every AI call is a first-class declared artifact".

This is what git tag v-a3-candidate means in CORE's autonomy ladder. Not that the system is feature-complete — there are 107 reporting warnings still open (modularity, file size, dead code). But the constitutional foundation is clean. The system can trust its own audit output.

The Broader Point

The pattern here isn't specific to CORE. If you're building any system that makes LLM calls:

Inline prompts are technical debt. They're ungoverned strings scattered across your codebase. You can't audit them, version them, test them, or enforce contracts on them.

Governance at the call site doesn't scale. You can't review every make_request_async() manually as the codebase grows.

The right abstraction is a declared artifact. Every AI invocation type should have an identity, a contract, and a home on disk. The invocation surface should be narrow and enforced — not wide open.

Whether you call it PromptModel, a prompt registry, or something else: the principle is the same. Prompts are policy. Policy belongs in declarations, not in code.

Credit: the PromptModel artifact pattern was inspired by Ruben Hassid's prompt engineering work.

CORE is open source: github.com/DariuszNewecki/CORE

If you're working on constitutional AI governance, autonomous code generation, or similar problems — I'd genuinely like to hear what you're building.

Closing the Loop: From Audit Violation to AI Fix in One Command

Dariusz Newecki — Tue, 03 Mar 2026 21:35:03 +0000

Every developer who uses static analysis tools knows the feeling. You run your linter or audit tool, get a wall of violations, and then spend 10 minutes manually figuring out what to show your AI assistant to fix them.

Copy the file path. Find the relevant class. Construct a prompt. Hope the AI has enough context.

We just eliminated that entire step in CORE.

The Problem

CORE has a constitutional governance system — 85 rules that audit the codebase for violations ranging from architectural boundaries to AI safety patterns. When the audit fails, you get output like this:

❌ AUDIT FAILED
  ai.prompt.model_required    │ 38 errors
  architecture.max_file_size  │ 13 warnings
  modularity.single_responsibility │ 11 warnings

Useful. But then what? You still have to manually translate "ai.prompt.model_required in src/will/agents/coder_agent.py line 158" into a context package that an AI can actually work with.

That translation is pure mechanical mapping. It shouldn't be human work.

The Insight

Audit tools know what is broken and where.

Context tools know what the AI needs to see to fix it.

The gap between them is just a function call.

What We Built

Part 1: `core-admin context build`

First, we built a command that simulates exactly what the autonomous CoderAgent sees before generating code. Not a semantic search, not a guess — the exact same pipeline:

core-admin context build \
  --file src/will/agents/coder_agent.py \
  --symbol CoderAgent \
  --task code_modification \
  --output var/context_for_claude.md

Output:

================================================================================
CORE CONTEXT PACKAGE  [Agent Simulation Mode]
================================================================================
Target file  : src/will/agents/coder_agent.py
Target symbol: CoderAgent
Task type    : code_modification
Items        : 8
Tokens (est) : ~3644
Build time   : 944ms

### 1. src/shared/context.py::CoreContext
Source : 🔍 vector search / Qdrant (semantic: 0.74)
...

### 6. src/will/agents/coder_agent.py::CoderAgent.build_context_package
Source : 🗄️  DB lookup (direct / graph)
...

Every item shows why it was included — AST force-add, DB graph traversal, or vector search with score. You can verify the AI's "view" before it touches anything.

Part 2: Audit hints

Then we added one function to the audit formatter. When the audit fails, it now prints the exact command to run for each actionable finding:

╭─────────────── AI Workflow — Next Steps ───────────────╮
│ 65 actionable location(s). Run the command below for   │
│ each, then paste the output to Claude.                 │
╰────────────────────────────────────────────────────────╯

  ERROR ai.prompt.model_required
  Line 158: direct call to 'make_request_async()' detected.

  core-admin context build \
      --file src/will/agents/coder_agent.py \
      --task code_modification \
      --output var/context_for_claude.md

  ERROR ai.prompt.output_validation_required
  Line 199: missing mandatory call(s): ['_validate_output']

  core-admin context build \
      --file src/shared/ai/prompt_model.py \
      --symbol _validate_output \
      --task code_modification \
      --output var/context_for_claude.md

The audit knows the file. It knows the rule. The mapping to task type is mechanical (ai.* → code_modification, test.* → test_generation). So it just... does it.

The Complete Workflow

core-admin code audit
  → ❌ FAILED
  → 💡 65 actionable locations
  → copy one context build command
  → run it → var/context_for_claude.md
  → paste to Claude
  → fix
  → repeat

Zero manual translation. Zero "what should I show the AI?" The audit tells you exactly what to run next.

The Meta Moment

After deploying, we ran the audit again. CORE found modularity debt in the files we had just written:

WARN  modularity.single_responsibility
src/cli/commands/check/formatters.py  ← file we just edited

WARN  modularity.single_responsibility
src/cli/resources/context/build.py    ← file we just built

And immediately printed:

core-admin context build \
    --file src/cli/resources/context/build.py \
    --task code_modification \
    --output var/context_for_claude.md

The system audited our work and told us how to fix it. That's the governance model working as designed.

Why This Matters

Most AI coding workflows are: human decides what context to provide → AI generates → human reviews.

The bottleneck is the first step. What context? Which file? Which class? How much?

CORE's constitutional audit already has that information. It found the violation, it knows where it lives. The only missing piece was surfacing it in a form that feeds directly into the next action.

This pattern is general. Any tool that produces findings with file paths and rule IDs can do this. Your linter, your security scanner, your test coverage report — they all know what's broken. The question is whether they tell you what to do next.

Code

CORE is MIT licensed and available at github.com/DariuszNewecki/CORE.

The relevant pieces:

src/cli/resources/context/build.py — agent simulation command
src/cli/commands/check/formatters.py — print_context_build_hints()

The core idea fits in about 60 lines. The _extract_symbol() function tries three approaches in priority order: structured context dict, then message parsing. _infer_task_type() maps rule prefixes to task types. The rest is just formatting.

CORE is a constitutional AI governance system — an experiment in building autonomous development tools that remain safely bounded by human-defined constraints. Previous post: Building an AI That Follows a Constitution

CORE's PromptModel pattern was inspired by prompt engineering work by Ruben Hassid — worth following if structured AI invocation interests you.

DEV Community: Dariusz Newecki

When My Governance System Governed Itself Wrong

Background

The Problem

Finding the Root Cause

The Architectural Lesson

What Got Fixed

Current State

PASSED with 252 findings. FAILED with 78. Which audit would you trust?

The paradox

The instrument qualification problem

Case 1: The orphan file detector

Case 2: The modularity score

The verdict paradox

The principle

I Spent a Saturday Cleaning My Own Repo. CORE Made Me.

The broken command nobody noticed

"If the docs lie, the system lies."

What a Saturday of self-governance looks like

The CLI reference problem is the whole problem in miniature

What this has to do with autonomy

The self-referential part

If you're curious

The AI That Refused To Ship Its Own Fix

The Setup

The Gate That Wasn't Wired

83 Silent Failures, Now Loud

319 Stuck Findings

What Makes This Different

Who This Is For

Your Agent Has Two Logs. One of Them Doesn't Exist Yet.

Two Logs, Not One

What CORE Gets Right

Where The Gap Actually Lives

.intent/ Is a Shim

The Architecture Is Self-Similar By Design

What The Thread Built

The Day CORE's Author Finally Followed CORE's Own Rules

A bit of honest backstory

CORE demands something from every project it touches

So guess what I had never written for CORE itself.

How I finally got there

Writing the requirements properly

Where does the document live?

The irony isn't lost on me

The governing invariant

How one missing line broke months of autonomous self-improvement — and what fixing it revealed about constitutional software governance

The Investigation

The Fix That Got Rejected

The Correct Fix

What Happened Next

First Autonomous Completion

What This Revealed About Constitutional Governance

Where CORE Stands Now

My AI Has 22 Workers, 2,470 Resolved Violations, and Still Can't Call Itself Autonomous. Here's the Gap.

What's Actually Running

The Gap Nobody Talks About

The Validator Problem

The Deepest Gap: Logic Conservation

What This Has to Do With LangChain

The Actual Roadmap to A3

The Vision Behind All of This

Why the Gap Is Actually Good News

DariuszNewecki / CORE

Governance runtime enforcing immutable constitutional rules on AI coding agents

CORE

The Problem

🎬 Live Enforcement Demo

My AI Governance System Passed Its Own Audit. Then I Wrote One Rule. Now It Fails. That's the Point.

The Gap

Two Files

Why FAILED Is the Right Answer

My Constitutional Auditor Missed Dead Code. Here's Why — and What I'm Doing About It.

The Discovery

The Investigation: What Is the Auditor Actually Doing?

The Insight

What the Fix Looks Like (Conceptually)

Status

How CORE Used Its Own Pipeline to Eliminate 36 Constitutional Violations — Including Its Own

The Rule

`.intent/` Is a Shim

Part 1: `core-admin context build`