Four Records That Make AI Usage Accountable

An enterprise AI platform often starts with a user table, an application table, and a credit balance. That is enough for a demo. It is not enough to answer a procurement, security, or finance question after real teams begin using the system.

TenSaaS keeps four records separate: team, application, contract grant, and usage ledger. They work together during every run, but they are not interchangeable.

Team: the accountable operator

The team identifies the tenant that owns the operating context. Membership belongs here, along with tenant-specific roles and lifecycle state.

A teamId in a URL is only navigation context. The server still resolves the current session and verifies active membership. That distinction prevents a caller from changing one identifier and reading another tenant.

The team record answers:

• Which organization unit owns this activity?
• Which people currently belong to it?
• Is the tenant active and allowed to operate?

Application: the governed capability

An AI application is more than a model name. It is a team-owned asset with its own state, configuration, permission boundary, and credential handling.

The application record answers:

• Which team installed this experience?
• Is it active now?
• Which members may use or manage it?
• Which server-side policy selects the provider and model?

Management and use are different operations. Team owners and administrators can receive app.manage. Active members can receive ai.use. The browser can open the experience, but it never receives the application API key.

Contract grant: the source of spending authority

A balance without a source is difficult to reconcile. TenSaaS attaches usable credits to a team contract grant. That source can carry validity, entitlement, and remaining amount.

The grant answers:

• Which commercial agreement funded this run?
• Is the funding source currently valid?
• Does it entitle the team to this application or model policy?
• How much of the source remains available?

Keeping the source matters when a team receives multiple allocations. Refunds, expirations, and adjustments can return to or reference the correct origin instead of changing an anonymous total.

Usage ledger: the receipt

The ledger records what happened. A dependable entry links the team, member, application, execution, grant source, and amount. It should support idempotent consumption and refunds, because provider callbacks and network retries do not promise exactly-once delivery.

The ledger answers:

• Who initiated the run?
• Which application and model policy were used?
• What was reserved before provider access?
• What actual usage was returned?
• What amount was settled or released?

The runtime chain

These records meet in a strict execution order:

1. Resolve the authenticated user and active team membership.
2. Resolve the active team application and required permission.
3. Resolve the active contract and entitlement.
4. Calculate estimated cost from the platform model price.
5. Reserve from eligible grant sources in one transaction.
6. Call the provider from the server.
7. Settle actual usage and release the unused reservation.
8. Return a safe result and receipt to the browser.

This order avoids two dangerous gaps. Provider access cannot begin before spending authority is reserved, and the browser cannot dictate the cost that the server will record.

Why one large record is worse

It can be tempting to store all of this on a single application or team row. That makes the first screen simple, but lifecycle changes become ambiguous. A team may remain active while one application is disabled. A contract can expire while audit history must remain. A refund can happen after an execution completes.

Separate records allow each lifecycle to change without erasing the others. They also make tests sharper. Tenant isolation, permission enforcement, application state, grant validity, and ledger idempotency can each fail independently and default to denial.

This is the practical value of a multi-tenant AI foundation. It does not merely add a team selector. It gives every AI run an accountable operator, an approved capability, a spending source, and a durable receipt.