The problem I started with
My research includes the ordinary controls that keep an AI workflow usable. A helpful draft is not a good result if the system ignores the rule that was meant to control its cost.
How I approached it
I examined the draft-generation boundary and tested the actual failure paths. The public example isolates the admission decision from the provider and database, using controlled responses instead of live credentials.
- The original service verifies identity before admission
- Ask the usage limiter for a decision
- Require an explicit valid allow
- Call the model only after admission
What is implemented
A JavaScript admission function extracted from the TypeScript handler uses injected callbacks to distinguish an explicit denial from a failed or malformed limiter response. The local example omits production authentication and networking. Its offline tests include malformed adapters, retry bounds and checks that generation is not called after rejection.
What the evidence shows
The original focused handler regression produced eight failures and two passes. The repaired private handler passed all ten cases. The public adaptation has its own reproducible tests and provenance rather than borrowing a whole-application security claim.
What remains open
This is one spending-control boundary. It does not establish production authentication, tenant isolation, provider uptime or a complete application security audit.
The next research step
Measure rejected requests, recovery behaviour and spend within a properly authenticated integration test environment.
Inspect and reproduce
The linked package contains its source map, setup instructions and tests. Public examples are designed for local inspection. No production account, paid model call or private dataset is required for their documented offline checks.
Open the implementation