One JSON File That Says No: A Readiness Record for Free-Model Features

Agentic coding tools keep getting faster. Teams merge generated code faster than they can verify it. That gap is where small features quietly rot.

Here is an example scenario. A two-person team adds a summarizer to their docs site. They point it at a free model endpoint and host the helper on a free server. Nothing is broken. Nobody can prove anything either.

A checklist lives in someone's head. It records intention. A readiness record records evidence, with dates and an expiry. When the evidence goes stale, the build fails closed.

That is the difference worth building today.

Why dates matter more than checkboxes

Most readiness docs answer one question: did we do this? They never ask when. Free tiers change, model aliases drift, and a rollback you rehearsed in March is folklore by June.

So the record needs two rules. Missing field means fail. Stale field means fail, exactly the same way.

Staleness is the honest part. It converts "we think this still works" into a date a machine can check.

The six fields

Each field carries evidence and a time-to-live. Copy the table, then change the TTLs to match your own risk.

Field	Evidence it carries	TTL	Fail behavior
feature + owner	One named human, not a channel	none	exit 1 if owner missing
model.id + captured_at	Exact pinned identifier you called	14 days	exit 1 if older
budget.cap + unit	Hard per-run ceiling, in one unit	30 days	exit 1 if absent
canary	One task, expected vs observed, date	7 days	exit 1 if observed != "pass"
rollback	Command string + rehearsed_at	30 days	exit 1 if empty or stale
expires_at	The record's own death date	—	exit 1 after that date

Two details matter. The canary is one task, not a suite. The rollback is a command you can paste, not a paragraph.

A named owner is not bureaucracy. It is the field that stops a record from becoming everyone's problem.

Step 1: Write the record

The artifact below is illustrative. I have not run it against a real repository, and the identifiers are placeholders.

{
  "feature": "kb-summarize",
  "owner": "sam",
  "model": { "id": "REPLACE_WITH_PINNED_ID", "captured_at": "2026-11-09" },
  "budget": { "cap": 5, "unit": "usd_per_run" },
  "canary": {
    "task": "summarize-3-short-docs",
    "expected": "3 bullets, no invented names",
    "observed": "pass",
    "at": "2026-11-09"
  },
  "rollback": { "command": "flag off kb-summarize", "rehearsed_at": "2026-11-02" },
  "expires_at": "2026-11-23"
}

Keep secrets out of this file. It should be safe to paste into a pull request comment.

Step 2: Validate it, fail closed

About fifty lines of standard library Python. Run it in CI on every pull request that touches the feature.

import json, sys, datetime

TTL_DAYS = {"model": 14, "canary": 7, "rollback": 30}
TODAY = datetime.date.today()

def age(date_str):
    return (TODAY - datetime.date.fromisoformat(date_str)).days

def check(rec):
    errors = []
    for field in ("feature", "owner", "model", "budget", "canary", "rollback", "expires_at"):
        if not rec.get(field):
            errors.append(f"missing {field}")
    if errors:
        return errors

    if age(rec["model"]["captured_at"]) > TTL_DAYS["model"]:
        errors.append("model pin is stale")
    if age(rec["canary"]["at"]) > TTL_DAYS["canary"]:
        errors.append("canary evidence is stale")
    if rec["canary"]["observed"] != "pass":
        errors.append("canary did not pass")
    if age(rec["rollback"]["rehearsed_at"]) > TTL_DAYS["rollback"]:
        errors.append("rollback not rehearsed recently")
    if not rec["rollback"]["command"].strip():
        errors.append("rollback command is empty")
    if TODAY > datetime.date.fromisoformat(rec["expires_at"]):
        errors.append("record expired")
    return errors

rec = json.load(open(sys.argv[1]))
problems = check(rec)
for p in problems:
    print(f"FAIL {p}")
print("OK" if not problems else "BLOCKED")
sys.exit(1 if problems else 0)

Run python readiness.py readiness.json and check the exit code, not the text. Exit 0 means the evidence is current. Exit 1 means someone re-runs a canary or a rollback drill.

Step 3: Refresh the two dated fields

When the build fails, you only ever fix one of two things. You re-run the canary and update observed and at. Or you rehearse the rollback and update rehearsed_at.

That is the whole maintenance loop. Ten minutes a week, mostly waiting for a single summarization call.

Where free model access and a free server help

This loop costs almost nothing to start. The canary is one small request. The validator is a static file. Neither needs infrastructure.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

MonkeyCode is an open-source project that offers free model access and a free server option. The allowance is currently advertised as a large free token pool; check the project's own pages for the exact current figure and conditions before you depend on it. Treat any quota as a number to verify, not a number to build a business on.

For this workflow, the free server option covers the boring half. Host the validator and the one-task canary harness there. Then every pull request runs the same check the team runs locally.

Pin the model identifier you actually called. Free access can change what sits behind an alias.

Limitations and who should skip this

This record proves currency, not correctness. A canary that passes can still miss a real failure mode.

The TTLs are guesses until your own incidents disagree with them. Start short and lengthen them with evidence.

Skip this if you are in a regulated environment. Free tiers and third-party servers may not satisfy your data rules.

Skip it if you cannot name one owner. A record with no owner becomes a red build everyone ignores.

Also check current limits yourself. Free offerings change, and this article does not promise permanence.

What to add

The obvious gap is a data-handling field. What leaves your box, and where does it land?

If you were adding one field to this record, which would it be? More useful: what condition should make the build fail that this validator still accepts?