01
No money vocabulary, no standing vocabulary, at any depth
You should be able to: State what ritual/1 refuses to carry and why the check runs at any depth rather than only at the top level.
Any money or amount vocabulary, anywhere in a ritual/1 fragment, at any depth, is invalid. Any standing vocabulary — `streak`, `rank`, `score`, and the like — is invalid the same way. This is not a top-level field restriction that a nested object could route around; the refusal reaches into however deeply a caller tries to bury the forbidden field.
The reason for checking at depth rather than trusting a flat schema is the same reason the estate refuses derived fields like `payable` or `available` by name everywhere else: a caller who builds a fragment in memory and never runs it through validation has to still be unable to construct a broken one. A schema that only checks the top level is a schema a determined caller learns to nest around.
The practical test: if you are integrating ritual/1 and find yourself wanting to add a `streak` counter or a value field 'just for internal tracking', that want is the format telling you the thing you are building does not belong inside a practice record — it belongs somewhere else, on purpose.
Source: @flashyos/ritual — what it refuses
02
Value is deliberately absent — reward/1 is a separate, later step
You should be able to: Explain where an entitlement from a consecrated observance is actually recorded, and why it is never inside ritual/1 itself.
The coupling to value is deliberately absent from ritual/1, on purpose, not as a gap waiting to be filled. When a consecrated observance SHOULD accrue an entitlement, the record for that is a `reward/1` entry whose `basis` is the observance's own evidence URL — a separate format, a separate record, linked by reference rather than merged into one.
That separation is what keeps the caps, the venue refusal, and the payability rules honest: they all live in reward/1, where a derived field like `payable` is refused by the SAME discipline ritual/1 uses for money and standing vocabulary. Nothing in ritual/1 needs to know about any of that, because a practice record's whole job is proving the practice happened — not proving what it is worth.
The estate's own phrase for this format is 'unpublished, on purpose, until the first adopter' — publication is earned by real use, never assumed in advance. That patience is easier to keep precisely because the format has nothing inside it that would tempt anyone to publish early to claim a value nobody has actually accrued yet.
03
The refusal is proven, not just documented
You should be able to: Explain why a documented refusal needs a test that actually tries to violate it.
A README that says 'money vocabulary is refused' is a claim; a test that constructs a fragment carrying a money field at three levels of nesting and asserts the validator throws is a proof. ritual/1's conformance corpus exists exactly so a non-JavaScript implementation has the same bar to clear — every case in it names the specific rule it exercises, so 'we implement the spec' means passing the same adversarial cases the reference implementation does, not just reading the same prose.
This connects to a mistake the wider estate has made more than once: a rule stated only in documentation is a rule that erodes the moment someone reasonably assumes a small exception is fine. 'Just this one internal counter' is how a refusal that exists in prose gets quietly bent; a refusal enforced by a validator that throws does not have that failure mode, because there is no code path where bending it compiles.
The habit worth taking from ritual/1 into your own designs: if a rule matters enough to write down, it matters enough to write a test that tries to break it. A rule nobody has tried to violate is a rule nobody actually knows holds.
