How this works in practice
No sales-page gloss: the whole cycle, what you need to connect, what the platform writes — and what it never does on its own.
There is no public API yet. When there is, the reference documentation lands on this page; for now, this page answers how the product works.
The cycle, from request to report
Every requirement walks the same nine-step path, and every step has an owner. The agent validates and attests; the decisions — accepting an objection, accepting the spec, approving a publication — always belong to a person.
- 1 · Requirement writtenhuman
- In ClickUp, Jira, the wiki or right in the platform — the way your team already writes it.
- 2 · Validation against the codeagent
- The agent reads the system you already have and returns objections with evidence at file:line. It is the most valuable step: the mistake is still text.
- 3 · Response cyclehuman
- The author accepts and adjusts, or pushes back and keeps it. Both are recorded.
- 4 · Spec generationagent
- The settled requirement becomes a spec in the project’s own format, item by item, each traced to the criterion it translates.
- 5 · Spec acceptancehuman
- By whoever will build it — and never by whoever wrote that version of the requirement. It is the one mandatory segregation.
- 6 · Developmenthuman
- The platform stays out: it does not write feature code.
- 7 · MR captureplatform
- The opened MR/PR is picked up by webhook, no manual step.
- 8 · Attestationagent
- Code × requirement × spec, criterion by criterion, with a verdict and evidence. Without evidence confirmed in the commit, the verdict drops to inconclusive.
- 9 · Publicationplatform
- The opinion becomes a comment on the code review — published after approval, or automatically if the project policy says so.
What you need to connect
Three connections, all in the project settings. Credentials go in encrypted and never come back: no API response returns one.
- Requirement source
- ClickUp, Jira or NextWiki — wherever the card already lives. The requirement is read from there, and it stays there.
- Git repository
- GitLab (self-hosted included), GitHub or Azure DevOps. Read access for the mirror, plus the MR webhook.
- Notifications (optional)
- Discord or Telegram, so the team knows when an attestation finishes.
- An AI account
- Your own, or a local model. The screen shows where your code goes before anything runs.
What the platform writes, and where
Every external write is a proposal: the exact text shows up first, and someone approves it — or a project policy approves it automatically, with the reason on record. Nothing is written without a record.
- A comment on the code review
- The attestation’s opinion, as a note. The MR/PR approval state is never touched.
- A comment on the card
- Objections and results, in the tool where the requirement lives.
- A message on the channel
- The done notice, with the link.
That is the entire list.
What it never does on its own
- Write feature code
- Never. Aferiz audits, questions and proposes; it does not implement.
- Commit or push
- Under no circumstance — not even with approval.
- Approve a merge
- Approving a proposal publishes a comment; merging stays with people.
- Put a standard rule in force
- An inferred standard is a proposal. Approval is human, rule by rule, with no self-approval path — not by API, not by configuration.
- Close an objection
- The requirement’s author accepts or pushes back. If the agent could close what it raised, the record would stop counting as proof.
- Force a verdict
- When the evidence does not hold, the answer is inconclusive. Forcing a verdict is worse than admitting doubt.
What does not exist yet
The honesty of the rest of this site applies here too.
- Public API and MCP
- Specified, not yet published. The reference documentation lands on this page when they exist.
When something on this list changes, it changes here first.