How the work is kept honest.

Report verification

Anyone holding a Solvex report can confirm it is genuine and unaltered, in public, without an account — and without seeing what it says.

Verification answers one question with one of these distinct states. The distinctions are the product: a failed lookup is never rendered as a forgery.

SOLVEX VERIFIED REPORT

The signature verifies. This report is genuine and neither its content nor its file has been altered.

SUPERSEDED

Genuine and unaltered — and no longer the current edition. A later version of this report has been issued. Nothing here is wrong; there is simply a newer one.

REVOKED

This report was withdrawn by Solvex and should not be relied on.

UNSIGNED

Issued before a signing key was configured. Integrity can still be checked against the hashes below.

SIGNATURE NOT CHECKED

This record exists, and we could not check its signature here — no verification key is configured for the key version it was issued under. That is a problem on our side and says nothing about your document. The hashes below can still be compared; contact us if you need the signature confirmed.

SIGNATURE INVALID

The signature does not verify against this record — it has been modified since issuance, or it was never issued by Solvex. Do not rely on this document.

NOT FOUND

No record matches this identifier.

INVALID FORMAT

That is neither a Solvex report identifier nor a verification reference. Check for a transcription slip and try again.

VERIFICATION UNAVAILABLE

The verification service could not be reached. This says nothing about the document — try again shortly.

Verification reveals authenticity only: no title, subject, finding, evidence, successor identifier or revocation reason. Having a reference is not authorization to read what it points at.

Team identity verification

Anyone contacted by somebody claiming to work with Solvex can check that exact public identity against our registry — in public, without an account.

• It answers one question

  Whether that exact public identity is currently registered and approved in the Solvex team identity registry by an authorized Solvex administrator. Not whether the account is trustworthy, and not the platform's own verification.

• Nothing is fetched

  No request is made to Telegram, X, GitHub, LinkedIn or any website. A check that dereferenced a URL somebody typed would be a server-side request forgery primitive, it would break whenever a third party changed a layout, and a page existing does not make it authentic.

• A specialist cannot verify themselves

  Only an administrator can register or approve a public identity, and every decision is written to the audit log with the administrator who made it. Owning an account is not evidence about the account.

• Not found is not an accusation

  It means the handle is not in our registry, which is a statement about the registry. And if the registry cannot be read, the page says so rather than answering "not verified".

Solvex specialists never ask for passwords, recovery phrases, one-time codes, or payments to a personal account. Scope and invoices are agreed in writing through the official channels on this site.

Signing and authenticity

Every issued report carries an Ed25519 signature over both its content and its delivered file.

• Two fingerprints, one signature

  The content manifest and the rendered PDF are each hashed; the signature binds both to the report's identifier. Neither can be swapped independently, and a single changed byte in the file fails verification.

• The key never leaves the server

  Signing happens in the issuance process. The private key appears in no database column, no projection, no response, and is returned by no function. What is stored is the signature, the two hashes and the key version.

• Identifiers you can read aloud

  Report identifiers and verification references use Crockford base32 — no I, L, O or U — so a reference read down a phone resolves even with the usual slips.

• Editions are distinguished

  A superseded report stays verifiable and says a newer edition exists. A revoked report stays verifiable and says not to rely on it. Neither is dressed as a forgery.

Evidence and provenance

A finding is only as good as what backs it. Evidence is measured, encrypted, anchored by digest, and frozen when the report is issued.

• Anchored by digest

  Each file's size, detected type and SHA-256 are measured on the server before encryption. The digest is what findings reference and what the signed report contains.

• Encrypted at rest, brokered on read

  Bytes live in a private bucket with no public access policy, under an AES-256-GCM envelope. Reads go through an authorized same-origin route that re-checks authorization every time; there are no signed URLs to leak.

• Frozen in the issuance transaction

  Issuing a report writes a manifest of every evidence row it was built from and freezes those rows, in the same transaction as the signature. If any step fails, none of it happened.

• Invisible to the public

  Public verification returns no evidence column at all — no filename, digest, size or path — so no wording change could leak them. The limit is enforced below the words.

Engagement authorization

Security testing runs only under written scope and signed authorization, against systems you own or are contractually entitled to have tested.

• Signed before anything is touched

  Every testing service in the catalogue carries the requirement, shows it on its page, and links the policy. Advisory work runs to a written scope agreed in advance.

• Boundaries published, not implied

  Every service page lists what the engagement will not do. The exclusions are part of the offer, not a footnote.

• Findings proven by hand

  Scanner output is a lead, never a finding. What reaches a report was demonstrated to be real and exploitable by a specialist.

• Retest included

  Fixing and retesting is part of the engagement. “Fixed” means we confirmed it.

Privacy and data handling

Collect the minimum, keep it for a stated reason, and never fake what happened to it.

• Free tools store hashes, not inputs

  A tool run records a SHA-256 of the normalised input and a coarse result summary — never the input itself. An email address is stored only where a tool offers a report and you choose to give one.

• Enquiries are confirmed only when saved

  The contact form reports success only after the row exists. If it could not be saved, you are told so and given an address that works without us.

• Cookies: strictly necessary only

  No ads, no cross-site tracking, no analytics cookies today. Your consent choice is recorded, and for signed-in accounts a server-side consent record is kept as evidence.

• Client engagement data is confidential

  Deliverables are encrypted per file under a server-only master key; access is brokered, logged and expiring. See the privacy policy for retention and your rights.

The platform's own posture

The standard we hold clients to is the one the platform is built to. Methodology aligned with OWASP and NIST; no certification claimed.

• Row-level security is the boundary

  Every table carries row-level security with explicit policies, and client-writable tables lock which columns may be written. Application checks are defence in depth, never the last line.

• The browser is untrusted

  Prices, roles, commissions and amounts are computed or re-read on the server. A client value never moves money or grants access; no browser input becomes a role.

• A strict content-security policy

  Default-src self; one third-party frame origin (the brand film); no remote fonts, images or scripts. HSTS with preload, nosniff, frame-ancestors none, a referrer policy and a permissions policy on every response.

• Fail closed, log the rest

  An unconfigured provider returns an error and degrades visibly; it never fakes success. Authentication, settlement, referral and admin actions land in an append-only audit log.

• Outbound requests refuse private space

  Tools that fetch public data go through a fetcher that resolves DNS, rejects loopback, private, link-local and metadata addresses, and revalidates every redirect hop.

• Rate limits in the application

  Public tools and the assistant are rate-limited in the application, keyed on the client address the edge in front of it reports. Burst limits on sign-in are a deployment control, not code in this repository, and this page does not claim them.

Wording rule from the platform's own baseline: we say “methodology aligned with OWASP/NIST”. We never claim certification we do not hold.

Responsible disclosure

Found something in the Solvex platform itself? There is a route for that, and it is machine-readable.

The platform publishes an RFC 9116 security.txt at /.well-known/security.txt naming the contact address, the policy and its expiry. Report suspected vulnerabilities in Solvex's own platform to the address it names; do not test against other users' data or accounts, and do not run denial-of-service or destructive tests. Coordinated disclosure is supported and reports are acknowledged.

What we do not claim

A trust page is only worth reading if it also says what is not on it.

• No certifications. Solvex Space holds no ISO 27001, SOC 2, CREST or similar certification and does not imply one. Readiness work for those frameworks is a service we deliver to clients.
• No customer names. Case studies are representative engagements: clients are confidential, figures illustrate typical outcomes, and every quoted comment is labelled as composed where it appears.
• No invented numbers. Every count on the site is derived from the catalogue or the registry at build time. The live rail shows real completed tool runs or says it is showing platform facts.
• No AI where there is none. The site assistant is retrieval over Solvex's own pages with no external model. Related-content suggestions are deterministic product data.