Compliance Glossary for Confluence

Where is evidence stored?

Production v6 stores terminology and scan records in Forge KVS. It uses tenant-scoped Forge SQL for indexed enterprise evidence and Forge Object Store for frozen content, archive parts, and manifests. The deployed manifest also includes an LLM module and GitHub backend egress. Deployment confirms availability, not staging qualification, measured capacity, physical residency, or legal immutability.

Last verified against production v6 · 26 September 2026

At a glance

Data classCurrent storage statusRecordsBoundary
Governed terminologyProduction KVSTerms, definitions, status, ownership, approval metadata, and version historyThe live app reads these records for administration and macros.
Confluence scan evidenceProduction KVSLatest scan results, scan snapshots, term usage, finding resolutions, and configurationStored observations are bounded. Source page bodies are not audit-export records.
Legacy baseline compatibilityProduction v6 compatibility pathBaseline headers, chunked term states, page states, usage indexes, and deltasThe qualification bundle keeps this path until migration parity passes.
Enterprise indexesProduction v6Artifacts, revisions, subjects, usage, traces, baselines, jobs, conformance, and archive metadata in Forge SQLThe SQL schema must pass its migration probe before enterprise reads or writes.
Enterprise objectsProduction v6Frozen content, archive parts, and manifests in Forge Object StoreKeys include tenant, baseline, object kind, and content hash.
MigrationDeployed with runtime gateScheduled SQL migration, legacy backfill, readiness probe, and verified promotionForge staging migration and parity evidence remain unrecorded.
GitHub accessProduction v6 egressBackend requests to https://api.github.comNo other external backend domain is declared in the deployed definition.
AI curationProduction v6 moduleBounded administrator-selected inputs processed through the Forge LLM moduleThis is a separate data boundary from the GitHub fetch allow-list.
ResidencyNot established by repository evidenceForge service choices and app storage contractsConfirm eligible regions and contractual terms with Atlassian for the target tenant.

Migration and failure path

  1. A scheduled migration creates or upgrades the enterprise SQL schema.
  2. The operation port probes SQL and Object Store readiness.
  3. An unavailable probe blocks enterprise operations.
  4. Legacy KVS reads remain available during the migration period.
  5. A staged enterprise baseline advances only after verification and parity checks.

Current production storage

Production v6 still uses Forge KVS entities. These records support Terms, Compliance Scanner, macros, finding history, and Audit Evidence Export.

Forge CLI records production version 6 as deployed on 2026-09-26 at 13:58:58.031 UTC.

Deployed enterprise storage

The deployed definition includes SQL, Object Store, LLM, 12 functions, four consumers, and one backend egress entry.

Forge SQL stores indexed enterprise records. Forge Object Store holds canonical content and archive objects.

Every enterprise SQL query includes a derived tenant identifier. Object keys also include tenant and baseline identifiers.

Production v6 mounts Enterprise evidence workspace under Terminology Baseline. It shows no partial workspace when storage readiness fails.

Deployment does not close the qualification gap. The repository still lacks recorded Forge staging parity, measured capacity, consumption, latency, and cost evidence.

Example

A production page scan writes its current result and history snapshot to KVS. Audit Evidence Export reads those supported records.

It does not create an enterprise SQL baseline. An enterprise freeze deposits indexed rows and content-addressed objects only after readiness checks pass.

Egress and residency boundary

The manifest allows backend fetches to GitHub’s API. It also declares a Forge LLM module for administrator-started draft curation.

Neither declaration proves a physical storage region. Local qualification also provides no Forge residency, latency, consumption, cost, or capacity evidence.

Content hashes and content-addressed keys support mismatch detection. They do not establish legal immutability or replace retention policy.

Related questions

Next step

Describe production v6 as KVS plus enterprise SQL and Object Store. Keep qualification, capacity, residency, and legal immutability claims separate.

View on Atlassian Marketplace
Verification basis: production v6 code, tests, manifest, and operations guidance. Verified 26 September 2026.