Audit & Compliance

Audit & Compliance is a first-party Hamstik Application that gives a Project a single, bounded view of the audit evidence Hamstik already possesses. It reads canonical Hamstik events; it does not maintain a second copy of them, and it does not change the workflows that produce them.

What it covers

The timeline brings together Project-scoped evidence from several Hamstik domains:

Evidence source	What it records
Work Item Activity	Comments, attachments, assignments, links, and other Work Item changes.
Work Item History	Delivery-relevant state changes such as status, sprint, and estimates.
Project Membership & Access	Project membership grants, role changes, removals, and default access-policy changes.
Guest Access Policy	Project, Work Item, and comment sharing-policy changes with recorded actor identity.
Hamstik App Lifecycle	Organization and Project App installation, enabling, disabling, binding, and configuration changes.
Source Control	Commits synchronized from selected Development repositories.
Code Review	Pull requests and reviews synchronized from selected repositories.
Build / Test	Actions workflow runs and useful job metadata.
Artifact	Metadata for artifacts produced by Actions. Hamstik does not download or mirror artifact binaries.
Release Lifecycle & Scope	Release Version changes, governance, readiness policy, and environment policy.
Release Approval & Override	Readiness evaluations, approvals, revocations, and overrides, including the evidence revision they bind to.
Deployment & Rollback	Completed deployment and rollback outcomes recorded against governed Project environments.
Evidence Report Generation & Access	Generation and retrieval history for canonical Release evidence dossiers and change registers.

Each card in the application shows whether its source is currently available, so a source that has no compatible provider yet is never presented as a failure.

What it does not do

Audit & Compliance is an operational evidence view, not a legal or regulatory archive. In particular:

It does not provide certification, conformity, or a compliance score.
It does not provide legal holds as a legal compliance certification — a hold is a product preservation mechanism, not a certification. Disposal is not scheduled automatically in this release.
It does not merge remote provider attempts into completed local changes. An attempted deployment is not presented as a completed one.
It does not reconstruct history that was never recorded. Where a source predates this coverage, the gap is shown rather than guessed.

Organization access history

Organization Settings → Audit & Compliance includes membership grants, role changes, member removals, and Organization-wide guest-access policy changes. Owners, administrators, and members with audit read delegation can read this history without a Project App binding. Project access alone does not grant access to Organization-wide membership history. Use Older access changes to page through earlier events.

Capture covers actual changes from Organization settings, platform administration, invitations, account removal, and Organization provisioning. Repeated requests that leave the role unchanged do not add another event. Changes predating capture are not reconstructed.

Organization retention governance

Organization owners and administrators configure versioned retention policy in Organization Settings → Audit & Compliance. Two independent classes are configured separately:

Audit events age from their occurrence time.
Saved packages age from their generation time.

New Organizations are provisioned with the documented default — 365 days per class with a 30-day deletion grace — at creation. Every Organization creation path (onboarding, administration, enterprise provisioning, imports) gets the same default, recorded as an immutable system_default revision so the adoption state is always visible. Existing Organizations that predate this provisioning are never silently adopted or backfilled: they keep their documented pre-upgrade behavior until an owner activates a revision through an authorized impact preview. A finite policy is between 1 and 3,650 whole days. Explicit indefinite retention is available but requires a written rationale and an annual review date; it is never selected silently, and the governance screen flags the annual review once its date has passed. Deletion grace defaults to 30 days and may be set between 7 and 90 days. Effective expiry combines the Organization policy, any Project extension, any prior protected commitment, and grace. Legal holds override disposal eligibility while they are active. A revision becomes effective when it is saved: future effective dates and backdating are rejected rather than applied silently.

Policy changes are immutable revisions with the acting administrator, a reason, an effective time, and a readable diff. New revisions apply prospectively by default. Applying a change to already-collected evidence requires a stable impact preview, and may only extend retention. A preview records the exact policy digest, scope, as-of boundary, how many matching records the proposal would actually schedule for deletion, legacy/protected/held counts, earliest and latest deletion dates, and reference versions for the active policy and Project overrides. Deletion dates include current Project extensions within the proposed ceiling and never move a record earlier than the date the currently effective policy already committed to — extending retained evidence recomputes expiry without shortening other protections. A preview is valid for 24 hours and is invalidated durably by a concurrent policy or Project override change. Confirmation and any later approval bind to the exact canonical policy digest, not just the preview ID. Retrospective reductions now route through the independent approval service (below): with the Organization’s two-approver requirement off, the requester’s confirmed preview authorizes execution; with it on, a different eligible approver must decide a digest-bound request and execution is a separate audited step. They never schedule or perform deletion on their own.

Legal holds

A legal hold preserves evidence from disposal evaluation. Hold scopes are the whole Organization, one Project, one Release Version, or an explicit bounded selection of resources. Organization, Project, and Release scopes include evidence created after placement; selections are fixed unless they are explicitly marked to include future matches.

Placement requires hold management authority and is immediate. A hold records its exact scope (as a stable digest), its owner, a recorded reason, an optional external reference, and an optional review date — the review date triggers a reminder state only and never releases a hold.
Holds combine: overlapping holds protect together, and releasing one never weakens another.
Releasing requires current hold authority and a recorded reason. When the Organization’s independent-approval requirement is on (below), the release becomes a digest-bound approval request decided by a different eligible approver, and the actual release is a separate audited step.
Releasing a hold does not delete anything: disposal evaluation resumes and any expired evidence starts a full deletion grace period computed from the policy effective at release. No immediate purge ever follows a release.
Where a viewer lacks the underlying Project access, a hold is shown as a protected summary: scope, reason, and owner — never the project’s objects.
A hold cannot preserve evidence that a disposal reservation has already claimed: such a placement fails with an explicit disposal-in-progress or already-disposed error instead of claiming success.

Independent governance approvals

The two-approver requirement is off by default. Enabling it requires at least two currently eligible approvers (an Organization owner/admin or a holder of the relevant delegated capability) and covers:

releasing legal holds;
retrospective retention and grace reductions;
Organization deletion; and
weakening or disabling the requirement itself.

Requests are bound to the exact action digest (scope, policy version, action), expire after seven days, and are invalidated by edits or by a participant losing authority before execution. The requester can never self-approve, and approval and execution are separate audited steps with current revalidation. If all eligible approvers are lost, pending requests stay pending or expire with actionable guidance — never a bypass.

Cross-domain audit exports

Export Organization, Project, or Release audit evidence as JSON + CSV under a common manifest, packaged as a ZIP.

Requesting an export. Requires export authority (plus audit read) and, for Project or Release scopes, current access to that Project. A request names its scope, an optional UTC occurrence window, an optional canonical source selection, and the as-of snapshot boundary — events recorded after that instant are excluded. The request’s digest (scope + sources + boundaries) is its retry identity: re-requesting the same scope and boundaries reuses the same job and never creates a duplicate package; the as-of boundary is fixed at the first request.

Generation. Jobs run in the background worker and report queued/running/completed/failed/cancelled with counts and safe error codes. Generation is bounded: 1,000,000 events, 512 MiB uncompressed, and a 30-minute window — exceeding any fails explicitly with narrowing guidance, and partial output is never marked complete or downloadable. Before streaming, a bounded internal export pin (at most 45 minutes, not a legal hold, granting no read authority) protects the exact selected sources through finalization; if the pin expires or is lost mid-run, the export fails and produces no package. Disposal reservations that already won for the scope are reported as disposed coverage — their records are never counted as exported.

The manifest. Every format describes the same authorized population: the manifest records the schema version, scope/filters/as-of, per-source coverage (including collected/unavailable/not-applicable/disposed states and gaps), counts, source identifiers, provenance, the active retention-policy state, overlapping legal holds (digests only — hold reasons stay governance-private), omissions, and per-artifact SHA-256 digests with verification instructions. A digest demonstrates byte consistency only — it is not independent attestation or WORM storage.

Downloads. Downloading revalidates your live membership, audit-read and export authority, and underlying Project access — every time. A revoked viewer is denied even while a delivery artifact is still within its 24-hour window. The delivery artifact is disposable and expires within 24 hours; the retained package follows the saved-packages retention class and can be repackaged on demand after the artifact expires. Downloads are audited without package contents.

Cancellation. A queued or running export can be cancelled; partial artifacts are removed and the pin released. A completed export is a retained package and cannot be cancelled.

Evidence review and chain of custody

Organization administrators (and members delegated audit read) can browse the Organization evidence index in settings without binding or selecting any Project. Each entry shows its canonical source, occurrence time, and a truthful disposal state: retained, held, disposal scheduled, or disposed. Per-domain panels state whether each evidence domain is collected, not collected, or stale (its newest event predates the Organization’s governance baseline) — missing history is never reconstructed.

Every entry links to a chain-of-custody view for the canonical record: availability, disposal history, covering holds (identified but never quoted — hold reasons stay governance-private), retained export packages whose snapshot boundary covers the record, and applicable policy revisions. Records that are missing or already disposed are reported exactly as such; nothing is invented.

Policy evaluation (v1)

The fixed, versioned evidence-rule catalog is evaluated from your evidence — it is not a scripting engine and cannot be extended with custom logic. Each rule result states the rule id and version, the evaluated scope, the as-of time, observed facts, exceptions, and an outcome of pass, fail, unknown, or not applicable:

capture-coverage — every canonical evidence domain reports captured-event presence. A domain with no captured events is unknown (inactivity and a capture gap are indistinguishable); missing evidence never passes.
retained-package-digest — the most recent retained evidence package is checked against its recorded digest. No package as of the evaluation time is unknown; a mismatch is a fail.
hold-respected — active holds are matched against disposal activity. An Organization without holds is not applicable; unverifiable scope matching is unknown, never assumed.
approval-present — with independent approvals disabled the rule is not applicable; pending protected-action requests or too few eligible approvers are a fail.

The strictest observed component wins per rule, and results never produce a certification claim, compliance score, or automatic conformity finding.

Standards mappings

Organizations may optionally attach standards labels — currently ISO/IEC 27001 and ISO 9001 control references — to rule-catalog ids. A mapping is an evidence index: it labels where a control’s evidence rule lives. It is not a certification, not a compliance score, and not an automatic conformity finding, and unselected controls are simply not evaluated (they are never reported as passing). Manage mappings in settings or through the API below.

Governance operations

The operations panel reports, without any evidence bodies: export jobs by state with the oldest queued age and last failure code; disposal backlog with the oldest scheduled age and the last successful sweep; active holds with overdue review dates; and which domains have captured evidence. Failed exports are re-requestable with the same scope (the same job is re-queued); manual retries of the disposal sweep converge with the hourly worker. Job retries preserve their logical effect identity, and the restore-reconciliation ledger state is shown when a restore has been verified.

Held-evidence accounting

Retention previews count held evidence separately (and exclude it from disposal eligibility) using the same hold predicate the enforcement fence uses, so a preview can never disagree with what a later sweep would protect.

Organizations can delegate narrow governance capabilities — audit read, export, policy management, hold management, and disposal/cancellation — to individual members. A delegation never grants Project read access or another capability, and both grants and revocations are audited. Revocation is checked at every execution, including later job runs and downloads. Project retention overrides are off by default and may only extend retention within an Organization-defined extension ceiling; an indefinite Organization policy cannot be overridden by a Project. Authorized Project managers can set Project extensions for the Projects they manage, and every extension set or removal is recorded in an append-only history that keeps the acting user, reason, and revision number. Extension changes also durably invalidate outstanding unconfirmed previews for the retention class, so a stale impact is never confirmed.

Public API preview reads require the governance:read token scope and current Organization ownership, administration, or both policy management and audit read delegations. This applies to listing previews and reading a preview by ID. Either delegation alone is insufficient; revoking either blocks subsequent reads, including access through a previously saved preview URL.

These policy capabilities do not by themselves delete or export evidence. See Release audit evidence for saved packages and the surrounding workflow.

Public API and CLI access

Retention governance is available through Public API v1 with a Personal Access Token granted governance:read or governance:write:

GET/POST /api/v1/organizations/{organizationSlug}/governance/retention-policies;
GET/POST /api/v1/organizations/{organizationSlug}/governance/retention-previews;
GET /api/v1/organizations/{organizationSlug}/governance/retention-previews/{previewId};
GET/POST /api/v1/organizations/{organizationSlug}/governance/capability-grants;
POST /api/v1/organizations/{organizationSlug}/governance/capability-grants/{grantId}/revoke.

Evidence review, policy evaluation, standards mappings, and the operations view use the same scopes:

GET /api/v1/organizations/{organizationSlug}/governance/evidence — the paginated evidence index (filters: retentionClass, sourceIds, occurredFrom, occurredUntil, projectId); every page, including direct-ID access, revalidates live authority;
GET /api/v1/organizations/{organizationSlug}/governance/evidence/{sourceId}/{recordId} — the chain of custody for one record;
GET /api/v1/organizations/{organizationSlug}/governance/policy-evaluation — rule results as of an optional asOf time;
GET/POST/DELETE /api/v1/organizations/{organizationSlug}/governance/standards-mappings — evidence-index labels (mutations require governance:write and live policy-manage authority; unknown rule ids are rejected);
GET /api/v1/organizations/{organizationSlug}/governance/ops — the operations view (no evidence bodies).

Mutation requests require an Idempotency-Key header. A created revision returns an ETag such as "governance-policy-4". A retrospective activation first generates an impact preview and then creates the revision with that previewId; reductions are rejected with APPROVAL_SERVICE_UNAVAILABLE until the separate approval service is delivered. Readable request examples are published in the generated OpenAPI document.

The official Hamstik CLI has no typed governance command yet; use its documented Public API passthrough with the same paths and scopes:

hamstik --json --no-input api request \
  "/api/v1/organizations/<ORG>/governance/retention-policies"
hamstik --json --no-input api request \
  "/api/v1/organizations/<ORG>/governance/retention-previews" \
  --method POST --field retentionClass=audit_events --field durationDays=365 \
  --field graceDays=30 --field projectOverridesEnabled=false \
  --field appliesToExisting=false \
  --field reason="Annual retention review by the governance owner."

No governance workflow ever requires direct database access; use the settings UI or the Public API endpoints above.

Historical integrity

New Work Item evidence and canonical Release/membership events keep captured actor and resource labels. Older Work Item records without snapshots show unknown historical labels; current names are never substituted. Renaming a user, renaming a Work Item or Release, or removing a user account does not rewrite previously recorded evidence. Corrections are added as new linked evidence rather than editing the original.

Attachment removal events retain the original display filename and attachment ID even after the stored bytes are deleted. Work Item activity and history survive permanent Work Item deletion, while Project and Organization disposal still remove their evidence; retained regulatory archives and legal holds are separate governance capabilities.

Availability

Audit & Compliance is available to every Organization. A Project uses it only when an Organization administrator enables the Application for that Project; Organization governance continues to work regardless of any Project binding.

Keep the boundary clear

Audit & Compliance provides a useful operational record. Evaluate your own retention, export, and evidence requirements before treating it as a legal or regulatory archive.

See Applications, Work Items, and Release audit evidence for the surrounding product workflow.