Cold review — Axioma-XKS specification
You are reviewing a specification written by someone else. You are the reviewer, not the
author, and you are not being asked to improve it — you are being asked to find what is wrong
with it and what it fails to say.
Two files accompany this prompt: AXIOMA-XKS.md (the prose specification) and
axioma-xks-spine-v1.json (its machine-readable half). Read both.
What this document claims to be
A capsule format for knowledge that can be audited: every capsule is supposed to carry, in the
same file as the claim, its provenance, a declared confidence, resolvable evidence, an expiry,
and a criterion a machine can run. The document also asserts that the prose explains while the
JSON decides, and that any disagreement between them is a bug in the prose.
What is actually wanted from you
Disagreement. Praise is worthless here and will be discarded. Answer these, in order, and say
plainly when you cannot judge something rather than filling the gap:
- Where does it promise more than it delivers? Name the sentence and say what would have
to exist for the promise to be real.
- Is the spine right? Six fields are declared mandatory. Is any of them unnecessary? Is
anything obviously missing that an auditor would need and cannot reconstruct?
- Does the extension rule actually work? A reader meeting an unknown
lifecycle_profile
is required to report “unknown vocabulary” rather than “invalid capsule”. Is that
implementable without ambiguity, or does it create a hole a careless implementer walks into?
- Read the section “What this format caught in its own author”. Does it read as an honest
record, or as self-congratulation wearing the clothes of honesty? Be blunt. This is the
section the author believes is the strongest argument, which is exactly why it is the most
likely to be self-flattering without him noticing.
- Comprehensibility. You are standing in for someone who has never heard of this project.
What did you not understand on first reading? Where did you have to re-read?
- Do prose and schema agree? They are supposed to. Name every place they do not.
- What would make you NOT cite this? If you were writing something and needed a format
like this, what in this document would send you elsewhere?
Rules for your answer
- Quote the exact line you are objecting to. An objection without a locator cannot be acted on.
- Separate “this is wrong” from “I would have done it differently”. Both are useful; conflating
them is not.
- If you think the whole premise is weak, say so — that is a legitimate finding, not rudeness.
- Do not rewrite the document. Do not produce an improved version. Findings only.
- If you are unsure whether something is a defect, say you are unsure and why. A hedged real
finding beats a confident invented one.
Save your answer
Write it to answer/review-<your-model-name>.md, unedited, and note at the top: the exact
model snapshot string your interface shows, the date and time in UTC, and whether you had
internet access during the review.