ClarixERR

What ClarixERR does

Organized by what you are trying to get done, with what sets ClarixERR apart first. Everything listed here is in the product today.

Know who decided, in what capacity, and who answers for it now

Every approval, waiver, sign-off and review verdict records the decider's position, department and permissions at the moment they decided, so a title change or a departure never rewrites the record.

When a decider has left, the record points to whoever holds that seat today and says how it reached that answer.

Each requirement shows the approvals it inherits from the goals and requirements above it, and stakeholders sign off in plain language against the version they actually read.

  • Read who approved, on which version, and in what capacity
  • Find who holds a departed decider's seat today
  • See the decisions made in the seat you now hold
  • Read the authority a requirement inherits from above
  • Collect stakeholder sign-off on the version they read
  • Record a compliance review against a programme
A requirement's approval record: who approved it, on which version, under which policy and in what capacity, followed by the approvals it inherits from the requirements above it.Create your organization

Produce the specification from the record instead of rewriting it

Generate an architecture requirements specification, or architecture definition sections by domain, from a published baseline, with every requirement at the version that was approved, its acceptance criteria, its approvals and the traceability matrix.

Generate a change impact report from a completed assessment, with before-and-after wording read from version history rather than retyped.

Your templates set the sections and their order, and a document whose baseline has since moved on says so every time it is opened.

  • Generate an architecture requirements specification
  • Generate architecture definition sections by domain
  • Generate a change impact report for a board
  • Export a document as a web page or Markdown
  • Set the sections, their order and fixed text
  • Export the catalogue to a spreadsheet
An architecture requirements specification generated from a published baseline, citing the baseline and listing each requirement at the version that was approved.Create your organization

Keep architecture, portfolio and delivery tools in step without retyping

Epics, features and stories are created in the backlog tool your teams use, each carrying the requirement it traces to, and their status, sprint, assignee and completion come back.

An edit made in the tool is shown word for word and waits for a person to keep one version, so neither side silently overwrites the other.

Applications, architecture elements and initiatives mastered in your enterprise-architecture tool are linked as read-only references, so traces reach them without a second copy to maintain.

  • Create and update delivery items in a backlog tool
  • Bring status, sprint and assignee back
  • Settle an edit made in the tool, word for word
  • Find work that already exists before creating it twice
  • Link elements from an enterprise-architecture tool
  • Connect any other tool through a published contract
A feature kept in step with a backlog tool: the item it was created as there, and the status, iteration and assignee that came back.Create your organization

Get requirements out of documents and into a structure you can query

Every requirement is a fact sheet: a registered type, an attribute schema, a lifecycle, and an owner, defined in a metamodel you can read rather than buried in a form.

Start from a template, import a spreadsheet you already have, or capture rough notes into an inbox and promote the ones worth keeping.

Nothing is deleted: a requirement is withdrawn, retired or superseded, and every version it passed through stays readable.

  • Create a requirement of any registered type
  • Start from an EARS or quality-attribute template
  • Import a spreadsheet, with a dry run before you commit
  • Capture rough notes and triage them later
  • Read any earlier version, and compare two
  • Change many at once
  • Find any requirement by key, name or wording
The metamodel: every record type, its attributes, its lifecycle and the relationships it may take part in.Create your organization

Know who approved what, and on which version

Review policies decide who reviews a requirement and how many of them must agree, by type, by engagement, or by priority; the policy in force is pinned to the item when review starts, so editing it afterwards never changes a review already under way.

Reviewers work from their own queue, comments anchor to the words they are about, and a reviewer who returns an item has to say why.

Approval writes a record: who approved, which version, under which policy, with the verdicts that decided it.

  • Define review policies per type, engagement or priority
  • Work from a reviewer's queue
  • Record a verdict, with a reason for a return
  • Comment on the exact wording under discussion
  • Read the approval record for any requirement
  • Waive a quality threshold, with an expiry
  • Assign follow-up work beside a requirement without changing it
A reviewer's queue: the requirements assigned to them, each waiting on a verdict.Create your organization

Freeze what was agreed, and make every later change answer for itself

A baseline captures an approved set at the version each item was at, and once published it cannot be edited at all, so what it says today is what it said when it was agreed.

Changes after that go through a change request carrying its reason, its urgency and the requirements it affects; impact analysis walks the trace graph to show what else moves, and the assessment records the decision.

A baseline the repository has moved past is marked outdated, and any two can be compared to show exactly what changed between them.

  • Create and publish a baseline
  • Preview what a baseline would capture before publishing it
  • Compare two baselines, or one against today
  • Raise a change request against approved requirements
  • Run impact analysis across the trace graph
  • Record the decision on an impact assessment
  • Bring requirements back for review on a cadence set by how volatile they are
A published baseline, listing every requirement it captured and the version each was at.Create your organization

Answer “what does this requirement come from, and what closed it?” without rebuilding it by hand

Relationships are typed, versioned and validated against a catalogue, so a link means something specific rather than “these are related”, and retiring an item marks its links historical rather than erasing them.

The matrix marks every confirmed trace between any two types, directly or through intermediates you configure, and names the rows and columns that nothing reaches; coverage analysis answers the same question as a list of what has no upstream, no downstream, or no requirement realizing it.

When a requirement changes materially the traces leading out of it are flagged as suspect, so somebody re-confirms them rather than assuming they still hold.

  • Link requirements with typed, versioned relationships
  • Walk the graph one hop at a time
  • Build a matrix between any two types, and export it
  • See coverage, orphans and unrealized goals
  • Re-confirm a trace a change put in doubt
  • Record verification against acceptance criteria
  • View an engagement by ADM phase, including what carried over
  • Read an engagement's dashboard of status, coverage, conflicts and review due
The traceability matrix, marking where a confirmed trace exists between two types and naming the rows nothing reaches.Create your organization

Hold requirements to a standard without reading every one of them

A linter checks each requirement against rules your organization controls — weak words, missing form, more than one requirement in a sentence, technology names where the wording should be technology-agnostic — and every finding says what to fix and where.

A quality score turns those findings and the item's own evidence into one number, explained check by check, and an organization can require a minimum before approval; user stories are scored against INVEST instead.

Near-duplicates are surfaced on capture, and two requirements that contradict each other can be declared in conflict, which blocks approval until somebody resolves or waives it.

  • Lint a requirement against your rules
  • Edit the rules, and the technology-terms dictionary
  • Read the quality score, check by check
  • Set the threshold approval requires
  • Find and resolve near-duplicates
  • Declare, resolve or waive a conflict
The quality rules an organization controls: each rule, its severity, and the weight it carries in the score.Create your organization

Let other systems and AI agents work in the repository without letting them decide

An agent is a first-class actor with its own identity, its own scoped token and its own line in the audit log; what it may do is an explicit list that can only narrow what its role allows, read on every request, so tightening or suspending an agent takes effect immediately.

Agents raise proposals, and a person accepts, edits then accepts, or rejects — the proposer recorded as the source, the person who accepted recorded as the author — and an agent cannot accept its own proposal, because deciding is a permission it does not hold.

Other systems subscribe to domain events, import and export tabular data, exchange elements in the ArchiMate model exchange format, or call the same API the interface calls.

  • Register an agent identity with an explicit permission list
  • Issue a scoped, expiring access token
  • Raise a proposal, and decide one
  • Subscribe to domain events, with signed delivery
  • Connect external AI agents over the Model Context Protocol
  • Export to the ArchiMate model exchange format
  • Read the whole API from its own description
The proposal queue: an agent's suggestions waiting on a person to accept, edit or reject each one.Create your organization

Show an auditor what happened, without preparing for the visit

Every change — a field, a state, a link, an approval, an agent's action — writes an append-only audit entry with its actor, its time and its before and after, in the same transaction as the change itself, and the log is searchable and exportable.

Each organization's data is isolated absolutely: a request for something in another organization is answered “not found” and discloses nothing more, and within an organization a restricted engagement or a confidential requirement is invisible to anyone outside it, including in search and in counts.

Roles carry granular permissions, and a change to someone's role reaches what they can see on their next page load.

  • Search the audit log, and export it
  • See everything that happened to one record
  • Manage members and their roles
  • Invite colleagues, and revoke an invitation
  • Inspect the metamodel every type is defined by
  • Add your own attributes to a type
  • Take job titles and departments from your directory
  • See how the repository is used, counted and never attributed to a reader
The audit record: each change with its actor, its time, and what it changed.Create your organization

Stand up your requirements repository today.

In your first ten minutes: create an organization, load the sample engagement, and follow one requirement from the goal behind it to the verification that closed it. Remove the sample in one step when you are ready for your own.

Create your organization
What ClarixERR does — capabilities