Privacy and product boundary
A working explanation of the data boundary.
This page is a working explanation for the current qualification and founding flow. It is not final legal advice and is not a completed privacy policy.
Current qualification flow
The form asks for ten bounded fields.
The form uses these fields to check whether a team fits the Founding criteria. It does not ask for prompts, provider keys, customer lists, or other product data.
- Work email
- Company name
- Company website
- Role
- Whether the server application uses TypeScript or Node.js
- Whether the application calls OpenAI or Anthropic directly
- Approximate application tenant count
- Whether the plans need plan-specific allowances
- Current allowance approach: gateway, custom counter, provider alert, open-source ledger, or none
- Product-boundary confirmation
Local event log
The browser records names and timestamps locally.
The current fixed logger writes only an event name and a timestamp to browser session storage. It does not send these events to a third-party analytics service, and it does not include qualification values or payment details.
landing_page_vieweddemonstration_startedrefusal_state_reachedsuccessful_settlement_reachedpricing_viewedqualification_startedqualification_completedcheckout_startedcheckout_completedcheckout_cancelled
Qualification and checkout milestones are logged once per page flow when their stated condition is reached.
Checkout modes
Payment mode changes what a provider sees.
In Demonstration mode, the qualification flow goes to a local success page. No card is collected and no payment is taken.
In Stripe test mode, Stripe receives the test transaction, the work email as the customer email, and the already collected bounded qualification metadata needed for the test Checkout Session. This is test data and never represents a live charge.
Future operational scope
The service boundary follows the protected call.
The intended TenantCap operational metadata is limited to what an allowance decision and settlement need. It does not make TenantCap a gateway, prompt store, customer directory, or provider-credential store.
Calls made outside the SDK remain invisible to TenantCap and cannot be refused by it. Provider invoices remain authoritative for what a customer is charged; no exact-charge guarantee is made.
Likely operational metadata
- An opaque tenant identifier supplied or derived by the customer application.
- Project, plan, and policy identifiers needed for an allowance decision.
- Provider and model path, estimated usage, and actual reported usage.
- Reservation or settlement state and the associated event timestamps.
Explicit exclusions
- Prompts and responses.
- Attachments and embeddings.
- Provider credentials, including API keys.
- Customer and end-user names and email addresses are excluded by default. TenantCap would use opaque tenant IDs supplied by trusted server code.
- End-user IP addresses.
- Arbitrary metadata unrelated to the allowance decision.
A clear qualification boundary
The current flow does not make unsupported promises.
This explanation does not promise a retention period, security control, data location, availability date, or regulatory compliance outcome. Those matters require a later, reviewed policy and operational implementation.