Claude, ChatGPT or Gemini · Practical walkthrough

Turn an approved procedure into a searchable mini-site

Nobody can find the contractor rule in the long access procedure, so someone asks AI to make it searchable. The search box arrives, and so does a friendly summary saying complete requests are approved, which the procedure never said.

Task by Task7 min read + practice

Example output

A searchable procedure page

Fictional finance-drive access procedure, version 3: every section keeps its source wording.

Local reference example

Source entries · read-only preview

Who can request

Any employee may request access. Name your line manager.

Contractors

Contractors also need a finance sponsor and an end date. Access ends on that date.

Decision

The finance lead decides. A complete request can still be refused.

Read the prompt

Build a small local searchable site from this supplied procedure.
Preserve authoritative wording, section IDs, exact thresholds and
exceptions. Add navigation and readable layout without changing policy.
If a summary is useful, label it as a companion and link its claims to
source sections. Keep source version/date visible. No accounts, tracking,
external calls or publication. Provide runnable files and search cases
that check ordinary words, exceptions and exact boundary terms.

What you'll make

a single HTML page you open in your browser, with a search box and section links, showing the procedure’s own wording, version and date unchanged.

What you'll need

the current version of the procedure (or glossary) and its version date, and an AI chat that can build and preview a web page: Claude (the page appears as an artifact you can download), ChatGPT (canvas, or ask for an HTML file to download) or Gemini (Canvas in the prompt bar). Use your work account, and keep the procedure where its usual audience can see it; a local file isn’t permission to publish. Allow about 20 minutes.

Paste the procedure into the chat and ask for a page that changes how it’s found, not what it says:

Build one HTML file I can open in a browser from this procedure:
[procedure text]. Keep every section's wording, number, threshold and
exception exactly as written, with its section ID. Add a search box,
a list of section links and the version and date at the top. Don't add
a summary. Make search match words inside each section as well as
headings. No accounts, tracking or outside links.

[procedure text] is the whole approved procedure, pasted with its version line.

Why this works: the builder’s natural instinct is to tidy. Saying “no summary” and “exactly as written” keeps it on layout, where it’s useful, and away from the rules.

What you should see: a preview or download of one page with a search box, section links and your version date. In Claude or ChatGPT, download the file and double-click it to open it in your browser.

2. Search for the rules that are easiest to break

Open the page and search for the parts most likely to go wrong: an exception, a number and a “no”. In the example below, that’s “contractor”, “90” and “refuse”. Open each result and read it against the source section. A matching keyword doesn’t prove the surrounding rule survived.

Then ask the AI to compare the text, word for word:

Compare every section in the HTML file with the procedure I gave you.
List any changed word, number or punctuation mark, any missing section
and any heading or snippet that makes a rule stronger or weaker than the
source. Then list the searches you tested and what each one found.

Why this works: a model can say it preserved the wording while a qualification went missing during layout. A word-for-word comparison makes it look, and your own searches check what a reader will meet.

What you should see: “no changes” or a short list of differences, plus the search results matching what you found yourself.

3. Keep the version visible

Put the procedure’s version and date at the top of the page and in the file name, such as finance-drive-access-v3-2026-09.html. When the procedure changes, rebuild the page from the new version rather than patching the old one. A polished old page can mislead more than a visibly dated document.

Why this works: readers trust whatever is easiest to find. A version line tells them whether the easy copy is the current one.

What you should see: the version and date on screen and in the file name.

Check the result

Every section matches the source word for word, including numbers and exceptions.
Searching for each exception and number finds the full section, not a shortened snippet.
Nothing on the page says a request is approved where the source says it can be reviewed or refused.
The version and date are visible at the top.

The usual failure: the builder adds a helpful summary or snippet that quietly changes a rule. “Eligible for review” becomes “approved”, or an exception disappears from the short version. Spot it by searching for the exception: if the snippet reads differently from the section, the page has rewritten the procedure.

The page changed section [ID] from "[source wording]" to "[page wording]".
Restore the source wording everywhere it appears, including snippets
and headings. Keep every other section as it is. Then repeat the
word-for-word comparison and the searches for exceptions and numbers.

Worked example: access to the shared finance drive

Fictional example. An operations team turned its access procedure into a searchable page for new starters.

Finance drive access, version 3, September 2026
A1 Any employee may request access. Name your line manager.
A2 Contractors also need a finance sponsor and an end date. Access ends on that date.
A3 The finance lead decides. A complete request can still be refused.
A4 Access is reviewed every 90 days.

The first page looked tidy and searched well, but it opened with a box the prompt hadn’t asked for:

Weak: “Quick answer: complete your request and you’ll get access to the finance drive.”

Two rules disappeared. The quick answer turned A3’s “can still be refused” into a promise and left out A2’s contractor end date. Searching “contractor” found A2 in full, but the box above it said otherwise.
The comparison caught it. The step 2 prompt listed the quick-answer box as text with no source section.
The repair removed the box. The repair prompt, filled in with “A3”, the source sentence and the quick answer’s wording, restored the exact rules. Searching “refuse” and “90” then found A3 and A4 with their wording intact.

Task kit for this job: Download (ZIP) · Reusable instructions

Go deeper

Make a glossary searchable without changing definitions

The same method works for a team glossary. Give each term an ID, its exact definition and a source link, and put synonyms in a separate field. Verbatim doesn’t mean “roughly the same meaning”: if a glossary defines “context” as the information the model has for the current response, a friendly rewrite that says “everything in your company” has changed its scope. If the search misses a term, fix the search, for example by adding a synonym. If a definition itself is wrong, take it to whoever owns the glossary rather than asking the page builder to improve it.

Check keyboard use and headings

Try the page with the keyboard only: can you reach the search box, move through the results and open a section, with a visible focus outline? Check that sections use real headings, so screen readers can jump between them. The accessibility review guide shows how to ask for checks tied to the page itself.

Keep access and publication separate

A file on your laptop is not a published page. If the procedure is internal, share the HTML file the way you’d share the document, or ask your intranet owner how to host it. Keep private procedures out of public practice examples and shared AI chats.