Frequently asked questions
Most of the answers are not about a product. They are about where the organisation stands today.
Jira carries the process, Jenkins automates delivery. Both do the right job. Neither one assesses the risk of a database operation, decides whose responsibility that risk is under the organisation's own rule, or produces evidence of the decision.
The governance layer does not replace these tools. It connects the decisions they produce into a single decision and evidence model.
How that connection works today: through the ticket number field on the request. You define the format rule, a request that does not match it is refused, and the number travels with the record. The product does not currently connect to Jira to verify that number or open tickets; that connector sits at the top of the roadmap.
The opposite. Governance makes visible and provable the work the team already does correctly.
Today the team makes the right call, but no trace of the call remains. When questions follow an incident, that leaves the team exposed.
Not if the control works by risk. What slows you down today is that every item goes through the same gate.
When the organisation's rule determines the risk, low risk work does not wait, and high risk work gets the attention it deserves.
SQL Server, PostgreSQL and Oracle. What an operation actually does is analysed in each platform's own language, while the rules are applied through the same governance model.
The rule engine parses the script with a real grammar and works on sentence structure. That is why it catches everything readable from the script itself: an UPDATE without a filter, a DROP on a critical object, or a naming convention.
Whether a query uses an indexed column, however, cannot be read from the script; it requires looking at the target database catalogue. That check is not in the scope of the rule engine today and belongs to database monitoring tools.
It is installed in your own environment. Access to your databases stays inside your network, and data does not leave the organisation.
Mature processes are exactly who this is for. The question is not whether the process exists, but whether it runs independently of specific people.
If two different people cannot assess the same work with the same outcome, the process exists but has not yet become institutional.
Day to day, the database and application teams. Its decisions and reports are used by change management, information security and internal audit.
Ownership being defined in one place matters more than the number of users.
Because the record is not assembled after the event. It forms with the event and carries its own integrity. The auditor can verify for themselves that it was not altered later.
The value of evidence comes less from its content than from who did not prepare it.
Concretely: the delivered zip holds an identity file listing the SHA-256 digest of every file, the RSA signature over it, and the public key that checks the signature. The steps and the commands are written out on the evidence verification page.
Yes, and the design is built around it. The verification runs on the auditor's own machine with standard tools: PowerShell or openssl. Nothing connects to the product, nothing goes over the network, nothing extra is requested from the organisation.
The signing key of the audit chain stays inside the organisation and is never handed over. That is exactly why the two most valuable checks are designed not to need it: the linkage between records, and the comparison against an anchor delivered earlier.
The evidence format is also a written specification, available on request. The authoritative description of the verification is in that specification, not in the script that ships inside the package.
A signature shows where a package came from, not when. The date is written from the organisation's own server clock, and that clock can be changed. We say so plainly.
There are two answers. The first is regular anchor delivery: a signed record saying "my last record was this number" goes to the auditor each day, and the delivery itself is what proves the date. The second is RFC 3161 timestamping: the digest of the package is sent to a timestamp authority and the response is placed in the package. Only the digest ever leaves, never the record. The shipped configuration has this on and points at a free public authority; in production it should be repointed at the organisation's own authority or switched off with a single setting. When it is off, no network call is made at all.
By seeing which level the organisation is at today. A six question self assessment shows which area is the weakest link.
In governance, the overall level equals the weakest link.