Accept results with outcomes
An outcome is a named rule your project agrees on, such as “Tops within 5 m”: what a residual result must show before it is used, and where an accepted result is delivered. Project administrators declare outcomes. Everyone in the project can read them, and every check against an outcome is kept as a record that is never changed.
An outcome reads residual results (well-residual/1, made by a residual tool; Run residuals at
wells says how to make one). Each outcome says:
- the rule: every computed residual within a tolerance, for example 5 m;
- rows not computed: whether a row without a residual (a member with no top, or no trajectory) is allowed;
- where it is delivered: the send tool that delivers it, by its name in the catalogue, and the destination in words, such as “Team database”.
The examples below deliver through residuals-to-team-database, an example send tool in the client kit
(examples-procedures.zip; see Write and run a tool). It writes a residual result
into the team’s PostgreSQL database; its README says what the database needs. Register and enable it in the project
first, or use your team’s own send tool.
Declare an outcome
Section titled “Declare an outcome”ophiolite outcomes declare --label "Tops within 5 m" --tolerance 5 \ --procedure residuals-to-team-database --destination "Team database"The outcome is enabled at version 1. Rows not computed are allowed unless you add --not-computed refused. Use
--unit ft for a tolerance in feet.
Change it with ophiolite outcomes revise "Tops within 5 m" --tolerance 1 --label "Tops within 1 m". A revision
is the next version; earlier versions and every check under them are kept. ophiolite outcomes disable,
enable and withdraw take the outcome’s name. A withdrawn outcome is never used again, and its name is free.
ophiolite outcomes list and ophiolite outcomes get NAME show every version and every action, with who took
it.
What a result’s states mean
Section titled “What a result’s states mean”ophiolite outcomes states "Residuals DCC@1" prints one line per outcome for that exact result version:
| Line | What it means |
|---|---|
| Accepted on 24 October 2026 under Tops within 5 m version 1 | Every row the outcome needs is there, and every computed residual is within the tolerance. |
| Rejected under Tops within 1 m version 2: … | The rows that fail are named, with their residuals; or the rows are not the ones the selection requires (rows missing, unexpected, duplicated or mismatched). |
| Not checked: published before this outcome; run and publish again | The result was published before this outcome’s current version, so that version has not checked it. |
| Not checked: This outcome is disabled | Nothing is checked or delivered under a disabled outcome. |
| Not checked: conflicting checks; resolve before delivery | Two records disagree for the same result; nothing is delivered until that is resolved. |
| Not checked: Not evaluated | No check exists yet. ophiolite outcomes evaluate "Residuals DCC@1" checks it. |
The check reads the result with the declaring administrator’s reading rights. A result is checked once per outcome version and publication, and the record names the exact input versions it used.
states and evaluate take the result as ITEM[@N]|@ASSET:REVISION: “The result by its name, and its version
number (default: its latest); or exactly, as @ASSET:REVISION”. When two results you can see share a name, the
name alone is refused and both are listed, so you can copy one:
More than one item is named "Residuals DCC": Residuals DCC version 2 (@<asset>:<revision>); Residuals DCC version 1 (@<asset>:<revision>). Name one as @ASSET:REVISION.A pair that is not a version you can see reads like a name that does not exist: “This project has no item named …”. It never says whether the pair exists.
Published before this outcome: run and publish again
Section titled “Published before this outcome: run and publish again”When an outcome is revised, results checked under the earlier version read “published before this outcome”. Version 2 checks a result only once it is published again. You do not need a different file: run the result again and publish it for the outcome. The tool runs again on your computer from the same project versions and settings:
ophiolite procedures again <result> --revision <its version> --output again --for "Tops within 1 m"When the run gives the same file, made with the same settings from the same input versions, the project publishes the same result again for that outcome, and the outcome’s current version checks it:
Published again for Tops within 1 m: Residuals DCC, version 1, the same result.If the new file is different, it is published as a new private result. Without --for, “Run again” works as
before: a run that gives the same result publishes nothing. The outcome is saved in the run folder with the
publication, so publishing again after a stop still publishes for it. A “Publish for” that cannot be done (the run
is not a run made again, the outcome is disabled or not declared over this kind of result) publishes nothing and
says why.
Deliver as an outcome
Section titled “Deliver as an outcome”ophiolite deliver residuals-to-team-database --as "Tops within 5 m" --item "residuals=Residuals DCC@1" --system db=db.json--item takes SLOT=ITEM[@N]|SLOT=@ASSET:REVISION, so --item "residuals=@<asset>:<revision>" delivers exactly
that version when two results share a name.
Before anything is sent, the project’s gate checks that you can read this result version now, that the outcome is enabled and accepts it under its current version, and that the tool and destination are the ones the outcome declares. Every answer is kept as a claim:
- a refusal keeps its sentence, for example “Rejected under Tops within 5 m version 1: …”, and nothing is sent;
- an accepted claim binds the acceptance record and a delivery id the project issues, and the delivery uses that
id. The result’s story then reads “delivered to Team database, confirmed
”.
If a delivery stops and you run it again, it resumes under the same claim only while the claim still holds. If the
outcome was revised in between, you read “This outcome’s acceptance changed; deliver as Tops within 5 m again”,
and a new deliver --as makes a new claim.
What the destination check covers. The gate compares the send tool’s name and the destination label with the outcome’s declaration. The label is words, not an address: the gate does not know where the tool’s own settings send the rows. Keep the tool and its connection settings under the team’s review, as for any delivery.
An ordinary ophiolite deliver without --as is unchanged: it makes no claim and asks no gate.
Private results
Section titled “Private results”Residual results are private by default. Outcome states are shown only to people who can read that result version, and a check uses the declaring administrator’s reading rights; a result they cannot read stays “Not evaluated”, without saying why. Refused claims are listed only to the sender, to the person an agent acts for, and to administrators who can read the result now. Delivering outside the project remains your own act, under your own rights.