Rules

The scoring formula, the policy gate, the state machine, and the capability boundaries this system enforces — copied by hand from the real source (file names given throughout) and re-checked against it, not re-derived here. This page renders no database query at all; it's the same class of artifact as docs/policy-matrix.md, just in one screen instead of eight files.

1. Lead scoring — a 0–100 formula, five sub-scores

Computed once per target by score_lead (app/tools/score_lead.py), immediately after research. Every sub-score is a pure function of what the research stage actually found — nothing here is guessed.

The five caps sum to 100, so the formula can never exceed its own scale without an extra clamp — the caps are the clamp. In practice a contact-less target (the common case) tops out around 70; even a target with full contact data tops out around 95, because email verification isn't built in this phase. That ceiling is stated honestly here rather than rounded up.

Fit label — what the score routes to

The LLM judge — a verdict, never a number

A second model (icp_judge) reviews the same evidence and may override the label above — but only with a written justification, or its response is rejected outright. Its output schema has no score field at all, so it structurally cannot touch the number: the policy floor below always reads the deterministic score the formula produced, never the judge's opinion. A judge that calls a 51-point target strong_fit changes the target's routing label, but the policy decision on that target still records a deny with rule P4 — the floor holds regardless of what the judge argues.

2. Policy gate — nine rules, one choke point

policy_check (app/policy.py) is the single place every action that could produce an external effect or a state change gets checked. It never fails silently — an action matching no rule below resolves to deny, not allow.

Underneath the numbered rules: per-agent capability enforcement

Every core-table write passes through write_gate.commit(), which checks three things before any SQL runs — a rejected write names both the agent and the action, so a denial is observable, never silent:

This is what makes an agent structurally unable to take an action, rather than merely instructed against it: the research agent handles untrusted scraped text and would be refused any write outside its capability set even if its own prompt were subverted.

The natural-language agent's four boundaries

The TaskmasterAgent (python -m app.taskmaster_cli) can plan and dispatch the whole pipeline from one sentence — but each of the following is something it cannot do, enforced in code and pinned by a test that fails if the capability is ever added:

3. State machine — every valid move, nothing implicit

No component transitions a target directly — every change goes through state_machine.transition(), validated against a fixed table (app/state_machine.py). A transition not in this table is refused; there is no LLM-decided or implicit state change anywhere in this system.

The 16 states

new → enriched / researched → scored → drafted → awaiting_review → approved → sent / dry_run_sent → replied → routed, with watchlist, not_target, bounced, suppressed, and failed as the exits along the way.

The path a target actually takes