Trust and boundaries
This page is not a control inventory and not an audit report. It is the set of commitments this service is designed around, each one labelled with how far it actually is, and each one paired with what it deliberately does not do.
How to read this page
The control model
People, workloads, and agents are distinguishable at the point of call, and the identity is the one the firm already recognises rather than a service account shared between them.
What this does not do. This does not decide what that identity may do. Authorization is a separate contract, checked by the system that owns the record.
A tool exposes one approved action with typed inputs and outputs. There is no general query surface and no pass-through to an underlying API.
What this does not do. A narrow tool is still only as safe as the permission behind it. Narrowness reduces blast radius; it does not replace the firm’s own access review.
Client and matter context, including ethical walls and purpose limitations, is carried explicitly rather than inferred.
What this does not do. The scope is applied by the system of record. This layer transmits and records it; it cannot enforce a wall on a system that does not implement one.
Allow and deny decisions, including revocation, stay with the system that owns the data. Unavailable is the default when that system cannot answer.
What this does not do. This means a misconfigured source system is still the authority. Correcting its permissions is firm work, not integration work.
What was called, by whom, in what scope, and what the outcome was. Privileged content is kept out of broad telemetry and logs.
What this does not do. This is an operational record, not a compliance audit trail, and it does not replace the audit trail the system of record keeps.
Where practical a capability ships read-only first, and write actions are added deliberately once the read path has been reviewed in use.
What this does not do. Some workflows have no useful read-only stage. Those start with a narrower write action instead, named explicitly before build.
Who does what
The same split shown on the home page, stated here as the reference version.
| Dimension | The firm | Backbone Legal | System of record |
|---|---|---|---|
| Who may act | Names the people, workloads, and agents permitted to act. | Binds every request to one of those named identities. | Accepts or refuses the identity it is handed. |
| What may be reached | Approves each resource and action before it is exposed. | Publishes only the approved set as typed contracts. | Holds the records and applies its own permissions. |
| Matter scope | Defines ethical walls and purpose limitations. | Carries that scope on every call it makes. | Applies the scope to what it returns. |
| The final decision | Sets the policy the decision follows. | Never overrides a refusal or re-issues a revoked grant. | Makes the final allow or deny, including revocation. |
| Evidence | Decides what must be retained and reviewed. | Records bounded operational evidence of each call. | Keeps its own audit trail of the underlying change. |
Data handling
Stated as a design commitment. Nothing here is an attestation, and none of it has been independently reviewed.
Reporting a problem
There is no bug bounty and no disclosure portal. There is an inbox a person reads, which is the honest state of a service this young.
Backbone Legal provides technology implementation and integration services. It is not a law firm and does not provide legal, ethics, or compliance advice.
Build the first governed capability