URL-grounded policies

Most policies come from a document you upload or text you paste. A URL-grounded policy starts from a link — an internal handbook, a wiki page, a public terms page — and InPolicy keeps a durable connection to it. That connection is what powers three things a static file can’t give you:

Citations. When the browser extension or the editor’s Check policy panel flags a violation, it can point to the exact sentence on the source page the text contradicts.
Freshness. InPolicy can re-read the source on a schedule (or on demand) and update what it enforces when the page changes.
Provenance. Every policy shows where it came from, with a link back to the original and the passage it was derived from.

When to use a URL

A URL source and a file source produce the same kind of policy. Reach for a URL when the source lives on the web and is likely to change.

Source	Best for	Stays current?	Cites the source?
URL	Handbooks, wikis, terms pages — anything hosted on the web	Yes — watch daily, or re-scan on demand	Yes — links back to the live page and passage
File upload	A fixed PDF or DOCX you own	No — re-upload to refresh	Shows the filename only (no public link)
Pasted text	A quick snippet with no canonical home	No	No source shown

Create a policy from a URL

Everything starts in the Policy Inbox — the staging area where imported sources become reviewable suggestions.

From the Inbox, click Import source.
In the import dialog, choose the From URL tab.
Paste the link — e.g. https://internal.acme.com/security-handbook.
Optionally tick Watch this source. When on, InPolicy re-scans the page about every 24 hours (and when you next open the editor), surfacing new suggestions as the source evolves. You can change this later.
Click Import & parse.

Parsing runs in the background — typically 10–30 seconds for a single page. You don’t wait on it: the dialog closes, you land in the Inbox, and PolicyBot’s suggestions appear there when ready. The import card shows Parsing · started … while it works, then a count like 3 pending suggestions when it’s done.

Imported suggestions behave like any AI suggestion: review them, edit if needed, and publish. See The Policy Inbox for the review flow and Policy lifecycle for how a suggestion becomes a published, enforced policy.

What grounding gives you

The source document and source paragraph

Open a URL-grounded policy and, alongside its settings, you’ll see where it came from:

A provenance chip near the title — “Suggested from internal.acme.com · imported 3 days ago” — that jumps back to the source in the Inbox.
The source document — the page’s hostname, an Open ↗ link to the original, and the import date. Use it to sanity-check that the policy still reflects what’s live.
The source paragraph — a blockquote of the exact sentence PolicyBot read when it distilled this rule. For example:

Employees must not use personal email accounts to send or receive work documents.

The source paragraph only appears when PolicyBot can point to a single representative sentence, and the quote is verified to be an exact substring of the page before it’s stored. If the model paraphrases instead of quoting, InPolicy stores nothing rather than show a misleading snippet. (See Create and edit policies for the same fields on every policy.)

Violations that cite their source

Grounding pays off at detection time. When a URL-grounded policy flags a conflict, the violation card carries a Policy basis block: the verbatim rule text, a View policy link, and — for URL-grounded rules — a Source document link straight to the page the rule came from. That turns “this looks like a violation” into “this contradicts your published refund policy, and here’s the exact line.”

You can trust the citation because of how the source is stored. Each page is distilled into reference facts — small, single-claim statements, each tied to a verbatim snippet from the page. A fact is only kept if its snippet is found character-for-character on the page, and a violation can only cite a fact when it carries the fact, its text, and its URL together. A citation therefore always points at real page text — it can’t be half-formed or invented.

The grounding status panel

When you publish a policy whose text contains a link, InPolicy grounds it against that source in the background and shows a status panel instead of returning you straight to the list. It refreshes every few seconds and settles into one of these states:

State	What it means
Queued for grounding	Publish succeeded; grounding is lined up to start.
Grounding N of M sources…	Reading and distilling the source pages right now.
Grounded from N sources	Done — the policy is enforced and its facts are searchable.
Grounding failed for N of M	Some sources couldn’t be read after automatic retries. A Retry button appears to re-run just those.
No external sources to ground	The policy has no reachable link to ground against — nothing to do.

Publishing never waits on grounding. The policy is live the moment you publish; grounding enriches detection as it completes. You can leave with Go to policies at any time — grounding keeps running.

You don’t have to stay on the publish page to see it. The same status also appears on the policy’s detail and edit pages while grounding is running, stalled, or has failed — including the Retry button — so you can come back to a policy later and still see (and fix) its grounding. Once grounding completes, the row disappears from those pages; a grounded policy just works.

Keeping a source current

A URL policy is only as good as the page behind it. Two controls, both on the source’s card in the Inbox, keep it fresh:

Watch daily / Stop watching — toggles the ~24-hour automatic re-scan. Watched sources show a watching daily pill and a last scanned … timestamp.
Rescan now — re-reads the source immediately.

A re-scan reads the live page again and reconciles what changed, without discarding the connections you’ve built:

Facts that still hold are kept, with their identity intact — so existing citations don’t break.
Facts whose text has vanished from the page are retired (superseded): they stop influencing detection but stay in the record for audit.
Genuinely new facts are added.
Unchanged pages are skipped — if nothing changed, InPolicy doesn’t waste a re-read.

If you’re pointing PolicyBot at a URL, turning on Watch daily is usually the right call: the whole point of a URL source is that it tracks a moving target.

What actually gets read

How much of a site InPolicy reads depends on how the source was added:

A link inside a policy you publish → just that one page is read.
A source added as a reference document → InPolicy expands it into a small same-domain crawl, following the site’s sitemap.xml to find related pages and reading the most relevant ones first.

The crawl is bounded so it stays fast and predictable. Rather than a fixed page count, it works to a small per-crawl budget and stops early if it hits a run of empty or value-less pages. In practice a handful of the most relevant pages get grounded, not an entire website.

Multi-page reading relies on the site publishing a sitemap.xml. A page with no sitemap — common on single-page legal pages and some JavaScript-heavy sites — grounds only the page you gave, and that’s expected rather than a failure. Wider discovery for section-scoped help sites is on the way; see Availability below.

Safety and limits

Internal addresses are blocked. InPolicy refuses to fetch URLs that resolve to private, internal, or cloud-metadata addresses. You can’t point the crawler at infrastructure that isn’t meant to be public.
Page size is capped. Each fetch is limited to a few megabytes so an oversized page can’t stall grounding.
Grounding is background work. Publishing, editing, and re-scanning never block on it. If a source can’t be read even after automatic retries, it settles into a failed state you can retry — the policy stays published and enforced throughout.
Login-walled pages don’t work. InPolicy reads a page the way an anonymous visitor would. If the content sits behind a login, prefer a file upload or pasted text for that source.

Gotchas

Grounding needs a real link in the text. The status panel only appears when the published policy actually contains an http(s):// URL. A policy that merely mentions a site by name won’t ground against it.
One link grounds one page. If you expected several pages to be read, add the source as a reference document rather than pasting a single link into the policy body.
Watch is per-source, not global. Turning on Watch daily affects only that one imported source.
Retired facts don’t erase history. When a fact is superseded on re-scan it stops enforcing but is retained — so an audit can always see what a policy claimed at a point in time.

Who can do what

Action	Admin	Policy Lead	Policy Editor	Viewer
Import a URL / add a source	✓	✓	✓	—
Watch or re-scan a source	✓	✓	✓	—
Publish (triggers grounding)	✓	✓	—	—
Retry grounding	✓	✓	✓	—
See cited violations	✓	✓	✓	✓

See the Roles & permissions matrix for the full picture.

Availability

URL grounding ships in layers. Here’s what’s live today versus rolling out, so nothing on this page catches you off guard.

Capability	Status
Import from a URL, Watch daily, Rescan now	Live
Provenance chip and source paragraph on the policy	Live
Same-domain sitemap crawl for reference documents	Rolling out
Fact-level reconcile on re-scan (keep / retire / add)	Live
Grounding status panel on the publish, detail, and edit pages, with Retry	Rolling out
Source-document readout and the extracted-text viewer	Rolling out
Source document link on violation cards	Rolling out
Wider sitemap discovery (sitemap index and section sitemaps)	Rolling out
`llms.txt` site discovery	Planned

The Policy Inbox — where imported sources become suggestions
Create and edit policies — the editor, source document, and source paragraph fields
Policy lifecycle — how a suggestion becomes a published, enforced policy
What the extension detects — where cited violations reach end users