Trust · private development · synthetic evidence only
The minimum crosses the boundary.
What stays on your device, what may cross only after you review it, what comes back, and what Tech City can and cannot read. Stated as boundaries, not reassurances.
Every control described here is either working with synthetic data in development, built locally, or labeled as an open gate. Nothing on this page is a certification, an audit, or a production claim.
Where things live, and who can see them.
- Your trusted device. Private file parsing, readable vault content, your vault keys, packet construction and preview, and encryption of anything you save.
- The control plane. Sign-in identity, opaque ownership metadata, exact-object authorization, ciphertext storage, policy enforcement, and operational evidence. It never holds a vault key.
- The inference processor. Only the exact purpose-bound packet you approved, through Amazon Bedrock in a fixed region. It receives neither your vault key nor general access to stored records.
A fourth boundary we disclose rather than hide. Tech City controls the code delivered by the application's web origin. A compromised or malicious release could reach unlocked data in the browser even though operators cannot decrypt stored ciphertext. Installed-app status alone does not remove that risk, which is why strict deployment separation, least privilege, a restrictive content security policy, dependency integrity, and reviewed release evidence are launch work—not marketing.
Authenticated ownership is deployed synthetically. Protected requests, accepted saved results, recovery, and account cleanup revalidate the same Cognito subject around sensitive operations and fail closed when the account changes or signs out. The service now returns a complete subject-derived inventory for managed objects, and a scheduled bounded monitor checks for managed ciphertext without an authoritative control record. Whole-account deletion is still incomplete: legacy remote ciphertext, production crypto, retention and remediation policy, rollback rehearsal, and hostile-browser acceptance remain open.
Can Tech City read it?
The vault promise is about persisted private content. We will not shorten it to “Tech City can never read any customer data”, because that would hide the deliberately readable rows below.
| Boundary | Readable by Tech City? | Required behavior |
|---|---|---|
| Persisted vault object in storage | No | Encrypted on the trusted device before upload; storage holds only ciphertext plus a separate outer storage-encryption layer. |
| Account, recovery, and object keys | No | Kept on trusted devices and in your recovery material; never sent to Tech City or to the analysis service. |
| Snapshot shared with a recipient | No | Encrypted locally for the verified recipient's exact key; the recipient, not Tech City, can decrypt it. |
| Sign-in and billing identity | Yes | Only what is necessary, kept separate from content records. |
| Operational control metadata | Yes, minimized | Purpose-specific pseudonymous bindings, bounded timestamps and state, content-free evidence. Pseudonymous is not anonymous, and we do not call it that. |
| The analysis packet you approved | Yes, transiently | Previewed and approved by you, used once in the inference path with content logging disabled, and not retained as plaintext. |
| The structured result before you encrypt it | Yes, transiently | Validated and returned without content logging; encrypted on your device before it is saved. |
| A recipient's copy after download | Outside Tech City's control | Revocation cannot erase a copy a recipient already downloaded. We say so before you share. |
Your private vault is designed to be encrypted using keys controlled by you, so that Tech City's normal systems and personnel cannot decrypt your stored vault contents. When you explicitly request analysis or share selected information, only the data you choose is disclosed, for that purpose.
Public wording pending legal and plain-language review · design intent, proven with synthetic data
Every analysis request follows this order.
- 1. Decrypt the selected source locally
- 2. Build a minimized, goal-specific packet locally
- 3. Show included, summarized, excluded, and unknown fields
- 4. Approve the exact digest, purpose, service, region, and expiry
- 5. Submit only through the fixed processing boundary
- 6. Application and model content logging are disabled
- 7. The structured result and its citations are validated by software
- One request. No automatic retry. A changed packet voids the approval.
- 8. The result returns without persistent server plaintext
- 9. It is encrypted locally before you save it
- Background analysis is never inferred from ordinary vault storage
Keys you control. Layers we name.
Stored private objects are encrypted on the trusted device before upload. The storage service adds its own outer encryption layer as defense in depth; that layer is not your vault encryption and is never described as such. Recovery is designed to work without a Tech City recovery key, and the synthetic recovery candidate has been browser-validated.
What remains open. The exact vault, recovery, and hosted release implementation must pass independent security review together with the applicable operational-security baseline. No FIPS claim is made, and none will be inferred from an algorithm name, a cloud key service, a browser API, or an endpoint. A validated client module remains a conditional future path if a customer, contract, regulator, or insurer requires it. Physical iOS and Android evidence also remains open.
Status: built and proven synthetically · production acceptance open
One snapshot. One verified person.
Sharing is deliberate and point-in-time: one immutable snapshot, encrypted on your device for one recipient's verified key, delivered once. Before sealing, you compare the recipient's safety number over a separate channel and confirm the match. Revocation blocks future access and removes every server-held copy—and the interface tells you plainly that it cannot erase a copy already downloaded.
Status: bounded sharing and revocation working synthetically · safety-number ceremony built locally
The model writes around the numbers, not the numbers.
Software owns the facts
Which weeks, which values, what difference, which citations—computed deterministically from the approved packet and checked before you see a result.
The model owns the caveats
Uncertainty, limitations, an authority boundary, and one bounded question. A response that tries to substitute its own facts is rejected.
Abstention is allowed
When evidence is insufficient, unstable, or ambiguous, the result says so. It does not invent a pattern to fill the space.
Guidance may take a coaching role for a goal the user owns and explicitly selects. It is not medical guidance and never diagnoses, treats, or changes a plan owned by a human coach or clinician.
What we do not claim.
- No SOC 2, ISO 27001, HIPAA, FIPS, or other audit or certification has been earned
- Not a claim that Tech City can never see plaintext: hosted client code and an explicitly approved analysis packet are named boundaries; minimized data is not anonymous
- Not production-ready; no public customers, no revenue
- No universal deletion: a recipient's downloaded copy is outside our control
- No medical guidance, diagnosis, or treatment
- No automatic sync, background analysis, or account scraping
- No marketplace, storefront, or social platform exists today
- No published-terms integrity or independent timestamping service exists today
- No claim that one accepted synthetic scenario generalizes to your data