HyperAxis

A Plain-English Guide for Auditors, Consultants, and Compliance Teams

What Hyperaxis is, the problems it solves, where it fits inside an organisation or a consultancy, and how a non-technical reader can pick it up.

v1 draft · 19 May 2026 · An Aperintel product

What this document is

This guide explains what Hyperaxis is, why it is the only AI governance tool a regulated organisation will need for the foreseeable future, the situations where it earns its keep, and the way it gets installed inside an organisation or used by an individual. It is written so a compliance officer with no technical background can read it end to end in under thirty minutes and leave knowing whether Hyperaxis fits their situation.

The guide is structured to address concerns in the order an auditor or compliance lead encounters them. The headline section sits up front. The problem and the people affected come next. The solution follows. The deployment patterns and day-to-day experience come after that. The roadmap, the frequently asked questions, and the glossary close.


Section 1. The short version

Hyperaxis sits in the middle of every conversation between an organisation's people, its applications, and the large language models they use (ChatGPT, Claude, Gemini, Copilot, and the others). For every conversation it records a tamper-evident, signed, plain-English account of what was asked, what was answered, what safety checks ran, what energy was consumed, and what cost was incurred. That record is periodically anchored to the Bitcoin blockchain so any third party can verify, without trusting Hyperaxis or the customer, that the record existed in its current form at a specific moment in time.

The output is what regulators actually ask for: evidence that an organisation knows what its AI did, when it did it, why it did it, and whether anyone overrode it. The same record reads as readable English (in English, German, French, Spanish, Italian, and Dutch) for the compliance officer and as a cryptographic proof for the auditor.

A consultancy can use Hyperaxis to run a one-off readiness review for a client. An organisation can use it as a permanent governance gateway sitting between its people and the AI services they use. An individual professional can use a personal install to keep their own audit trail of conversations with ChatGPT or Copilot, useful when their work is subject to professional indemnity rules.

The first release of Hyperaxis ships every governance primitive a regulated buyer asks for in the same product: a cryptographic audit chain, plain English narratives in six languages, drift detection across eight categories, per-call energy and carbon disclosure, prefilled regulator packs for the EU AI Act, the FCA Consumer Duty, the NHS Data Security and Protection Toolkit, ISO 42001, SOC 2, shadow AI discovery, MCP and A2A tool governance, an inline counterfactual fairness primitive, and a structured request / review / approve / deploy workflow. There is nothing else like it in the market today.


Section 2. Why Hyperaxis is the only AI governance tool you will need (at least for the foreseeable future)

There are roughly twenty other vendors selling some form of AI governance, AI security, AI observability, or AI compliance product. Most of them solve a slice of the problem well. None of them, as of May 2026, ships the combination of features Hyperaxis ships in v1. The point of this section is to be specific about that claim.

One. Hyperaxis is the only product with Bitcoin-anchored AI audit evidence backed by an open-source verifier. One competitor (2021.AI, based in Denmark) anchors AI evidence to a different blockchain (Concordium, which requires their permissioned token). All the others (Credo AI, Holistic AI, Trustible, Modulos, Saidot, Lakera, Robust Intelligence, Protect AI, CalypsoAI, Galileo, Fiddler, Arthur, IBM watsonx.governance, Microsoft Purview, Google Model Armor) write their audit logs into databases that the customer or the vendor could in principle edit. A regulator asking "how do you know this record was not changed after the incident" gets a satisfactory answer only from Hyperaxis. Anyone with the audit identifier can independently verify integrity at the Hyperaxis public verify URL plus a Bitcoin block explorer, without trusting Aperintel.

Two. Hyperaxis is the only product where every entry is written as plain English by default. Most governance platforms generate human-readable reports as a quarterly deliverable. Hyperaxis writes a plain-English narrative on every single audit row, alongside the cryptographic detail. Switch the dashboard to Auditor mode and the timeline reads like prose. Switch to Engineer mode and the technical fields expand. Read fifty decisions in five minutes; understand them all.

Three. Hyperaxis is the only product where drift events live on the same signed audit chain as normal activity. Other observability tools store drift in a separate alerting system. Other governance tools generate drift findings in a quarterly report. Hyperaxis writes drift detections (eight specific kinds) as their own polymorphic entries on the same cryptographic chain. The regulator sees one unified timeline of both ordinary activity and detected anomalies, with the same cryptographic guarantees.

Four. Hyperaxis is the only product purpose-built to be used by consultancies as well as by end-customers. A fourth role on the dashboard ("Consultant") supports a single user being assigned across multiple client tenants, with white-labelled PDF exports under the consultant's own letterhead, billable-hour tracking, and portfolio benchmarking. A referral programme returns twenty percent of recurring revenue for twenty-four months when a consultant refers a client into Hyperaxis. No other AI governance platform ships any of these primitives.

Five. Hyperaxis is the only product whose regulator packs include UK frameworks alongside European ones. Modulos ships EU AI Act and ISO 42001 packs. Credo AI ships EU AI Act, NIST AI RMF, ISO 42001, SOC 2. Trustible covers ten-plus frameworks but is US-focused. None of them prefill an FCA Consumer Duty pack or an NHS Data Security and Protection Toolkit submission. For UK financial services and UK healthcare buyers, Hyperaxis is the only product on the market that produces evidence in the format their regulator asks for.

Six. Hyperaxis is the only product that reports per-call energy and carbon use alongside the audit chain entry. The EU AI Act will require energy disclosure for large AI systems. Other observability vendors track cost but not energy. Hyperaxis writes an estimated kilowatt-hour figure into every chain entry, derived from a maintained provider lookup table multiplied by the token counts already on the chain. The auditor or the ESG team gets the figure for free.

Seven. Hyperaxis is the only product that governs both Model Context Protocol and Agent-to-Agent calls on the same chain. MCP governance is becoming common in the market; A2A v1.0 was published earlier in 2026 and no governance platform has shipped A2A governance yet. Hyperaxis writes both as typed entries onto the same audit chain, with per-tool and per-agent permissions enforced at runtime.

Eight. Hyperaxis is the only product that combines all of the above with a structured request / review / approve / deploy workflow on the same chain. Most governance platforms have a workflow product; most audit platforms do not. Hyperaxis writes the approval workflow steps as audit entries, so the chain records not just what happened, but who decided to let it happen, and when. The auditor gets the full lineage from "team proposes a change" to "compliance officer approves" to "deployment lands" to "first user interaction" to "drift event detected three weeks later".

Future releases will continue to add to this list. The first release is deliberately comprehensive because the buyer does not have time to wait for features to land one at a time. Every governance primitive a regulated organisation needs in 2026 is in v1.


Section 3. The problem, told as four scenarios

Hyperaxis exists because four concrete problems show up over and over again in organisations that use AI for decisions that affect customers, patients, employees, or regulated activity. Each scenario below has been heard verbatim in interviews with compliance officers, regulators, and internal audit teams during 2025 and early 2026.

Scenario A. The bank that cannot prove its customer-support assistant

behaved correctly

A retail bank rolled out an AI assistant to triage incoming customer support queries and produce a recommended response for the human agent to send. Eight months later the Financial Conduct Authority asks for evidence that the assistant was operating within the bank's stated scope and did not provide financial advice to vulnerable customers. The bank's engineering team exports the application logs and discovers two problems. The logs are a flat file that a privileged engineer could have edited at any point, so the FCA will not accept them as evidence on their own. And the logs are pages of JSON that the compliance team cannot read, so even the bank cannot tell from the logs alone whether the assistant misbehaved.

The bank fails the spot check. Not because the AI did anything wrong, but because the bank cannot produce the evidence to prove it.

Scenario B. The hospital trust that finds AI agents nobody approved

A National Health Service trust is preparing for its annual Data Security and Protection Toolkit audit. The information governance team runs a discovery exercise across the network and finds twelve different AI tools in use across the trust. Three were procured and approved. Four were trialled under a research arrangement that has lapsed. Five were installed by clinicians on their personal laptops and accessed via the trust's VPN. Patient data has been pasted into some of them without the trust's knowledge.

The trust cannot remediate what it cannot see, and it has no way to enforce a policy on tools it does not know exist. Discovery is the first move, not an afterthought.

Scenario C. The consultancy that has nothing to give the client

A boutique compliance consultancy is engaged by an insurance company to do a pre-audit AI readiness review under the new European Union AI Act. The consultants conduct interviews, review policies, and produce a report. The report identifies gaps but cannot evidence them, because the consultancy has no way to observe the insurer's actual AI usage. The insurer's response is "prove it", and the consultants cannot. The engagement loses its commercial weight and the consultancy is paid for the report but not invited back for the implementation work that would have been the real revenue.

Scenario D. The law firm that does not realise its associates are pasting

privileged material into ChatGPT

A mid-market law firm runs Microsoft 365 for all staff. Associates have discovered that ChatGPT is faster for first-pass document review than the firm's existing tooling. They access ChatGPT through their browsers on firm-issued laptops, on the firm's VPN, with their personal accounts. They paste excerpts from privileged client communications to get summaries. The firm's IT team has no visibility into this; the firm's compliance lead has no logs of it; the firm's professional indemnity insurer has no idea it is happening. When a client later raises a question about confidentiality breach during an internal review, the firm has no way to prove what was shared with whom and when, and the insurer treats the gap as material.

The firm does not need a new AI tool. It needs a record of how its people are already using AI tools that exist outside its perimeter.


Section 4. Where auditors and consultants come in

The two professional roles most closely involved with Hyperaxis are the internal or external auditor, and the consultant brought in to advise an organisation on AI risk. These are different jobs with different needs, and Hyperaxis is designed for both.

The auditor

An auditor is the person responsible for confirming that an organisation has followed the rules it claims to follow. The auditor may be internal (working for the organisation's audit or compliance team), or external (a Big Four audit firm, a regulator, a boutique GRC firm, or a specialist AI auditor brought in for a single review). The auditor's job is to produce a defensible opinion: either the organisation is compliant, or it is not, with specific evidence supporting the opinion.

What the auditor needs from a tool like Hyperaxis:

The auditor never needs to understand the cryptography. They need to know the cryptography is verifiable by a third party, and that the vendor has published the verifier as open source so the cryptography is not opaque. That is what Nexuscone (the open-source primitive underneath Hyperaxis, github.com/nexuscone/nexuscone, Apache 2.0) is for.

The consultant

A consultant is the person hired to help an organisation get to a place where it can pass an audit. Consultants do not certify compliance; they advise on what needs to change before certification is sought. They are the channel that introduces Hyperaxis to many of its end-customers.

Consultants come in several flavours. The Big Four (PwC, KPMG, EY, Deloitte) all have AI risk practices; some are building first-party AI assurance tools, others use third-party tools and adapt the methodology. Boutique compliance firms (Hardingham Sloane, Hogarth Compliance, Drum Cussac) bring sector-specific expertise. Fractional Chief Information Security Officers (especially in mid-market organisations) often play the consultant role across multiple clients in parallel. Independent consultants, including former regulators and former internal auditors, make up a substantial portion of the addressable market.

What the consultant needs from a tool like Hyperaxis:

The consultant role is the largest commercial channel for Hyperaxis. Twenty consultancies each running five Hyperaxis-enabled engagements is one hundred customer accounts that Aperintel did not have to sell directly.

The auditor and the consultant working together

In a typical engagement, the consultant runs a two to four week observation window inside the client. At the end of that window, the consultant produces a report backed by signed audit chains. The client passes that report to the auditor (internal or external). The auditor verifies the chain integrity independently using the open-source Nexuscone verifier (or the public verify URL), checks the prefilled regulator pack against the framework requirements, and signs off. The whole chain of work, from consultant observation to auditor sign-off, is itself recorded on the audit chain as a sequence of typed entries.


Section 5. Why existing tools do not solve this

Several categories of tool already exist in the AI governance space, and each solves a useful slice of the problem. None of them, however, gives the compliance officer the seven things a regulator asks for first: tamper-evident evidence, an explanation a non-technical reader can understand, a complete view of every AI tool actually in use, a drift record on the same timeline, framework-aligned export, multilingual readability, and energy disclosure.

Observability platforms (Datadog, New Relic, traditional logging tools) record what happened but write it into append-only files that a privileged administrator could edit without a trace. The records are also engineering artefacts, not compliance artefacts; the compliance officer cannot read them.

Guardrail vendors (Lakera, Robust Intelligence, Pillar Security, Prompt Security, NVIDIA NeMo Guardrails, Guardrails AI, others) sit on the wire and block dangerous prompts or outputs. They are valuable for prevention but do not produce the audit-quality evidence record needed for an external regulator. Their decisions live in their own logs, separate from the organisation's own audit trail.

Governance and risk platforms (Credo AI, Holistic AI, Trustible, Modulos, Saidot, Fairly AI, IBM watsonx.governance) help organisations build AI policies, classify their AI use, and document their risk posture. They are excellent for policy work and committee preparation but do not sit on the wire of every AI call, so they cannot produce real-time evidence of what the AI actually did at any given moment.

Discovery tools for shadow AI (Holistic AI's discovery module, WitnessAI's Observe module, Microsoft Agent 365, Portal26, Knostic) find the agents but do not connect their findings into a unified audit trail.

AI gateways (Portkey, now Palo Alto Networks; Kong AI Gateway; Helicone, now part of Mintlify) sit on the wire but optimise for routing, caching, and cost rather than for compliance evidence.

Blockchain-anchored governance is exactly one product: 2021.AI, on the Concordium chain (paid, permissioned token). No other vendor has shipped this.

Hyperaxis is the first platform that connects all of these jobs into a single signed audit chain. It is a guardrail vendor, an observability layer, a governance platform, a discovery tool, an AI gateway, an energy reporter, an approval workflow engine, and a public-blockchain anchoring system, all writing to the same tamper-evident timeline, all exported in the regulatory frameworks UK and EU buyers actually use.


Section 6. What Hyperaxis actually does

Hyperaxis runs as a gateway between an organisation's users or applications and the AI providers they use. Every request and every response passes through it. For each request, Hyperaxis performs seven jobs in roughly forty milliseconds and writes one signed entry into its audit chain.

One. It identifies the requester. This may be a named application, a named user, or a discovered agent that was not previously known to the organisation.

Two. It runs guardrails. These include personally identifiable information redaction (UK postcodes, NHS numbers, National Insurance numbers, sort codes, account numbers, custom organisation-specific patterns), prompt-injection detection, scope checks (is this question within what the AI is allowed to discuss for this organisation), and cost-anomaly detection. Customers can also plug in third-party guardrails (Lakera Guard, OpenAI moderation, Anthropic safety classifier, Microsoft Presidio) through a published adapter pattern; their verdicts join the same audit chain.

Three. It forwards the request to the AI provider the customer configured. Hyperaxis supports OpenAI, Anthropic Claude, Google Gemini, Microsoft Azure OpenAI, AWS Bedrock, Cohere, and self-hosted models.

Four. It receives the response, runs the output through the same guardrails again on the way back, and returns the response to the original requester. The original application sees the same response shape it would have seen without Hyperaxis.

Five. It writes a single audit entry containing the request, the response, the guardrail verdicts, the cost, the latency, the estimated energy consumption in kilowatt-hours, the cryptographic hash of the previous entry (linking this entry into the unbreakable chain), and the cryptographic signature of this entry. The entry is also assigned a plain-English narrative by an internal translator service so it reads as prose for the compliance officer. Narratives are rendered in English, German, French, Spanish, Italian, and Dutch.

Six. If the call was an MCP (Model Context Protocol) tool invocation or an A2A (Agent-to-Agent) call rather than a plain LLM completion, it applies the per-tool or per-agent permissions defined by the organisation and writes a typed audit entry that records the tool, the caller, the allowed scope, and the actual call.

Seven. Periodically (every one thousand entries or every sixty minutes, whichever comes first), Hyperaxis submits the latest chain entry's hash to the OpenTimestamps public service, which writes it into a Bitcoin block. A second, parallel submission to a commercial RFC 3161 timestamping authority provides a non-Bitcoin fallback. This is what makes the chain externally verifiable without trusting Hyperaxis or the customer.

What this gives the auditor day to day

Open the Hyperaxis dashboard, switch to Auditor mode, and the audit chain reads like prose. A typical entry looks like this:

On 20 May at 11:47 UTC, your customer-support agent processed an enquiry from a retail-banking customer. The request was routed to Claude Sonnet 4.6, your second-tier model for general support tasks. Before the prompt left this organisation's perimeter, the PII redactor removed one name and two postcodes and replaced them with deterministic placeholders. The redaction receipt is recorded as audit entry aux_v8mZk2tR_9b1b. The model responded in 412 milliseconds at a cost of £0.0023 and an estimated energy use of 0.84 watt-hours. All four pre-egress guardrails passed in under twenty milliseconds combined. The cryptographic signature on this entry was generated by signing key aks_2026q2_main, and the chain head was anchored to Bitcoin block 847,291 at 12:08 UTC and to DigiCert TSA serial 0x4f3a91 at 12:09 UTC. Any third party with the audit identifier can verify integrity at verify.hyperaxis.io/aux_v8mZk2tR_9b1a without requesting access to your systems.

That is what an auditor sees. The engineer view, one toggle away, shows the full technical detail with hash inputs, signature bytes, and exact field values, for the rare occasions when the cryptography itself is what is being questioned.

What this catches that other tools miss

Hyperaxis writes a separate audit entry, on the same chain, whenever it detects that the AI is behaving differently from how it has been configured. There are eight specific drift conditions Hyperaxis watches for:

  1. Output schema drift. A model that normally returns structured JSON suddenly returns prose. Often a sign of model degradation, a bad prompt change, or an attempted attack.
  2. Cost or latency anomaly. Response time or cost jumps far outside the rolling baseline.
  3. Provider drift. The configured model is, say, Claude Sonnet, but the response signature suggests the request is actually being answered by a different model. Catches misconfigurations and substitution attacks.
  4. Guardrail bypass. A request that should have been redacted (the PII detector confirms personally identifiable information is present) was not actually redacted before it left the perimeter. Catches silent guardrail failures.
  5. Unsigned prompt change. A deployed AI assistant's system prompt was changed without an approval signed by an authorised user in Hyperaxis. Catches the "developer pushed a change at 2am" scenario.
  6. Scope violation. An AI agent called a tool that was outside its authorised scope. Catches agents trying to delete files when they are only allowed to read them. Applies to both MCP and A2A calls.
  7. Chain integrity break. Any tampering with past audit entries is detected on the next periodic re-verification.
  8. Behaviour drift. Statistical drift in output distributions (sentiment, refusal rate, output length, vocabulary). Catches the slow creep of a model's behaviour over time.

Every detection writes its own entry to the same chain. The auditor sees one unified timeline, in plain English, of both ordinary activity and detected anomalies.

Fairness on demand

When the AI in question is making decisions that could affect a protected characteristic (hiring, lending, insurance underwriting, clinical triage), Hyperaxis offers an inline counterfactual fairness check. The user selects a sample of decisions; Hyperaxis re-runs each decision with the protected attribute flipped (gender, ethnicity, age band, postcode tier, etc.) and reports demographic parity, equalised odds, and counterfactual flip rate. Each fairness check writes its own audit entry. The auditor or the consultant can produce a fairness attestation as part of the regulator pack.

The fairness primitive uses Microsoft Fairlearn under the hood (open source, well-documented, widely accepted), so the methodology is defensible in front of any regulator.

Approval workflow on the same chain

When a change to a deployed AI system needs sign-off (a new system prompt, a new model, a new guardrail rule, a new MCP tool permission), the proposer files a request through Hyperaxis. The request becomes a chain entry. Reviewers (named users with the appropriate role) approve or reject; each action becomes a chain entry. On approval, the change is deployed and the deployment becomes a chain entry. The first user interaction post-deployment also becomes a chain entry. The full lineage, from "proposed" to "in production", lives on the same signed timeline as the request and response data.

This matters because regulators ask not just "what did your AI do" but "who decided to let it do that". Hyperaxis is the first product to put both questions on the same chain.


Section 7. How Hyperaxis is deployed inside an organisation

There are four main patterns for an organisation to adopt Hyperaxis, chosen based on how that organisation's people and applications currently access AI services. None of the four requires the organisation to rewrite its existing code or change which AI provider it uses.

Pattern A. The proxy gateway

The organisation already has applications that call AI provider APIs directly. The organisation changes one line of configuration so those API calls now go to a Hyperaxis URL instead of the provider URL. Hyperaxis receives the request, runs the governance checks, forwards the request to the real provider, processes the response, and returns it. To the application nothing has changed. To the organisation, every call now lives on the audit chain.

Setup time: typically one to four hours for the engineering team.

Pattern B. The browser proxy

The organisation's users access ChatGPT, Microsoft Copilot, Google Gemini, and similar services through their web browsers, often from the office network or via a VPN. The organisation deploys a browser extension or a network-level proxy that intercepts traffic to those AI services. Hyperaxis sees the conversation as it leaves and returns, performs the same governance checks, and writes the same audit entries.

This pattern is the only practical option when the organisation's people use the AI services directly in the browser rather than through internal applications, which describes most non-technical professional services firms (law firms, accountancies, consultancies, NHS trusts, local authorities). The most common configuration is a browser extension on managed devices combined with VPN-level enforcement.

Setup time: one day for the browser extension; one additional day for VPN-level enforcement.

Pattern C. The shadow-AI discovery overlay

The organisation does not know what AI tools its people are using. Hyperaxis ships a discovery scanner that examines the organisation's container images, code repositories, network egress logs, and (optionally) endpoint software inventory. The scanner produces an Agent Bill of Materials: a list of every AI tool found in the organisation's stack, who owns it, what it talks to, and whether it is governed or shadow.

Setup time: one week for the first discovery scan, then ongoing weekly scans automatically.

Pattern D. Real-time pause and rollback

For organisations where compliance must be enforced, not just observed, Hyperaxis can run in inline-blocking mode. A drift event of sufficient severity (a chain integrity break, a confirmed guardrail bypass, a scope violation against a critical tool) automatically pauses the relevant agent and notifies the configured channel (email, Slack, PagerDuty). The pause is itself a chain entry; the resumption is a chain entry; the post-incident review (added by an authorised user) is a chain entry.

Setup time: configuration only; no separate deployment.

Mixing patterns

Most organisations end up running multiple patterns simultaneously. The internal applications go through Pattern A. The browser-based usage goes through Pattern B. Pattern C runs continuously to surface new shadow AI. Pattern D is enabled selectively for the highest-risk agents. All four feed the same audit chain.


Section 8. How a consultancy uses Hyperaxis

A compliance consultancy, a fractional Chief Information Security Officer, a Big Four ESG team, or any other professional firm advising organisations on AI risk uses Hyperaxis differently from an end-organisation customer. The consultancy is not running the AI; the consultancy is helping someone else who is.

Phase one. Engagement scoping

The consultant invites the client to install Hyperaxis as a read-only observation gateway for an agreed window, typically two to four weeks. The client retains full control of its own data; the consultant gets the Consultant role on the Hyperaxis dashboard.

Phase two. Discovery

During the observation window, Hyperaxis writes the audit chain for every AI call the client makes. The consultant runs the shadow-AI discovery scanner to surface tools the client did not know it had.

Phase three. Findings

The consultant produces a report. Unlike most compliance reports, this one is backed by signed audit chains that the client and any future external auditor can independently verify. The consultant exports a regulator pack: a signed PDF that pre-fills the answers to the relevant compliance framework (EU AI Act, FCA Consumer Duty, NHS Data Security and Protection Toolkit, ISO 42001, SOC 2), with citations into the audit chain for each answer. The PDF carries the consultancy's letterhead, logo, and primary colour rather than Aperintel branding.

Phase four. Remediation or handover

The consultancy either implements the remediation itself or hands the report to the client's own team. The consultancy's billable hours across the engagement are exported as CSV for invoicing. Either way, the client now has Hyperaxis installed and the consultancy has a sample of a substantive deliverable to take to its next prospective client.

The consultancy workspace

Consultants with multiple clients see all their engagements in a single view. The dashboard supports white-label PDF exports under the consultancy's own letterhead, billable-hour tracking per engagement, portfolio benchmarking of the consultant's clients against each other (anonymised), and a referral programme that pays the consultant twenty percent of revenue for twenty-four months on any client they refer into Hyperaxis directly.


Section 9. How an individual professional uses Hyperaxis

A solicitor, accountant, doctor, architect, or any other professional whose work is subject to indemnity rules can install Hyperaxis on their own device. The setup is lighter than the organisational deployments above and takes about fifteen minutes.

The personal install

The individual installs the Hyperaxis browser extension on their work machine. The extension intercepts traffic to ChatGPT, Claude, Gemini, Copilot, and Perplexity. Every conversation with those services produces an audit entry stored in a local database on the user's own machine. The audit chain is signed by a key on the user's machine and anchored to Bitcoin on the same schedule as the organisational version.

Optionally, the individual can configure the extension to forward audit entries to a cloud database (hosted by Hyperaxis on EU infrastructure) so the audit trail survives a lost laptop.

What this gives the individual

Three things. First, evidence that a particular AI conversation took place at a particular time, useful if a client later disputes the advice given. Second, a personal record of which AI tools they have used for which clients, useful if their professional body audits AI usage. Third, the peace of mind of knowing that if an AI provider's behaviour changes (model update, policy change, outage), they have a record of what the AI said before the change.

Edge case. The individual without an organisation

Hyperaxis works for a freelance consultant, a journalist, an academic, or anyone who uses ChatGPT or Copilot regularly and would like a tamper-evident record of their AI interactions for their own protection.


Section 10. What the auditor sees day to day

This section walks through the typical workflow of a compliance officer or external auditor using Hyperaxis once it is installed and running.

The dashboard at a glance

The auditor opens the Hyperaxis dashboard on any device with a browser. The home view shows five numbers: the count of audited requests in the last twenty-four hours, the percentage that passed all guardrails, the median response latency, the total estimated energy consumed in kilowatt-hours, and the chain integrity status (verified, or the entry ID of the first failing row).

Below the numbers is a live table of recent audit entries. Each row shows the timestamp, the model used, the four guardrail outcomes as small chips, the entry hash, the per-call energy, and the status (signed, flagged, blocked).

Drilling into an entry

The auditor clicks a row and the audit detail view opens. The default is Auditor mode, which shows the plain-English narrative on the left and a right-hand column of cryptographic fields that are always visible but do not require attention unless something is being questioned. A toggle at the top switches to Engineer mode, which inverts the layout and gives the full technical detail. The narrative language can be switched between English, German, French, Spanish, Italian, and Dutch.

At the bottom of the narrative is a Sign off as reviewed button and an Add a note and flag for follow-up button. Sign-offs themselves write an entry to the audit chain, so the chain records not just what happened but who reviewed it.

The Anomalies panel

A separate panel lists every drift event detected by Hyperaxis, filtered by the eight event types from Section 6. Each anomaly carries a colour indicator (red, amber, or yellow) based on severity and a one-line plain-English summary. Clicking the anomaly opens the audit chain entry that recorded it, alongside the original request entry that triggered the detection. The organisation configures, per anomaly type, whether the detection should also notify by email, Slack, or PagerDuty.

The Approvals panel

A separate panel lists every change request flowing through Hyperaxis: new system prompts, new model selections, new guardrail rules, new MCP or A2A permissions. Each request shows its proposer, the requested change, the diff against current state, and the current approval status. Authorised reviewers approve or reject from within the panel. Every action writes a chain entry.

Exporting evidence

The auditor selects a time window and clicks Export regulator pack. A dialog appears with the available frameworks (EU AI Act, FCA Consumer Duty, NHS Data Security and Protection Toolkit, ISO 42001, SOC 2 Type II, or a generic format). The auditor picks one. Hyperaxis produces a signed PDF that pre-fills every answerable question in that framework with citations into the underlying audit chain entries, and presents the cryptographic chain proof at the back of the document. The PDF is signed by the organisation's chosen signing key and timestamped at the Bitcoin block height of the most recent anchor.

That PDF is the evidence pack. It goes straight to the regulator, the internal audit committee, or the external auditor's working file. For consultant users, the same export can render with the consultancy's letterhead and branding.


Section 11. What's in v1 (the hurricane release) and what's coming next

The first release of Hyperaxis is deliberately comprehensive. Compliance buyers do not have time to wait for features to land one at a time, and regulators have already started enforcing in the categories Hyperaxis covers. Rather than shipping a minimum viable product and adding features over a two-year cycle, Hyperaxis v1 ships every primitive a regulated buyer needs in 2026 inside the same product.

What ships in v1

  1. Cryptographic audit chain (SHA-256 hash chain plus Ed25519 signatures), with the audit primitive published open-source as Nexuscone on PyPI under Apache 2.0.
  2. Bitcoin anchoring via OpenTimestamps, plus a parallel RFC 3161 commercial timestamp authority for a non-Bitcoin fallback.
  3. Plain-English narratives on every audit row, with Auditor mode and Engineer mode toggles.
  4. Multilingual narrative rendering: English, German, French, Spanish, Italian, Dutch.
  5. Drift detection across eight event types, written onto the same signed chain.
  6. Per-call energy and carbon reporting in kilowatt-hours.
  7. Guardrail framework with native rules (PII redaction, prompt injection, scope, cost) and adapters for third-party guardrails (Lakera, OpenAI moderation, Anthropic safety, Microsoft Presidio, custom).
  8. Counterfactual fairness primitive (Microsoft Fairlearn) for protected-characteristic decisions.
  9. Multi-provider gateway: OpenAI, Anthropic, Google, Microsoft Azure OpenAI, AWS Bedrock, Cohere, self-hosted.
  10. Shadow AI discovery scanner across containers, repos, network egress, and endpoint inventory.
  11. Model Context Protocol (MCP) tool governance with per-tool permissions on the chain.
  12. Agent-to-Agent (A2A) protocol governance, parallel to MCP.
  13. Regulator packs prefilled for EU AI Act, FCA Consumer Duty, NHS Data Security and Protection Toolkit, ISO 42001, SOC 2 Type II.
  14. Approval workflow on the same chain: request, review, approve, deploy.
  15. Four-role RBAC: admin, reviewer, read-only, consultant.
  16. Consultancy workspace: white-label exports, billable-hour tracking, portfolio benchmarking, referral programme (20% revenue share, 24 months).
  17. Deployment patterns: proxy gateway, browser proxy, shadow-AI discovery overlay, real-time pause and rollback.
  18. Public verification endpoint at verify.hyperaxis.io for third-party audit-chain verification.

What's coming next

Future releases will continue to expand the product. The current short-term roadmap (next twelve months):

How Hyperaxis stays ahead of the market

The AI governance market is consolidating fast: Palo Alto Networks acquired Protect AI and Portkey, F5 acquired CalypsoAI, Check Point acquired Lakera, Cisco acquired Robust Intelligence, SentinelOne acquired Prompt Security, Coralogix acquired Aporia, Mintlify acquired Helicone, Apple reportedly acquired WhyLabs. The pattern is platform vendors buying point solutions and bundling them. Hyperaxis is built to stay independent of the platform vendors by keeping the cryptographic primitive open-source (Nexuscone), the verification public, and the buyer base UK and EU-anchored where vendor independence is a procurement requirement rather than a nice-to-have.

The product evolves quarterly. Each release adds capability that matches the regulatory and technical evolution of the market without losing the principle that brought the buyer to Hyperaxis in the first place: tamper-evident, plain-English evidence that can be verified by anyone without trusting the vendor.


Section 12. Frequently asked questions

Does Hyperaxis see the content of our prompts and responses?

Yes. Hyperaxis is a gateway, so by definition it sits in the path of every request. The PII redactor strips personally identifiable information before the prompt is forwarded to the AI provider, and the redacted text is what is written to the audit chain. The original unredacted text is held only in transient memory long enough to perform the redaction and is not stored. Customers can configure additional redaction rules for organisation-specific data classes.

Where is our data stored?

The audit chain database is stored in the location the customer chooses. For the hosted Hyperaxis service, this is Supabase EU (London region) by default. For customers with stricter data-residency needs, Hyperaxis can be self-hosted via Docker Compose, in which case the database sits inside the customer's own infrastructure and never leaves.

What happens if Hyperaxis itself is unavailable?

The customer configures one of two modes. In fail-open mode, if the Hyperaxis gateway is unreachable, the request falls back to a direct provider call (with no audit trail for that call). In fail-closed mode, the request returns an error and the user must retry. Regulated customers typically choose fail-closed; consumer products typically choose fail-open.

What if the Bitcoin anchoring breaks?

The audit chain stands on its own without Bitcoin. The cryptographic hash chain and the Ed25519 signatures together provide tamper-evidence even if the Bitcoin layer is unavailable. Hyperaxis also submits each anchor to a commercial RFC 3161 timestamping authority (DigiCert, Sectigo, GlobalSign) in parallel, so the chain has a second independent timestamping proof from a regulated TSA. A regulator can choose whichever proof they find most credible. The two failure modes are independent, so the probability of both failing for the same record is very low.

Does Hyperaxis change which AI provider we use?

No. The customer continues to use the same OpenAI, Anthropic, Google, Azure, AWS, or self-hosted model they were using before. Hyperaxis adds a governance layer; it does not replace the AI itself.

Does Hyperaxis store our API keys?

Optionally. The customer can either supply their provider API keys to Hyperaxis (the managed mode) so Hyperaxis forwards on their behalf, or configure their applications to pass the keys on each request (the bring-your-own-key mode) so Hyperaxis never sees the keys.

Can the auditor verify the chain independently, without trusting

Aperintel?

Yes, and that is the whole point of the open-source primitive. Anyone can install Nexuscone from PyPI (pip install nexuscone), point it at an exported chain, and run the verification themselves. The Bitcoin anchor proof file (.ots format) can be verified independently using the OpenTimestamps client, with the Bitcoin block headers as the only trust dependency. The RFC 3161 timestamp can be verified with the TSA's public certificate. No part of the verification requires access to Hyperaxis or to Aperintel servers.

What does it cost?

Pricing tiers as of the design-partner phase: free for evaluation (one hundred calls per month, thirty-day retention), Solo at £199 per month (ten thousand calls, full retention, all guardrails), Studio at £999 per month (one hundred thousand calls, plus shadow AI discovery, plus regulator packs, plus consultancy workspace features), Enterprise from £4,999 per month (custom volumes, self-hosting option, dedicated success manager). Pricing for the individual personal install will be confirmed ahead of v1.5; planned around twelve pounds per month for up to ten thousand audited calls.

Can we self-host Hyperaxis?

Yes. The Enterprise tier ships a Docker Compose configuration that runs Hyperaxis entirely inside the customer's own infrastructure. The only external dependency is the OpenTimestamps calendar servers and the RFC 3161 TSA, and even those are optional (a self-hosted RFC 3161 service can replace both anchors if needed).

Does Hyperaxis work for non-English prompts?

Yes. The PII redactor and the plain-English translator both support major European languages. Audit narratives can be rendered in English, German, French, Spanish, Italian, and Dutch by default.

How does the energy figure work?

Hyperaxis maintains a lookup table of per-token energy cost for each supported model, derived from the model card and from independent research (the DigitalApplied AI sustainability tracker, the Stanford Carbon Tracker project). Each chain entry's token counts are multiplied through the lookup to produce an estimated kilowatt-hour figure. This is the same methodology the EU AI Act conformity assessment expects for large AI systems.

What's the fairness check actually doing under the hood?

Hyperaxis uses Microsoft Fairlearn, an open-source Python library for algorithmic fairness assessment. When the customer triggers a counterfactual fairness check, Hyperaxis takes a sample of decisions, re-runs each with the protected attribute flipped, computes demographic parity, equalised odds, and counterfactual flip rate metrics, and writes the results into a chain entry. The methodology is documented and reproducible; an auditor can verify the calculation by re-running Fairlearn on the same sample independently.

Who built Hyperaxis?

Hyperaxis is built by Aperintel, an independent AI studio based in London. The audit-chain primitive at the core of Hyperaxis is published as open-source software under the name Nexuscone, available on PyPI under the Apache 2.0 licence. Any organisation can verify the cryptographic logic themselves without trusting Aperintel.


Section 13. Glossary

A2A protocol. Agent-to-Agent protocol, published by the Linux Foundation Agentic AI Foundation in early 2026, alongside MCP. Allows AI agents to coordinate with each other across organisations.

Audit chain. A sequence of records where each record references the previous record by its cryptographic hash. Changing any record breaks the chain at every subsequent record, which is how tampering is detected.

Behaviour drift. Statistical change in how an AI system responds to typical inputs over time. Detected by Hyperaxis through a rolling baseline of sentiment, refusal rate, output length, and vocabulary diversity.

Bitcoin anchoring. Submitting a hash to a public service that includes it in a Bitcoin block. After the block is mined, the hash is permanently embedded in Bitcoin's blockchain, and anyone can verify the hash existed before that block was mined.

Counterfactual fairness. A fairness assessment method that re-runs a decision with the protected attribute flipped and checks whether the outcome changes. Considered the 2026 gold standard for fairness audit in regulated decisions.

Ed25519 signature. A cryptographic signature scheme used by Hyperaxis to prove that audit entries were written by the holder of a specific private key, not by an impostor.

Fairlearn. Microsoft's open-source Python library for algorithmic fairness, used by Hyperaxis to compute counterfactual fairness metrics.

Guardrail. A policy check that runs on a request or response and either allows it, flags it for review, or blocks it. PII redaction, prompt-injection detection, and scope checks are all guardrails.

Hash. A short, fixed-length string produced by running a longer text through a one-way mathematical function. Changing one character in the original text produces a completely different hash. Hashes are how the audit chain links its records together.

MCP. Model Context Protocol, a standard introduced by Anthropic in late 2024 for connecting AI models to external tools. Hyperaxis governs MCP calls.

Model. The AI itself (Claude, GPT, Gemini, Llama, etc.). Hyperaxis sits between the user and the model.

Nexuscone. The open-source audit-chain primitive that underlies Hyperaxis. Published as a Python package on PyPI under Apache 2.0. Available at github.com/nexuscone/nexuscone.

OpenTimestamps. A free public service that submits hashes to Bitcoin on behalf of users, run by community volunteers and the Electronic Frontier Foundation.

PII. Personally identifiable information. Names, postcodes, NHS numbers, National Insurance numbers, and similar fields that identify specific individuals.

RFC 3161. A standard for digital timestamping by a trusted third party. Hyperaxis uses an RFC 3161 timestamping authority as a parallel anchor alongside OpenTimestamps, so the audit chain has two independent timestamp proofs.

Shadow AI. AI tools running inside an organisation that the organisation's leadership does not know about. Discovered by Hyperaxis's scanner.

System prompt. The hidden instructions that tell an AI assistant how to behave for a particular application. Changing the system prompt without approval is what the unsigned-prompt-change detector watches for.


Section 14. Where to next

For questions, design-partner enquiries, or to request a personalised demo, contact osi@aperintel.com. The marketing site at the chosen Hyperaxis domain carries the latest pricing, the design-partner programme details, and the public verification endpoint. The audit-chain primitive is open source at github.com/nexuscone/nexuscone and pypi.org/project/nexuscone.

This document is updated as Hyperaxis evolves from design-partner phase through to v1 launch. The most current version is always at the /docs route of the Hyperaxis marketing site.