How Managed Judgments Work

A managed judgment evaluates a small, feature-specific piece of structured state against versioned questions. The response is constrained to choices, scores, or yes-or-no probabilities. SchemaBounce then applies a deterministic product policy.

Processing flow

feature-selected state
      |
      v
deterministic rules
      |
      | ambiguous cases only
      v
bounded judgment
      |
      v
versioned thresholds
      |
      +---- Flagged
      +---- Review
      +---- Silent

The judgment result is evidence. It is not authorization.

Confidence bands

Flagged means the result cleared the feature's higher threshold. SchemaBounce surfaces it as likely and identifies the evidence source.

Review means the result is ambiguous enough to ask a person. A person can confirm or dismiss it.

Silent means the result did not clear the review threshold. It is not stored as a customer finding. SchemaBounce may retain a short-lived input hash so an unchanged item is not judged and billed repeatedly.

Thresholds are versioned feature policy, set per feature and measured against a representative set labeled by someone who did not write the question set before a feature is allowed to release. They are not universal definitions of certainty.

Provenance

Where the feature supports it, a result includes:

• the target object reference;
• the source revision;
• whether a rule or judgment produced it;
• its confidence band;
• the policy and question-set versions;
• freshness;
• confirmation state.

Exact probability distributions and engine model identifiers are limited to authorized evaluation surfaces.

Availability

A feature runs only when all required gates pass:

• the feature is implemented;
• the platform kill switch is on;
• the workspace master switch is on;
• the individual feature switch is on;
• a usable managed or workspace credential is available;
• the caller has the required permission;
• any applicable budget gate passes.

The workspace settings API reports configured and effective state separately.

The console renders features from that capability response. Implemented features show their effective state and configuration control. Planned features remain informational and never appear as working switches.

When the engine is unavailable

Features must define an explicit fallback. They do not invent a result. Sensitive-column detection runs deterministic rules only and reports the reason for the reduced mode. A future safety gate must fail closed or request human input according to its documented policy.

Configuration drafts

Future agent-authored judgment-assisted configuration follows a preview, submit, approve sequence:

1. Preview computes a candidate without storing or applying it.
2. Submit rechecks the source revision and creates an Inbox proposal.
3. A person reviews the evidence and approves in the console.
4. SchemaBounce applies the change transactionally before marking the proposal approved.

If the source changed after preview, submit returns a conflict and requires a fresh preview.

A masking suggestion shown to a person is different. It is still a preview and never changes a route automatically, but a permitted person can confirm it through the normal transform-create flow without first sending their own action through Inbox.