How Enumeray fits together

Enumeray makes installed scientific models available through a self-service CLI and HTTP API. A model can accept JSON, declared files or both. Runs retain the publication, scientific definition, inputs, execution disclosure and installation selected at acceptance, even if the owner later updates the model.

The execution path

1. CLI or clientDiscovers models and submits inputs
2. API + PostgreSQLRecords authorization, runs and provenance
3. ConnectorClaims work over outbound HTTP
4. Compute runnerLaunches the installed wrapper

Connector ⇄ versioned object storage · process or Slurm · direct or SSH

The connector initiates contact with the API. The API does not open inbound connections to compute.

The wrapper maps your model’s native interface to a request/result protocol. Connectors stage input files, track backend ownership, collect outputs and publish verified artifacts. Wrappers receive local file paths and scientific inputs; API, storage and SSH credentials stay outside the model process.

Choose a responsibility

Role	Owns	Start here
Model user	Inputs, access requests, submitted runs and result interpretation	First run
Model owner or co-admin	Scientific contract, wrapper, publications and model sharing	Author overview
Connector owner or co-admin	Connector, execution accounts, contexts, installation roots and compute grants	Connector quickstart

An account can hold several roles. Resource ownership is independent: administering a connector does not automatically make you a model administrator. Model administrators may inspect their model’s scientific run data; connector-only administrators receive operational metadata unless separately authorized.

Follow a complete workflow

Enumeray operates the service. Obtain its API origin and an account from Enumeray, then follow the handoff for your role. Model users can begin with the first-run guide.

Step and responsible role	Concrete work	What the next person needs
1. Connector owner	Create and enroll the connector; install a runner, execution account and approved context.	Context ID, approved release directory and installation method.
2. Model author and connector owner	Author scaffolds/tests a wrapper and agrees a scientific contract; connector owner grants the author’s user UUID compute access and arranges an immutable installed release.	Tested editable publication.json, installed wrapper/runtime/datasets.
3. Model owner/co-admin	Validate, save, register and activate a publication, then choose sharing policy.	Model ID, access/invitation, scientific examples and interpretation.
4. Model user	Review the contract and initialize/submit an analysis, optionally bind local files, then collect outputs and provenance.	Private analysis directory, original input bytes and verified result bundle.
5. Responsible owners	Update publications, operate connectors and contact Enumeray support when service assistance is needed.	Retained publication/installation identity and execution evidence for recovery.

The connector owner needs the author’s account UUID from auth whoami, rather than the user’s email or a token. The author needs a context from connector grant available, rather than database credentials. The user needs a model ID and access, rather than a context ID or wrapper installation path. These values refer to different resources and cannot substitute for one another.

Know which file you are handling

The guides show complete examples of each file. Keep these boundaries explicit when integrating:

File	Created by	Consumed by
publication.json in an author project	Author edits the scaffold directly	Local tests, model validate, model create --file, model release init --file
Saved release directory	model release init freezes source and assigns a candidate ID	model release resume, status, review and activation
context.json	Connector owner using a backend template	connector context create
inputs.json	User using the published scientific contract	analysis init --inputs; the saved copy stays editable until first submit
Analysis directory	analysis init saves reviewed inputs and durable identities	analysis submit, status, wait, logs, cancel and collect; exact retries use the same directory
upload.json for independent data	artifact upload --state	artifact resume --state; normal analysis bindings retain transfers automatically
request.json / result.json in an execution workspace	Compute runner / model wrapper	Protocol-1 wrapper / compute runner; see wrapper examples

A scientific input object, an editable publication, an HTTP management request and a wrapper envelope are different JSON formats. Start from the example for the command you are using. Manifests and downloads maps each format to its consumer; HTTP workflows shows which JSON to send over the API.

What to expect

Publication requires the connector to acknowledge the candidate configuration as ready. A failed candidate leaves the current publication available. Readiness checks installed entrypoints and backend access; authors must still test their science, runtime dependencies and datasets.

Lost contact does not authorize another execution. Queued work, assigned work, scheduler evidence and pending result transfers are durable. Required output verification precedes a successful public result. Log archives have their own publication lifecycle and cannot change the scientific outcome.

For terms such as publication, scientific definition, context and grant, see the glossary.