Verdicts and policy

A verdict is the result of running one security's data through your policy: a versioned set of written rules with numeric thresholds. The evaluator is pure. The same inputs and the same policy version always produce the same verdict, the same rule outcomes and the same fingerprint. A language model can explain a verdict afterward; it never computes one.

This page explains the mechanism. The live thresholds your policy uses right now are listed on Strategy rules.

Rule outcomes#

Every evaluation produces a list of rule outcomes. Each outcome has:

The rule that decided the verdict is called the binding rule. It is moved to the top of the list, and the verdict summary is built from it.

Severities#

Statuses#

What the rules check#

How the verdict is decided#

The evaluator walks this list top to bottom and stops at the first match:

Soft rules never change the verdict. Each soft concern (a market cap in the half-size band, too many recent new lows, a low set recently, a YELLOW market regime) adds a size reason, and any size reason makes the suggested size HALF. Size is reported as FULL or HALF only for GREEN and YELLOW verdicts, and NONE otherwise.

UNKNOWN is a real answer#

Every input to the evaluator can be missing, and missing is never treated as a pass.

• A rule without the data it needs reports UNKNOWN with a sentence saying what is missing, for example "Net debt not derivable from XBRL filings."
• With nothing failing, one or two unknown hard rules hold the verdict at YELLOW with a list of what to verify. Three or more make it INSUFFICIENT.
• MANUAL rows never count toward a pass. A GREEN verdict still asks you to complete them.
• In the report, unknowns get their own list next to the bull and bear lists.

The policy version tag#

Every evaluation records the policy that produced it as a tag:

<policy id>@v<version>#<first 8 hex characters of the thresholds fingerprint>

For example quality-velocity@v3#1f0c9a2e. The version number tells you which saved revision of your policy ran. The hash suffix is computed from the thresholds themselves (merged with the defaults), so two evaluations with the same tag used exactly the same numbers.

The default policy is the Quality-Velocity Framework v5, id quality-velocity. Evaluations stored under an earlier policy keep their original tag.

The input fingerprint#

Each evaluation also carries an inputFingerprint: a 16-character hash of the policy tag plus the evaluator's inputs. If neither the policy nor any material input changes, the fingerprint does not change.

Inputs are normalized before hashing so trivial noise does not register as a change:

• The evaluation time and the last price are left out. Price alone never makes research "changed"; rule outcomes do, through the distance above the low.
• Distance above the low and ATR are rounded. Dollar volume, market cap and position cost are compared by order of magnitude.
• The spread and the day counts to and from earnings are left out; the earnings date itself is kept.
• The market regime is reduced to its state, and the age of the 52-week low to a recent, middle or mature bucket.
• The dataset versions the inputs came from (such as the latest daily bar date and the latest filing accession) are included.

Investi saves a new evaluation revision only when the fingerprint changes. Revisions are immutable and linked to the one before. The screener uses the same fingerprint to decide whether a name is CHANGED or UNCHANGED; see Candidate states.

Verdict diffs and the change log#

When a security is evaluated again, the new result is compared with the previous stored revision. Every rule whose status differs (including rules that appeared or disappeared) is listed with its old and new status. A one-sentence summary is written:

The first evaluation of a security reads "First analysis under this record." The sentence and rule changes appear in the report's change log and on the research page; see Research.

Saved answers to the judgment checks#

On a company page each judgment check (Kodak test, legal event, known vs newly revealed) has an Answer control: Pass, Fail or Unknown (for the revealed check: Known, Newly revealed or Unknown), a note, and a date it counts until, 90 days by default. Saved answers feed the verdict until that date and the rule reads "Your answer: Pass until 2027-02-02". A Kodak or legal FAIL makes the verdict RED; a newly revealed answer caps it at YELLOW; a known answer saved after the report lifts the earnings-reaction cap. A legal PASS saved before newer evidence arrived does not hide that evidence: the rule turns WARN and asks again. Answers are also available at GET/PUT/DELETE /api/v1/securities/{ticker}/checks and through the MCP tools get_manual_checks and set_manual_check.

Overrides#

You can record your own verdict (GREEN, YELLOW, RED, FLAGGED or DORMANT) against an evaluation with a written rationale of at least 8 characters, through POST /api/v1/securities/{ticker}/override. The computed verdict is never replaced; it is kept alongside your override and rationale.

Position signals#

For a security you own, the evaluation adds a position signal based on your unrealized return:

The signal is null when you do not hold the security. Like the verdict, it is research, not an instruction to sell.

Saving a new policy version#

Policies are versioned and immutable. Saving never edits a policy; it writes a new version.

• In the app: edit thresholds and hard rules in Settings and save. See Settings.
• Over HTTP: PUT /api/v1/policy with a JSON body containing thresholds (any subset of threshold fields, each validated against its allowed range) and optionally hardRules (up to 50).

PUT /api/v1/policy
Content-Type: application/json

{ "thresholds": { "earningsSoonDays": 10 } }

Before saving, the merged thresholds are checked for consistency, for example that the leverage watch level sits under the leverage ceiling, that the ATR bands increase, and that entry gates widen as ATR rises. An inconsistent set is refused with 400 inconsistent_thresholds and a sentence for each problem.

The value in the example is illustrative, not a recommendation. The new version number is one higher than any version you have saved before, and always above the default policy's version. Thresholds you leave out are carried over from the current version (thresholds added to the engine since your last save come from the defaults), and so are hard rules if you omit hardRules. Each save is recorded in the audit log.

Saving requires the signed-in app session. Requests made with an API token are refused with 403 session_required ("Strategy rules can only be changed in the Investi app"), so no integration can quietly change your rules. Reading the current policy with GET /api/v1/policy works with the research:read scope.

After a save, every new evaluation carries the new version tag, so every screener candidate is marked CHANGED until it is analyzed under the new policy.

Hard rules#

Hard rules are personal exclusions stored with the policy: a sector, an industry containing a word, a ticker, a minimum market cap, or a minimum price. A name that matches one is marked BLOCKED in the screener and skipped by the research queue. They do not change the computed verdict.