Learned rules

Prok doesn’t score every opportunity from a blank slate — it remembers durable policies it has learned from your feedback and applies them going forward. A learned rule is a standing instruction like “we don’t hold the clearance for defence work” or “always flag anything mentioning municipal snow removal,” not a one-off note about a single opportunity.

curl "https://app.prokure.ca/api/v1/settings/rules" \
  -H "Authorization: Bearer $PROKURE_API_KEY"

Reading requires settings:read; changing a rule’s active state requires settings:write.

Where rules come from

Every rule is learned from something you said: replying to a daily digest email, or agreeing or disagreeing with a match in the portal (see Sending match feedback). Not every reply becomes a rule — a reason specific to one opportunity (“the deadline is too tight”) stays a one-off, while a reason that generalizes (“we don’t sell to municipalities”) is what turns into a lasting rule Prok applies to future opportunities too.

What a rule looks like

Field	Meaning
rule_type	green_light, no_go, or preference.
description	The policy itself, in a sentence.
signal	The reason you gave that produced it, verbatim.
source	email_feedback or portal_feedback — which channel taught it. A handful of rules predate any feedback and carry neither.
evidence_count	How many times feedback has reinforced this rule.
last_evidence_at	When it was last reinforced.
active	Whether Prok is currently applying it.
origin_rfp	{ id, title } of the opportunity that produced it, when known.

Provenance

When origin_rfp is present, it links a rule back to the specific opportunity your feedback was about — useful when the wording alone doesn’t remind you why you said it. Rules created before this linkage existed don’t have one: they show their source and signal text only, with origin_rfp staying null. That’s expected for an older rule, not a data gap in a rule created since.

Deactivating and reactivating

curl -X PATCH "https://app.prokure.ca/api/v1/settings/rules/$ID" \
  -H "Authorization: Bearer $PROKURE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"active": false}'

Deactivating stops Prok from applying a rule without deleting it — the record, its evidence, and its provenance stay intact, and setting active back to true restores it. Setting a rule to the state it is already in is a no-op: 200 with the rule unchanged.

An actual activation or deactivation also requests background re-scoring of your existing opportunities. The request is saved with the rule change, so a temporary processing outage does not require toggling the rule again. Results are not updated immediately. Previously screened opportunities can qualify for a later digest; this does not resend prior notifications or unarchive opportunities. Repeated processing failures may need the Prokure team to investigate.

The active-rule cap

At most 40 rules learned from feedback (email_feedback or portal_feedback) can be active at once — the response’s top-level active_count and cap tell you where you stand. This is the same budget Prokure’s automatic rule-learning already respects when a new rule would be created from your feedback; reactivating through this endpoint draws from the same pool. Reactivating past the cap returns 409 rule_cap_reached — deactivate another rule first, or leave this one inactive. The cap only counts feedback-learned rules; anything seeded for your account before you gave feedback sits outside the budget.

Disagreeing always gets a fresh look

Sending a disagree on an opportunity does more than log your feedback — it makes Prokure re-evaluate that opportunity immediately, from scratch, rather than reusing whatever verdict it had already reached. Even when nothing about your profile or the opportunity looks different, disagreeing guarantees a genuinely fresh verdict, not a repeat of the old one.

Related

• List learned decision rules, Activate or deactivate a learned rule: full schemas.
• Sending match feedback.
• Scopes explained.