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 and separate consent.

The application form asks for the ten fields below and a separate required response-consent checkbox. It does not ask for prompts, provider keys, customer lists, or other product data.

Before sending your answers, the form checks the ten qualification fields and required response consent. When a submission succeeds, the application server stores your answers and the form shows a confirmation ID.

If the application service is unavailable, the form cannot confirm receipt. This explanation makes no retention or security commitment.

The required consent permits TenantCap to use the submitted answers to review founding fit and respond about the application.

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

Private Blueprint feedback

A private link accepts a bounded response for review.

If you submit feedback through a private Blueprint link, the selected topic, optional message, consent choices, receipt, and internal Blueprint binding are stored for review. Possession of a private link does not verify the identity of the person who submits a response.

A keyed IP-address hash is used for abuse prevention. The feedback record does not store a raw IP address. The hosting environment may still process network information, so this page makes no claim that it never has a raw IP address.

The form does not ask for credentials, personal data, or confidential material. Local edits to the Blueprint scenario stay in the browser and are not included in feedback unless you type that information into the message.

Separate local event log

Only the browser event log is session-local.

The current fixed logger writes only an event name and a timestamp to browser session storage. This event log is separate from application answers. It does not send these events to a third-party analytics service, and it does not include qualification values or payment details.

landing_page_viewed
demonstration_started
refusal_state_reached
successful_settlement_reached
pricing_viewed
qualification_started
qualification_completed
checkout_started
checkout_completed
checkout_cancelled

Qualification and checkout milestones are logged once per page flow when their stated condition is reached.

Separate test checkout history

The separate checkout test path has its own data handling.

In Demonstration mode, the legacy 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. It is separate from the founding-fit application flow.

Future proposed service

The proposed service boundary would follow the protected call.

If the proposed TenantCap service is built, its operational metadata would be limited to what an allowance decision and settlement need. It would not make TenantCap a gateway, prompt store, customer directory, or provider-credential store.

Calls made outside the future SDK would remain invisible to TenantCap and could not be refused by it. Provider invoices would remain authoritative for what a customer is charged; no exact-charge guarantee is made.

Intended proposed 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.

Apply for founding fit Return home