What ClarixERR does
Organized by what you are trying to get done. Everything listed here is in the product today.
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
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
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
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
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
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
- Export to the ArchiMate model exchange format
- Read the whole API from its own description
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
Stand up your requirements repository today.
Create an organization, load the sample engagement, and see a full trace in a few minutes.
Create your organization