# Tenant Billing Demo

This demo workspace models a small multi-tenant SaaS back office. It is intentionally compact in code, but it still shows a realistic set of responsibilities that agents and developers ask about when they are dropped into an unfamiliar repository: authentication, tenant scoping, billing, notifications, jobs, reports, and support operations. The code path is designed so that a graph can surface the important entities quickly, while the surrounding documentation provides the kind of broader project context that would otherwise inflate prompt size if an agent had to read everything directly.

The runtime entrypoint lives in `src/app.ts`. It wires a tenant-aware auth service, a billing flow that can issue invoices and receipts, a monthly close job, and a report generator used by finance. The important business concepts are split into focused modules. `src/auth/` handles password policy checks and session creation. `src/shared/tenant-context.ts` defines the tenant identity passed through the rest of the system. `src/billing/invoice-service.ts` coordinates invoice work and passes email delivery to `src/notifications/email-notifier.ts`. `src/jobs/monthly-close-job.ts` triggers the monthly billing close and asks `src/reports/revenue-report.ts` to build the summary that finance reviews at the end of the month.

The code intentionally reflects the kinds of questions a developer would ask in a code review, onboarding session, or incident response. They want to know how password login becomes a tenant session, which module is responsible for invoice receipts, what runs the monthly close, how the revenue report is built, and where tenant context is defined. Those are the exact questions in `benchmark-questions.json`. The graph proof is strongest when the question set lines up with real navigation tasks instead of abstract benchmark prompts.

This workspace also includes narrative documentation because real projects almost always do. Teams keep architecture notes, operational runbooks, design rationale, and process guidance alongside code. Agents that do not have graph structure often have to ingest all of that prose together with the source tree. For a small demo, that extra corpus is enough to show the difference between blindly stuffing everything into a context window and pulling a focused subgraph that answers a concrete question.

Nothing in this workspace depends on a database or an external service. The implementation itself stays local and deterministic so the demo corpus is easy to generate in CI and in a fresh checkout. The prompt-backed proof commands (`benchmark`, `eval`, and `compare`) still need whatever terminal runner you choose to pass via `--exec`. The goal is not to simulate production scale perfectly. The goal is to create a controlled, believable corpus that makes benchmark and eval numbers easy to reproduce and easy to explain. When the benchmark says the graph query bundle is smaller than the full corpus, and the eval says recall stays perfect on the labeled questions, users can see both halves of the product claim in a single place.

If you want to adapt this demo for your own presentations, keep the same shape. Use a repository with a few well-named modules, a small labeled question set, and enough surrounding prose that the corpus is meaningfully larger than the critical code paths. That combination makes the difference between naive full-repo context and graph-guided retrieval visible without needing a massive enterprise codebase.