How to write a System

What a submission contains

systemKey

The identity a System is resolved by at install. It has to be a non-empty string, at most 200 characters. Its shape is not policed by the submission surface — a key that collides with an existing one is a judgement for review, not a validation error.

instructions

The text the agent runs under. This is the System. It is stored exactly as you wrote it, and its sha256 digest is what a customer consents to at install and what the box checks the content against afterwards.

manifest

A JSON object. Anything that is not an object is refused at submission rather than stored to fail later at install. The field customers read first is egressAllow: the hosts the System asks to reach. A System that needs no network declares an empty list, and that is a stronger position than a short one.

Write the manifest to bound the instructions

The two are read against each other. A manifest is not a wish list; it is the claim that these hosts are enough. Instructions that ask the agent to do more than the manifest bounds are the most common reason a submission comes back — see What gets rejected, which publishes a real refusal with its reason.

Concretely:

• Name one function. A System that exercises one confinement edge can be reviewed; one that offers to help with anything cannot.
• Declare the narrowest egress the instructions actually require, and no host you added in case it turned out to be useful.
• Say what the System will not do, in the instructions themselves. It is easier to review a stated boundary than an implied one.
• Assume the reader of your instructions is the customer, not only the agent. They will see the whole text.

Who may submit

The criteria a submission is judged against are: an active subscription; a one-paragraph pitch for the System that names the confinement edge it needs; and no contact with the veto domains — no financial, legal or medical advice, no health data, nothing that moves money, nothing that touches employment decisions. There is no published turnaround time, and this page does not offer one.

Those are criteria for the decision, not checks the surface performs. Today the submission surface accepts a draft from any signed-in account, so a submission being accepted for review says nothing about whether it meets them.

The path a submission takes

1. Draft. Created and edited at your submissions. Only you can see it, and you can change the instructions and the manifest as often as you want.
2. Submitted. Submitting is the act that opens the row to a verdict. After it, the content is fixed: there is no edit, no withdraw and no delete, because the row is now the reviewer's to decide.
3. Approved or rejected. Both are terminal to you. A rejection carries one verb from a fixed vocabulary rather than free text.

A submission that belongs to another author answers “not found” rather than “not allowed”, so the surface does not confirm that someone else's row exists.

The rejection vocabulary is a proposal awaiting founder ratification, so treat the verbs as the current wording of the reasons rather than as a settled contract. They are listed, with the refusal exemplar, on What gets rejected, and the words this product uses for the things you name in a manifest are on Vocabulary.