SCEpter

SCEpter is a CLI-first knowledge graph that lives inside a codebase. Documentation gets atomised into individual claims with stable IDs (R012.§1.AC.15-style), and each claim gets tracked across the artifacts that derive from it — requirements to specifications to detailed designs to code to tests. When a requirement makes a promise, the trace matrix tells you which spec realised it, which design refined it, which file implemented it, and which test validates it. Coverage gaps become a CLI query instead of a memory exercise.

It’s designed primarily to be operated by AI coding agents, but it’s plain markdown and JSON underneath. Humans can read and edit it directly.

Why this exists

The honest reason I built SCEpter is that AI coding agents lose context. A session that took three hours to build a deep understanding of your system evaporates the moment the conversation hits a context limit. The next session starts cold, re-reads what it can find, hallucinates the rest, and either rebuilds the same understanding from scratch or — more often — quietly diverges from it.

The conventional fix is “write better documentation.” That doesn’t survive contact with reality. Documentation drifts from the code, becomes out of date, gets contradicted by newer documentation written elsewhere, and an agent reading it has no way to know which sentence is current.

SCEpter takes a different stance. Instead of trusting prose, give every claim that matters a stable identifier and a mechanically-checked annotation chain. The implementation cites the design claim it realises. The design claim cites the spec claim it derives from. The spec claim cites the requirement. The whole chain is queryable. When something is incomplete or stale, the CLI says so out loud.

This is the same thesis as Stellium approached from the other direction. Stellium is about making the data layer itself structured enough for agents to operate. SCEpter is about making the discipline of building software with those agents structured enough that nothing important gets lost between sessions.

What it actually tracks (and what it doesn’t)

This is the most important thing to understand about SCEpter, and I want to put it up high so it doesn’t get lost:

The trace matrix tracks expressions, not truth.

SCEpter does not prove your code is correct. It does not verify that an @implements annotation matches the spec it cites. It is not AI fact-checking. What it gives you is the mechanical guarantee that the bookkeeping is complete — that every requirement has somewhere it’s expressed downstream, that every implementation cites the claim it realises, that every gap is named. Truth still requires humans, tests, and review.

The distinction matters because it’s the difference between epistemic theatre — a tool that pretends to verify things it can’t — and epistemic bookkeeping, which is the thing I actually find useful. SCEpter helps you keep track of what you’ve said you’ll do. It doesn’t promise that what you did was right.

How you use it

The CLI is the user-facing surface. scepter create Requirement starts a new note from a template. scepter ctx gather <ID> assembles all the linked context for a task. scepter claims trace computes the projection matrix from a requirement down through the artifacts that derive from it. scepter claims gaps reports missing derivations. scepter lint validates structure.

Note types are configured per project. Requirement / Specification / DetailedDesign / TestPlan are the defaults, but the schema lives in a scepter.config.json you control — a research project might use Hypothesis / Experiment / Finding instead. The shape is yours; the discipline is the same.

For AI agents specifically, SCEpter ships with four Claude Code subagents — sce-producer writes notes, sce-reviewer validates them, sce-researcher investigates the graph, sce-linker keeps the cross-references hygienic — and a Skill that loads the methodology into the model at the start of every session. There’s also a programmatic chat orchestrator for non-Claude-Code workflows.

Who this is for

Solo developers running AI coding agents heavily on non-trivial projects. Small teams where decisions need to be externalised because no single session — human or AI — holds them all. Projects with rich acceptance criteria where “did we actually implement every AC?” matters and can’t be a memory exercise. Anyone who wants a maximalist context-capture habit because the consumer of that context is a language model that genuinely benefits from the structure.

It’s explicitly not for projects where lightweight notes are enough, or teams already happy with Jira plus ADRs. SCEpter is deliberately more rigorous than a human would bother being, because the discipline is in service of agents who get real value from the rigour.

What this is, right now

v0.1.0, MIT-licensed, dogfooded against its own development — _scepter/ is the project’s own knowledge graph. No npm install yet; setup is git clone && npm link && /scepter from your project. Usable today by motivated early adopters; not packaged for a casual quick-start. Active development; the metadata event log subsystem stabilised in April 2026 and the workflow recipes settled around the same time.