Release audit reports

Every Project starts with basic Release management. Project managers can create and release versions, acknowledge unfinished scope, and publish an optional announcement without an audit report, ISO label, or approval. Core still records Release lifecycle and membership events and freezes the first released scope. Open Project → Releases → Optional audit reports and governance to generate an on-demand report from the evidence actually collected.

Project managers can opt into a governed profile for future Releases. They may require a published announcement, select release-time evidence categories (lifecycle, scope, first released scope, and announcement), require Organization control mappings for those categories, and have Core generate an immutable dossier in the same transaction as the release. The selected categories are checked against the release transaction; empty scope is still recorded as evidence of an empty release. An announcement requirement needs a published revision, and a mapping requirement needs Organization-defined labels for every selected category. If a configured requirement cannot be met, the release stops with an actionable error. Switching back to basic affects future operations; existing events and generated packages remain under the Core deletion policy. This release-time profile is separate from optional delivery readiness and environment promotion policy; basic Projects need neither.

Reports

Release dossier captures the canonical Release Version ID and metadata, original first-release scope when present, current scope at generation, lifecycle and membership events (including correction reasons), published announcement revisions, actor snapshots, timestamps, source IDs, counts, and known evidence gaps. It also captures linked builds, synchronized check and artifact provenance, readiness at generation, Project readiness policy history, approval/revocation/override decisions, environment policy history, and deployment/rollback attempts when those records exist. A dossier generated before first release explicitly lacks a first-release scope. Current Work Item fields are labeled current and are never substituted for first-release facts.

UTC change register includes every recorded Release event for one Project within a selected period of up to one year, ordered by timestamp and event ID. The through value includes every microsecond in its final millisecond; the manifest records the exact exclusive upper bound. It includes creation, metadata changes, release, archive/restore, membership corrections, and publication events, plus separate readiness policy, approval, evaluation, environment policy, and deployment event sections. The report fails before saving if it exceeds the supported 100,000 Release-event bound or any 10,000-row delivery section; select a shorter period. Dossiers also fail before saving if their event, announcement, current-scope, delivery-section, or 64 MiB document bound is exceeded. No report silently omits a row.

Each generated package is immutable. Its JSON document is available directly and inside a CSV ZIP with events.csv, coverage.csv, control-mappings.csv, governance-history.csv, readiness-events.csv, approval-decisions.csv, deployments.csv, readiness-policy-history.csv, environment-policy-history.csv, and manifest.json. Dossier ZIPs also include original-scope.csv, current-scope.csv, and announcements.csv. The manifest carries counts, filters, provenance, the Project governance profile captured at generation, limitations, and the complete file list. The coverage CSV identifies categories required by that captured profile. For a report generated later, this snapshot does not prove which policy was in force at an earlier release; inspect the included append-only policy and decision records. A dossier includes up to 10,000 events per delivery section from the Project lifetime; a register includes up to 10,000 in each requested-period section and fails explicitly above that bound. CSV cells are protected against spreadsheet formula interpretation. The printable full view can be saved as PDF through the browser. The manifest SHA-256 is calculated over the exact UTF-8 bytes of report.json; compare it with a local SHA-256 utility after download. The digest detects accidental or unauthorized changes to stored bytes; it is not independent attestation. All formats describe the same saved package and generation time. Reads and exports are logged without copying report content into the access log.

Standards and evidence coverage

Organization administrators may add evidence index entries with a standard edition, control reference, evidence category, and Organization-selected applicability value. Supported edition labels are ISO/IEC 27001:2022, ISO/IEC 27002:2022, ISO 9001:2015, and ISO 9001:2026. These labels appear only in dossiers and registers generated for governed Projects. They contain no licensed standard text and are not compliance scores, findings, certification, or automatic proof of control satisfaction. The Organization owns its audit scope and Statement of Applicability. See the ISO 9001 edition information when choosing a quality-management edition.

Core marks lifecycle and scope events as collected. It marks announcement, review, build/test/security, and artifact evidence unavailable when those sources are absent. Deployment scope remains unknown until a successful environment record has exact build-to-Work-Item evidence. A Release in Hamstik’s released state means its scope was finalized; it does not prove software was deployed. A passed readiness check also does not prove deployment. Inspect source links, freshness, approval revisions, policy history, override reasons, and the deployment outcome before using external evidence in an audit.

Only current authorized Project members can view or export a saved package; Project managers generate packages or change policy. The Audit & Compliance App links to the same Core reports when bound, but App binding is not required for on-demand Core reports. Core retains report packages until the Project is deleted under the current Project deletion policy, unless an authorized Organization retention policy in Audit & Compliance governs the saved-package class first. Organization-wide retention policy never shortens the documented pre-upgrade behavior of evidence that predates it, and disposal itself is not activated until every source path is protected.