Your own models

A model of yours is never listed as admitted. Admitted is a label for public open-weight models that went through the admission gate. Your models have two other labels, shown in the console under Admission, then Your models.

Where the record lives

The record lives in your own estate, in your own policy repository. Heliast does not hold it, does not hold your weights, and does not host the model. You serve the model yourself, and your own policy decides who may reach it. Every request is still logged, and the log row states the class of the model.

Register a model

Under Your models, the Register a model panel is a form. You give:

• a model id, as org/name
• the kind: language model, embedding or reranker
• a version label and an owner (a person or team who answers for the model)
• optionally a short purpose and the sha256 digest of your weights, computed in your own environment
• the endpoint address, the network it sits on (a CIDR) and its port
• one group to entitle

From a valid form the console generates four pieces of text, each with a copy button and a download:

1. the model record, with class: "registered", kept in your model catalogue directory. The owner and purpose are written as comments.
2. lines for the policy configuration: the entitlement for your group and, if you gave one, the model digest.
3. an entry for clientModels in the Agent Router chart values.
4. an entry for client_model_endpoints in the network baseline, which opens egress from the router to that one network and port.

The checks the form applies match the ones the hook and the charts apply:

• the id must be name or org/name, and must not equal the id of a public catalogue model or a name an external provider route uses
• the address must start with http://, with a host and no credentials; an https address is refused for now, because the router has no TLS setting for the endpoint
• the network must be an IPv4 CIDR no broader than /8, or an IPv6 CIDR no broader than /32
• the port must be 1 to 65535
• the digest, if given, is 64 hexadecimal characters
• an owner and a group are required

The hop from the router to your endpoint is not encrypted. The router sends the request, which carries the prompt and the caller's identity headers, over plain HTTP, and the answer comes back the same way. Put the endpoint on a network segment you control and that only the router can reach. The network rule the console generates opens that one address and port and nothing else. TLS to your own endpoint is not built.

A registered model has no attestation, so the policy lines never name an attestation version. The hook refuses a policy that does.

If you leave the digest out, the policy lines carry the entitlement only, and the console warns you. The hook will not load a policy that names a registered model without a digest, so hash your weights in your own environment and add it before you apply the lines.

What the console does not do

• It writes nothing. The four texts are for your operator to commit and apply.
• It does not contact the endpoint you give it.
• It does not read your weights, and it never reads or shows prompts or completions.
• Heliast makes no statement about a registered model.

The generated files have been loaded by the hook's own loader in tests, and the form's rules are tested. They have not been applied in a real estate.

Read a model's page

Each model has its own page, which keeps three groups apart:

• Declared by your team: the lineage, your data rights and who hashed the weights. Heliast did not verify these.
• Measured: for an assessed model, a Compare report on your own test set, referenced by its digest. A registered model has nothing measured.
• Not assessed: training-data cleanliness, model safety, memorisation and export control. No claim is made about any of them.

For an assessed model the page also shows the signed assessment statement as stored: the key id, when it was issued, that Heliast did not see the weights, and that the statement is not an admission. The console shows the file as it sits beside the record. The console does not check the signature itself. The hook does, and the console shows "Refused by the hook" with the reason on any assessed model it has refused. The hook checks: it checks the signature against Heliast's public key when it loads the catalogue, and an assessed model whose statement is missing, edited, or signed by another key is refused. The other models keep working.

Limits

• The console reads the directory named by UI_CLIENT_CATALOGUE_DIR. If it is not set, the list is empty and says so.
• A record of class admitted placed in that directory is ignored, with a note.
• A file that cannot be read is named in the list, and the other records still load.
• The record schema published for the catalogue does not yet describe a registered record. The generated record follows what the hook reads: the class and the model id. Confirm with your Heliast contact before you validate it against that schema.
• A registered model needs no statement and no key. Only a model that claims to be assessed does.
• Assessed records are produced by the assessment tool run by Heliast with you, not by this form.