Attribute directory
Where is this transaction used?
Not in one diagram – in all of them. A system is to be replaced. A role is redefined. An auditor asks for the evidence. The question is then not „how does this process run“ – but where does this appear everywhere.
The problem
You can read a diagram, but you cannot query it
In most tools a process model is a picture. What it contains sits in the picture – not in a structure that gives answers. With thirty models that means: open every file one by one, and again next time.
Where is this transaction?
Spread across models, departments and years – findable only by someone who knows them all.
Where is the evidence missing?
Inspection required but no test case. A risk named but no control.
The answer
One question, every model in the company
TAOM keeps the details on the process step itself: role, system, transaction, inspection duty, risk, control, test case, provenance, approval state. The search does not run in the open file but across the whole inventory – thirty models, twelve departments, three years of work, one answer.
One term, three models, three departments – without opening a single file.
The difference
What is missing is the more valuable question
An ordinary search finds what is there. The questions that matter before an audit aim at the opposite – and they can only be answered because the details sit on the step.
Inspection required, no test case
The step is marked as requiring inspection – the evidence is missing.
Risk without control
A risk is named but nothing mitigates it.
AI-generated, not approved
The text comes from the agent and has passed nobody.
Only in one language
Described, but the second version is missing.
From finding to fixing: Every question has a bulk action – create test cases, set the inspection duty, request the missing translation, for the selected steps in one go. Selected, not automatic: Naming a test case is a professional statement, not a formality.
The catalogue
Thirteen questions a picture cannot answer
No search form you have to think your way into – ready-made questions, in the words of the people who ask them. Seven aim at gaps, six show what exists. And each runs over one model, your own, or every model in the company.
What is missing
- Inspection required but no test caseThe step must be inspected – no test case is recorded.
- Risk without controlA risk is named but nothing mitigates it.
- Inspection duty still openRisks or test cases are there – whether inspection is required has not been decided.
- AI-generated but not approvedThe content comes from the agent and has passed nobody.
- Test case without resultIt was to be tested – no result is recorded.
- Inspection duty not yet decidedThe most common starting point in a new model.
- Description in one language onlyDescribed, but the second version is missing.
What exists
- All steps requiring inspectionWhat must be inspected by your own definition – with and without a test case.
- All steps with a riskWhere a risk is named, mitigated or not.
- All steps with a controlWhere a control is recorded.
- All steps with a test caseWhere at least one test case exists.
- All steps with a test resultWhere a result exists – passed or not.
- Explicitly not requiring inspectionReviewed and found not to require inspection – not to be confused with “still open”.
The difference lies in the last entry. “Explicitly not requiring inspection” and “not yet decided” look identical in any table – empty. In an audit they are two entirely different statements: a decision taken and an open question. TAOM keeps them apart.
Found – and then?
From hit to comparison – in one click
The hit sits in another department’s model. In any other tool that means: close your own model, open the other one, switch back and forth. TAOM opens it alongside – one click from the list of hits: on the left for viewing, on the right your own editor. Both searchable, both zoomable, nothing is lost.
Editing happens only ever on the right. Two editable models would mean two saved states and the question which one is meant when somebody saves. Both sides have their own search and zoom; the swap makes the found model editable with one click.
Honestly
What it is not
The directory answers questions across models. It is not an impact analysis with a dependency tree: anyone wanting to know which training a change triggers will not find that today.
Two searches, two jobs. Across every model the search runs on attributes – roles, systems, transactions, inspection states. Inside an open model the editor and viewer additionally search the body text of the descriptions. One finds where something occurs; the other, what it says there.
Process it further
The answers can be fetched
What the search finds can also be fetched programmatically: attributes, models and hits are available through the interface – for your own reports, analyses or a tool alongside.
Where the knowledge comes from
The memory behind the search
The directory finds what is there. How it knows was exists at all – roles, activities, areas with their frequency – is in the Learning Model.