Bloom is a multi-tenant production AI platform for wedding venues, running across four product tiers with versioned prompts, provider routing with a primary and live fallback, per-call metering, and client-facing generation against live business records. Most of the implementation is generated by Claude Code against written architecture, product rules, failure behaviour and acceptance criteria.

A structured cross-tier audit of that system produced three findings that resolved to one.

Client boundary. Provider exceptions could reach a user as a raw server failure rather than an application-owned response. Generation was well specified. Failure was not owned by the application across every route capable of reaching a client. The correction was normalising provider-specific failures at the application boundary and testing failure paths alongside success paths, rather than strengthening the system prompt.

Cost enforcement. A five-dollar daily per-venue threshold pauses autonomous AI behaviour while leaving operator-initiated work available. Metering had generalised, with calls through the shared client recording provider, model, tokens, cost, prompt version and correlation ID. Enforcement had not. It remained a helper function each caller had to invoke, and one path with a legitimate reason for its own provider client recreated the circuit breaker and the usage logging but not the autonomy gate.

Data contract. Lead ageing, stage duration, follow-up scheduling and decay scoring all resolve to a single inquiry_date field. Doctrine covered timestamp handling but did not specify behaviour for a missing or untrusted source timestamp, so the implementation selected new Date().toISOString(), conflating ingestion time with source time and scoring late-processed enquiries as new.

The common shape is control placement. In each case the rule existed as written policy or as a convention on the expected route, one layer above the point where it could be enforced. Written specification moves judgement earlier and gives the diff something concrete to be reviewed against, but a control that holds only because the generating model did not route around it is a capability gap rather than a control.

The session covers the build loop and where audit differs from test, the evidence standard applied to audit claims and why a model-assisted review of a model-built system is not independent assurance, and the migration of each finding to an enforceable boundary. It draws on published work on requirement ambiguity in function-level code generation and on maintainer acceptance of agent-written patches that pass automated graders, and it includes the remediation that remains deliberately incremental.