Keep Unsourced Limits Out of Model-Drafted Product Pages

Model-drafted product pages should ship only when every availability sentence is copied from a human-owned pin. A true option becomes a false support fact as soon as the draft adds a quota, a duration, a region, or a hardware shape. The workflow below separates draftable procedure from owned availability, then fails the docs check when that split is violated. Readers can reproduce the check with the file layout and the Python example that follows.

The failure mode is invented precision

Routine documentation review will catch a broken command, yet still miss a confident extra that no operator ever sourced. A page can correctly say that a free model access option exists, and that a free server option exists, without knowing any numeric allowance. When a generator treats that silence as a blank to fill, it may emit token counts, retention windows, instance classes, or model identifiers. Those additions are not style issues, because a later reader can treat each one as an operational commitment.

Weekly headlines do not repair that gap, even when a team wants the page to feel current. A title seen on a community feed is an untrusted topic signal, not a primary source for access limits or server terms. This walkthrough therefore ignores unsourced news claims and uses only the two availability options supplied for the drafting step. If a newer limit appears in a vendor document, a human adds it to the pin before any model is allowed to repeat it.

Split ownership before the first draft

The model may draft sequencing, transitions, and cautions, provided none of those sentences assert a product limit. The human must own the pin, the source note, the review date, and every phrase that mentions access or compute availability. The model must not add pin keys, rewrite allowed phrases, or infer a limit from a neighboring sentence. This split is what keeps generated prose away from facts a maintainer has not explicitly signed.

Surface	Model may draft	Human must own
Procedure between markers	Steps, transitions, and cautions	Whether those steps match the repository
Availability pin entries	Nothing	Statement, source, review date, and allowed phrases
Quotas, durations, and regions	Nothing	Omission, unless a primary source is attached
Model names and hardware nouns	Nothing	Omission, unless the pin lists the exact token
Checker fixtures	Nothing	Expected pass file and expected failure files

The table is the review contract, and a draft that adds a column of estimated limits has already crossed the boundary. Procedure quality can be discussed only after the checker passes, and not while an ownership defect is still open. A cautious adjective does not convert an unsourced limit into an owned claim that reviewers can trust. Ownership means presence in the pin, rather than confidence in the wording of the drafted sentence.

The pin is the only availability source

Store the pin at a fixed ownership path, and treat a missing review date as a failed documentation build. Each claim carries an identifier, a kind, one statement, a source label, and the exact phrases a draft may repeat. The two claims in the example are operator-supplied availability options, not measured quotas and not a permanence promise. If a statement cannot be sourced, it stays out of the pin, and the draft is not allowed to mention it.

{
  "schema_version": 1,
  "owner": "docs-platform",
  "reviewed_on": "2026-10-10",
  "claims": [
    {
      "id": "AVAIL-001",
      "kind": "access_option",
      "statement": "A free model access option is available for the drafting step.",
      "source": "operator-supplied",
      "allowed_phrases": ["free model access"]
    },
    {
      "id": "AVAIL-002",
      "kind": "compute_option",
      "statement": "A free server option is available for the drafting step.",
      "source": "operator-supplied",
      "allowed_phrases": ["free server option"]
    }
  ]
}

The date in that file is the walkthrough freeze date for this explanation, not a certification of unnamed product terms. A maintainer who adopts the schema replaces both statements with sentences the operator can still support. Changing a statement without changing the review date should fail review, even if the checker does not yet encode that policy. A claim identifier remains stable only for as long as the meaning of its statement remains completely unchanged.

Run the workflow in four steps

1. Freeze the pin on the review date

A maintainer copies only statements supplied for this publication, then sets the review date before opening a drafting session. No model call is allowed to create the file, append a claim, or complete a blank numeric field. The commit that introduces the pin should contain no generated page, so the ownership diff is visible on its own. Later statement edits require a human commit, a new review date, and a note that names the primary source.

2. Mark the draftable region and constrain the prompt

The page template keeps availability sentences outside the draft region, or repeats them only as exact allowed phrases. A model may fill the procedure region with steps for running the checker, reading the failure output, and opening a review. It may not edit the pin, the disclosure paragraph, the ownership table, or any fixture that defines a failure. The markers make that boundary visible, so a diff review can reject an edit that crosses it.

Draft only inside the PROCEDURE markers.
Do not add numbers, durations, hardware nouns, model names, or availability claims.
Repeat an availability phrase only if it appears in allowed_phrases.
If a fact is missing, write OWNER_MUST_SUPPLY rather than guessing.

That prompt is only a constraint, and it is not evidence that any particular model will follow it. The checker remains mandatory because instruction text does not bind a later edit, a paste from a chat, or a merge from another branch. Teams that skip the checker and simply trust the prompt have not actually separated ownership from drafting. Prompt compliance is only an input convenience, while the pin check remains the actual publication gate.

3. Run the checker before prose review

The example below is a proposal, and it was not executed against a production docs tree for this article. It uses only the Python standard library, reads the pin, and scans markdown after removing exact allowed phrases. A remaining digit, duration word, hardware noun, or model-identifier pattern is reported with a line number and a non-zero exit status. Exact repeats of pinned phrases are removed before the scan, so the allowed availability wording can appear without becoming a failure.

#!/usr/bin/env python3
"""Proposal checker: reject availability prose that extends the human pin.

Unexecuted example. Run it locally before adopting it in a docs build.
"""

import json
import re
import sys
from pathlib import Path

DURATION = re.compile(
    r"\b(day|days|month|months|year|years|forever|permanent|hourly)\b",
    re.IGNORECASE,
)
HARDWARE = re.compile(
    r"\b(gpu|cpu|core|cores|region|regions|ram|ssd)\b",
    re.IGNORECASE,
)
NUMBER = re.compile(r"\b\d[\d,._]*\b")
MODEL_ID = re.compile(
    r"\b(?:gpt|claude|gemini|llama|qwen|deepseek)[\w.-]*\b",
    re.IGNORECASE,
)


def load_pin(path: Path) -> tuple[list[str], str]:
    data = json.loads(path.read_text(encoding="utf-8"))
    reviewed = str(data.get("reviewed_on") or "")
    if not reviewed:
        raise SystemExit("pin missing reviewed_on")
    phrases = []
    for claim in data.get("claims", []):
        phrases.append(claim.get("statement", ""))
        phrases.extend(claim.get("allowed_phrases", []))
    return [phrase for phrase in phrases if phrase], reviewed


def scan(markdown: str, phrases: list[str], reviewed: str) -> list[str]:
    redacted = markdown.replace(reviewed, " ")
    for phrase in phrases:
        redacted = redacted.replace(phrase, " ")
    errors = []
    rules = (
        ("number", NUMBER),
        ("duration", DURATION),
        ("hardware", HARDWARE),
        ("model_id", MODEL_ID),
    )
    for index, line in enumerate(redacted.splitlines(), start=1):
        for label, pattern in rules:
            for match in pattern.finditer(line):
                errors.append(
                    f"{label} not in pin at line {index}: {match.group(0)}"
                )
    return errors


def main() -> int:
    if len(sys.argv) != 3:
        raise SystemExit(
            "usage: check_availability_pin.py PIN.json PAGE.md"
        )
    phrases, reviewed = load_pin(Path(sys.argv[1]))
    text = Path(sys.argv[2]).read_text(encoding="utf-8")
    errors = scan(text, phrases, reviewed)
    if errors:
        print("\n".join(errors))
        return 1
    print("availability pin check passed")
    return 0


if __name__ == "__main__":
    raise SystemExit(main())

The pass fixture repeats only pinned phrases inside ordinary procedure sentences that a reviewer could ship. The number fixture adds an unsourced integer, and the duration fixture calls an option permanent without a sourced window. Both negative fixtures must exit with status 1 before this publication gate is considered fully defined. These files are part of the owned artifact, not optional illustrations that a later draft is free to delete.

Run the checker against the frozen pin, then read the exit status before editing prose.
The drafting step may use free model access.
The drafting step may use the free server option.

The drafting step includes 123456 units at no cost.

The free server option is permanent.

python3 scripts/check_availability_pin.py \
  docs/ownership/availability-pin.json \
  docs/fixtures/availability_pass.md

python3 scripts/check_availability_pin.py \
  docs/ownership/availability-pin.json \
  docs/fixtures/availability_number.md

The first command is the pass path, and it should exit with status 0 on the clean fixture. The second command should exit with status 1 when its fixture contains an unsourced integer such as 123456. A duration fixture that calls the option permanent must also fail, even though that sentence contains no digits. Store those fixtures beside the pin so a later edit cannot quietly drop the negative cases from the test plan.

4. Review the failure, not the model's confidence

A failing line returns to the owner as an ownership defect, not as a request to make the sentence sound more cautious. Replacing an unsourced integer with a vague magnitude still fails the policy, even if this first checker only catches the listed patterns. The durable fix is deletion, or a human update to the pin with a primary source attached. Prose review should start only after the checker exits with status zero on the page under review.

Checker result	Next action	Not an acceptable fix
Status 0	Human reads the procedure for accuracy	Skipping the diff because the draft sounded sure
Number finding	Delete the integer or pin a sourced value	Rounding it, or calling the figure approximate
Duration finding	Delete the duration	Writing a for-now hedge without a sourced window
Hardware or model-id finding	Delete the noun	Substituting a different unsourced name

Where the drafting step may run

A drafting pass can use MonkeyCode's free model access, or the free server option if the draft should stay off a laptop. Disclosure: This article was prepared as part of MonkeyCode's product outreach. Those two options matter only as the place where procedure prose is generated, after a human has already frozen the pin. They are not a source for quotas, model names, hardware shapes, or any claim that either option is permanent.

The checker still runs in the repository, because a hosted draft does not become an owned fact. The outreach relationship does not extend the pin, and it does not authorize extra capability claims on the page. No model list, token allowance, server size, or retention period appears here, because none was supplied as a sourced pin entry. Teams that need those details should stop, obtain a primary source, and add one narrow claim before drafting.

Limitations and who should skip it

This gate does not understand synonyms, so a draft can still sneak an unsourced limit through unusual wording. It does not verify that an operator-supplied statement remains true later, which is why a person must refresh the review date. It will false-fail version numbers, benchmark tables, and ordinary words such as core, unless those tokens live in a separate allowlist. Teams that need rich numeric docs should split those pages, rather than weakening this checker until it accepts every digit.

Teams should not use this workflow when they lack a named owner for the pin, because an unowned file is only another draft. They should not use it as the sole control for legal terms, security advisories, or pricing pages, where counsel or finance must own the full text. They should not point the checker at vendor blogs or community roundups, because those pages are not availability sources. A private notebook that never publishes product claims will also gain little from maintaining the extra file.

Close the loop before publish

The publication rule is small: freeze the pin, draft only the procedure, and treat every unsourced number as a build failure. Copy the schema, replace the sample claims with statements your operator can source, and run the fixtures before the next publish. If free model access and a free server option are already part of that drafting step, keep them inside the pin as exact phrases. Leave every unsourced limit out, including any limit that would make the page sound more current than the pin.