Trust centre · For a programme director, QA lead or audit reviewer
Four systems of record. One traceable line from requirement to evidence.
AIRAS Cloud is not built informally and documented afterwards. It is delivered through an engineering management system in which source, delivery state, documentation and test evidence each have a single named authority — and no change is complete until all four agree.
- 7
- Xray test packs under management
- 1,333
- Registered test cases across packs
- 17
- Governance blocks tracked as Epics
- 9
- Generated Confluence record sets
The authority model
Each system holds one authority. Nothing important depends on two systems telling the same story by accident.
Authoritative source
GitHub
Every line of application code, every database migration, every regulatory ruleset and the entire controlled documentation set live in one version-controlled repository on a protected branch.
- Repository
- AirasCloudIreland
- Release gate
- Types, lint, full suite, evidence
- Rebuild path
- Documented clean-room runbook
Authoritative delivery state
Jira
Work is planned against seventeen governance blocks, each an Epic. Findings are raised as issues with a machine-matched key, remediated under a one-blocker rule, then closed with a reconciliation comment naming the engineer.
- Project
- AIRAS — governance delivery
- Governance Epics
- B00 to B16
- Closure record
- Findings register in Git
Authoritative documented reality
Confluence
The documentation space is generated from the repository, not typed by hand. Pages are updated in place, so history is preserved and no page can quietly diverge from the artefact that produced it.
- Controlled tree
- Nine top-level page sets
- Generated from
- docs/ in the repository
- Update mode
- In place, versioned
Authoritative test evidence
Jira Xray
Test packs, cases and executions are imported natively from evidence artefacts. An import ledger maps each artefact to exactly one execution, so a run cannot be double-counted or invented after the fact.
- Quality project
- XSP — AIRAS Quality Hub
- Test packs
- Seven
- Ledger
- Artefact-to-execution mapping
The reconciliation loop
How one change moves from raised to reconciled, every time.
This is the sequence a reviewer can walk backwards. Pick any closed issue and it names the commit; the commit carries the tests; the tests produced the execution; the execution is registered; the documentation was regenerated from the same repository.
- 01
Change is defined
A regulatory, security or product change is raised as a Jira issue under the governance block that owns it.
- 02
Change is built in Git
Implementation lands on the protected branch with the ruleset, migration and documentation change in the same commit set.
- 03
Change is proved
The full automated suite and the headless browser suite run. Evidence artefacts are written, not summarised by hand.
- 04
Evidence is registered
Executions are imported into Xray against the affected packs, with pass counts taken directly from the artefacts.
- 05
Reality is documented
Confluence pages regenerate from the repository and the weekly engineering record is appended, naming the developer and tester.
- 06
Change is reconciled
The Jira issue is closed with the commit, the evidence keys and the published page references. Unreconciled work is not complete.
Test management in Xray
Seven packs, each with a defined purpose and its own regression obligation.
Packs are defined in the repository and mirrored into Xray, so the structure a reviewer sees in Jira is the structure the suite actually runs. Executions carry the pass count from the evidence artefact and the name of the engineer accountable for the run.
- SMOKE
Smoke
Shortest signal that identity, tenancy and response hardening are sound.
- REG-ENGINE
Regulatory engine regression
Deterministic verification of the ARIE classification and obligation engines against the AI Act text.
- DISCOVERY
Discovery pipeline regression
Document ingestion, extraction, lineage, detection, triage and acceptance behaviour.
- SECURITY
Security and abuse resistance
Content safety, archive-expansion limits, request throttling and integration authorisation.
- DEMO
Demonstration and workshop
Synthetic-only client-facing surfaces: the guided tour, workshop studio and demo.
- E2E-WEB
Website and workspace end-to-end
Headless browser verification of every public route and the governance workspace.
- DOCS-EVIDENCE
Documentation and evidence integrity
Verifies the controlled record itself: inventory freshness, configuration and evidence consistency.
Claim register
What our delivery governance demonstrably is — and what it is not.
How to read the evidence status on this page
- Verified in product
- Implemented in the platform and covered by automated tests or recorded verification evidence.
- Controlled document
- Maintained as a version-controlled internal artefact, issued under agreement rather than published.
- In external assurance
- Scheduled with, or in progress with, an independent party. No external opinion is claimed until the report exists.
- Not claimed
- Deliberately not asserted. Stated openly so a reviewer never has to infer whether it exists.
| Claim | Status | What evidences it |
|---|---|---|
| Delivery work is tracked in Jira against numbered governance blocks | Verified in product | Seventeen Epics, B00 to B16, cover custody, build integrity, schema, authorisation, the regulatory engine, evidence, APIs, storage, privacy, public truth, supply chain, reproducible build, recovery, observability, controlled documentation and release readiness. |
| Test packs and executions are registered natively in Jira Xray | Verified in product | Seven packs and 1,333 registered cases, with executions imported from evidence artefacts through a source-controlled importer and an idempotency ledger that prevents duplicate or invented runs. |
| Confluence documentation is generated from the repository | Verified in product | The controlled tree is produced by publishing scripts held in Git and updated in place, so page history is retained and each page names the artefact it was generated from. |
| Every material change is reconciled across all four systems before closure | Verified in product | A standing change-reconciliation control defines per-surface duties and a completion checklist. A change that is built but not reconciled is treated as incomplete, not as done. |
| Publication mapping is itself version-controlled | Controlled document | A publication record in the repository maps each artefact to its Jira issue, Confluence page identifier and Xray execution key. Issued to customers and reviewers under agreement. |
| Customer-facing programme reporting from the same records | Controlled document | Deployment, onboarding and weekly engineering reporting are produced from the same repository artefacts that drive Jira, Confluence and Xray. Provided during an engagement. |
| Independent audit of the delivery management system | Not claimed | The management system is documented, operated and evidenced, and we support customer-led review. It has not been independently audited or certified, and we do not present it as such. |
Stated plainly
Our engineering management system is documented, operated and evidenced, and the mapping between repository artefacts and Atlassian objects is itself held in version control. It has not been independently audited or certified. We will not describe it as audited, and we will not present programme tooling as a substitute for the independent assurance work recorded on the external assurance page.
Why this matters to your assurance function
When a supervisory authority or an internal auditor asks how a governance decision was produced, the answer cannot be a screenshot. It has to be a chain: the requirement, the change, the test, the evidence and the documented control state, each held in a system with a single owner.
We run AIRAS Cloud that way so that your own review of us takes days rather than months, and so that the control language in our documentation matches the control language in your framework.
What we can share, and when
Under a mutual agreement we provide the publication record mapping artefacts to Jira issues, Confluence pages and Xray executions, the current test registry, the execution history and the weekly engineering record.
We do not disclose proprietary ruleset internals, scoring logic or customer content in any of these artefacts. The record is designed to be reviewable without exposing what makes the engine work.
Bring your programme office into the review.
We will walk your delivery, QA and audit leads through the live governance records — the block structure, the test packs, the execution register and the reconciliation control — using the same systems your own teams already work in.
No commercial commitment. No confidential information required.