TenSaaS Documentation

TenSaaS is an enterprise multi-tenant AI platform. It makes the team the ownership boundary for members, AI applications, entitlements, quota, and audit history.

Choose the correct operating surface

A route shows context. It does not grant authority. Every team request resolves the signed-in user and verifies an active membership on the server.

Role model

Platform administrator

Platform administrators operate TenSaaS itself. They activate model prices, create or manage tenant contracts, allocate traceable grants, and review platform-wide risk. Platform roles must not be inferred from team roles.

Team owner and team administrator

Owners and administrators operate one team. They manage members and applications when their team capability includes app.manage. They cannot use that role to access another tenant or change platform-wide model prices.

Team member

An active member with ai.use can run an approved team application. The member uses the team's entitlement and quota under server policy. The browser never receives the application API key.

Create and prepare a team

1. Open Team workspace from personal settings.
2. Create a team and choose a clear operating name.
3. Add existing registered users as owner, administrator, or member.
4. Ask a platform administrator to activate a contract, entitlement, and team grant.
5. Install or activate the required AI application.
6. Confirm members who will run the application have ai.use.

For a paid pilot, start with one team and a small named member group. Do not widen access until both successful and denied runs have been verified.

Reference application: Team Knowledge Answering Assistant

The Team Knowledge Answering Assistant is the reference browser experience for the TenSaaS application contract.

Open the experience

1. Enter the target team workspace.
2. Open Applications.
3. Find Team Knowledge Answering Assistant.
4. Select Open experience.
5. TenSaaS navigates to /workspace/:teamId/apps/:applicationId.

The destination is bound to the team and installed application. Copying another team or application identifier does not bypass membership checks.

Submit a question

Enter a question in the browser and submit it. The server performs the following checks again before provider access:

• authenticated user and active team membership;
• application ownership and active state;
• required ai.use capability;
• active contract and entitlement;
• active model price;
• sufficient eligible team grant balance.

If any check fails, execution stops. The runtime does not fall back to personal credits, another tenant, or an unpriced model.

Quota lifecycle

The runtime owns cost calculation. A browser cannot submit its own credit cost.

1. Calculate an estimated maximum cost from the active model price.
2. Reserve the estimate from eligible contract grant sources in a transaction.
3. Call the provider from the server.
4. Read actual usage returned by the provider.
5. Settle the actual cost against the original grant sources.
6. Release the unused reservation.

Retries and refunds use idempotent ledger references so a repeated message does not create a second charge.

Review the receipt

After a successful run, review the team credit and audit surfaces. A complete operating record can connect the execution to its team, member, application, model price, contract grant sources, actual usage, and resulting balance change.

Fail-closed conditions

TenSaaS refuses execution when any required boundary is invalid:

• the session is missing or expired;
• membership is inactive;
• ai.use is missing;
• the application is disabled or belongs to another team;
• the contract or entitlement is inactive;
• no active model price is available;
• eligible team quota is insufficient.

These refusal paths are part of the product contract. They should be tested during pilot acceptance, not treated as exceptional implementation details.

Security expectations

• Provider and application credentials remain server-side.
• Team identifiers from the browser are treated as untrusted input.
• Application and membership state are rechecked at execution time.
• Team quota mutation requires transactional storage semantics.
• Audit records retain the actor, tenant, target, and relevant action metadata.
• Production multi-tenant quota deployments use PostgreSQL as the supported baseline.

Pilot acceptance

Before adding more applications, verify:

1. A permitted active member can run the reference application.
2. A member without ai.use is denied.
3. A removed member and a disabled application are denied on the next run.
4. Insufficient quota prevents provider access.
5. Successful usage settles actual cost and releases the remainder.
6. Repeated callbacks or retries do not duplicate charges.
7. Browser responses and source inspection reveal no application API key.
8. The team credit ledger and audit history explain the run.

Further reading

• Why TenSaaS makes the team the AI tenant
• Four records that make AI usage accountable
• Reference case: Team Knowledge Answering Assistant

Support

For pilot support, use the support entry in the signed-in workspace. Include the team, application, approximate run time, and visible execution reference. Never send application credentials or provider keys in a support request.