Trust
Trust, shown the way a security reviewer would want to see it.
Every statement here carries how sure the project is of it, taken from the project's own records. Where something does not exist, has not been tested or is not held, it says so first.
- Certifications, audits and independent assessments held
- None
- Pilot items verified on a deployed environment
- 0 of 20
- Critical pilot items still open
- 11 of 11
- Real customer data gate
- Closed
How sure each statement is
Six levels, used the same way on every page. Nothing is described more strongly than its level.
- Tested locallyBuilt, and an automated test that would fail without it passes. Not yet shown on a deployed system.
- Reviewed in codePresent in the code and read by a person, without a test of its own.
- Needs checking on a live systemDepends on how the real environment is set up, which the code cannot prove.
- Partly in placeSome of it exists; what is missing is said.
- Not establishedNobody has shown this yet, so no statement is made.
- Not in placeIt does not exist, or is not held. Said plainly.
Ten ways to look at it
Each page answers one question a reviewer would ask, shows what exists and how sure we are, and ends with a small example on fictional data.
- 5 in place · 1 openCustomer-controlled accessAccess by organisation, role and location, decided on the server, and what stops when it is withdrawn.
- 5 in place · 2 openRead-only database connectionsWhat a read-only connection proves before every use, what it cannot do, and what a customer's administrator should check first.
- 4 in place · 3 openUploaded dataLimits, what is read and what is not, and the checks that are not done.
- 5 in place · 3 openAI provider disclosuresWhich features can send content outside the platform, what they may send, and what has not been established.
- 5 in place · 3 openEncryption and access controlsWhat protects sign-in, sessions and secrets, and the controls that only a live inspection can settle.
- 5 in place · 2 openAudit evidenceA tamper-evident decision record, what it proves, and what it cannot.
- 6 in place · 1 openHuman approvalsWhat an assistant may draft or propose, what it refuses, and how a person's decision is recorded.
- 2 in place · 4 openData retention and deletionWhat can be deleted now, what must wait, what is kept by design, and what is not finished.
- 4 in place · 2 openCustomer-hosted and dedicated deploymentUpload, read-only connection, natural-language questions, a customer-hosted connector and a dedicated environment: what exists.
- 0 in place · 7 openPilot security requirementsThe twenty-item gate, what it counts, and what is open.
Five ways to bring data to the platform
What the project's own assessment found for each, including the two that do not exist.
- Tested locallySecure upload. Files and media, bounded and read in a sandbox. Tested locally; not scanned for malware; scanned pages are not read.
- Tested locallyGoverned read-only database connection. A live connection proved read-only before each use. PostgreSQL only; tested on disposable databases.
- Reviewed in codeQuestions over already-authorised sources. Natural-language answers drawn only from what the asker may see. Built as tested code; deliberately not connected to a customer screen.
- Not in placeA connector inside the customer's network. An agent that only calls out. Does not exist.
- Not in placeA dedicated or isolated environment. A separate environment for one customer. No per-customer deployment mechanism exists.
Deployment and connection in detail · Security overview · Pilot data handling · Ask for the evidence