Reading a model verdict

What a verdict is

Before a model can be served through Heliast, a checking tool called the admission gate assesses it and records what it found and what it decided. That record is the verdict. It is evidence, not a setting: a verdict never turns a route on or off by itself, and nobody can fill in a field to admit a model.

There are three verdicts.

A verdict applies to one revision of a model. The page shows the revision and the date it was assessed.

Only an admitted model can be made available through the enforcement hook. A held or rejected model is not available anywhere.

What the gate checks

The verdict page lists six checks, each with a plain result. Behind them is a section, "The evidence behind each check", that shows the full record, including the exact words the gate used for each reason.

Licence

The gate records the licence and how it knows. The page shows the licence identifier, the basis, and an evidence tier.

The basis is one of:

• a licence file in the model repository
• a licence section in the model card
• the repository metadata tag only

The evidence tier grades that basis:

For a model to be admitted the evidence must be T1 or T2. A metadata tag alone (T3) is a hold, whatever licence it names, because a tag is a label and not a grant. T4 is also not admitted.

The record also keeps two things apart: the licence the publisher declares, and the licence the gate concludes the weights are granted under. For a model derived from another (a distill or fine-tune), the conclusion can name both licences together, for example MIT AND Apache-2.0, and the gate checks the base model's licence obligations clause by clause. Whether a fine-tune inherits its base model's licence is a legal question Heliast does not claim to settle. The gate records the evidence and holds where it is not enough.

The check result reads Concluded, Not proven or Failed.

Added clauses

A licence file is not always the whole story. Publishers sometimes add a usage policy, a notice file or an access prompt next to the licence. The gate reads the sibling policy files the candidate declares and looks for an added clause: an indemnity, a field-of-use restriction, a revenue or user threshold, a naming or credit requirement, an age restriction, or other binding terms. If it finds one, the model is held and the clause is quoted word for word so you can read it.

This screen has limits. It reads only the files declared for that model. A publisher can always put terms in a file nobody declared, so a clear result means no added clause was found in the files read, not that none exists.

Provenance

The gate checks that the weights come from the licensor's own repository, not from a re-upload, a merge or a third-party conversion. If the model derives from another, the page names the base model and the relation. A source that is not the licensor's repository is rejected.

Files and digests

The gate requires the safetensors format and rejects pickle-format checkpoints, which can run code when loaded. It compares each weight file against a pinned digest. A digest is a fixed-length fingerprint of a file's contents, so a changed file has a different digest.

The page says how many weight files were hashed against their pinned digests. Where it says the files have not been byte-checked, the digest is pinned in the record but Heliast did not hash the files itself. Read the wording on the page: it states which of the two applies.

Export screening

This check is not assessed. The page reads: "Export screening: not yet assessed. No export claim is made."

Nobody has assessed any model against export control rules, and Heliast makes no claim either way. If you are subject to export control rules, you need your own adviser to assess the model before you deploy it. A record can show a status of "screened internally" or "counsel reviewed" only when it also carries who assessed it, on what basis and when, and for counsel review a citation. Treat any other presentation as not assessed.

Attestation

An attestation is a signed statement that a particular admitted model, at a particular revision, passed the gate. It names the signing key and the gate version that produced it. An attestation exists only for an admitted model, so a held or rejected model shows "None". The signed statement lets the hook and your own tooling check an admission without trusting a screenshot.

The page shows the key it was signed with. Confirm with your Heliast contact how to obtain the matching public key and which attestations in your estate are signed, since the console shows the pairing that was recorded.

Holds, and what would change one

A hold means a person has to decide something. Typical causes are an added clause in a sibling policy file, a licence that rests on a metadata tag alone, or a derived model whose base-licence obligations are not evidenced.

The page quotes the gate's reasons word for word, each tagged with the check that raised it. For a hold it also says what would change it: evidence from the licensor, or a ruling by a person. If the publisher adds a licence file or clarifies the clause, the model can be assessed again.

A rejection is different: the gate found an automatic failure, such as a licence outside the accepted set, a pickle checkpoint, or a source that is not the licensor.

Licence classes

The catalogue uses two licence classes.

• Class A. The admitted catalogue. The licence must be Apache-2.0 or MIT, evidenced at T1 or T2, with no added clause found. A licence that is anything else, including a Hugging Face license: other tag, is outside Class A and is not admitted.
• Class P. A model you own, such as your own fine-tune of an admitted base. It can be assessed, but the result is assessed, never admitted. An assessed record never enters the public catalogue. It records what you declared (lineage, data rights, a hash you ran yourself) separately from what Heliast checked. Heliast did not see the weights. Training-data cleanliness, safety, memorisation and export control are marked not assessed. The assessed statement and its signature exist in the tool and have been exercised on synthetic data only, not in a real estate, and the hook does not yet verify the signature when it loads such a record.

A model registered by you without an assessment is likewise not admitted.

Hosted provider routes

A model reached through a hosted provider or a frontier API has a separate host record. Weights on someone else's server cannot be byte-checked, so these routes are never labelled verified. They carry the label "provenance by host attestation, not verified", with the provider's declared data handling and a review-by date. Past that date the gate treats the host record as held.

The Admission list

The Admission list shows one row per candidate the gate assessed, newest first and grouped by month. Each row shows the verdict, the model, its licence and evidence tier, how many hosts it can run on, and the assessment date. A held or rejected row shows the gate's first reason. Selecting a row opens that model's verdict page.

The controls are:

• Search. Filters by model name. Press / to jump to the search box.
• Verdict. All, Admitted, Held or Rejected, each with its count.
• Sort. Newest first, or by name from A to Z.
• Filters. Opens the filters below. Whatever is on shows as a removable chip, with "Clear all" and a count of how many entries are shown. The state of the list is kept in the page address, so a filtered list can be shared as a link.

The filters:

Counts beside each filter value show how many entries it would leave, given the other filters in force.

Limits

• A verdict is about licence, provenance and file integrity. It is not a measure of how well a model performs on your tasks. Use Compare for that.
• Export screening is not assessed for any model.
• The added-clause screen reads only declared files and does not prove that no other terms exist.
• Hosted routes are never verified, and a model you own is never shown as admitted.
• Nothing on a verdict page is legal advice. Where the licence position is uncertain, ask your own counsel.