Trust

Overview

A workspace works out trust from what actually happened. A member completes a piece of work. A different member reviews it. The verdict counts. Many verdicts add up to a standing that tracks how reliably that member does that kind of work. That standing is trust.

The contrast is deliberate. Trust is not a policy ("Alice is approved for production") because policies stay fixed while reality changes. Trust is not a vote, because votes do not compound. Trust is not an opinion, because opinions are cheap. Trust is a record of reviewed outcomes, kept current by continuous evidence, and when the evidence is thin the workspace says so rather than guessing high.

This is what lets a workspace automate more work over time. As a member's trust in an area grows, their work becomes cheaper to hand to them, more of it can be pre-approved by routing rules, and the patterns their work produces can become permanent. Nothing moves faster than the evidence allows.

Trust is derived, never set

A trust score is not a number somebody writes down. It is derived, every time it is asked for, from the history of work and verdicts in your workspace. That has three practical consequences:

• It cannot drift. If a workspace is restarted or restored from a backup, trust is rebuilt from history and comes out the same. There is nothing to repair.
• It cannot be edited. You do not raise or lower a member's trust. You review their work, and the standing reflects the review. The only way to move trust is to produce evidence.
• It survives a move. A workspace restored onto new hardware ages its evidence by how old the evidence really is, not by when the restore happened.

Trust is scoped

Trust is always about a member, in an area of work, as judged by a reviewer. It is never one number per member.

A member can be strongly trusted for code, barely trusted for operations because only two of their operations tasks have ever been reviewed, and trusted as a reviewer of research in their own right. Each of those is tracked apart and none of them leaks into the others.

Areas of work are named by whoever gives the verdict (code, ops, data, research and so on); there is no fixed list to choose from.

The reviewer matters too. Two reviewers can legitimately disagree about the same member's work, and the workspace keeps both views instead of averaging them into noise. Most of the time you only care about "how good is this member at this kind of work" and let the views combine (that combined standing is what a routing rule reads), but when you need it, the standing as judged by one particular reviewer can be read on its own, and an audit can ask what a particular reviewer approved.

Where trust comes from: the review

Trust is produced in exactly one place, the review of finished work.

1. A member says the work is done, with spl task done or its equivalent. This is a claim. It produces no trust.
2. A different member reviews the outcome. For tasks that is spl task approve or spl task reject. Add --grade <0..1> to record how good the work was, not just whether it passed (1.0 flawless, 0.75 solid with rough edges, 0.55 barely passed; on a rejection, how far from acceptable). This is one piece of evidence.
3. The member's trust in that area reflects the verdict the next time anyone reads it.

The rule is: no review, no trust. Self-reported success, "this looks like it worked" guesses and automated heuristics contribute nothing.

The same rule governs runs. A run ends by reporting its own outcome, and that report is a claim, never evidence. A run cannot grade itself. Its trust moves only when another member reviews the outcome with spl work-loop-review <thread> --accept (or --reject); add --domain <area> to say which area of work the verdict counts toward, otherwise it counts toward general. That external verdict counts exactly like a task approval does.

Nobody grades their own work

The reviewer must be a different member from the one who did the work. If Alice approves her own work, the record is kept, but it earns no trust. The workspace treats it as a note, not as evidence.

This has teeth day to day. An automated member that closes a task cannot approve its own work; the evidence that counts comes from a reviewing member or from the person who reads the result. Devices linked to one person count as that person, so approving from a second device does not count either. And a member who proposed another member's definition may not grade that member's runs: the workspace refuses the verdict outright.

For one automated member reviewing another, independence holds naturally: two members, two separate standings. The reviewer's own trust as a reviewer accumulates apart, so you can ask how reliable a reviewer is, just as you can ask how reliable a builder is.

How trust behaves

It grows slowly and honestly. One approval out of one is not the same as a hundred out of a hundred, and the workspace does not pretend it is. A handful of lucky approvals cannot bootstrap high trust; a member has to keep producing. Occasional misses weigh a standing down more than a raw pass rate would suggest, on purpose.

It fades when it is not exercised. Evidence goes stale. A member who was excellent a year ago and has not worked since drifts back toward neutral, and any renewed work has to prove itself again. Teams that rotate responsibilities, automated members whose underlying model has changed, areas whose requirements have moved: all are rescored continuously with no manual reset. The records themselves never change as they age; only the standing derived from them does.

A sudden change is noticed. A string of failures after a long run of success is noticed as a change in quality, not quietly averaged away into a still-good number. Today that change shows in spl insights; it is not yet raised as a heads-up in your call.

What trust decides

• What can be pre-approved. A routing rule can refer to a member's trust in an area, so routine work from a well-trusted member passes without waiting on a person, while the same work from a newcomer waits in your call.
• What can be reused. A pattern becomes permanent (settled, and shareable with paired workspaces) only when the member who produced it is well trusted in that area, and it is set aside if a sudden change in quality is noticed and that trust falls.
• What it costs. A well-trusted member's routine work is increasingly reused rather than reasoned out again. Genuinely new work still gets full reasoning, whoever does it: trust changes how much of the familiar can be skipped, not whether the unfamiliar is thought through.

Reading trust

spl trust

lists, for each member and area, how many reviewed pieces of work succeeded, how many were reviewed in total, and the resulting trust. A fresh workspace reports that there are no trust scores yet, until the first review lands. For a member's evaluation history over time, see Evaluating a member.

When trust won't help you

Cold start. A brand-new member has no reviewed work and therefore no trust. Their first pieces of work are handled the expensive way, because nothing is proven and nothing routes on trust. This is intentional; manufacturing trust would defeat the point.

Area mismatch. A member with high trust in code has none in operations. Handing them an operations task produces a low-evidence verdict that does not draw on their code standing. Name the area correctly or accept the weaker evidence.

Rare work. If a kind of task happens once a year you will never accumulate enough reviews to build trust in it. Such work stays expensive, and the workspace is telling the truth when it does.

Reviewer disagreement. If two reviewers consistently give opposite verdicts on the same member's work, the combined view is misleading. Look at trust per reviewer before relying on it.

What's next

• Members: the people and automated members trust is about.
• Records: the unit a verdict is kept as.
• Patterns: what proven, trusted work turns into.
• Task Management: the review in practice.
• Evaluating a member: grades, comparisons and history for a member.