Trust & procurement

What your security and procurement review needs to know about Kortex, stated plainly; including what we do not yet have. Kortex is a product of Orkora Limited, sold through pilot programmes. We would rather state that clearly than imply enterprise scaffolding that does not exist yet.

Security posture

Transport. TLS 1.2/1.3 only, HSTS enforced, certificates via Let's Encrypt. Requests for any hostname other than kortex.orkora.com are refused at the edge.
Authentication. API keys are stored as SHA-256 hashes; plaintext keys are never persisted. Keys are scoped (capability grants per key), support expiry, and are revocable immediately. Key rotation is available on request.
Anonymous surface; the full list. Unauthenticated access is limited to the documentation pages plus a fixed demo scope enforced at the edge: ten exact query strings and one parameterised family (corridor sensitivity between two country codes), each mapped server-side to a demo key holding insight scope only. The globe viewer's map tiles run on a separate demo key with base scope and no insight, traversal or Cypher grant. Answer receipts can be fetched anonymously because the receipt id is itself the unguessable capability, and private receipts still refuse anyone outside the owning organisation. Everything else requires a key, and each anonymous route carries its own rate limit.
Audit trail. Every API request is metered and logged per key, endpoint, cost, status, latency, giving both sides a complete usage record.
Isolation. Services (graph database, relational store, cache, API, edge proxy) run as isolated containers; the databases are not reachable from the network, only through the API.
No third-party code on public pages. All JavaScript, CSS and fonts on the public site are self-hosted. No CDNs, no analytics trackers, no cookies on public pages.
Query surface. Customer-facing Cypher access is read-only and scope-gated; write access to the graph does not exist through the API.

No opaque model decides a verdict

No generative or learned model controls a Kortex verdict. The answer path is deterministic: database reads, spatial joins and disclosed arithmetic, versioned at /methodology, where the rules that decide a verdict are published in full and served machine-readably at /v2/methodology. There is no LLM in the answer path, no machine-learned scoring and no analyst narrative. Where the evidence does not support a verdict, the screen abstains rather than estimates, and every answer carries a receipt pinned to graph and data snapshot identifiers; since methodology 1.29 that receipt also freezes the complete rulebook it was decided under, with a SHA-256 over it, so an answer can be audited against the rules in force when it was computed rather than the rules in force today.

This page used to say "there is no model to validate", and that was too strong. Kortex does contain models in the ordinary sense: the methodology describes weighted siting scores, a DC power-flow (PTDF) formulation, and modelled revenue and carbon layers. What is true, and what matters for model risk, is narrower and more defensible: those models are deterministic, their formulations and weights are published, they produce figures rather than verdicts, and none of them is a learned or opaque function. Deterministic is not model-free, and we should not have implied otherwise.

For buyers subject to model-risk frameworks (SR 11-7 and its UK/EU equivalents), the practical position is that every derivation is inspectable: sources, transformations, formulations, weights and methodology versions are all published, and every served figure states its basis. Your model-risk function can assess the classification from the public methodology record rather than taking a claim from us; we will answer their questions directly.

Where we do use a language model, and where we never do. One internal operations job uses a third-party language model to sift published public-sector procurement notices for our own bidding. It sits nowhere near the product: it reads public tender text, it writes to no customer-facing table, and nothing it produces reaches an answer or a receipt. No customer data, no query, no receipt and no candidate site is ever sent to a third-party model. If that changes we will say so here before it ships, not after.

Data protection

The graph is infrastructure and corporate-entity records. Nodes are power plants, substations, grids, dams, ports, legal entities, jurisdictions. The product holds no consumer data and no special-category data.
Limited business-context personal data exists and we say so plainly: public-register records such as company officers and persons with significant control are personal data under UK/EU GDPR even in a business context. We process them under legitimate interests, sourced from statutory public registers; the full lawful-basis statement, transparency notice and named subprocessor list are published at /data-protection.
One internal source (ICIJ Offshore Leaks) includes named company officers. Officer records are held internally for derived corporate-screening analytics and are not served through the API; entity-level candidate matches served by the diligence screen carry no officer personal data.
Every source feeding the graph is documented with licence and commercial status at /sources and /licensing; including, honestly, the ones still under rights review.
Customer account data we hold is minimal: contact details, API keys (hashed), and usage records.
Hosting and offsite backup infrastructure is located in the EU.

Your candidate data & receipts

What we store when you run a screen. A screen receipt archives your request (candidate coordinates or counterparty identifiers; site boundaries are stored as a hash and area, never the outline) together with the frozen answer, so the result stays retrievable and auditable. This is the one place your candidate data lives on our systems.
Private by default. Screen receipts computed with your key are bound to your organisation: retrieval and export require your credential, and anyone else asking for the receipt id gets the same 404 as a nonexistent one. Receipts of public-data insights carry no customer data and remain shareable links.
Sharing is an explicit act. POST /v2/receipts/{id}/share turns a receipt into a forwardable link (the deliverable is designed to be forwarded to lenders, boards, counterparties); unshare reverses it. Nothing is forwardable until you decide it is.
Retention and deletion. Receipts are retained so your audit trail survives; your organisation can delete any of its receipts at any time (DELETE /v2/receipts/{id}), and on contract end we provide a final export of your investigations and receipts before deletion on the agreed schedule.
Access on our side. The operators who run the platform can access stored receipts for support and incident response; receipts are never used to train anything, never shared with third parties, and never feed other customers' answers.

Availability, backups & support

Deployment. Single-region deployment, appropriate to pilot scale. GET /health is public and unauthenticated for monitoring, and /status publishes recorded per-minute uptime history: measured through the public edge, honest about when recording began, with failures shown red rather than smoothed.
Backups. Nightly database snapshots and dumps of the curated and audit layers, pushed encrypted (restic) to offsite storage in a separate EU facility, with 14-daily / 8-weekly / 6-monthly retention.
Support. Direct, by email (kortex@orkora.com): same-business-day response as the working target during pilots. Incidents affecting your keys or data are communicated by email.

What we do not have yet; stated plainly. No formal SLA (a measured-uptime SLA comes with the first annual contracts). No SOC 2 or ISO 27001 certification (on the roadmap as the customer base matures; the controls above are what exists today, and we will not imply otherwise). No Cyber Essentials certification yet; for UK public contracts we work to the in-place-before-award position that PPN 09/23 allows. No 24/7 on-call rota. If your procurement gate requires these today, we are happy to discuss timelines honestly.

Commercial terms

Pilots. Fixed-term pilot agreements signed per customer, covering scope, keys, usage limits, confidentiality and fees. Terms of service and data-processing terms are agreed within the pilot agreement; standard drafts are available on request.
Pass-through obligations. Some sources impose attribution or share-alike conditions (e.g. ODbL for OpenStreetMap-derived layers). These are documented per source at /licensing, and responses carry the provenance needed to comply.
Pricing. Metered, published machine-readable at /.well-known/kortex.json; every response reports its own cost. Provenance metadata on responses is never billed.

Corporate compliance & insurance

Modern slavery. Orkora Limited adopted a Modern Slavery and Human Trafficking Policy on 3 August 2026. We are below the GBP 36 million turnover threshold at which section 54 of the Modern Slavery Act 2015 compels a statement, so we hold the policy voluntarily; it claims only the controls a company of our size genuinely operates, and it is available on request.
Insurance. Public liability cover of £10m is in force. Professional indemnity, cyber and employers' liability are placed to the level each contract requires and evidenced before contract start. We will not claim cover we have not bought.
UK public procurement. Registered on the Central Digital Platform (Find a Tender); supplier identifier PPON PGYD-9115-GQJZ. Standard supplier questionnaires are answered directly by the people who operate the system.
Parent company guarantee. Orkora Limited is a young company and its solo balance sheet reads that way. Where a buyer's financial standing test needs more, an Orkora Inc. parent company guarantee is available on request rather than argued about after the fact.

Verify us

/validation; flagship outputs checked against GLEIF, published LBNL research, and SEC filings, with misses published.
/licensing; per-source commercial rights, including what is still under review.
/sources; the full source register, licence and cadence per source.
GET /health, GET /stats; live, unauthenticated.

Company & continuity

Kortex is built by Orkora, a funded floating-nuclear developer, to screen sites for its own gigawatt-scale plants; the same evidence layer is what we sell.

Orkora Limited, registered in England and Wales (company no. 16555987), is a wholly-owned subsidiary of Orkora Inc. (United States), which has raised over $10m in institutional investment. Orkora Limited has no subsidiaries of its own. The team is 10 to 20 people and growing. kortex@orkora.com. Security questions, procurement questionnaires and vulnerability reports all go to the same address; questionnaires are answered directly by the people who operate the system.

Continuity commitments. Everything you buy is exportable in open formats (CSV, GeoJSON, JSON) throughout the contract. Answer receipts are self-contained documents: they remain readable and auditable after contract end, independent of platform access. On termination we provide a final export of your investigations and receipts before deletion on the agreed schedule.