The canon says what a module should do and why. These docs are different: each takes one architectural, technical, or data decision the estate has had to make more than once, lays out the ways it has been taken, what each way bought and cost in a real system, and when each is the right call. They are not rules. They exist because the owner asked that the policy docs "describe and showcase various ways of taking certain architectural and technical and data decisions", after App V5's systemic assumptions turned out to fit its first years and then not the next ones.
Same shape as versable-builder's 13-when-a-solution-is-unsuitable.md: the
tells, the options, the judgment a procedure cannot carry.
| Guide | The decision | Status |
|---|---|---|
00-service-granularity.md | few big services with capabilities added inside, or many small modules; in-system composability or a contract | written 2026-08-18 |
01-outputs-as-a-transform.md | make the pipeline produce the shape the consumer wants, or keep outcomes raw and transform on read | written 2026-08-18 |
02-data-ownership.md | which store holds what, which layer is the source of truth per entity, where configuration lives; the four splits side by side, what each bought and cost, what the misplacements have in common, the five config buckets, the external system of record, and what the module tree chooses | written 2026-08-18; two questions open with the owner |
03-state-derived-or-stored.md | count the record or keep a status column | planned; the substance is in canon/03 and canon/05 today |
03-machine-identity.md | who mints the credential an app presents to a module: five contenders with a ruling each (A validate, B plan, C under contract, D rejected, E later), how more than one is supported at once through the verifier chain, migration between them | written 2026-08-18 |
04-push-or-pull-queue.md | Cloud Tasks push, a Redis-backed pull worker, or in-process; what fairness, versioning, and recovery each gives | planned; the substance is in canon/04 today |