Phyloop audits physics-AI surrogates for a stated engineering use case. You provide the model evidence; we return the deployment boundary, fallback rule, and evidence gaps.
The audit starts with one stated engineering use case. It checks the declared parameter envelope, prediction metrics, calibration evidence, and OOD behavior, then returns a report and runtime fallback rule.
Define the context of use, operating envelope, allowed decisions, and excluded claims before judging the surrogate.
Check prediction metrics, calibration coverage, ID/OOD pools, uncertainty score, and case-level failures.
Return the qualification report, runtime gate, case decisions, solver backfill queue, and manifest.
Send the surrogate type, solver/source of truth, and decision it feeds. The first step is to map what evidence already exists and what must route back to the solver.
Before sharing private model data, a CAE team can open the public audit sample, read the method paper, and inspect the repository behind the qualification flow.
Method note
The technical note behind the audit: context of use, explicit envelope, score threshold, coverage evidence, OOD behavior, and solver fallback.
Open the full report when you want the detailed evidence, limitations, runtime gate, and backfill recommendations.
Yes. Start with the sample audit report, PL-WP-002 method paper, and public evidence repository. The private pilot uses the same audit shape on your surrogate evidence.
A parameter table, a prediction/metric table, and a short context file: what the surrogate predicts, what solver or test data it answers to, the intended decision, and the parameter envelope you want reviewed.
A decision-first report, runtime gate, case-by-case serve-or-solver decisions, solver backfill recommendations, and a manifest of the inputs used. The report says where the surrogate may answer and where it should not.
No. It is not certification or homologation. It is an engineering qualification audit for one stated context of use, with explicit limits and fallback rules your team can review.
The gate routes the case back to the solver. That is the point: the surrogate is allowed to answer only when the declared envelope and score policy support it.
For a prepared surrogate with usable tables, the first useful result should be a short audit cycle, not a platform rollout. The goal is to decide whether the qualification shape is valuable before deeper integration.
A qualification audit is scoped to one surrogate, one intended engineering use, and one evidence package. It produces a deployment boundary and fallback rule, not a universal approval for every future design case.
Runtime gate, parameter envelope, case decisions, solver backfill queue, evidence gaps, and reportable limitations.
Certification, regulatory sign-off, production release approval, and hidden-regime guarantees not supported by the evidence.
New geometry families, new physics regimes, extrapolated design spaces, changed solver settings, or changed training data.
For an active model, the first deliverable is a bounded audit: what the surrogate may answer, when it must fall back, and what evidence supports that decision.
Phyloop is a product company at the design-partner stage. The first product is narrow: turn surrogate evidence into an audit report, runtime gate, fallback rule, and solver follow-up queue for one stated engineering use.
If the risk is real but the engagement shape is not obvious yet, share the model decision, solver stack, and what would go wrong if the surrogate is wrong.
The first pilot is a bounded audit, not a platform rollout. It should tell your team whether the surrogate can be used inside a stated boundary, needs more solver evidence, or should not be deployed yet.
A short note is enough. The useful context is the decision, the solver or model stack, and what would go wrong if the surrogate is wrong.
Need to know when your surrogate should answer and when it should fall back?
