Rule builder

Compose a rule change, dry-run it, and submit it for approval

Author a new functionOpen the assist conversationPOC

Every value below comes from the deployed rules registry.

1. Author the rule

In progressNo step chosen yet.
The rule and its steps

Each step calls one deployed function. Step 1 pipes into step 2.

Step 1

Function

Reading the registry…

Is the transform you need missing from this list?
Author a new function

A function you author there becomes selectable here only after a different person merges it and the pipeline deploys it in this environment.

The same for every column you bind below, so it is not asked for here.

The value of whichever column this rule is bound to

The target column's datatype is the last step's declared return type. There is no datatype control in this builder.

More about the datatype

The registry's FUNCTION_OUTPUT_TYPE says SCALAR for every deployed function. That is scalar-versus-table, not a datatype.

The registry read does not carry a deployed function's return type, so this builder cannot name the datatype for one. It is not guessed at. A function you author here shows its return type on that surface.

Upper case, digits and underscores, at least three characters. Unique among live rules.

Reuse and the rule name

Checked against the deployed catalog as you compose the steps. Advice only — it blocks nothing.

No catalog answer for these steps yet

Every step needs a function before the catalog can be asked. Nothing has been read, and nothing is claimed either way. You do not have to name the rule first.

Note for the approver — optional, empty

Carried into the approval record. No patient data.

2. Bind it to columns

Not startedNo column bound yet.
What the rule applies to

Silver is format alignment. Outcomes is outcome generation. It applies to every binding below: one change is reviewed by one population.

Where the rule applies

One rule, one or many columns. Each column keeps its own argument values.

1 binding. This change applies the rule to one column.

Binding 1

Source system

Reading the registry…

Medallion move

Reading the registry…

Source column

Select a move first; the column lists come from it.

Derived from the source column as <name>_XFR. The original column is left as it arrived.

Select a source column above and the target column follows from it.
Argument values for binding 1 — none set

These belong to this column alone. Two columns bound to one rule may take different values, and that is what the values are for.

No argument values are set.

A change needs at least one binding, so the last one cannot be removed.

Each column you add is part of the same change and the same approval. It is not a second submission.

3. Check its impact

Not startedNothing to check until at least one column is bound.

Dry-run

Reads aggregates only. Writes nothing.

The form does not yet express a proposal, so there is nothing to dry-run.

Sample preview

Per column: the value going in, and the value coming out.

Optional for this rule. Submitting waits on coverage.

The form does not yet express a proposal, so there is nothing to preview.

4. Submit it

Not startedNothing to submit until the rule is authored and bound.

Records this configuration as a change awaiting approval. It writes nothing to Snowflake.

Submitting is blocked: the form does not yet express a proposal.

Approval

What approving does, and what it does not do

This commits one file — the change's configuration as an environment-neutral artifact, carrying no surrogate ids and no database names — on a new branch, and opens one pull request against the rules-engine repository. One pull request per unit of approved work: the optional new rule and every one of its column bindings, together.

It writes nothing to Snowflake. The studio's credential is read-only on every environment, so a write would be refused by the database rather than withheld by this screen. It runs no transformation, rebuilds no data, merges nothing, promotes nothing and deploys nothing.

Someone other than the author still has to merge it. That merge is the human gate, enforced by the rules-engine repository's own branch protection — its default branch requires an approving review, and GitHub does not let a pull request's author approve their own — so no defect in this studio can bypass it.

A merged pull request is not a deployed rule. The rules-engine deploy pipeline applies the merged artifact per environment, and today only main → poc is wired: INT, QA, STG and PRD are the agreed design, not the running system. Where this rule has actually reached is what the environment view reports, from GitHub's own deployment records.

Nothing is overwritten and nothing is physically deleted. The artifact proposes a new effective-dated version, and a deletion is a logical-delete flag — the pipeline applies it as a superseding version if and when the pull request is merged.

There is no merge, promote, deploy or apply action on this screen, and none is shown greyed out. The studio holds no permission to merge and must not imply that it does.

There is nothing to approve yet. A change can be approved only after it has been submitted.