Detect that someone edited your Sume Format before the weekly run
Pin the Format's package_sha and version, and compare them right before a weekly run. If a teammate edited the Format, stop the run instead of paying for it.

How can I tell a Format changed since I last tested it?
A Format record carries a version that rises with each commit and a package_sha, the identity of the files behind it. Read both from GET /v1/formats/{handle}/{slug}. If the sha you pinned after your last review differs from the current one, the package changed, whoever changed it.
This matters because a run reads whatever package is live when it starts. A scheduled or scripted weekly run does not warn you that a colleague edited SKILL.md on Friday afternoon; it just runs the new instructions on Monday and charges for them.
What does a pre-flight check look like?
Store the reviewed sha next to your job config. Before submitting, fetch the Format and compare. On a mismatch, fail loudly and let a person re-review. One caveat from the docs: Formats published before package_sha existed do not have one, so treat a missing value as unknown and fall back to comparing version.
import os, requests
URL = "https://api.sume.com/v1/formats/acme/weekly-promo"
H = {"Authorization": "Bearer " + os.environ["SUME_API_KEY"]}
def preflight(pinned_sha, pinned_version):
f = requests.get(URL, headers=H, timeout=30)
f.raise_for_status()
data = f.json()["data"]
sha = data.get("package_sha")
if sha is not None and sha != pinned_sha:
raise RuntimeError(f"package changed: {pinned_sha} -> {sha}")
if sha is None and data["version"] != pinned_version:
raise RuntimeError(f"version moved to {data['version']}")
return data["version"]
What do I do after a mismatch?
Read the files with the Contents API, review the difference by hand, and re-pin the new sha once you approve it. Sume has no history browser or blame, so keep your own copy of the reviewed files in git and diff against that.
Afterward, each run receipt shows format.version, so you can confirm which version a past run used. If a run already went out on an unreviewed package, compare its version with your pinned one, and decide whether to regenerate. Since receipts also carry usage, you can see what the unreviewed run cost before you decide.
- Pin both the sha and the version in your job config.
- Call the check immediately before the submit, not at the start of the week.
- Keep reviewed copies of the package in your own repository.
- Use
If-Matchon your own writes so you never overwrite a colleague's edit unknowingly.
Sources
Related posts
More in Formats
- Flat Sume output schema for a spreadsheet row: null is an empty cell
Design a Sume output_schema that maps to one spreadsheet row. Optional fields become nullable strings, and a null becomes an empty cell when you write the CSV.
- Format run queue.position is always null: no queue depth published
The status response has a queue object, but position is null on purpose. Use queue.state and expires_at for waiting UX instead of a fake countdown.
- Argon 1M output tokens vs Sume Format 120,000-character schema cap
A 1M-token output limit does not lift Sume's output_schema limits. The 120,000 characters bound the schema, and the fallback projection reads 8,000 characters.
- Argon targets long-horizon work; a Sume Format run ends at 90 minutes
Google positions Gemini 4 Argon for long tasks. A Sume Format run is force-finalized as failed 90 minutes after creation, so split long jobs into runs.
Written by Sume