ThinkToAction Lab
Loading your workspace…
ThinkToAction Lab
Loading your workspace…
Trust Center · FAQ
These answers describe the current product and its known boundaries. Native disclosure controls work with a keyboard and common screen readers.
How the account design protects access—and what still needs live verification.
The implemented design uses managed email/password authentication, verified server sessions, protected routes, same-origin checks, request limits, and database rules that match each record to one user. The live identity and database environment still needs end-to-end acceptance before accounts can be called operational.
Today, learning progress and drafts can live in your browser's local storage. Account-backed storage is designed for Supabase PostgreSQL, but no approved live project or data region is documented yet. We will name the real region before public activation.
The application delegates password handling to Supabase Auth; it does not store password hashes itself. The live provider configuration still needs verification. We avoid the vague promise that a password is simply ‘encrypted.’
They should not. Database row-level rules match each record to one user. That cross-account isolation still requires live negative testing with separate accounts.
There is no employee support operation today. In a future live service, tightly authorized operators or infrastructure providers may need limited access for security, support, deletion, or legal duties. We will document roles and access before launch; we do not promise that stored data is technically impossible for every administrator to access.
You can access it through a valid session. The identity provider and narrowly authorized operators may administer identity or data when needed. Your employer, another learner, and the public receive no account-access feature.
The code uses HTTP-only, SameSite cookies, the Secure flag in production, server-side session checks, and session refresh. You can choose a remembered browser session or a browser-session cookie. Final lifetimes depend on approved provider settings.
The implemented recovery flow asks the identity provider to send a time-limited link without revealing whether an address has an account. Email delivery is not yet live-tested.
The account area includes global session revocation. It needs live provider acceptance before we can promise production behavior.
The designed flow deletes the managed identity and cascades through account-owned database records. Browser-local drafts on your devices do not disappear automatically. Backups and provider retention still need a production schedule.
What is collected, why it is needed, and what is not part of the product.
Depending on use, the platform may handle account, learning, AI, security, commerce, and allowlisted first-party product-event metadata. Analytics collection is disabled, accepts no learner or workplace content, and has no configured third-party provider.
To provide learning you request, remember progress, protect an account, generate feedback you explicitly request, and respond to future support or rights requests. We do not authorize unrelated secondary use.
Yes. Core learning, the Framework, Practice, evidence, and reflection do not require external AI.
A production retention schedule has not been approved. Browser data remains until you or the application clears it. Durable account data is designed to remain until deletion or another approved rule applies.
The account design includes evidence deletion and complete account deletion. Remote deletion cannot erase browser-local copies on every device, provider records, or backups outside their schedules. Live deletion acceptance is pending.
The implemented account area creates a JSON export covering profile and learning records. It requires the live account service to operate.
No sale or behavioral-advertising system exists. The Academy does not currently sell personal data. Any future change would require a new decision, implementation, notice, and legally required choice—not a silent policy edit.
There is no employer, manager, team-reporting, or enterprise visibility feature. Do not share an export or account access if you want work to remain private.
There is no learner-to-learner sharing feature. The account database is designed to isolate records by user.
If OpenAI is configured and you explicitly request external Coach or Mentor feedback, submitted text is processed by the OpenAI API. Local or deterministic operation does not make that call. Do not submit confidential or sensitive information.
The Academy does not build or train its own model from learner content. We have not verified a live OpenAI project and its data-control settings, so those settings must be confirmed before external AI is activated.
You can avoid external AI by not requesting it or by enabling local-only mode. The server guard enforces the account preference for both Coach and Mentor when authenticated persistence is configured; Mentor also offers a per-request local-only choice.
AI is an optional practice aid—not the product's authority or decision maker.
Reflective Signal uses AI to give bounded, qualitative feedback on an explicitly submitted Practice response using the published Framework. It is not a human coach or employee-performance assessment and does not decide whether you are capable.
Mentor reviews plain text that you choose to paste. It does not automatically import Practice history or workplace files.
An external model is used only after an explicit feedback request and only when the OpenAI API is configured. Opening, typing, saving, or completing a lesson does not automatically call OpenAI.
AI is not required for reading, Practice, progress, evidence, summaries, or core learning. It is not used when no external provider is configured or a local/deterministic mode applies.
Yes. The learning method and scenario practice stand on their own.
The application returns a plain-language error or a bounded deterministic/local fallback where one exists. It does not silently switch provider.
Requests use strict schemas, small approved context packets, published Atlas references, output validation, evidence checks, limits, timeouts, and safe fallbacks. These controls reduce risk; they cannot make output infallible.
No. Reflective Signal and Mentor do not hire, promote, rank, discipline, or determine workplace eligibility.
No. It is educational feedback, not management, supervision, or accountable professional judgment.
No. Practice may help, but no improvement, promotion, influence, or business outcome is guaranteed.
AI lacks full context, accountability, lived judgment, and reliable factual authority. You decide what is accurate, appropriate, ethical, and safe.
A plain-English guide to each learning record.
It stores learner-written summaries of observable work. You choose what to enter and its privacy classification. Omit identifying or confidential workplace details.
It is a qualitative draft built from evidence you select. Private reflections and workplace-sensitive entries are excluded by default. It documents participation, not verified capability.
Practice history may include scenario responses, revisions, reflections, dates, and Framework references. It is not an employer report.
Reflective Signal history contains AI-guided feedback results you choose to save. It is not a hidden score or employee profile.
With persistence consent, it may contain the pasted draft and review. Without consent, text and review can remain only in page memory for the tab.
They are intended for the learner and are not shared with employers or learners. Browser scripts on the same site and narrowly authorized operators may technically process stored data, so do not enter secrets.
Drafts can remain in the browser as temporary local data. If account sync is active, supported records may also copy to the account.
The relevant AI request uses a deterministic path and does not send that text to an external model. It does not mean every browser record is encrypted or invisible to all site code.
It is the designed ability to copy supported learning records into your authenticated database record and load them on another device. Live cross-device acceptance is pending.
You can delete evidence or the durable account through implemented controls once live. Device-local copies must be cleared separately.
Commerce architecture exists, but purchase remains inactive until the seven listed legal, country, tax, invoicing, refund, and digital-content decisions are resolved.
Not yet. Hosted Stripe Checkout, purchase, payment, entitlement, refund, billing-reference, webhook, and AI-allowance architecture exists, but the product and price remain inactive until commercial and policy decisions are approved.
No. Founder Edition v1 is a one-time purchase with no recurring subscription and no automatic renewal.
The intended Founder Edition policy uses a 14-day request window. A request does not revoke access; entitlement changes only after approval and successful processing. Final wording and digital-content consumer-right implications require counsel review.
Billing-reference architecture supports receipt or invoice references after activation. The final receipt, invoice, merchant, and tax behavior depends on approved Stripe and commercial configuration.
Price records support an unknown, inclusive, or exclusive tax state, but no tax position is approved. Seller, countries served, collection, and invoice requirements remain founder/counsel decisions.
Founder Edition is designed as a one-time purchase, not a recurring plan. Billing history and refund requests are implemented; no subscription cancellation flow exists.
No separate credits or top-ups are sold in Version 1. Founder Edition includes 30 successful external Reflective Signal evaluations and 15 successful external Mentor analyses; local-only operations and provider failures do not consume them.
Accessibility is a requirement, while testing gaps remain visible.
Professionals should be able to learn and practice without interface exclusion. Accessibility improves clarity and control for everyone.
The target is WCAG 2.2 Level AA. It is a goal, not a claim of complete conformance.
The product uses semantic headings, labels, landmarks, status regions, and text alternatives intended to support screen readers. A full usability study is not complete.
Navigation and core controls are designed for keyboard use with visible focus. Native FAQ disclosures use standard browser keyboard behavior.
The project needs a full automated browser audit, representative screen-reader study, and end-to-end review of live identity emails and third-party states.
A monitored accessibility contact is not approved. Before launch, the Academy must publish that channel and an alternative process.
Reported barriers and test findings are treated as product defects. Public statements should change as evidence changes.