The Engine

What the engine is for

Every workspace has an engine running behind it. Nothing on screen is labelled "engine", but it is why a workspace does anything on its own: a message gets an answer, a task lands with the right member, a heads-up appears in your call. It has four jobs:

1. It takes in what members write and keeps it, once and forever.
2. It notices what needs a decision and puts it in front of the right person.
3. It keeps trust and patterns current, so the workspace learns from what actually worked.
4. It runs scheduled work, and tells you when it could not.

Everything the engine knows comes from the records members have written; every figure it shows you is worked out from them.

Taking in what members write

When a member writes a record (a person typing, an assistant answering, an automated member reporting a result), the engine accepts it at once. From that moment:

• It is kept as written. No one, the engine included, edits a record afterwards. A correction or a change of mind is a new record that points at the old one.
• The same record sent twice is one record. A client that loses its connection mid-write can simply send again.
• Everyone sees it at once. A member waiting on the thread and any open screen are told the moment the record lands; a paired workspace that has permission to see it picks it up on its next sync, within seconds.
• Slow work never blocks fast writes. Accepting a record and acting on it are separate, so a busy workspace stays responsive.

The engine checks only that a record is well formed and that the writer may write there; meaning is worked out afterwards.

Noticing what needs a decision

After a record lands, the engine asks whether anything needs to happen because of it, in a fixed order that prefers what you said over what it inferred:

1. The record names who it is for. It goes there, and nothing else is consulted.
2. A rule you wrote matches. Rules say what should happen when a certain kind of record appears: send it to a member, start a run, raise a heads-up (Routing rules).
3. A proven pattern matches. When the workspace has seen this shape of work succeed before, it can reuse that outcome. A rule you wrote always beats a pattern it inferred.
4. Nothing matches. The engine does not guess. It writes a proposal for you: a decision in your call describing what it thinks should happen, which you can approve into a standing rule or decline. Where proposals are switched off, you get a heads-up naming the record and offering to create a rule for it.

Whatever the engine puts in front of a person lands in one place, your call, read with spl register or from the workspace screen. It keeps two kinds of item apart: a decision needs an answer (choose an option, or provide something); a heads-up needs only a nod. Near-identical proposals appear as one group with a count, and answering any one clears the group. A decision with a time limit that goes unanswered is resolved rather than left hanging. A workspace set up with the recommended preset starts with one decision waiting, a question about what you are working on: answering it opens your first thread, titled by what you typed, and a repeated answer after a dropped connection lands in that same thread, never a second one.

Keeping trust and patterns current

Members earn trust by having their work judged. A verdict is a record like any other, and the engine takes every new verdict into account:

• A member's standing reflects the verdicts on their work, per area of work. Being good at one kind of work does not make a member trusted at another.
• Recent results count for more than old ones. A member coasting on year-old approvals drifts down; one whose recent work is judged well rises.
• A sudden change is noticed. If a member's results shift meaningfully from their track record, the engine writes a note of the drift on the thread where it happened, so the change is visible.
• Ways of working that keep succeeding become the default for that kind of work, and drop out of use if they stop succeeding. The workspace gets cheaper at the things it has done many times.

None of this is a stored opinion: read the verdicts and you can see why a member stands where they stand. Trust explains what the score is for.

Running scheduled work

Some work runs on a clock rather than in response to a record: a standing check every morning, say. Triggers are how you declare it, and the engine promises:

• A missed run is recorded, never silently dropped. If the workspace was off when a run was due, the miss is written down and the trigger's own policy decides what happens next: skip it, run the latest occurrence once, or catch up on each one it missed.
• A trigger never fires twice for the same occurrence, even across a restart.
• A trigger that cannot fire says so. spl doctor reports how many triggers are enabled, and names any enabled trigger that fires nothing, with when it last fired and why it is skipping; spl trigger history <name> shows each skip. A trigger installed from a blueprint starts switched off.
• Spending is bounded. Each trigger runs under a budget and the workspace has a daily ceiling; a run past either is refused and recorded, and a trigger whose budget runs out, or that keeps failing, raises a decision in your call instead of going quiet.

spl trigger list | show | history <name>   # what is declared, what fired, what was skipped
spl trigger pause | resume | run | remove <name>

On the same clock the engine does its own housekeeping: the daily backup (spl backup), clearing out old telemetry, and keeping the store under any size ceiling you declared. Above the ceiling, ordinary writes are refused with a clear reason, and your own configuration writes never are, so you can always raise it. spl doctor shows the store's size and what is taking the room.

Changing how the engine behaves

You never restart or redeploy a workspace to change what the engine does. Rules, triggers, permissions and health checks are records you write (most are one short expression), and three things hold: a change applies to the next record that arrives; every rule that was ever in force is still there, with who wrote it and when; and a rule the engine cannot load is left out rather than half-applied (a refused trigger is reported by name) while every other rule stays in force.

spl config show                    # what is loaded right now
spl config list-rules              # routing rules; also list-triggers, list-health, list-permission-rules
spl expr eval                      # try an expression before you store it

What the engine does not do

It does not do the work itself. Runs, answers and tool calls happen as the member who asked, within that member's permissions and budget; see Running a goal.

It does not decide what leaves your workspace. Sharing with another workspace happens only by a permission you grant; see Federation.

What's next

• Patterns: how proven ways of working get reused.
• Routing rules: telling the engine what should happen.
• Configuration reference.