Skip to content
SmokeAlarm.ioBY AUDIT SHIELD
Open app Book a walkthrough
Menu

Evidence & control 5 MIN READ

From inventory discrepancy to a reviewable audit trail

Learn what to retain as a discrepancy moves through evidence gathering, independent verification, named approval, authorized action and source confirmation.

By Audit Shield AIReviewed

The quick answer

A reviewable audit trail connects the original finding, source records, physical evidence, supported cause, proposed change, named approval, action result and confirmation. It preserves the distinction between what was observed, what was inferred, what was authorized and what actually happened. An approved proposal is not yet a verified result.

Preserve the original question and its sources

A later reviewer should be able to understand why a case existed. Retain the package and location, the quantities being compared, the relevant units, the source timestamps and the finding that prompted the review. Keep a missing count or unavailable source visible as missing evidence.

Supporting material should stay attached to the question it helps answer. A package history, manifest reference, count or note is more useful when its role is clear. Avoid replacing the original finding with only a final summary; the intermediate decisions explain how the conclusion was reached.

Keep observation, hypothesis and supported cause distinct

An observed difference is not automatically an explanation. A possible timing issue, receipt error or counting mistake should remain a hypothesis until the available records support it. Note what evidence was checked and what is still needed instead of turning uncertainty into a confident narrative.

A physical count is part of that evidence. SmokeAlarm's count and correction workflows preserve independent observation and verification. An imported quantity does not become a physical count merely because it appears on the same screen, and the observation alone does not authorize a change to the state record.

Record exactly what was proposed and who approved it

A correction should identify the affected package and the intended change, with its supporting cause and required approvals. Permission to investigate is distinct from permission to approve or execute. Retaining the named decision helps reviewers understand both the reasoning and the authority behind an action.

SmokeAlarm reads Metrc by default. A platform administrator can authorize the narrow package-quantity correction path for a store. The case must still satisfy count verification, cause, approval and readiness requirements, including founder approval where that control is enabled. Broader writes should not be inferred from this specific path.

Verify the outcome and retain the history

After an authorized action, distinguish an attempted change from a confirmed result. Source read-back is the evidence of what the external system reports afterward. If the response is missing or does not match the approved change, preserve that state and the next step instead of presenting the case as successfully resolved.

SmokeAlarm retains an append-only audit log and a dated evidence binder with a SHA-256 fingerprint. A fingerprint helps identify the file that was produced; it does not establish that every underlying fact is correct or that a regulator has approved it. The quality of the evidence and decisions remains central.

  • Original finding and source context.
  • Counts, verification and supporting evidence.
  • Supported cause and proposed change.
  • Named approval and authorization state.
  • Execution result and source confirmation.
  • The reason the case was closed or remains open.

ILLUSTRATIVE EXAMPLE

Approval exists. Source confirmation is still missing.

In this illustrative scenario, a case has the required evidence and approval, and an authorized correction has been attempted. The read-back confirmation has not arrived.

  1. Retain the approved change and the recorded execution result without relabeling either as verified.
  2. Keep the case's missing confirmation visible to the responsible person.
  3. Review the source state through the supported workflow before deciding the next action; do not assume a repeated write is safe.
  4. Retain the confirmation and closure reason when the result is actually established, or document the unresolved state.

This example describes evidence handling, not instructions to submit or repeat a live correction. It uses no customer records.

SMOKEALARM / CURRENT AVAILABILITY

How this fits the platform

Audit trail and binderAvailableDiscrepancy casesAvailableAutopilot remediation engineConfirm availabilityMetrc connection (reads)Requires setup

SmokeAlarm's audit trail, evidence binder and discrepancy cases are available with setup. AI remediation is not generally released; confirm availability and scope with the team. Metrc corrections are narrowly scoped, off by default and available only when the store and case satisfy authorization, approval and readiness requirements.

Common questions

Can AI approve a correction?

No. The Cannabis Control contract allows AI to prepare a draft. It cannot sign, approve, execute or contact Metrc or the POS. Consequential changes require the applicable human authorization and server-enforced workflow.

What does an audit binder establish?

A binder organizes retained evidence. Its usefulness depends on the underlying records, investigation and decisions; it is not a regulatory sign-off or a promise of an outcome.

Why keep a failed or unconfirmed action in the history?

It explains what was attempted and what remains unknown. Removing that distinction could cause a later reviewer to assume that an approval or transmission produced a confirmed source change.

Written by Audit Shield AI

Reviewed · Built in New York, by New Yorkers.

All guides

FROM READING TO DOING

Make it concrete.
Bring your workflow.

See how the records, the people and the next step come together in SmokeAlarm.

Book a walkthrough