Behind the Door

1Where are my receipts kept?

With the app that made them, in its own records. A receipt is a small record: what happened, when, and a fingerprint of the record it belongs to, not the money, and not the contents of your accounts. The fingerprints are chained together, so if one receipt were changed or moved out of order, the chain would show it.

State: proven. The chaining itself, in a tested kit (built, clean-room tested, independently verified). That kit is tested, not deployed. It is not running in any live system today. Designed: receipts kept this way inside the products themselves.

2Where are the logs kept?

Beside the records they describe, under the same control. The log is the list of who touched what, and when, including us. Every read of a protected record is meant to leave its own entry in the log, so the log itself can be checked the same way the receipts can.

State: proven. In the tested kit, no record opens without its check passing, and every attempt lands on the chained access log. Designed: that discipline at product scale.

3Where is all my data kept?

In the smallest number of places the design allows, and split on purpose: the record in one place, the keys that protect it in another, and identifying details never stored inside the receipts themselves. Our apps are also built to keep data with you: the store apps collect nothing for us and send nothing to us, see question 11.

State: designed. The splitting arrangement as a product construction. Proven: we run our own work this way today. Records, keys, and identities are held by separate hands, under a written rule.

4What exactly is behind the door?

Receipts and their fingerprints. Logs of access. References that point at records without containing them. Not behind the door: your money (these systems keep records; they do not hold funds), your full account numbers, or the contents of your documents. The most sensitive things are not locked up by us, they were never brought in.

State: designed. The rule that contents are never held. Proven: the tested kit’s entries carry hashes and references, never contents, checked at the kit’s own gate.

5Who can see behind the door?

You, the person the records belong to, and the people you authorize, in the apps’ own terms. On our side, no single person holds the record, the keys, and the identities together; the house’s work is divided so that reaching a record takes more than one pair of hands, by rule.

State: proven. The separation of hands as our operating practice (a written standard, three roles kept apart, independently checked). Designed: the same compartments as product construction.

6Can Agentic Armor read my receipts?

Your receipts are encrypted under keys tied to you, their holder, that is the design, stated exactly. In the tested kit, receipt encryption of exactly this kind has been built and checked. Under that design, what your key protects does not open without your key, and the design contains no side door for us.

State: proven. Receipt encryption in the tested kit. Designed: encryption under holder-tied keys across the products. It leans on the answer to the next question, which is printed without softening.

7Where are the keys? Who holds them?

State: not yet built.

The piece that creates and holds a person’s keys, we call it the Agentic Key, stands at design, with zero code written. What has to happen before it can be built, and where its design stands, are counted in Data Security, under “One point on keys.” We print that here because so much leans on it: until it is built, every answer that depends on personal keys is a designed answer, not a working one. Inside our own house, working credentials live in a proper password vault, our own stored secrets live in a protected vault of their own, and a register keeps track of which keys exist, the register holds descriptions only, never the keys themselves. (That arrangement is proven. It is our own practice, under a written standard.)

8Can a receipt be changed afterwards?

A receipt is never quietly rewritten. The record is append-only: a correction is a new entry that names the entry it corrects, and the original stays where it was, visible as history. The chain of fingerprints makes a silent change detectable, that is the part that has been proven, in the tested kit.

State: proven. Tampering and reordering are detectable, in the tested kit (not deployed). Designed: corrections cite the original and never overwrite it, as the products’ standing rule. We already keep our own books this way.

9What if someone steals the data anyway?

Nothing is unhackable, and we do not say otherwise. The design’s answer is that what can be stolen is bounded: records without contents, fingerprints instead of the things themselves, and keys kept apart from the data they protect, so a theft yields fragments, not your life in one file. If something looks wrong, the design’s response is to halt rather than leak: a freeze that stops the system and writes its own receipts while it does.

State: designed. Stolen-is-useless and exposed-is-bounded are design claims, printed as such. The freeze is designed too. It is filed, waiting on its final approval, not yet analyzed, and nothing about it operates today.

10What if I lose my phone, or something breaks?

Your records are designed to be restorable, and restoring them is a deliberate act, not an automatic one. We print the honest part without being asked twice: the house’s own restore exercise has not yet been run. It is the first cure on our own security list, and until it has run and been checked, “we can restore it” is a designed answer, not a proven one.

State: not yet built, as an exercised capability: the restore drill. Designed: the restore path itself.

11Do you track me, or sell my data?

No, and we hold that answer to evidence, not intention. The standing rule for our store apps: no analytics, no advertising trackers, no third-party trackers in the app at all; no account required for the app’s own functions; nothing leaves your device for our benefit. Crash or diagnostic information stays on the device, or goes only when you choose to send it, each time, never silently.

State: designed, with its verification named. Before any store listing may say “no data collected,” the built app is checked at the binary level. Its permission list is read. Its network traffic is watched for any third-party address. A separate person does the checking, and the receipt of that check rides with the app’s record. Until an app has that receipt, the honest sentence is this one: the rule stands, and the check is the price of printing it as fact.

12What can my bank see?

Today: nothing through us, no bank has adopted Agentic Armor, and no bank receives anything from these apps. If a bank ever adopts it, adoption is that bank’s own act, on its own side: the bank would see its own side of its own customers’ transactions, the counting done in front of both parties. What a bank could never see through adoption is your other banks, your other records, or anything behind a door its own act did not open.

State: not yet built: any bank adoption. Designed: the bank-side picture, labeled feature by feature wherever it is shown. The products mark what works today and what unlocks only when a bank adopts, and nothing is sold as the other thing.

13If I leave, what happens to my receipts?

Deletion is designed to be real: when you delete, the item and what the system learned from it go together, and a marker remains saying only that something was removed, not what it was. Your receipts are yours; the exit is part of the design, not a favor granted on request.

State: designed. The learning-and-deletion machinery is stated as a design. It ships only after it passes its own checks, and this answer will be updated when it does.

14Is all of this proven, or promised?

Both, and the labels are the difference, that is the point of this page. Said in one sentence, the way our own security list says it: the house’s designed security is ahead of its exercised security. What is proven today is proven in a tested kit and in our own operating practice, checked by a separate person. The kit is not deployed in any live system, ours included. What is designed is stated as a design. What is not yet built, the Key above all, is printed as not yet built. The gap is not a secret kept from you; it is the list we work from, and its cures are sequenced: the restore exercise first, the exercised checks next, the Key on its own ordered line.

15Who checks you?

A different person checks us, by rule. The team that builds a thing does not grade it. The grades are written, kept, and re-checked on a weekly rhythm, and we publish our own audit, findings and all, where anyone can read it. Outside scanning and testing services are not used on our systems. Verification stays inside, where the people checking can be named. Where a claim on this page outruns its evidence, our rule is that the claim is struck or re-labeled, in the open, with the correction printed.

State: proven. The checking practice as our operating record. Checked documents, a published audit, and a weekly verification rhythm all exist and can be asked for by name.

16What about the platforms underneath you?

Underneath every app and every website sits somebody’s backbone, a phone’s own system, a store, a company that carries the website’s traffic, a social platform. Our promise binds us: our code, our pages, our conduct, what we choose to build and where we choose to stand. It cannot bind the owner of the ground. The owner of a backbone can see what travels their ground, under their own rules, a social platform’s house is governed by that platform’s practices, not ours, and we will not pretend otherwise in smaller print.

So we do three things. We build our own layers to collect nothing. We put nobody’s private data on anyone else’s ground, what we publish on platforms is public material by design. And we print the map: which backbone carries what, whose it is, and what they can see, so the promise you read from us is exactly as wide as the ground we actually govern, and not one inch wider.

State: proven. The boundary itself, as the platforms’ published terms stand. We have read our main platform’s terms and act on them, including switching off the training setting its terms offer. Designed: the map as a standing, printed part of this page’s honesty.

17If you partner with a big platform, what stops them from harvesting the data?

The design’s answer is construction, not a promise: your data travels sealed under keys that never leave you, the platform carries the minimum a task needs, and every touch writes a receipt you hold. A contract says a partner will not. This design is built so it cannot — and what never arrives cannot be harvested.

State: designed. The partner arrangement as a construction: keys held by their holder, minimum carriage, and a receipt on every touch. No platform partnership exists today, and none is implied; this is the design a partner would be adopting, printed as a design.

18Can’t someone just talk the AI into opening it, like other chatbots?

No, and the difference is where the lock sits. In the systems that were talked around, the AI itself was the guard. Here the AI is never the lock: it moves work, it does not hold trust, and it does not hold your keys. Your seal is mathematics, not a mood, and anything that matters passes a named person, deciding with your verification. A fooled AI can still make noise — bad drafts, wasted motion — and every attempt writes a receipt you hold, so nothing happens quietly.

State: designed, with its proven piece named. That attempts land on a chained log is proven, in the tested kit (question 2). The seal and the human gate are the design’s stated construction. Your own phone and your keys remain real surfaces — the film prints those edges itself, not in a footnote.