01 — Decision Records
Reasoning, as it was actually written down.
Every architectural decision on a Whyire engagement produces a Decision Record in the client's own repository. These three are redacted for publication — client identity, dates in some fields, and specific figures withheld at the engagement's request.
EVIDENCE — DR-0007 · Masanchara — ledger migration
Shadow-table migration over in-place schema change
Context. Client’s existing point-of-sale ledger could not accept barcode-scanner input without a schema migration on a table with foreign-key dependents across six services.
Options considered.
- In-place migration during a maintenance window
- Shadow table with a nightly reconciliation job
- Defer scanner input to phase two
Decision. Shadow table, reconciled nightly, promoted to primary after four weeks of measured parity.
Consequences. Added roughly nine days and a redacted cost to the timeline. Avoided a maintenance-window migration on a production financial table during month-end close.
EVIDENCE — DR-0012 · Academiq — tenancy
Row-level security over schema-per-tenant
Context. A prospective client asked for schema-per-tenant isolation, citing a competitor’s marketing claim that it is "more secure."
Options considered.
- Schema-per-tenant
- Database-per-tenant
- Shared schema with PostgreSQL row-level security
Decision. Shared schema with row-level security, tenant id enforced at the connection-pool layer.
Consequences. Materially lower operational overhead at the client’s actual tenant count (single digits). We told the client schema-per-tenant would cost more to run and would not measurably change their audit posture — the trade-off in Layer 03 of the Execution Stack, made concrete.
EVIDENCE — DR-0019 · Internal platform — authorization
Hybrid RBAC + ABAC + PBAC over a single model
Context. A regulated client needed role-based grants for day-to-day use but policy-level rules that could change without a deployment, for compliance reasons that shift faster than release cycles.
Options considered.
- RBAC only, with a slower release cycle for policy changes
- ABAC only, more flexible but harder for non-engineers to audit
- A layered model: RBAC for coarse access, ABAC for context, PBAC for policy that compliance can edit directly
Decision. Layered model, resolved in that order, denying by default if none grant explicitly.
Consequences. More complex to reason about than a single model — this is the trade-off we would flag to a client considering it for a simpler use case. Justified here because compliance needed to change policy without a code deploy.