Governance
Assurance is only credible when actions, access and changes are traceable.
An assessment nobody can attribute is a document, not evidence. OTReady records who may see what, who decided what, and when, so the record of the work can be examined as carefully as the work itself.
- Access is project-scoped and default-deny
- Material governance actions are recorded as audit events
- Issued reports keep their version, digest and issuer
Why it matters
The record has to survive scrutiny too.
Most of what OTReady produces is intended to be shown to somebody: an auditor, a regulator, a board, a customer. That audience will reasonably ask who reached a conclusion, on what basis, and whether it could have been changed afterwards.
Those questions have to be answerable from the system rather than from memory, which is why access and history are part of the product rather than an administrative afterthought.
People & Access
Named people, scoped to a project.
Access is granted on a project, with roles carrying capabilities and grants narrowing them to exactly what someone needs. A restriction takes precedence over a broader grant, and the default is deny.
Scoping can go down to an exact assessment, scope or conduit, so an external reviewer can be given precisely the one thing they were asked to look at, and nothing adjacent to it.
- Project-scoped roles, grants and restrictions
- Default deny, with restrictions taking precedence
- Access enforced server-side, not by hiding menu items
Governance moments
The decisions worth recording.
These are the points where something moves from provisional to agreed. Each is an explicit act by a person, not a side effect of saving a form.
- Architecture approval
- An object becomes an agreed part of the architecture, separately from wherever it came from.
- Target confirmation
- A proposed Security Level profile becomes a confirmed target on a named subject.
- Evidence review
- A reviewer records what a piece of evidence supports, and to what level.
- Remediation approval
- Work presented for review is verified and accepted.
- Report issuance
- A report version is issued, with its number, digest, issuer and time recorded.
Audit history
Material actions, readable after the fact.
Audit history records material, user-driven changes to canonical data as events, with the actor derived server-side rather than accepted as input. Reading it is itself permission-aware, so a narrowly scoped principal cannot use the history to learn about the parts of a project they cannot see.
A refused action leaves no event. The history records what happened, not what was attempted and blocked.
What this does not claim.
Issued reports are immutable versions, and audit events are written in the same transaction as the change they describe. That is not the same as claiming every object in the system is cryptographically immutable, and OTReady does not say so. Audit coverage is also not yet universal across every module: where a surface is not covered, the honest answer is that it is not, rather than an implication that everything is.
Related capabilities
Reports
Issued versions, and what stays fixed about them.
Architecture
Approval state on canonical objects.
Remediation
Review and approval on remediation work.
Show the work, and who did it.
See how access, approval and history hold together on a real project.