> ## Documentation Index
> Fetch the complete documentation index at: https://docs.synscribe.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How to run compliance edits across landing pages (LP refiners)

> Apply reusable, schema-safe edits across many landing pages at once — compliance fixes included — and revert them safely.

Run compliance edits across landing pages with LP refiners — reusable rulebooks applied as safe edits
over many pages at once (`/app/landing-page-refiners`, or Pi's `landing-page-refiner-management`).
They make a consistent change — positioning, compliance wording — across a pillar without hand-editing
each page and **without breaking the page's data structure**: edits touch text inside existing fields
only, and every applied edit can be reverted. This is the landing-page counterpart to blog
[refiners](/platform/set-up-refiners), and it's a *fix*, not the gate — see
[Refiner vs guardrail](/platform/refiner-vs-evaluator).

## What they're for

* Alignment: enforce consistent positioning and messaging across a pillar.
* Compliance: apply your must/must-not language as precise edits (e.g. remove a claim you
  can't make), so pages stay compliant at scale.

## Run them with Pi

Use the `landing-page-refiner-management` / `landing_page_refine` tooling:

```text theme={null}
apply the [refiner] to the [pillar] landing pages — make the edit precisely without
changing the page data/schema, and show me the diff before applying across all pages.
```

The edits are schema-safe: they change the content, not the page's underlying data shape, so a
compliance fix won't wipe a page's structured fields.

## Why it's safe to run at scale

Three guarantees make a bulk edit across a whole pillar safe:

* The edits are schema-safe: the refiner proposes targeted `search`/`replace` edits over the *text
  inside existing fields* and can't add, remove, reorder, or restructure fields. After applying, the
  page data is re-validated against the pillar schema, and the result is only written if it still
  validates. A compliance edit therefore can't corrupt a page's structured data (the old data-wipe
  failure mode this design fixes).
* Reverts are concurrency-safe: every applied edit is recorded with a before/after snapshot and hash.
  Reverting does an optimistic version check, so if the page has been edited again since the refiner ran
  (its current hash no longer matches the refiner's after-hash), the revert is refused rather than
  silently discarding the newer edits. It also won't double-revert the same edit.
* You diff before you apply: review the proposed change on a page before applying it across the pillar,
  so a bad rule is caught on one page, not fanned out to hundreds.

## Relationship to the guardrail

Refiners fix content; the compliance guardrail is the gate that blocks non-compliant
content at publish. Guardrail violations come with a suggested fix that feeds one-click refiner
remediation, so the two work together: the gate catches it, the refiner fixes it. See
[Refiner vs guardrail](/platform/refiner-vs-evaluator) and
[Use the guardrail at publish](/platform/automate-compliance-checks).

**Related:** [2.3.3 Align a pillar prompt](/platform/align-pillar-prompt) · [Blog refiners](/platform/set-up-refiners) · [Refiner vs guardrail](/platform/refiner-vs-evaluator)