These are the questions that actually get asked in a technical evaluation, a security review and a procurement process — including the ones with uncomfortable answers. Where something is not established, it says so and says why.
Showing all 55 questions
What it is
The architecture, the property it produces, and what it is not.
What is ORMAS?
A neural network training architecture that produces a causal account of its own behaviour as a physical consequence of how it learns.
Every node in an ORMAS network carries a bounded local gradient chain — four operations through a shared 4,715-parameter bottleneck. Because that chain is bounded, the contribution of each node to the loss is not estimated after training, it is read directly off the backward pass. Attribution stops being an interpretation of the model and becomes a measurement taken from it.
The practical consequence is that a model trained under ORMAS arrives with a record of what it did, which component was responsible, and what changed — produced during training, not reconstructed afterwards.
The architecture in full →Is this interpretability? How is it different from SHAP, LIME or attention maps?
Those methods build a second, simpler model of a first model and report what the approximation says. They are estimates of a system from outside it, they disagree with each other on the same input, and their output is not stable enough to put in front of a regulator who is entitled to ask how the number was produced.
ORMAS does not approximate. The attribution is a quantity the network computes about itself while training, bounded by construction. There is no surrogate, no sampling, and no post-hoc reconstruction that could be run a second time and return a different answer.
The distinction matters commercially rather than philosophically: an approximation is an opinion about a model, and an opinion cannot be entered as evidence.
How is this different from Weights & Biases, MLflow, Arize or our own observability stack?
Those tools record what a training run reported about itself. They are excellent at it, and ORMAS does not replace them.
What they cannot do is answer a causal question, because the information required to answer it was never produced. A loss curve tells you the run degraded at step 40,000. It cannot tell you which component caused the degradation, because a standard architecture does not compute that quantity at any point.
ORMAS produces the quantity. An observability platform is then the natural place to put it.
Is it a model, a library, a wrapper, or a training method?
A training architecture, delivered as software you run in your own environment. You bring the task, the data and the compute; ORMAS determines how the network is structured and how the backward pass is instrumented.
It is not a pre-trained model, and it is not a monitoring layer bolted onto one. The property it delivers cannot be added to a network after training, which is the entire reason it has to sit at the architecture level.
You list seven applications. Are those seven products?
No. There is one product and one licence. The seven are what the same mechanism is called by the people who buy it — a bank, a hospital and a training lab describe the identical capability using three different nouns, because each is solving the problem in front of them.
They are ordered on the product page by how hard it is to say yes to them, from sending us a file to agreeing a bound with your regulator. That order is the recommendation.
The seven applications →What are the three signals?
Global backpropagation, a per-node local loss, and health-gated self-correction. Standard training has the first. The second is what makes each node individually accountable rather than accountable only as part of an aggregate. The third lets the network act on what the second tells it, under a gate that decides whether intervention is warranted.
The five telemetry layers are what those signals emit, from system-level health down to per-parameter attribution.
The signals and telemetry layers →Does the account depend on a second model or a judge?
No. Nothing in the record is generated by another network, scored by a critic, or produced by any component that could itself be wrong in an unbounded way. The record is arithmetic performed during the backward pass.
This is the property that survives the question an auditor eventually asks, which is what validates the validator.
What does "bounded" actually mean here?
That the local gradient chain for any node is four operations long — LayerNorm, Linear, PReLU, Linear — and cannot grow with the depth or width of the surrounding network.
An unbounded chain is why attribution in a standard deep network is intractable: the causal path from a parameter to the loss runs through the entire remaining architecture. Fixing the length of that path is what converts attribution from an estimation problem into a measurement.
Evidence & limits
The results, the benchmarks they were measured on, and where it loses.
What is the evidence that this works?
383 controlled experiments across four architecture families, 67 archived runs reproducible from seed, and 16,316 lines of instrumentation across 85 files. A manuscript is under peer review, and the architecture and every experiment behind it are published.
The headline result is recovery: +70.3 percentage points from catastrophic structural collapse, in conditions where a parameter-matched baseline is permanently dead rather than merely degraded.
Every run regenerates from seed. The claim is not that you should believe the numbers; it is that you can produce them yourself.
The results in full →What benchmarks were these measured on?
CIFAR-10 and CIFAR-100. That is the honest scope of the published evidence and it is stated on every page where a result appears.
No clinical, biological, financial or defence data has ever touched this system. The mechanism is domain-independent by construction — it operates on the backward pass, not on the semantics of the input — but a mechanism being domain-independent is an argument, and an argument is not a result.
Closing that gap is what the dataset partnership on the careers page exists to do, and it is the single largest thing standing between the result and the fields it was built for.
Has this been peer reviewed?
A manuscript is under peer review. Until that concludes the architecture is not public, and the release is committed to acceptance rather than to a date we control.
What is available now, to an investor or an evaluating institution under a short agreement, is the full experimental archive: 383 runs, each regenerating from seed, including the ones that failed. Peer review is a meaningful signal and it is not yet held. Seeded reproducibility is the stronger one, and it does not wait for a reviewer.
Where does ORMAS lose?
Under adversarial weight injection, it performs 1.0 percentage point worse than a parameter-matched baseline. That is the one adverse result in the programme and it is published on the technology page and named in every market where it bears on the decision.
It is a real deficit and it is small. It sits alongside a +70.3 pp recovery advantage under structural collapse, and any evaluator weighing the two should weigh them against the failure mode their own systems actually encounter.
What has not been established?
Behaviour at frontier scale, behaviour on any regulated dataset, and behaviour in production over time. There is no deployment, no pilot and no customer, so none of the three has been observed.
The technology page carries a section listing exactly this, written before anyone asked for it.
What is not established →Does it scale to large models?
The bottleneck is 4,715 parameters and is shared, so the instrumentation cost does not grow with model size the way the model does. The architecture has no scale-dependent term in it.
That is the structural argument, and it is a good one. It is not the same as having run it at frontier scale, which has not been done and is listed among the things a first partner would establish.
What would prove this wrong?
Under 30 GPU-hours on a single card. The remaining research programme is designed so that its central claims can be falsified cheaply and quickly, and the experiment that would do it is specified rather than described.
A programme that cannot be killed inexpensively is not a research programme. Any serious technical evaluator should ask for that specification, and it is provided on request.
You mention an adversarial test suite that the earlier version failed. What was it?
42 runs across two backbone types, with an explicit pass/fail list written in advance. The earlier architecture failed four of them outright: it lost to a plain CNN at every noise level tested, recovered worse under weight-perturbation shock, never triggered its correction mechanism across the full set, and produced ablation arms indistinguishable from the full system.
The logs were kept rather than deleted. The trainer was rewritten, the architecture reconstructed, and the suite that broke the first version became the standard the second had to clear.
The evidence base is adversarial rather than confirmatory, which is the answer to anyone asking whether the results were selected after the fact.
Running it
Where it executes, what it costs to run, and what integration involves.
Where does it run?
Inside your environment, on your hardware, against your data. On-premise, in your own cloud tenancy, or in an air-gapped enclave.
There is no hosted service, no inference endpoint and no control plane operated by us. The software has no outbound route, which is an architectural property rather than a policy commitment — a policy can be broken and a system with no network path cannot be.
The full data position →Does it need to contact you to run? Licence checks, telemetry, updates?
No. Not for licence validation, not for telemetry, not for updates. It runs with no connection outward from your network.
This is the first question every security reviewer in a regulated environment asks, and the answer determines whether the rest of the review happens at all.
What frameworks and hardware does it need?
It is a PyTorch architecture and runs on standard NVIDIA accelerators. It requires no specialised silicon, no custom kernels and no changes to your scheduler or orchestration layer.
Integration is a change to how the network is defined and trained, not a change to your platform.
Can we apply this to models we have already trained?
Not retroactively, and this is the honest constraint at the centre of the product. The account is generated during training. A model already trained under a standard architecture never produced the quantity, and nothing can recover it afterwards — that is precisely the problem ORMAS exists to solve, so it would be incoherent to claim otherwise.
What applies to an existing model is assessment: a trained checkpoint can be examined and reported on. Forward from that, models trained under ORMAS carry the record natively.
What does the instrumentation cost in compute?
The bottleneck is 4,715 shared parameters and the local chain is fixed at four operations, so the overhead is a bounded constant rather than a proportion of your model.
Set against it is the cost of the failure it prevents. A frontier run that dies at 60 percent and is restarted blind burns thousands of GPU-hours to reach the same checkpoint twice. The telemetry is not a tax on training; it is what stops you paying for the same training more than once.
Does it modify weights? Can we stop it doing that?
Read-only is the default posture, not a reduced tier. In that mode the network produces the full five layers of telemetry and changes nothing about itself.
Self-correction is enabled deliberately, by you, when you have seen enough of the telemetry to want it. Nobody sensible allows an unproven system to modify weights inside a run that costs six figures, and the product does not ask them to.
What does integration actually involve on our side?
Defining your network under the ORMAS architecture and routing the telemetry it emits into wherever you already keep run records. The second part is usually the shorter one.
The people who need to be in the room are the team that owns model training and whoever owns your evidence retention. It is not a platform migration.
Data, IP & security
What we receive, who owns what, and what happens to your records.
What data do you receive?
Under a deployment licence, none. Not the training data, not the weights, not the telemetry, not the records. The software runs with no outbound route, so there is no transfer to govern.
This changes the legal analysis rather than merely softening it: where we do not receive, store, transmit or access personal data, no processing occurs on our behalf and no Article 28 relationship arises in respect of it.
The exception is an evaluation you send us deliberately, which is a different mode with its own terms and a data processing agreement executed before anything moves.
The three modes, separated in law →Do you train on our data or use it to improve your product?
No, and under a deployment licence the question does not arise, because we never hold it. There is no telemetry channel, no opt-out to configure, and no setting to get wrong.
Where an evaluation places data with us temporarily, its use is limited to that evaluation in writing, and it is returned or destroyed on completion.
Who owns the models we train and the records they produce?
You do. Your weights, your training data, your telemetry and your compliance records are yours without qualification. We claim no interest in the outputs of a licensed deployment and no right to inspect them.
The licence covers the architecture you are running. It does not reach what you build with it.
If our licence ends, can we still read the records we already produced?
Yes, permanently. Records are written in a documented, open format that does not require our software to interpret, and they live in your storage rather than ours.
A compliance record that becomes unreadable when a commercial relationship ends is not a compliance record. Retention obligations outlive vendor contracts routinely — the EU AI Act alone requires logs to be kept for at least six months, and sector rules run to years — so artefact survival is written into the licence rather than left to goodwill.
Artefact survival in the licence →Is source code escrow available?
Yes, and alongside it the licence carries a release commitment: the mechanism is published in full on acceptance of the manuscript, irrevocably. That is a stronger position than escrow, because the architecture cannot become unavailable to you once released, and escrow covers the implementation until then.
Escrow covers the production implementation and the assurance work around it, and is agreed in the contract.
What is your security posture as a supplier?
Under a deployment licence we are a software supplier rather than a service provider. There is no outbound connectivity to review, no data residency question, no standing credentials to any customer environment and no subprocessor touching your data, because none of it moves.
That is a materially smaller third-party risk surface than a hosted vendor presents, and most of a standard questionnaire resolves to "not applicable" for a structural reason rather than an asserted one.
You are going to publish the mechanism. What stops a competitor building it?
Nothing will stop them reproducing it once it is out, and that is intentional — a result nobody can check is worth nothing in the fields this sells into.
What a reimplementation does not come with is the calibration behind the bound, the adversarial suite the architecture was hardened against, the archived experimental record, or a counterparty who will stand behind a number in your filing. Institutions under obligation are not buying source code. They are buying somebody who is accountable for it.
Compliance
The frameworks an evaluator will hold this against, answered individually.
Does this make us compliant?
No, and any vendor claiming otherwise is selling you a problem. Compliance is a determination made by you and accepted by your regulator, about your system, your use case and your controls.
What ORMAS produces is the evidence such a determination requires and which most organisations currently cannot generate: a causal record of what the model did, which component was responsible, and what changed. The evidence has been the missing input, not the paperwork around it.
How does this bear on the EU AI Act?
Article 12 requires high-risk systems to technically allow automatic recording of events across their lifetime, sufficient to identify risk and substantial modification, support post-market monitoring, and monitor operation. Article 19 requires providers to retain those logs for at least six months, and longer where the intended purpose demands it.
The obligation is on the system to be capable of producing such a record. Standard architectures satisfy it with operational logs that capture what happened without capturing what caused it — which meets the letter for many systems and leaves the provider unable to answer the substantial-modification question when it is actually asked.
ORMAS produces a per-component causal record natively, which is a materially stronger position under the same article. Under the Omnibus timetable, Annex III obligations apply from 2 December 2027 and Annex I from 2 August 2028.
Does it help with ISO/IEC 42001?
Directly, in three of its clauses. 42001 asks for documented operational information (7.5), controlled development with version records for traceability and reproducibility (8.3), and monitoring and measurement that supports audit and incident analysis (9.1). Model and dataset lineage sit underneath all three.
Those clauses describe evidence an organisation must be able to produce. ORMAS produces it as a by-product of training rather than as a documentation exercise performed alongside it.
Oxiedo does not hold 42001 certification, and a certification held by us would not transfer to you in any case. The relevance is to your management system, not ours.
How does this map to the NIST AI Risk Management Framework?
Most usefully to MEASURE, which is the function organisations struggle to evidence because it requires quantities they do not compute. MAP and GOVERN are largely organisational; MEASURE asks what the system actually did and how you know.
Per-component attribution and the five telemetry layers are measurement functions in the framework sense. They also feed MANAGE, in that a named failing component is actionable where an aggregate degradation signal is not.
Under GDPR, are you a controller or a processor?
Under a deployment licence, neither, in respect of your data. You remain the controller. A processor is a party that processes personal data on behalf of a controller, and where we do not receive, store, transmit or access it, no such processing occurs.
For an evaluation you send us, we are your processor and a DPA is executed before any transfer. For this website, we are the controller of what you submit through it.
Oxiedo is not yet separately incorporated; a Delaware C-corporation is being formed. Until it completes, the controller for anything submitted through this site is the UK-registered company through which we currently contract, and UK GDPR and the Data Protection Act 2018 apply to it as home law. EU GDPR applies under Article 3(2) for data subjects in the Union. That entity is named in full in any agreement and before any data is transferred to us.
Positions under GDPR and HIPAA →Do we need a business associate agreement?
Under a deployment licence, no. A business associate is an entity that creates, receives, maintains or transmits protected health information on behalf of a covered entity. In that mode we do none of those four things, and the four verbs are the whole test.
Where an evaluation involves PHI, we execute a BAA before any transfer.
How does this relate to an FDA predetermined change control plan?
A PCCP requires a manufacturer to specify in advance what modifications a device may undergo, the methods used to implement them, and the evidence that each stays inside the authorised envelope. The hard part in practice is the third.
A model that modifies itself and records each change against a declared bound produces exactly the artefact that requirement describes. Of the 1,451 FDA-cleared AI-enabled devices at the end of 2025, roughly 8 percent carry a PCCP — the constraint has been the ability to evidence adherence, not willingness to file.
Oxiedo makes no regulatory submission on your behalf and holds no clearance. The submission and its contents remain yours.
The medical AI position →How does this sit with model risk management supervision?
SR 26-2, effective 17 April 2026, supersedes SR 11-7 as the interagency model risk guidance. The requirement an institution has always struggled with is effective challenge: independent validation with sufficient information to actually challenge a model rather than review documentation about it.
A validator who can see per-component attribution and a change record is performing effective challenge. A validator handed a loss curve and a model card is performing a document review, and examiners have been increasingly explicit about the difference.
The finance position →Do you hold SOC 2 or ISO 27001?
Neither, and both are planned once first engagements fund the audit. Claiming otherwise would be the fastest way to fail a diligence process that verifies certificates directly.
What is worth weighing is what those attestations cover. Both assess controls over data a vendor holds. Under a deployment licence we hold none of yours, which is why most of a security questionnaire resolves structurally rather than by attestation.
What is held and what is not →Will a regulator accept these records?
No regulator pre-certifies an evidence format, and any vendor promising acceptance is describing something that does not exist.
What can be said precisely: the records are per-component, causally grounded, immutable once written, and readable without our software. Those are the properties that make evidence admissible in a supervisory process. The determination remains your regulator’s, and the records are built to survive it rather than to anticipate it.
Licence & commercial
The licence, what is free, what is not, and how terms are agreed.
What licence is this under?
A research licence. Free for research, teaching and evaluation, including commercial evaluation, from the moment the release lands. Production use is licensed separately.
It is not an open source licence and is not described as one. Open source has a specific meaning and this does not meet it — the restriction on production use is the entire point.
The licence in full →What exactly can we do for free?
Read the architecture, reproduce every experiment, teach from it, publish on it, and evaluate it against your own workload — including inside a commercial organisation deciding whether to buy. Evaluation access is available now under a short agreement; everything else follows the release.
What the free licence does not carry is production deployment, the calibrated bound, the assurance work, or a counterparty. An open licence has no counterparty: you cannot put it in a filing, you cannot ask it to stand behind a declaration, and there is nobody to hold to it.
We are a university lab. Is there anything to sign?
Nothing, once the release is out — no registration, no seat count, no notification to us. Publish what you find, including results that contradict ours. Before then, ask and we will give you evaluation access.
A mechanism researchers must ask permission to examine is not published in any meaningful sense, which is why the release carries no gate at all.
What does a deployment licence cost?
There is no price list. The figure is agreed per institution against scale of deployment and the assurance work involved, and written into the contract.
This is not evasion. A published number would be wrong for nearly every reader of it, and the variable that matters — what a failure in your environment costs you — is one you can calculate before the first conversation and we cannot calculate at all.
What does pre-booking mean?
Agreeing deployment terms now, ahead of general availability, and shaping the integration around your environment while that is still possible.
Early partners influence what the production system prioritises, because the requirements are still open. There is no artificial limit on how many are accepted and no countdown attached to it.
Start a conversation →Can we evaluate before committing?
Yes, and it is the expected path. Evaluation access is available now under a short agreement, and free and unrestricted once the research release is out. Either way it runs entirely in your environment against your workload, with nothing reaching us.
Where you would rather we assessed a checkpoint directly, that is a scoped evaluation with a DPA executed first.
What support comes with a licence?
Direct engineering access to the people who built the architecture. There is no support tier structure and no account management layer between you and the work.
We hold no standing credentials to any customer environment. Where a support question requires us to see something, you decide what to share and share it deliberately, and that transfer carries evaluation terms.
The company
Who is behind it, how it is funded, and what happens if it fails.
Who is behind this?
Oxiedo is a research company in formation, founder-owned, incorporating as a Delaware C-corporation alongside a move to San Francisco. Until that completes it contracts through an existing UK-registered company, named in full in any agreement. The founder is a technical founder who has built and exited companies before this one.
The team is one person, and the second is the most consequential thing missing. That is stated on the about page rather than left for diligence to discover.
The company and the founder →One person built all of this?
Yes — 16,316 lines across 85 files, 383 controlled experiments and 67 archived runs reproducible from seed.
The right way to weigh that is not to take it on trust. Every run regenerates from seed, and the mechanism is released in full on acceptance — so the work becomes checkable in a way that a larger team behind a permanently closed implementation never is.
Are you raising?
We are open to early investment conversations ahead of a priced round, alongside commercial licensing and pre-booking.
The investor case rests on one architectural result, published and reproducible, in markets where the obligation to produce evidence is arriving on a legislated timetable rather than a speculative one.
The investment position →Why should we engage a company with no paying customers?
Because the alternative on offer is a mature vendor selling an approximation, and an approximation does not become admissible by being sold at scale. The question is not who has more customers; it is which one produces evidence that survives a regulator.
What is normally opaque at this stage is not opaque here. The release commitment is written into the licence, every experiment regenerates from seed, the one adverse result is disclosed on this site, and the falsification test costs under 30 GPU-hours. Most established vendors will not give you any of that.
Zero customer conversations have taken place, and it is on the about page in those words.
What happens to us if Oxiedo fails?
You keep everything that matters. Once the architecture is released it cannot be withdrawn — the licence makes that irrevocable — and escrow covers the implementation before then. Your models, weights and records are in your environment and were never in ours. The records are written in a documented open format that needs no software of ours to read, and remain readable indefinitely.
Escrow covers the production implementation. This is the concentration-risk question every procurement function is right to ask, and the answer is structural rather than reassuring: there is no switch we could throw that would take anything away from you.
How much of what you sell depends on work not yet done?
The published architecture and its results are complete and reproducible today. The programme extending it is described by its objectives and constraints on the technology page; its mechanism is not published, and will not be until it is protected.
Anything sold against work not yet complete is identified as such in the contract, with the milestone written in. Nothing here is priced on a promise that is not also a commitment.
Where does the name come from?
ORMAS is the architecture. Oxiedo is the company that publishes and licenses it. The distinction matters in a contract, which is the only place it matters.
How do we start a conversation?
Through the contact page. Every message is read by a person and answered within a few days, and the first reply comes from the person who built the architecture rather than from a qualification process.
Useful things to bring: what you train, what obligation you carry, and what a failure currently costs you to diagnose.
Contact →Nothing matches that.
If the question is not here, it is one worth answering. Ask it directly and the reply comes from the person who built the architecture.
Ask it directlyThe fastest way through this is a conversation.
Bring what you train, what obligation you carry, and what a failure currently costs you to diagnose. Those three answers decide whether this is relevant to you faster than any page can.