Documentation · Task
AI and data handling
Deterministic policy owns clearance. AI may help explain a decision, only when your administrators turn it on, and it can never set one.
The rule
- The Warden's policy is deterministic. The same evidence under the same contract gives the same decision.
- AI can assist an explanation. It cannot grant clearance, override a HELD decision, manufacture evidence or approval, or change any stored state.
- Evidence is the input to a decision. An external tool's approval or score is evidence, never CLEARED.
Marketplace V1
Marketplace V1 — publicly listed
V1 has no user-facing AI, uses no external AI processor and declares no external egress in its manifest. Evidence intake, the CI gate and Warden decisions work entirely on the deterministic path.
Optional AI explanation
Developer preview — live acceptance pending
The developer pilot lane adds one optional action, ai.dev.explainWarden, that explains a HELD change in plain language. It uses the Forge llm module with a Claude model through Atlassian's Forge LLM capability.
| Control | Behavior |
|---|---|
| Default | Off. Nothing is sent to a model until enabled. |
| Enablement | A site administrator turns AI on for the site. |
| Consent | Required before any request is made. |
| Budget | A spending cap applies. Requests stop at the cap. |
| Grounding | The prompt is built from the evidence references the caller is authorized to see. |
| Output | Must be a single JSON object with citations that match real references. Empty or forged citations, extra keys, multiple objects and truncated or tool-call responses are rejected. |
| Failure | Fails closed. A refused or invalid answer shows no AI text. |
| Scope | Per installation. There is no cross-customer training or pooling. |
progressionAllowed and is never needed to read the facts.With AI off
With AI disabled, not consented or over budget, the facts still render deterministically. In the developer API, quality.explain returns mode: "deterministic" and modelInvoked: false, with the failed requirement, assertion link and next actions taken from recorded evidence. See API, CLI and MCP and the developer overview.
Where data lives
- TestWarden runs on Atlassian Forge. Data is stored in Forge SQL and Object Store, scoped to your installation.
- V1 declares no external egress and no third-party analytics.
- Raw evidence reports are stored immutably in Object Store with a content digest. Receipts and decisions are kept in Forge SQL.
- On uninstall, Atlassian retains Forge-hosted data for its platform retention period of 28 days and then destroys it.
- Personal-data reporting follows Atlassian's lifecycle: closed accounts are anonymized in place, and test, evidence and decision records are kept.
Scopes and architecture are on Security; legal terms are on Privacy.
Quality Memory history
Quality Memory is the immutable record of your own changes: evidence receipts, content digests, decisions and their reasons. It is append-only and per installation. It is a history you can read, not a learning system, and it is not used to train models.
In development
The following are the approved development direction. None is part of the submitted Marketplace V1 version, none is active in production and none can grant clearance.
- Quality Memory retrieval: expanded historical ingestion and retrieval over your own tenant-isolated history, with provenance.
- Verification Intelligence: coverage-gap analysis, changed-code test impact, flaky-test and failure-pattern detection, release-risk analysis and evidence-grounded recommendations. Each is advisory and is labelled available only after deployed, verified acceptance.
- Quality Agent: designed to investigate quality problems and recommend maintenance or repairs in workflows an administrator has explicitly authorized. It never certifies its own work; a repaired change needs fresh independent evidence.
Each would use the same consent, permissions, tenant isolation, budgets and source-provenance controls as AI explanation. See Proof for current status.
Questions
Security and privacy questions: [email protected] and [email protected]. See also Permissions.
Related tasks
- Onboarding
Choose a path, enable access, confirm the first change appears.
- CI evidence
Submit JUnit, SARIF or JSON and gate on the exact build.
- API, CLI and MCP
Read status, obligations and explanations from a terminal or agent.
- Decisions and approvals
States, reason codes, next actions and preserved history.
- Permissions
Roles, custom scopes and who can read, write or request.