Reference Case: Team Knowledge Answering Assistant

The Team Knowledge Answering Assistant is the TenSaaS reference application. Its purpose is not to show the largest possible AI feature set. It demonstrates the smallest complete enterprise loop from application installation to a traceable team charge.

What a member experiences

An active team member opens the team workspace, enters the application list, and selects Open experience. TenSaaS navigates to the installed application at /workspace/:teamId/apps/:applicationId.

The member can submit a question and receive an answer in the browser. The page keeps the current team and application visible so the user knows which tenant owns the interaction. It also presents the usage outcome returned by the server rather than guessing a cost on the client.

This simple interaction is intentional. It allows a pilot team to test the complete governance chain without adding document connectors, retrieval pipelines, or workflow automation before the boundary is trusted.

Permission model

Use and management are separate permissions:

• ai.use allows an active owner, administrator, or member to run an approved application.
• app.manage allows a team owner or administrator to manage application state and configuration.

The role name alone is not the final authorization. Execution verifies active team membership and the required capability at runtime. A member who was removed, suspended, or no longer entitled cannot rely on a page that was opened earlier.

Application state is checked again

Before a provider call, the server verifies the current team, member, application, contract, and entitlement. The application must still belong to the selected team and remain active.

This closes a time-of-check gap. A team administrator can disable an application after a member loaded the page, and the next run will stop. The browser route is a user experience entry, not an authorization token.

Credentials never enter the browser

The application credential is handled only by the server. The page submits the member input to an authenticated TenSaaS route. The server selects the permitted provider and model policy, calls the provider, and returns a safe response.

This prevents members from extracting a shared key, changing the provider destination, or bypassing team quota with a direct call.

Reserve first, settle actual usage

Model price is activated by the platform administrator. The application runtime uses that server-side price to calculate an estimated maximum cost.

In one transaction, TenSaaS revalidates the team context and reserves the estimate from eligible contract grants. Only then does provider access begin. When the provider returns actual usage, the runtime settles the true cost back to the original grant sources and releases the unused reservation.

If the provider fails, the reservation can be released or refunded through the idempotent ledger path. If the team has insufficient eligible quota, the run fails before the provider is called.

What the receipt proves

A successful run produces an execution record that can be connected to:

• the team that owns the application;
• the member who initiated the run;
• the installed application and active model price;
• the contract grant sources used for reservation;
• actual provider usage and final settlement;
• the resulting team balance change.

The member sees the useful result. Team and platform administrators retain enough context to explain access and cost without exposing provider secrets.

Pilot acceptance checklist

The application is a useful benchmark only if both success and refusal paths work:

1. An active member with ai.use can open and run the experience.
2. A member without ai.use is denied.
3. An inactive member or disabled application is denied at execution time.
4. An invalid contract or entitlement is denied.
5. Insufficient team quota stops the provider call.
6. A successful provider response settles actual usage and releases the remainder.
7. Browser network responses contain no application API key.
8. Repeated callbacks or retries do not duplicate the charge.

Once one team can pass this checklist, TenSaaS has proven more than a chat screen. It has proven a reusable enterprise AI application contract.