# Deterministic on Purpose Separating relevance, eligibility, and judgment in deterministic systems. Kumiko · 2026-09-22 Source: https://kumikosolutions.com/notes/deterministic-on-purpose Atorasu collects public procurement notices from several platform families and brings them into one review workflow for Kumiko. Collection solved the first problem. It gave us one place to look. It also created the next one. Once hundreds of notices are in the same system, somebody still has to decide which ones are worth opening. Procurement data is noisy. A software company can match a broad classification code on work that has little to do with software development. Requirements are often buried in prose. Important fields can be missing. Different observations of the same opportunity can even disagree. The evaluation system needed to reduce that workload without hiding how it reached a result. We ended up separating the problem into three questions: 1. Is this opportunity relevant to the work we do? 2. Does the available evidence show anything that prevents us from pursuing it? 3. Should we actually pursue it? Atorasu assigns each question to a different part of the system. --- ## In Plain English Atorasu finds **government software projects** that Kumiko might be interested in. Instead of having AI make a yes-or-no decision, it uses **clear rules** to show **why** a project looks relevant, **flags** anything **uncertain** for review, and leaves the final decision to a **person**. --- ## Relevance Relevance is handled by a deterministic scoring engine. The engine evaluates configured phrases and procurement classifications against normalized opportunity data. Title and description matches are evaluated separately, which allows a strong phrase in the title to carry more weight than the same phrase in the body. A simplified result might look like this: ```text application modernization in title +25 custom software development in body +15 matching NAICS classification +8 --- 48 ``` The score alone is not the important part. Every contribution is retained as evidence. A scoring result records the rule, matched phrase, field, and point contribution: ```go if match != "" { result.Matched = true result.Points = points result.Explanation = fmt.Sprintf( "%s: matched %q in %s (%+d)", r.Description, match, field, points, ) } ``` That evidence is shown in the opportunity detail view, so a score can be inspected without reconstructing the matching process. ### Keeping classifications in proportion Government procurement systems commonly attach classification codes such as NAICS, PSC, and UNSPSC. Those codes are useful, but they can be broad. Several matching classifications can make an opportunity appear more relevant than its actual text supports. Atorasu requires positive textual evidence before a positive classification can contribute to the score. It also limits classification contributions to the amount of positive textual evidence found. ```go if r.Kind == "code" && results[i].Points > 0 { if textPoints == 0 { results[i].Matched = false results[i].Points = 0 } else { codePoints += results[i].Points } } adjustment := min(0, textPoints-codePoints) score += adjustment ``` This keeps classification data useful as corroboration while preventing several broad codes from overwhelming weak textual evidence. ## Eligibility A relevant opportunity can still have requirements that affect whether Kumiko can pursue it. Atorasu handles those conditions through a separate gate engine with three states: ```text PASS REVIEW BLOCK ``` The gate engine evaluates information such as deadlines, structured eligibility requirements, qualification data, and configured company capabilities. Keeping this separate from relevance matters operationally. A strong software match can remain a strong software match even when an eligibility condition blocks pursuit. The score continues to describe relevance, while the gate describes the state of the available eligibility evidence. ## Unknown stays unknown Public procurement data is incomplete often enough that missing information has to be handled explicitly. Atorasu does not convert the absence of a value into evidence that a requirement has failed. A missing field generally produces `REVIEW`: ```go case "missing_field": if (r.Field == "closes_at" && o.ClosesAt == nil) || (r.Field != "closes_at" && strings.TrimSpace(ruletext.Field(o, r.Field)) == "") { finding( domain.GateReview, r.Field+" is unknown; absence is not disqualification", ) } ``` `BLOCK` requires affirmative evidence from a deadline or structured eligibility condition. Conflicting data is handled the same way. If the canonical record contains an expired deadline but another preserved observation contains a future deadline, the gate returns `REVIEW` so the conflict can be resolved by an operator. ```go if futureConflict { finding( domain.GateReview, "canonical deadline passed but another source supplies a future deadline; resolve conflicting dates", ) } else { finding( domain.GateBlock, "closing timestamp is at or before evaluation time", ) } ``` This behavior became important because normalization and deduplication can bring observations from multiple collection paths into the same opportunity. Source-specific evidence is preserved even after a canonical record is created. ## Judgment The final decision belongs to the review workflow. Atorasu stores operator state separately from both scoring and gating: ```text NEW → REVIEWING → PURSUE / PASS ``` A reviewer can inspect the original procurement notice, normalized fields, relevance evidence, gate findings, and source information before recording a decision. Changing the review state does not rewrite the automated evaluation. The data model reflects that separation directly: ```go type Opportunity struct { ReviewStatus ReviewStatus PassReason string Score *int GateStatus *GateStatus } ``` A nil score or gate also has its own meaning. It indicates that an evaluation does not exist yet, rather than representing a zero score or a passing gate. Evaluations retain the input and rule configurations used to produce them, along with the individual rule results. This gives the system enough provenance to inspect how a result was produced later. ## The full path These decisions fit into the larger Atorasu pipeline: ```text collect ↓ normalize ↓ deduplicate ↓ gate ↓ score ↓ review ``` The separation between relevance, eligibility, and operator judgment determines how opportunities are handled once they arrive. Relevance is a weighted measurement with visible evidence. Eligibility is a separate assessment of the available requirements and constraints. Missing or conflicting evidence is surfaced for review. The pursuit decision remains an operator action. That structure has kept Atorasu's evaluation behavior predictable as source coverage has grown.