> ## 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 set up Synscribe for compliance and quality control

> Where compliance and quality actually get controlled in Synscribe — five layers, from what Pi knows about you to the gate at publish, set up in order.

Compliance and quality in Synscribe are controlled across five layers, each one reducing what the next
has to catch. Set them up in order: your org info and Product Bible ground what Pi knows about you,
your pillar prompts constrain what it writes, refiners auto-fix drafts, and the guardrail catches
anything that still slips through at publish. Get the upstream layers right and little reaches that
final check.

## 1. Org info: tell Synscribe who you are

Your [Organization Information](https://www.synscribe.com/app/settings/organization-information) is the
top-level context every part of Synscribe reads: what you do, what you sell, and your regulatory
posture. Make it accurate and specific. For a regulated business, spell out what you are and aren't
(for example, "a licensed payments institution, not a bank or lender"). This shapes how Pi writes and
gives the guardrail the context to judge claims correctly.

## 2. Product Bible: bound your claims

The [Product Bible](/platform/company-research-product-bible) is Pi's source of truth about your
company, kept in [its memory](/platform/filing-in-the-vfs). Its Impact Claims section carries the rule
*"every number needs a source; never invent metrics,"* and you flag up front what must **not** be
claimed: specific metrics, customer names, positioning, or regulatory language that's off-limits. That
list becomes the input to every layer below.

## 3. Landing-page pillar prompt: constrain what gets written

Bake non-hallucination hard rules into your [pillar prompts](https://www.synscribe.com/app/landing-page-pillars):
*do not invent metrics, certifications, customer names, or capabilities.* When you
[set up a pillar](/platform/design-landing-page-pillar), Pi asks up front what must not be claimed and
writes those constraints into the prompt, so generation never produces the forbidden claim to begin
with.

## 4. Refiners: auto-fix drafts before they're judged

[Refiners](/platform/set-up-refiners) rewrite each draft to match your brand and compliance rules, at
generation or [on demand](/platform/set-up-refiners), so most issues are fixed before the guardrail ever
sees the draft. Refiners run *before* the guardrail (see [refiner vs guardrail](/platform/refiner-vs-evaluator)).

## 5. Evals: gate what's left

The [compliance guardrail](/platform/automate-compliance-checks) is the backstop. At publish it judges
the finished piece and blocks anything that still breaches a rule. Write its rules to encode exactly
what your business can't say, each with a carve-out so it doesn't over-flag, then
[calibrate it](/platform/calibrate-evaluator) on copy you know should pass and should fail.

## A worked example: a regulated fintech

Take a fictional licensed fintech that issues a regulated digital-payment token. Its guardrail rules
might read:

| Rule                      | Flag                                               | Carve-out (do NOT flag)                                                            |
| ------------------------- | -------------------------------------------------- | ---------------------------------------------------------------------------------- |
| No guaranteed returns     | Any promise of yield, returns, or profit           | Factual statements about how the product works (e.g. that a balance is redeemable) |
| No regulator endorsement  | Implying a regulator endorses or backs the product | Factual, accurate statements of the licenses actually held                         |
| No absolute safety claims | "100% safe", "risk-free", "can't lose"             | Qualified statements tied to real reserves or audits with a source                 |

Each rule pairs a sharp "flag" with a specific carve-out, so the judge blocks the marketing overreach
without tripping on the accurate, licensed facts the company is allowed to state. You don't have to
write these by hand: hand Pi your requirements and it drafts the policy.

```text theme={null}
my company is a licensed fintech. set up our compliance policy: no guaranteed returns, no regulator
endorsement, no absolute safety claims — each with a carve-out for the accurate factual version. then
turn it on for landing pages and blog.
```

<Frame caption="Pi built the context and a full rule set for a licensed payments company from its compliance requirements.">
  <img src="https://mintcdn.com/synscribe/nrc8GKkJ73Gh9UPN/images/platform/pi-guardrail-rules-created.png?fit=max&auto=format&n=nrc8GKkJ73Gh9UPN&q=85&s=369247c9fbfb7b226152d05ba48f1d41" alt="Pi's guardrail result for a MAS-licensed payment institution: a policy context and a table of rules with what each one catches." width="1930" height="1244" data-path="images/platform/pi-guardrail-rules-created.png" />
</Frame>

**Related:** [Automate compliance checks](/platform/automate-compliance-checks) · [Set up the compliance guardrail](/platform/set-up-evaluator) · [Calibrate the guardrail](/platform/calibrate-evaluator) · [Refiner vs guardrail](/platform/refiner-vs-evaluator) · [Build a Product Bible](/platform/company-research-product-bible)
