Flows

Drafts and published versions

A Flow has two states at once, and keeping them apart is what makes Ray9 reproducible.

The draft is yours to break. Change fields, add a navigation step, tighten a validation rule, test it as often as you like — nothing that is scheduled or running is affected.

A published version is immutable. It cannot be edited, only superseded. Every run points at an exact version, so any record in your dataset can be traced back to the precise definition that produced it, however long ago that was.

The lifecycle is deliberately small:

draft → test → publish → version 1
                 ↑            ↓
              (edit) ←── run / schedule

Editing a published Flow creates or resumes a draft. It never mutates a version that already exists. Publishing requires a short change note, and shows you which schedules are currently pinned to the older version.

Promotion and rollback

Schedules pin a version on purpose. When you publish a new one, promotion is an explicit choice:

• promote immediately,
• promote at the next scheduled run,
• or keep the current version and leave the schedule alone.

Rollback repoints a schedule at an earlier version. It does not rewrite history: the runs that already happened still record the version that actually produced them.

The builder

The builder is evidence-led. It does not ask you to trust an extraction you have not seen.

Ray9 acquires a test page, then shows the proposed records beside the captured page, with every field highlighted against the region it came from. Each field has a name, a type, a required or optional flag, and an example value. Fields Ray9 is unsure about — inconsistent across items, ambiguous in context — are marked for review rather than quietly guessed.

You correct it visually:

• Define the repeated record container first. Ray9 has to agree with you about what one record is before individual fields mean anything.
• Click a value on the page to map it to a field. Rename, retype, mark required, delete.
• Add validation — types, required fields, ranges, patterns, expected record counts, duplicate rules.
• Add pagination, scrolling, clicks, waits, and navigation once a single page validates. Getting page one right first is faster than debugging twenty at once.

Deterministic selectors and transformations are available if you want them, under advanced sections. They are never required.

A test run is visually distinct from a production run and uses a separate test budget. Because the capture is retained, repairing a field mapping and re-testing usually does not require fetching the page again.

Templates

Templates are maintained starters for jobs people do repeatedly: a product page, a paginated directory, article extraction, change monitoring.

The catalog is searchable and filterable by outcome, source, data type, and maintenance status. A template's detail page shows example output, the maintained version, the inputs it needs, the credits a run is expected to cost, its known limitations, and how reliable it has been recently.

Forking a template creates an ordinary Flow owned by your organization. It does not silently track upstream template code — that would mean a change you never reviewed could alter tomorrow's data. When the maintained template improves, Ray9 notifies you and offers an explicit, reviewable upgrade.

From that point on, a forked template is just a Flow: you edit it, publish versions of it, schedule it, and roll it back like any other.

Ad hoc runs and Save as Flow

Not everything needs to be a Flow on day one.

A quick scrape takes a URL, a choice of outputs — cleaned markdown, text, retained HTML, a screenshot, structured records — and runs. No builder, no schema step, no publishing. You get an estimated credit range first, and a result.

An ad hoc run is still a real run. It carries an immutable definition snapshot, it is subject to the same policy evaluation, it reserves and accounts credits the same way, it keeps the same evidence, and it produces the same kind of output. The only thing it lacks is a Flow around it.

When the result is what you wanted, Save as Flow promotes it: the snapshot becomes a draft you can publish, schedule, give a monitoring policy, or open in the full builder. You do not rebuild it from scratch.

Autosave and recovery

Builder work autosaves as you go. Leaving the page, navigating away, or closing the tab does not cost you the draft — a long AI-assisted session is exactly where losing state would hurt most, so drafts keep a recoverable edit history.

Because the draft is separate from the published version, this is safe by construction: an autosaved half-finished change cannot leak into a scheduled production run. It sits in the draft until you deliberately publish it.