Reference
Tools for insight and action. Configured around your work.
Read business data, save approved changes and follow up on outstanding work. The catalogue below describes the core discovery and analysis tools. Source updates, uploads and proactive workflows are enabled separately for your systems and permissions; your deployment's tool list reflects that configured scope.
Understand the data. Act on it. Keep the next step moving.
Source updates and follow-ups are part of the workflow, with their own controls.
The core read profiles below do not grant source updates. An enabled action can validate an upload, preview proposed changes and save approved values to the target system. Configured follow-up workflows can create tasks, send reminders or nudges and check status. Availability depends on the integration; targets, approvals, recipients and timing are agreed before use.
The tools
The core catalogue. With the access each tool needs.
Tool names are per category rather than per product, so the day a Salesforce adapter exists it answers crm_read and nothing downstream changes. The last column is the governance fact: which of the seven profiles expands to include this tool.
| Tool | Reads | Granted by |
|---|---|---|
| describe_modelDescribe the planning model | planning model | 4 of 7 profiles |
| list_membersList dimension members | planning model | 4 of 7 profiles |
| read_sliceRead cube slice | planning model | 4 of 7 profiles |
| validate_modelValidate model integrity | planning model | 4 of 7 profiles |
| variance_autopsyVariance autopsy | planning model | 3 of 7 profiles |
| anomaly_detectorAnomaly detector | planning model | 3 of 7 profiles |
| environment_statusPlanning environment status | planning model | 2 of 7 profiles |
| crm_describeDescribe the CRM connection | your CRM | 3 of 7 profiles |
| crm_readRead my CRM records | your CRM | 3 of 7 profiles |
| crm_read_allRead all CRM records | your CRM | client-admin only |
| docs_describeDescribe the document connection | your documents | 3 of 7 profiles |
| docs_searchSearch documents | your documents | 3 of 7 profiles |
| docs_readRead a document | your documents | 3 of 7 profiles |
| tasks_describeDescribe the task-tracker connection | your task tracker | 3 of 7 profiles |
| tasks_listsList task lists | your task tracker | 3 of 7 profiles |
| tasks_readRead tasks | your task tracker | 3 of 7 profiles |
| handbook_searchSearch the client's process handbook | your own handbook | 4 of 7 profiles |
| handbook_readRead a handbook entry | your own handbook | 4 of 7 profiles |
| handbook_assessRecord a check against an entry | your own handbook | 2 of 7 profiles |
| handbook_confirmConfirm an assessment | your own handbook | client-admin only |
| list_projectsList my projects | this platform only | client-admin only |
Three tools sit behind the client-admin profile alone, and each for its own reason. crm_read_all reads past the record-ownership filter that crm_read applies, so reaching the whole pipeline has to be asked for rather than inherited when a profile grows a member. handbook_confirm is the step that turns a model's reading into evidence a named person stands behind, which belongs to whoever owns the process. list_projects is the only tool that needs no project at all, because it answers the question of which projects you have.
The profiles
Seven named sets. And an unknown one expands to nothing.
A grant names a person, a project and a profile. The profile is expanded once, at the moment the grant is written, which is why widening a profile does not retroactively widen anybody who already holds it. An unrecognised profile name expands to an empty list rather than to everything, which is deny-by-default written as code rather than promised as a policy.
| Profile | Tools | What it is for |
|---|---|---|
| finance-readthe narrowest useful grant | 6 | The four schema-agnostic planning reads plus the handbook. Somebody who asks the plan questions and reads nothing else. |
| finance-analyst | 8 | The same, plus variance and anomaly analysis. Still read-only, still planning only. |
| crm-read | 2 | The CRM, narrowed to records that person owns. Deliberately not folded into the finance profiles, because reaching commercial pipeline should be asked for. |
| docs-read | 3 | Documents, read as the signed-in person, so the source system enforces its own item permissions. |
| tasks-read | 3 | The task tracker, through that person's own token. |
| deliverythe working profile | 18 | Everything read-only across planning, CRM, documents and tasks, plus recording a check against the handbook. It cannot confirm its own assessments and cannot read the whole CRM. |
| client-admincore catalogue | 21 | The profile that reaches every tool in this core catalogue, including the three above. Action workflows have their own scope. |
Documents and tasks are folded into delivery and the CRM is not, and the difference is not arbitrary. Those two read as the person asking and the source system enforces its own permissions, so including them widens nobody's reach beyond what they already have. Our CRM adapter has no such ceiling behind it, which is exactly why it stays out. That reasoning is the same one on whose permissions apply.
The refusal codes
Twenty names, frozen by a test.
A refusal carries a stable code rather than a sentence somebody will reword. That matters because these are persisted: a row written last month still carries its code, and a detector built on prose silently stops working the day the prose improves. Renaming or removing one is a deliberate edit to a test that exists to make it deliberate.
| Code | Stage | What it means |
|---|---|---|
| no_identity | identity | No verified email on the request. Answered with a sign-in invitation rather than a refusal. |
| token_rejected | identity | Bad signature, expired, or an audience belonging to another client's connector. |
| token_host_project_mismatch | identity | A token pinned to one project, presented to a different connector. |
| entra_tenant_mismatch | identity | The sign-in did not come from the directory registered for that organization. |
| identity_tenant_absent | identity | The organization is bound to a directory and the sign-in carried none. Usually a configuration conflict, never reported as a possible breach. |
| identity_tenant_ambiguous | identity | The sign-in carried the directory claim twice, with different values. Refused rather than resolved. |
| not_provisioned | identity | Authenticated, but nobody by that email exists here. Also what a probe looks like. |
| person_inactive | identity | The person exists and has been switched off. |
| no_live_grant | grant | A known person holding no live grant on anything. |
| project_not_granted | grant | The project was named and this person holds no grant on it. |
| project_ambiguous | grant | Several projects were possible and none was default. Refused with the list rather than guessed. |
| project_vanished | grant | The project was resolved and then was not there. Fails closed. |
| skill_not_enabled | tool | The tool is real and this person's profile does not include it. |
| skill_not_enabled_projectless | tool | The same, for a tool that needs no project. |
| pack_not_owned | tool | The tool belongs to another client's pack. Never says whose. |
| tool_not_available_on_project | tool | Your administrator has not switched this capability on for this project. |
| tool_has_no_connection | tool | Nothing of that kind is connected, so there is no system to read. |
| dispatch_tool_not_visible | dispatch | Called anyway, having never been offered. Refused a second time at the moment of the call. |
| dispatch_no_project_bound | dispatch | A project-bound tool reached dispatch with no project scope. Structurally should not happen, and refuses if it does. |
| control_plane_unavailable | dispatch | Ours, not yours: the control plane was unreachable, so the request failed closed. |
Only three of these twenty may ever be described to you as a possible breach, and that mapping is fixed in code rather than decided during an incident. The rest are refusals working correctly. A configuration conflict reported as a breach gets escalated to a CISO who then owns an incident that never happened, which is why the distinction is a data structure rather than a judgement call. The record itself is on the audit trail.