Governance
How we hold ourselves to what we sell.
We build governance software, so our own governance is published rather than described. Everything below is a control we operate today — enforced in continuous integration, recorded in decision records, or written into a constitution anyone can read.
- Change control
- Every change is a tracked work item with acceptance criteria written before work starts. Nothing reaches the default branch except through a pull request that a human approves, with the full gate green as a precondition.
- Review gates
- Automated review runs independently of the author, and human approval is a separate, mandatory step. An automated actor may never approve its own work, and may never approve at all.
- Evidence and acceptance
- Work is not closed by declaring it done. Acceptance requires evidence — a build URL, a measurement, a commit — and an item marked complete without it is reverted automatically.
- Decision records
- Architectural decisions are recorded with their rejected alternatives, what they forbid, and the trigger that would justify revisiting them. A decision without its alternatives is unreviewable.
- Technical-debt control
- Known debt is measured, frozen at a baseline, and forbidden from growing: the build fails if it increases. Debt may shrink. It may never quietly expand.
- AI governance
- AI may propose; only deterministic analysis attests. Inferred results are marked as candidates for human judgement and excluded from reproducible evidence. No automated actor may weaken a check to make a build pass.
- Verification and reproducibility
- Analysis output regenerates byte-identically from a repository state. Release artifacts are verified by consuming them in shipped form, not by the test suite alone — a lesson two defects taught us.
- Security reporting
- Vulnerabilities are reported privately, never as public issues. Acknowledgement inside 72 hours; assessment and plan inside a week; credit in the release notes unless declined.
- Support commitments
- Substantive response — a fix, a workaround, or a clear statement of findings — within 72 hours for defects and about a week for complex requests. Published as policy, not promised in a deck.
- Data handling
- Engineering data stays in the customer's repository. No proprietary store, no telemetry without explicit configuration, and analysis that runs entirely inside the customer's environment.
Safety
The human stays responsible. The architecture makes sure of it.
- 01
AI proposes
drafts, suggestions, candidates
- 02
Analysis attests
deterministic engines verify
- 03
Governance approves
compiled policy, uniformly applied
- 04
A human decides
review is a step, not a setting
- 05
The repository records
ordinary Git edits, in history
Nothing enters engineering memory without review. Nothing becomes certification evidence without deterministic verification. Safety here is architectural, not procedural — the system has no path around it.
Transparency
Auditable by reading, not by asking
Our engineering constitution, principles, standards and architecture decisions are public. So is the operational tooling that enforces them. A reviewer does not need our cooperation to verify how we work — which is the same standard our products hold engineering artifacts to.
Vendor assessments, security questionnaires and compliance reviews: write to us and you will reach the engineers who built the controls, not a queue.
contact@ejadahailabs.com