Where claims meet their evidence
Verifable places implementation claims beside the route, file or test that supports them, and keeps release-candidate capabilities separate from deployed product surfaces. This page organises that evidence by capability; the public register lives at Facts.
Check it yourself
- Facts The claim-by-claim register: every capability this site states, each next to the URL, file, or test that settles it.
- OpenAPI contract The whole HTTP surface as one version-controlled document, built and served by the same origin it describes.
- llms.txt An agent-readable guide to capabilities, their availability and known limits.
Facts is a curated register, not a substitute for inspection. Follow the named route, source file or test beside a claim to see what supports it and where its boundary sits.
Organised by capability
The sections below group capabilities by subject and link to their documentation. Facts records the exact scope, current status, supporting evidence, and stated limitations for the claims this site makes.
Product passports and sector requirements
The product passport, product group and built environment pages describe each group's required data, validation before signing and relevant regulations. Facts links each claim to its supporting evidence.
Lifecycle and value-chain records
What happens to a record after issuance, and where it goes when it changes hands — lifecycle and value chains name what runs today against each job, and what is still being built.
Semantic data, querying, and validation
Veritas Workbench lets visitors query a temporary example graph, inspect RDF and validate shapes. It can inspect OWL 2 source but does not run public OWL reasoning. Facts and llms.txt carry the evidence and limits.
The Veritas database engine has a broader, separately evidenced scope: in-memory and selectable durable operation, OWL reasoning, many-worlds datasets, active-active and decentralized replication, structured traces, and a CLI stdio MCP server. That release-candidate capability must not be confused with the deliberately bounded public Workbench deployment.
Identity, wallets, and trust
How a party, a product, or an agent gets an identity that resolves, and how a wallet holds and presents what it is given—wallets, the wallet, and the resolver carry the working parts; organisations is where the relationships around them sit. Veritas-backed wallet storage is implemented but opt-in; SQLite remains the default.
Access, privacy, and selective disclosure
Who reads which fields of a record, and how a holder can prove a claim without handing over everything behind it — the tiered read and the selective-disclosure credential path are on Facts, with the deny-and-request path a refused caller follows named alongside them.
Agents and authority
What a software agent can call directly, what it can only draft for a person to publish, and where its authority ends — for agents lists the surfaces by name, and llms.txt is the same statement in the form an agent reads first.
Security and software
Security headers, session handling and passkey sign-in have deployment-specific configurations. Public libraries can be inspected separately; publishing a library does not publish or audit the hosted service. See the repositories named on Company.
Portable data. Accountable AI. Secure software.
European product rules matter here where they give a person or organisation something concrete to expect from the product. Their scopes are assessed separately; naming a regulation is not a blanket compliance or certification claim.
- EU Data Act · a usable path out Paid use requires a documented path for retained records, evidence and metadata to leave in structured, commonly used and machine-readable formats. The commercial promise and its privacy boundary are stated on Pricing.
- EU AI Act · people can see and steer Agent work keeps the principal, authority, policy decision, proposed change, human checkpoint and result inspectable. The duties that apply depend on the actual system, risk classification and deployment.
- Cyber Resilience Act · security through the software lifecycle The native Wallet and software workstreams map secure design, vulnerability handling, support periods, updates and component evidence to product proof. A practical CRA field guide is planned; the plan is not compliance evidence.
International standards and interoperability
Open standards keep identities, credentials, product records and evidence portable between systems. Their exact specifications, implementation status and limitations are listed on llms.txt and checked row by row on Facts. Lumoin's participation in European DPP standardisation is described with its exact boundary on Company.