Requirements next to the code are not a replacement for the tools you plan your work with. This page draws the line and names the price, so you can decide before you start.
What CodeCharter is not
CodeCharter is not a ticket system. There is no assignment to a person, no status workflow across columns, no estimation, no sprint, and no board. A requirement carries a delivery status, but it describes the state of the promise, not the state of a work package.
It is not a backlog. Ideas, wishes, and topics not yet decided still belong wherever you collect them today. A requirement only enters the corpus once it has been decided and someone later wants to know whether it was fulfilled.
It is not project management. CodeCharter does not model deadlines, dependencies between work packages, capacity, or progress reports. The only dependency the corpus knows is a substantive one: one requirement refines another, one requirement conflicts with another, or a criterion is waiting on another.
And it is not a content check. Whether the text is correct and whether the bound test tests the right thing is decided by a human. The tool checks the structure, the binding, and the durability of the evidence.
Relationship to ticket systems and ALM tools
Jira, Azure Boards, Linear, and comparable tools plan work. They answer who is working on what and what comes next. Classic requirements and ALM tools, by contrast, manage a stock of requirements with versioning, approvals, and proof, but sit next to the repository and demand their own maintenance to keep the link to the code current.
CodeCharter does not fully occupy either role. It covers the narrow strip where the two usually drift apart: the binding between a decided promise and the place in the code that fulfills it, checked by the same run that also gates your findings. You keep the ticket system. A separate requirements tool can be dropped if its only remaining purpose is proof against code.
A workable side-by-side setup looks like this: the ticket system runs the
work, the corpus runs the promises, and the ticket number goes in the
requirement's source field, so the way back stays open.
Bringing in an existing specification document
The corpus consists of ordinary Markdown files, so the way in is legwork, not an import project. This order has proven itself.
Start with the requirements that are truly subject to proof. In a specification document with two hundred sentences, that is rarely more than twenty to thirty. Everything else can come later, or not at all.
Create a <id>.req.md file for each and carry the original text into the
body instead of rephrasing it. The reference to the source location belongs
in section and source, so nobody later has to guess where the sentence
came from.
Set the status honestly. A requirement you have long since implemented is
set to implemented and then also needs an anchor, otherwise
codecharter req check reports an error. That is exactly the point of the
exercise.
Finally, mirror the outline of the original document in documents.yml.
Then something the client recognizes as a specification document,
requirements document, or acceptance protocol can be generated from the
corpus again.
An AI agent can prepare this transfer. req_draft drafts requirements and
req_bind suggests criteria and anchors, both explicitly for human review.
Acceptance stays with you in every case.
What maintenance costs
Creating a requirement takes a few minutes; formulating the criteria honestly takes longer, because that is where the real work happens: deciding what tells you the promise has been fulfilled. You do not save this time, you only move it earlier, ahead of acceptance.
In ongoing operation, three recurring efforts arise. When a code change touches an anchored place, someone has to renew the acceptance. When a new promise arises, a file gets added. And if you turn on the coverage gate, every new method without a justification becomes a decision: either anchor it or deliberately classify it as infrastructure.
The cost should be borne by whoever is responsible for the promise, usually the same person who writes the change, not a separate role alongside it. As soon as maintenance is delegated to a person who does not write the code, the corpus drifts again, and then you have the original problem back, just in a different file format.
When it is not worth it
If you are building an internal product without formal acceptance, your requirements arise as tickets and are done once merged, and nobody later demands proof, then the corpus brings you little and still costs maintenance. In that case, the rest of CodeCharter is unaffected: analysis, rules, coverage, and the gates work without a single requirement entry.
Next steps
- Requirements at a glance: what the corpus is for
- First requirement: the practical starting point
- Requirements: the file format with all fields