Skip to content
flowlakes FlowLakes documentation home

Rule proposals

A rule proposal is a pattern the platform noticed in its own AI work, written up as a Business Rule you can turn on. When agents have resolved the same shape of record the same way often enough, or a Decision has answered the same question the same way often enough, the platform drafts an inactive rule that captures it and files the proposal here with the records behind it. You read the evidence and decide. Nothing changes until you activate one.

The point is cost and consistency. An AI run that reasons its way to an answer the platform has already reached fifty times is spending tokens on something knowable. A rule answers it in no time, for free, the same way every time.

When you’d use it

  • Retire repeated triage. Every network incident from the payroll site has gone to the same assignment group for a month. Activate the proposal and the next one is routed on arrival.
  • Promote a workflow that always runs. Agents keep proposing the same workflow for the same class of request. Activate the proposal and it starts on its own.
  • Check whether an agent is still earning its keep. A long list of high-agreement proposals for one table is a sign that the work has become predictable, and that the agent’s budget belongs somewhere harder.
  • Record a deliberate no. Some patterns are real and still should not be automated. Dismissing one keeps it from coming back and leaves your reason on the record.

What you manage

Proposals live at Automate → Rule Proposals (/admin/rule-proposals). Reading the list needs platform.rules.read. Activating or dismissing needs platform.rules.write, the same capability that lets you edit a Business Rule by hand.

Each row shows the pattern in one line (“When category is network, set assignment_group to Network Operations”), the table it applies to, and two numbers you should always read together:

Evidence is written as support of observations: how many cases did this thing, out of how many matched the condition at all. Five of five and five of forty are very different claims, and only the pair tells you which you are looking at.

Agreement is the percentage those two numbers give. A high agreement over a small population is a thin case; a high agreement over a large one is a rule.

Open a proposal to see the drafted rule exactly as it would run, its full description, and the records behind it. Then either:

  • Activate rule makes the drafted Business Rule live. This is the only way a proposal becomes an active rule, and the change is audited as you.
  • Dismiss records your no, with an optional note. The drafted rule stays in place, inactive, which is what stops the same pattern being proposed again next week.

Once you have decided, the decision stands. To change your mind later, edit the Business Rule directly at Automate → Business Rules.

The platform notifies everyone holding platform.rules.write once per pass when new proposals arrive, rather than once per proposal.

Good to know

Nothing a proposal creates can change a record. Every drafted rule is created inactive. The mining pass runs daily and only ever writes inactive rules, review rows, and one notification.

A proposal will never suggest closing a record on arrival. This is the most important limit, and it is deliberate. Because the platform mines pursuits that ended in a resolved state, the most strongly evidenced pattern in that data is always “set state to resolved”. It would score perfectly and it would resolve nothing. Any proposal that would land a terminal state, or a state that pauses the SLA clock, is refused before you ever see it. So are writes to platform-managed columns like number and created_at, and workflow proposals naming a workflow the tenant no longer has.

Only pursuits that genuinely resolved are counted. A cancelled record resolved nothing, so it contributes no evidence. Pursuits closed before 1.14 have no recorded closing state and are skipped rather than guessed at.

Only work an agent actually carried out is counted. The pattern’s action comes from plan steps that were approved and executed, not from an agent’s narration of what it did. A proposed plan nobody approved teaches the platform nothing.

Proposals are shaped for arrival, not for later. The platform mines records whose pursuit began when they were created, and the rules it drafts run on insert. That is why a proposal can safely claim the answer was knowable up front. Patterns that only become visible after a record has been worked are not proposed yet.

Every rule carries a guard. A drafted field-setting rule only fires when the target field is empty, so activating one never overwrites a value a person or a Decision already chose.

Thresholds are tenant settings. By default a pattern needs five supporting cases and 90% agreement. Lower promotion.min_support if you want to see thinner patterns, and raise it if the list is noisy.

An empty list is the normal state early on. Mining needs resolved pursuits, so a tenant whose agents have not yet carried records to resolution will see nothing here for a while.

How it connects

A rule proposal is not a rule. It is a draft plus the evidence for it; the thing it creates and the thing you activate is an ordinary Business Rule, managed and edited in the usual place.

It is also not a Plan. A plan is an agent’s proposed change to one record, approved by whoever owns that record. A proposal is a change to how the platform behaves for every future record, approved by whoever owns its rules.

Both sources of proposals keep working as they always did: Agents pursuing records, and Judgments answering single questions. Rule proposals are what the platform learns from watching them.

Now do it

  • Review a waiting proposal at Automate → Rule Proposals, read its evidence, and activate it.
  • Compare the activated rule against its neighbours at Automate → Business Rules.

Exact shapes