Learn and improve

The platform finds the problem. You decide what to do about it.

Proposals are generated with evidence, classified by confidence level, and staged for human review. The AI never changes a campaign autonomously. Every proposal requires explicit approval before anything changes.

4 classesDescriptive, Directional, Statistically Supported, Human Judgment
PENDINGall proposals created with this status — never auto-applied
0 auto-changesapproval is the only action that updates campaign configuration
Linkedevery approved proposal creates a versioned record with proposal origin
How proposals work

Evidence classified. Proposal written. Human decides.

The pattern detector classifies every finding by evidence strength before writing a proposal. A Descriptive finding notes an observation. A Statistically Supported finding comes with a metric and a sample. The AI never overstates its confidence — and neither does the proposal.

  • Descriptive — observational finding, limited sample, no causal claim
  • Directional — correlation observed across a growing sample
  • Statistically Supported — consistent signal, sufficient sample, metric projection included
  • Human Judgment — pattern identified but not quantifiable, routed for expert review
  • Proposals created with status PENDING — never applied without explicit approval
  • Rejection notes stored permanently — accessible to Friyay operators across all clients
Proposal lifecycle
  1. 1
    Pattern detected
    Drop-off, tone signal, or conversion driver identified
  2. 2
    Evidence classified
    Descriptive / Directional / Statistically Supported
  3. 3
    Proposal written
    Specific change proposed with before/after projection
  4. 4
    Created PENDING
    Config unchanged — proposal staged for review
  5. 5
    Human reviews
    Approve or reject with notes
  6. 6
    Approved
    New campaign version created — revertable
The review interface

Everything you need to decide. Nothing you don't.

The proposal review interface gives operators the information they need to make an informed decision — without requiring them to understand the underlying data model.

Evidence class badge

Each proposal displays an evidence class badge — Descriptive, Directional, Statistically Supported, or Human Judgment — so reviewers understand the confidence level before reading the detail. Low-confidence proposals are never dressed up as certain.

How it works: Evidence class badge tested in the proposal detail view — badge visible and explained, including disclaimer for metric projections on low-confidence proposals.

Readable diff

The proposal shows exactly what change is being proposed — not a summary, a readable diff. If the proposal is to change a question from one phrasing to another, both phrasings are shown side by side.

How it works: Readable diff is the primary output of the PROMPT_CHANGE and QUESTION_CHANGE proposal types — always visible in the proposal detail view.

Approve with version creation

Approving a proposal creates a new campaign version immediately. All new conversations run under the new version. The proposal is marked APPLIED and linked to the resulting version — the full chain from evidence to version is always traceable.

How it works: resulting_version_id is recorded on the proposal row on approval — navigate from any version back to the proposal that created it.

Reject with notes

Rejecting a proposal records the reviewer's notes and sets status to REJECTED. Campaign configuration is unchanged. Friyay operators can see rejection reasons across all clients — helping identify systemic proposal quality issues.

How it works: Rejection notes persisted and visible to Friyay operators in the proposal list — not restricted to the reviewing client.

Want to see a real proposal
with evidence and diff?

We'll run the learning engine against a live campaign and show you what it surfaces.