Every domain answered, including the ones where the answer is nothing.

No SOC 2 Type II attestation, no organizational ISO/IEC 27001 certification and no ISO/IEC 42001 certification are held. What does exist is a ten-gate pipeline that runs on every push to main and blocks the deploy on failure: type checking, linting, a secret scan across the working tree and full git history, metadata and claims verification, layout measurement across 44 routes and 24 device classes, a no-JavaScript and reduced-motion degradation suite, a WCAG 2.2 target-size check, and Lighthouse thresholds. That is engineering assurance, not an attestation, and the two are not interchangeable.

Check itThe gate definitions are in .github/workflows/gates.yml and scripts/. The certification position is stated on /security.

The public site is prerendered: of 44 gated routes exactly one page is server-rendered on demand, and it is dynamic only because it reads query parameters so the tool behind it works with JavaScript disabled. There are three server route handlers and five runtime dependencies in total. Response headers set Strict-Transport-Security for two years, X-Frame-Options DENY, X-Content-Type-Options nosniff, Referrer-Policy strict-origin-when-cross-origin, Cross-Origin-Opener-Policy same-origin, and a Permissions-Policy denying camera, microphone, geolocation, display capture and payment among others. A Content-Security-Policy is deployed in report-only mode with a reporting endpoint while it is observed, and is not yet enforcing.

Check itEvery header is observable with curl -I against any page. The policy is defined in apps/web/next.config.ts.

No recovery time or recovery point objective is published for client engagements, and none should be inferred. The marketing site itself is statically prerendered and holds no client data, so its availability is not a client-data risk.

Nothing is published for this domain. Ask, and you will get a direct answer or an honest "we do not have that".

Every change reaches production through version control and the gate pipeline; the production build fails on a TypeScript error rather than warning, because typescript.ignoreBuildErrors is set to false. Deployment to the application server smoke-boots a freshly built image in a throwaway container before the live one is replaced, so a configuration or startup failure aborts the deploy with the previous container still serving.

Check itapps/web/next.config.ts for the build setting; the deploy workflow for the smoke-boot-before-swap sequence.

Transport is HTTPS only, with HSTS set to two years. Encryption at rest for engagement data depends on the storage a client specifies, since retrieval can run inside the client's own tenancy; where it does, the client's keys and controls apply and we hold nothing. API credentials used by the site are server-side environment variables only, never exposed to the client bundle, and the site renders no assistant at all when its key is absent rather than shipping a broken one.

Check itHSTS is observable in response headers. The key handling rule is documented in CLAUDE.md section 4 and enforced by the secret-scan gate.

MetaMinds operates no datacenter and owns no physical infrastructure. Physical and environmental controls are the responsibility of the named hosting subprocessors, whose own attestations should be assessed directly rather than through us.

Check itThe subprocessor list at /legal/subprocessors names each host and its region.

Client data never trains any model. The smallest sample that answers the question is requested rather than a full corpus, and the corpus can remain in the client's own environment. Retention is the duration of the engagement, after which data is deleted, and deletion is a line item in the contract rather than a favour. Findings are not published or reused. A data processing addendum is signed as standard.

Check itStated on /security, with the processing terms at /legal/dpa and the retention and rights position at /legal/privacy.

The governing rule is that every factual claim published must trace to evidence that exists today, enforced by a claims register with a row per number and named framework and a gate that fails the build when a page carries a claim the register does not support. Certifications not held are stated on the public site rather than omitted. This posture exists because a previous version of this site claimed SOC 2 compliance without holding an attestation.

Check itdocs/05-CLAIMS-REGISTER.md, the verify gate in scripts/verify.mjs, and the certification rows on /security.

Access to client material is limited to named engineers on the engagement. Background screening, confidentiality agreements and security training are matters of record the owner holds; no policy document is published, and none should be assumed.

Check itThe access position is stated on /security. The remainder is not published.

Credentials issued to us are scoped to the engagement and revocable by the client at any time, and we ask for the narrowest scope that completes the work. The public site has no user accounts, no login and no session state, so it presents no authentication surface of its own.

Check itStated on /security; the absence of authentication is verifiable by inspection of the site.

Deliverables belong to the client, including the parts we would rather not write. Systems are built on the client's own infrastructure and data where they choose, so there is no proprietary format or hosted dependency that has to be unwound to leave.

Check itStated on /security and in the engagement scope on /services.

Retrieval can run entirely inside the client's tenancy, which is the recommended arrangement for regulated data: the corpus does not move and the tenancy boundary is the client's own. Where work runs on our infrastructure instead, that infrastructure and its subprocessors are the ones named in the published list.

Check itStated on /security; hosting is enumerated at /legal/subprocessors.

The site operates a Content-Security-Policy violation reporting endpoint during the report-only observation period. No security information and event management arrangement, log retention period or alerting commitment is published for client engagements, and none should be inferred.

Check itThe reporting endpoint is visible in the CSP header. Nothing further is published.

A security.txt is published so a finder has a defined route to report a vulnerability. No incident response plan, notification timeline or forensic capability is published, and a buyer requiring a contractual breach-notification window should raise it directly.

Check it/.well-known/security.txt is served. Nothing further is published.

Every subprocessor is published rather than supplied on request, each with the legal entity, the specific data it receives, its processing region, whether it is active or dormant, its privacy terms and the date it was first listed. Six are named. The application itself carries five runtime dependencies in total, which is a deliberate constraint on supply chain surface rather than an accident, and a secret scan runs over the working tree and the full git history on every push.

Check it/legal/subprocessors, apps/web/lib/subprocessors.ts, and the secret-scan gate.

Adversarial testing of AI systems is a service line here rather than a claim: prompt injection including injection arriving through retrieved documents, data exfiltration paths, and agent authority boundaries. That is what we do for clients. For our own estate, no internal vulnerability management policy, scanning cadence or remediation service level is published, and a buyer should ask rather than assume.

Check itThe service scope is described on /security and /assure. No internal policy is published.

No endpoint management, device encryption or mobile device management policy is published for the machines used to deliver engagements.

Nothing is published for this domain. Ask, and you will get a direct answer or an honest "we do not have that".