Posture ladder

A rung is a promise about what can block.

Your workspace sits on exactly one of four, and the sequence only ever widens what is allowed to block. That is what makes moving up meaningful and moving down always safe: a lower rung can never make your traffic more dangerous to run, so it needs no permission — and a higher rung is a bigger promise, so it needs evidence.

The ladder lives on Protection → Enforce. Turn on enforcement moves the workspace to scoped_enforce, and Back to Shadow moves it down to shadow. The checklist's first item, Start the measured window, has a Start measuring button that moves it to observe. Every rung, enforce included, is under More settings → Every protection level.

The dashboard names the rungs in words: shadow reads Shadow, observe reads Shadow · measuring since the day the window started, and both blocking rungs read Enforce.

The four rungs

Rung	What may block	The promise
`shadow`	nothing	"Watch everything, block nothing. Tell me what you would have done."
`observe`	nothing	"Same, and we are now working the review queue. Start the clock."
`scoped_enforce`	every rule your active policy sets to block	"Block what my policy says to block, and turn on the first-contact checks for consequential actions."
`enforce`	the same as `scoped_enforce`	"The same blocking as `scoped_enforce`."

New workspaces start on shadow.

Shadow and Observe block the same thing: nothing

Worth saying outright rather than leaving you to discover it. The two lowest rungs are identical at the moment of decision — neither can stop a call. They differ in two ways that matter later:

The clock starts at observe. The measured window that a blocking rung requires is measured from the moment you commit to working the review queue. A window has to start somewhere, and "when nothing could have blocked anyway" is not an honest origin.
The review queue changes role. In shadow it reads as a digest — grouped, no expectation on any single item. In observe it is your operating surface, and the workspace starts counting how quickly items get dispositioned.

What blocks once you enforce

On scoped_enforce and on enforce, every rule in your workspace's active policy that is set to block does block, whatever kind of tool it matches. Blocking is not limited to money movement, counterparty changes, credential changes, external sends and destructive writes. What can stop a call:

Sentisec's built-in protection rules and your egress allowlist.
The rules of your active contract that are armed to block. When you activate a contract while the workspace already blocks, a new blocking rule that Prove saw catch harm without stopping good work arrives armed. Every other new blocking rule arrives unarmed: it watches, records what it would have blocked, and says why it only watches. An admin arms a watching rule on Protection → Enforce, under Rules to arm, once Prove has seen it work. See what blocks after you activate.
Tools your agents never declared, once a contract is active: a call to one is stopped when Sentisec can tell it does something consequential, and sent for review when it cannot tell what the tool does. A tool is never blocked only because nobody could classify it.
The approval policy, which holds a call for an admin's approval rather than refusing it.
Calls proposed together with a held or refused call. On the API endpoints, when one call in an answer is held or refused, the other calls in that answer that change something are not sent either. Calls that only read still run. See calls proposed together.

Every block names the rule that made it, on the session and in the answer your agent receives. A call that was not sent because it went with a held or refused call names that call instead, and counts with it: one wait or one refusal, not two.

On shadow and observe none of this stops a call. The session records what would have been blocked, held or held back.

What `scoped_enforce` turns on

The rung itself turns on one family of checks: first contact on consequential actions. A payment, a write to a record, an outbound message, a destructive action or a credential change that names a counterparty your own data has not vouched for asks for approval. It never refuses. Below scoped_enforce these checks only record. The ladder publishes the list of what it turned on (see what the ladder arms).

enforce blocks exactly what scoped_enforce blocks, and the two need the same evidence to reach. Most teams should land on scoped_enforce: moving to enforce adds no protection.

Moving up requires evidence

A promotion is not a toggle. Each transition is checked against a set of requirements, and the ladder shows all of them for every transition — the satisfied ones too. A screen that shows only failures teaches you to click again; a screen that shows what was measured beside what is required teaches you what to do.

Each requirement renders three things: what your workspace measured, what the rung requires, and the one action that closes the gap.

Requirement	What it is asking
Approved counterparties	Enough of your counterparty relationships are vouched for — either watched long enough to be trusted, or signed off by you out of band.
Test against recorded traffic	If a learned policy governs the workspace, it has been replayed against your own recorded traffic and that replay actually exercised something.
Clean traffic window	A measured period at your current rung with no blocks your team judged wrong — and enough traffic inside it for the absence to be evidence rather than an absence of measurement.
Rule settings	A policy mined with loosened learning settings cannot buy a blocking rung. Re-learn it at the defaults.

Three properties of that list are deliberate, and each one is the difference between a gate and a rubber stamp:

A requirement that cannot be measured is not satisfied. "We could not read this" and "we read this and it was zero" are different answers, and only one of them is a reason to keep going.
A requirement that does not apply is reported by name. A workspace with no learned policy has no proof to check. That reads as not applicable, and here is why — never as a quiet pass, because an operator whose policy is active needs to see the difference.
You cannot bank a window on a lower rung. The clean window for a promotion is measured at the rung you are on now. A spotless record in shadow, where nothing could have blocked, proves nothing about blocking.

The thresholds behind these requirements are fixed. They are not workspace settings, and nothing you can configure moves them.

What a refusal looks like

Ask for a rung whose requirements are not met and the answer arrives in place, underneath the rung you asked for, and stays there. It lists every requirement with its measurement and its remedy, and it ends with the sentence that matters most:

Your workspace is unchanged — it is still on <rung>.

A refusal that does not say what did happen leaves you unsure whether you half-promoted, which is worse than the refusal.

A rung you cannot reach yet is still listed, disabled and annotated with what would unlock it. Hiding it would teach you nothing; showing it with its gap teaches you the path.

Moving down is always available

Dropping a rung has no requirements at any time. It shrinks what may block, so it can never make your traffic less safe to run.

It asks for two things:

Administrator rights. Members see the whole ladder and every requirement; only an admin moves it.
A reason, in your own words. Not a confirmation dialog — a text box, and an empty one is refused. The reason is recorded with who moved it and when.

The change takes effect on your next requests. No restart, no redeploy, no client change.

Nothing demotes you automatically

A control that disarms itself when it fires too often is protection that quietly degrades exactly as you use the product. Instead there is a brake: when your team marks blocks inside the current window as wrong, the ladder turns red and says so —

Sentisec has blocked N calls your team judged legitimate. Recommended: drop to observe while the rule is reviewed.

— with a one-click demotion and a link to the items in question. The brake changes no rung. It is a recommendation with a human attached, and the page says so whether it is tripped or not.

Re-promotion starts the window again

Coming back up re-checks every requirement, including a fresh clean window. A demotion caused by a wrong block therefore costs you the window, which is the correct incentive: fix the rule, then earn the rung back.

What the ladder arms, and what it leaves alone

Moving up does not rewrite your policy. The ladder arms rules at resolution time, which is why moving back down un-arms them with no edit, no re-approval and no compensating change.

The consequence is that your saved policy still describes those rules as recording-only while the ladder has them armed — so the ladder publishes the explicit list of what it armed, not a count and not a claim. Open the artifact and open the dashboard and they will not disagree with each other; they are answering two different questions.

Two related behaviours are worth knowing before you meet them:

A rung you inherited arms nothing. If your workspace arrived on a rung rather than choosing one — because it was already enforcing before the ladder existed — the armed list is empty and the page says the rung was inherited, not chosen. Choosing a rung yourself is what arms anything.
Arming can invalidate a proof. If a learned policy governs the workspace, arming rules can mean it has to be proven again before it can be activated. The dashboard tells you when that happens and links you straight to it, rather than letting you find out at activation.

Who can change it

Moving a rung is administrator-only. If the controls are read-only for you, the page says moving it is admin-only and still renders every rung, every requirement and every measurement — a member who cannot promote can still tell you exactly what is missing.

Every move is written to the workspace's audit log: who, when, from which rung to which, and the stated reason. The log is hash-chained, so a missing or altered entry is detectable.

Protection setup — the guided flow that ends on this ladder
Enforcement mode — the two-state view of the same setting
Verdicts — what gets recorded, and what a block looks like to your agent
RBAC — who can move it

On this page