Country packages

A package is a country’s official collection: publications, agreements, and legal references brought in as a release. You bring the release in yourself with the Add a country package wizard, then work the board so every item is found, checked, or honestly marked missing.

The packages list

Packages shows imported releases and the intakes still in progress. Filter by country. Open a row to reach the coverage board, or resume an intake where you left it. From the list you can also open the Source router, Registry exports, and Registry watch. The platform assistant can suggest the next step and answer questions about these screens. A count on Sources means it has a suggestion you have not opened. Suggestion cues explains the count.

Add a country package

The wizard takes a release from spreadsheets to documents in the knowledge base in eight steps. Each step has one main action and tells you what happens next. You can leave and come back; the wizard resumes where you were.

1. Package input — drop the sheets as CSV or XLSX files (one workbook with a tab per sheet works), a ZIP, or links; or pick a release already in the repository. Enter the country and the release date.
2. Analysis — the wizard says which sheet each file is, then shows five charts: legal instruments, agreement events, event type, pointer class, and ingestion. It also lists the websites and what needs fixing. If it cannot place a file, pick the sheet yourself.
3. Country setup — only when the country has no profile yet. The wizard infers the territory levels, the language, the register and the websites from the package and asks you to confirm a few values. Download the profile for the country folder when you are done.
4. Import and plan — preview, then write the release and plan every source. A release imported before is linked, never duplicated. If the platform does not know the country or a language yet, a platform admin must add it first; the wizard names exactly what.
5. Set up hosts — the wizard works out how each gazette website lists its documents from the package’s own links and the site’s front page, tests it once, and marks sites it cannot read for manual download or for a developer (with the pages it saw).
6. Sample — fetch five documents per website, review the finds, and decide per website whether its confirmed finds can be accepted without review.
7. Acquire — fetch everything still planned. Sites are visited politely, one request at a time; unreachable sites are retried overnight.
8. Review and deliver — decide the flagged finds on the Review queue, then approve the current-text drafts in the Watch inbox. Run Verify, and watch the charts fill in (how to read them). The run is delivered when every current source is settled.

Blockers are shown with their fix. A yellow one needs the platform team; a red one is something you can change — another file, a sheet choice, an answer.

Reading the charts

The charts are the coverage picture for one country release. You see them when the wizard analyses the files, on Review and deliver, and at the top of the coverage board. Each chart answers one question. A ring’s number in the middle is that chart’s total. Each slice is sized by its count, and the list beside the ring gives the count and its share. A slice with no rows is left off the ring.

Legal instruments

This ring counts the instruments themselves: collective agreements and statutes. An agreement is the instrument the events belong to. A statute is a legal-framework text, usually a consolidated text from the national legislation publisher. The center says “instruments.”

Events

This figure counts events of the collective agreements only. An event is one publication or registration of an agreement: the base text, a later change, a pay revision, a work calendar, and the other acts in the release. Several events belong to one agreement. Statutes have no events, so they are not in this figure. It reads as a count, for example “192 events for 10 collective agreements.”

Event type

This ring splits those agreement events by the kind of act. The center says “events.” The largest kinds are listed first.

• Base texts — the agreement text a later act amends or sits beside.
• Corrections — a correction of errors in an earlier publication.
• Modifications — a change to the agreement.
• Extensions — the agreement is prolonged.
• Salary revisions — a pay table or pay update.
• Work calendars — the working calendar for a period.
• Commission acts — a record of a joint commission.
• Partial agreements — an agreement that covers part of the instrument.
• Denunciations — notice that ends or challenges the agreement.
• Other — an act that does not fit the kinds above.

Pointer class

This ring also counts agreement events, split by how the release points at the document. The center says “events.” Statutes are not a pointer class.

• Official publications — events that already have an official publisher address. This is the list the wizard fetches.
• Registry only (no document yet) — events the country’s register knows about, with no document attached yet. They stay on the list until someone finds the official file.
• Secondary links to replace — pointers on a site other than the official publisher. An official source has to replace each one before it can count as evidence.

Ingestion

These bars count every row the pipeline acquires: the agreement events, split by pointer class, and the statutes. One row is one worklist. Its length is that worklist’s count compared with the largest worklist, so a small worklist stays a short bar even when every one of its rows is in scope. Colour inside the bar is the stage, drawn in the legend’s order. The numbers in the legend are the stage totals across every worklist. They add up to the acquirable rows, which is the agreement events plus the statutes. Before anything is fetched, every row is Waiting and the chart says nothing has been fetched yet.

• Collective agreements — official publications, registry only, and secondary links to replace. Each of these is the agreement events of that pointer class.
• Statutes — the legal-framework rows. These are current.
• Delivered to the knowledge base — green. The text is in the knowledge base and can be cited.
• In progress — blue. The row is being located, registered, or acquired, or a draft is still waiting for approval.
• Waiting — grey. Imported or planned, and waiting to be picked up.
• Needs a person — amber. Flagged for review, or held because the only link is a secondary one. Open the review queue for these.
• Kept, not ingested (history) — purple. Fetched and stored as evidence, and left out of the knowledge base. Current and history says which texts that applies to.
• Stopped — red. The fetch failed, or someone excluded the row.

Current and history

The figures on the right of each ingestion row split that worklist into current and history. Current texts are still in force. They are what the release is meant to put in the knowledge base.

Historical means the publication belongs to an earlier generation of an agreement, so Advisory must not cite it as the text in force. The file is still fetched and kept as evidence.

For each agreement, the planner finds the latest base text. A base text and anything republished or corrected within the same window (six months, unless the country profile says otherwise) count as one generation. The start of that latest generation is the cut-off. A publication dated before the cut-off is history: an older base text, or a change that belongs to that older generation.

A pay revision or a work calendar whose end date is already before the release date is history too, even when it was published with the latest base text. The country profile chooses which kinds of text expire this way. A row with no date, or an agreement with no base text, stays current. The planner does not invent a cut-off it cannot see. Statutes on the legal-framework list are all treated as current.

The history figure on a row counts every superseded row of that worklist. Purple in the legend counts the superseded rows that have already been fetched and stored. Historical rows still drawn in amber or grey are waiting for a person, or waiting to be fetched.

When the release is delivered

The run is delivered when every current source is settled and no draft is waiting for approval. A current publication or statute is settled when it is in the knowledge base or it has been stopped. A historical publication is settled when it is kept as evidence or it has been stopped. A batch that is still running keeps the release open. The banner above the charts names how many current sources, legal references, and drafts are still open.

The numbers under the charts

On Review and deliver, and on the coverage board, the row under the charts is what reached the knowledge base: documents, chunks, embedded chunks, drafts waiting for approval, and items flagged for review. A document is split into short passages, called chunks, so an answer can cite the relevant passage rather than the whole file. Embedded chunks are the passages Advisory can already search. A chunk that is not embedded yet is stored, but an answer cannot find it. A draft waiting for approval is a copy a person still has to approve in the Watch inbox before it can be cited. An item flagged for review is still waiting on the Review queue, and that draft cannot be approved until the queue decision is made.

When a host needs a developer

Most gazette websites can be read from the instruction card alone. When the wizard cannot make a site work, and the site is not a manual-download case, it marks the host Needs a developer. The fixture bundle is the page it read and one known document, so the platform team can teach the locator that site. Hand over the bundle. Every other row on the release keeps moving.

Coverage board

The coverage board is the status wall for one release: how many items exist, how they were found, and what still needs a person. The charts at the top are explained in Reading the charts. The lists under the charts are explained in Reading the count cards. Counts never change the original package files.

A yellow overdue note means a publisher or a website check is past the 90-day refresh promise. Plan a new run or run the router self-test.

Reading the count cards

Under the charts, each card is a list: a label and a count. A label with no rows is left off. The lists describe the release as it stands. Reading the charts explains the rings and the ingestion bars above them. The cards and the Ingestion chart count related things, and their totals differ for the reasons below.

Release class × state

One line is one kind of pointer crossed with one exact collection stage. Add the lines and you have every publication event. Statute rows are on the Ingestion chart, and they are left off this card.

• primary — official publications. The package named an official publisher address. This is the list the search fetches.
• registry_only — the country’s register knows the event, and the package has no document address yet.
• secondary_replacement — the only address is a site other than the official publisher. That address is never the evidence. An official source has to replace it.

The stage is the same word as on the Acquisition state card, such as planned, needs_review, or acquired. The Ingestion chart draws these three kinds as bars, then adds the statutes. Colour on that chart folds several stages into one: needs_review and secondary_hold are both Needs a person, and imported and planned are both Waiting. This card keeps those stages on separate lines. The chart also prints current and history beside each bar. A historical row that is still planned or needs_review stays on that line here, and it stays grey or amber on the chart. Purple on the chart is only acquired_not_ingested. Current and history says which texts count as history.

Acquisition state

Every publication event once, by the stage it is in now. The lines add up to the same total as Release class × state.

• imported — in the release, and not planned yet.
• planned — planned, and the search has not run.
• locating — a run owns the event now.
• located — a document address was found.
• registered — a watched source exists for that address.
• acquired — the file and a draft exist.
• ingested — the text is in the knowledge base and can be cited.
• needs_review — the search flagged the event. The reason is on the Review flags card.
• secondary_hold — a secondary link, and no official replacement was found. These rows have no review reason.
• acquired_not_ingested — fetched and kept as evidence, and left out of the knowledge base. This is how historical texts are stored.
• failed — the fetch failed.
• excluded — someone stopped the row.

The Ingestion legend folds these stages into six colours and includes statutes. Needs a person on that legend counts needs_review, secondary_hold, and any statute waiting on a person. This card lists those stages separately and leaves the statutes out.

Location outcome

What the search concluded. The card lists events the search has finished. Acquisition state also counts events still imported, planned, or being located, so this total is smaller.

• document_pdf — a PDF was fetched and it passed the identity checks.
• document_html — the official text is a web page.
• not_found_anywhere — the sources that apply were tried, and the text was not there.
• unreachable_exhausted — the site and its alternatives never answered. The text may still exist.
• mismatch — a file was fetched, and it is a different announcement.
• landing, not_found, unreachable, blocked, and too_large — a single fetch result that stopped the search.

Verification

Whether the stored file is the event the package describes. Choose Verify on the board to score the files already saved. Verify does not fetch again. Only scored events are listed, so this total grows when you run Verify and can differ from Location outcome until then.

• confirmed — the file is this row.
• conflicting_evidence — the file is a different document, or it carries an identifier the package did not name.
• needs_manual_review — the checks are only partly sure, there is no document, or the checks do not decide.

Review flags

The reason stored on each event the search flagged. An event has one reason. The words match the Reason menu in the review queue, except the card prints waf_rejected where the queue says Publisher firewall. Reasons says what to do with each one.

A decision leaves the reason on this card. The review queue is the events still waiting, so after Accept, Reject, or Confirm not found the card can show more rows than the open queue. secondary_hold rows wait in the queue when State is Secondary holds, and they have no reason, so they are on the Acquisition state card and absent here.

Loader flags

Notes the importer wrote about the package files, before any fetch. A note sits on an agreement, an event, or a statute, and this card adds the notes up. One agreement can carry several notes, so the numbers can add up to more than the number of agreements. The notes stay for the life of the release. Fetching, review, and delivery leave them as they are. They are a separate list from Review flags. A release still imports with them present. Correcting one means bringing in a new release.

Read them to see which agreements have no base text the planner can trust, and which named base the sheets contradict. An agreement with no base text stays current: the planner does not invent a cutoff it cannot see, so those events stay in the current count until each one is in the knowledge base or stopped. An agreement whose base pointer disagrees with the sheets needs a look at which text is in force before a fetched file is accepted as that text.

• no_primary_events — the agreement has no official-publication events.
• base_pointer_blank — the agreement names no base publication.
• no_base_text_event — the agreement has official-publication events, and none is the base text. Every event of that agreement stays current.
• base_pointer_not_primary — the named base is a registry-only or secondary row.
• base_pointer_not_base_text — the named base is not typed as a base text.
• base_pointer_procedure_mismatch — the named base is typed as a base text, and its procedure label matches no base-text phrase for this country.
• multiple_base_texts_in_window — two base texts sit inside the country’s window, so the planner treats them as one generation and the cutoff moves back to include both.
• base_url_differs — the agreement’s base address and the event’s address differ.
• declared_count_mismatch — a count on the agreement disagrees with the event sheets. The event sheets are what these cards count.
• registry_code_format, agreement_id_template, and scope_level_unmapped — the agreement does not match the country profile, so a register match or a territory step can miss.
• orphan_publication — the event’s agreement is missing from the agreement list.
• registry_code_mismatch — the event’s register code and the agreement’s code differ.
• relationship_type_unknown — the kind of act is not one this release recognises.
• release_class_unmapped — the package’s pointer class is not one this country maps.
• primary_without_url — an official-publication row with no address.
• url_not_http — the address is not a web address.
• registry_only_with_url — a registry-only row that does carry an address.
• source_url_not_http — a statute whose source address is not a web address.

A note about a website, or about the source catalogue, stays on the package check and is left off this card. A website the country profile does not know shows on the Hosts card with Routed set to no.

Hosts

One row per website named on an event, the busiest first. Events with no website are left off, so the Events column can add up to less than the publication total. A registry-only row with no address is a common case.

• Host — the website name.
• Events — how many events point at that website.
• Routed — yes when this country has visit instructions for the website, including when the name is another name for a site that already has instructions.
• Retrieval — how the site is read. Manual download opens the hand-fetch list for that website. A dash means the site has no instructions yet.

The line above the table says how many of those websites already have visit instructions.

Reading the cards together

• Which kind of pointer is at which exact stage — Release class × state.
• How much of the release is waiting, stored, or already citeable — Acquisition state.
• Whether the search came back with a file — Location outcome.
• Whether that file is the event the package described — Verification.
• Why a flagged find is on the list — Review flags, then the review queue for the ones still waiting.
• Which agreements have a base-text problem in the files themselves — Loader flags.
• Whether a stuck pile is one website the release does not yet know how to visit — Hosts.

A large not_found on Review flags, together with not_found_anywhere on Location outcome, means the search ran and the text was absent. A large planned on Acquisition state means the search has not run for those events. A loader note stays put either way.

Batches

A batch is one run of the same job across many rows of this package: find the official text, retry a site that did not answer, or check that a saved file still matches the publisher. The line under the title is the package’s name and its status. The form at the top plans or starts a run. The cards underneath are runs that already exist, newest first. Sites are visited one request at a time, with that site’s pause between requests, so a gazette is not hit all at once. Use Dry run before Start batch.

Kind

Kind chooses the job. Locate and fetch searches for texts that are still waiting and downloads them. With the boxes left as they open, that is events at Planned whose retry is already due. It also includes statutes in those same stages. A website marked for hand download is left off, unless you name that website or the row already has a direct file address. A website paused after a failed visit check is left off too. Those hand-download rows are collected on Manual download.

Retry unreachable takes only Planned events whose last result was unreachable and whose retry time has arrived. The States boxes and Force review states do not change that selection. A nightly run starts the same kind for events that are due.

Re-verify stored artefacts fetches files already saved from a publisher of record or a register, when that check is older than 30 days, and compares the new file with the stored one. An unchanged file is stamped as still current. A changed file is kept as history and scored again. This kind covers agreement events that already have a resolved address. It does not collect statutes. A website paused after a failed visit check is left off. A website marked for hand download is left off unless you name that website.

The other fields

A blank field means every value that kind would already select. Host, Territory, and Agreement are lists you can also type into. The list is filled from this package. A typed value is still accepted, which matters for a website that is not in the event list, such as a statute publisher or another name for the same site.

States is a set of tick boxes, and the boxes follow the kind. Leave them all off to use that kind’s default. For Locate and fetch the only box is Planned, and the default is Planned. Check Force review states and the list also offers Locating, Needs review, Failed, and Secondary hold. With Force on and nothing ticked, the run uses Planned, Needs review, Failed, and Secondary hold. Locating is included only when that box is ticked. Re-verify offers the stages that already have a stored file: Located, Registered, Acquired, Ingested, Needs review, Secondary hold, Acquired, not ingested, and Failed. Leave them off to check every stored file that is due. Retry unreachable hides the boxes and always uses Planned events whose retry is due.

Force review states does two things for Locate and fetch. It allows the review, failed, and held stages above, and it includes events that are parked until a future retry. It does not change Retry unreachable. Notify on finish sends mail when the batch completes or is cancelled. The mail names the package, the kind, and how many were found, flagged, not found, unreachable, or failed, and it links to the Review queue and to this page.

Agreements and statutes

Locate and fetch runs agreement events and statutes together. A statute is a legal-framework text, usually a consolidated text from the national legislation publisher. Retry unreachable and Re-verify stored artefacts queue agreement events only.

On Locate and fetch, Host and States narrow the statutes as well as the agreement events. Agreement, Territory, Release class, and Limit narrow agreement events and leave the matching statutes in the batch. A paused website, or one marked for hand download, is still visited for its statutes. Naming the national legislation site still collects the consolidated statutes there even when agreement fetches to that site are paused.

The Dry run event count is the agreement events. Each website’s count in the plan, and the number queued on the card, includes the statutes. When the batch finishes, the report lists each statute with its stage, how it was located, and any review flag. The manifest and the Documents ZIP cover the agreement documents. A fetched statute is registered as prepared text and then ingested, so it does not appear as a file in that ZIP.

Dry run and Start batch

Dry run builds the same plan and does not write a batch or contact any site. The plan names how many agreement events, how many websites, and a rough duration. The duration is about one and a half requests for each event, times that website’s pause, spread across the number of websites the country allows at once. Each website line gives its event count and its pause. The national publisher of record is marked first. If another batch that is still queued, running, or paused already covers some of these events, those batches are listed as conflicts.

Start batch writes the batch and queues one job per event. It is refused when nothing matches, or when a batch already in progress covers the same events. The same plan appears, titled Started, and names the new batch. While a request is in flight, both buttons wait.

The cards

Each card is one batch. The title is the kind and the state in the stored words: locate_fetch, retry_unreachable, or re_verify, then queued, running, paused, completed, or cancelled. A queued or running card offers Pause and Cancel. A paused card offers Resume and Cancel. Resume puts events that are still planned back on the queue. Cancel drops events that never ran and closes the batch with a report of the ones that did. A completed card has none of those buttons.

The progress line is finished jobs over the number queued, then the percent, then when it started. The percent can pass 100 when the same event’s job is counted again, for example after a second delivery or a resume. The percent is finished jobs divided by the number originally queued.

Each website line is that site’s finished jobs over the events planned for it, then found, flagged, and remaining. Found means the job came back with a document address. Flagged means the job set a review flag, so a person still has to decide. A row can be both found and flagged. Remaining is events on that site not yet finished. A finished card shows remaining 0 on every website.

Report, manifest, and documents

Report, Manifest, and Documents ZIP are three ways to inspect a finished batch. The report says what the run did. The manifest lists every agreement event in a spreadsheet. The ZIP is the files themselves, for reading away from the publisher. Report and Manifest appear once the batch is completed or cancelled. Documents ZIP is on every card.

Report is a written summary, built again from the rows as they stand when you download it. A review decision made after the batch finished is already in the file. Use it to decide what to do next. It names the package and the batch, the filters, how long the run took, and the counts by stage and by flag. A table for each website says how many were tried, found at the stated address, found elsewhere, not found, unreachable, mismatched, flagged, failed, or held. It lists websites that need attention: paused, waiting out a run of failures, limited to some countries, or not yet known how to visit. It lists the ten finds with the lowest match scores, so a person can check those first, and it lists the statutes in the batch. A clean website table means the run is done. A flagged or unreachable website means open the Review queue, fix that website on the Source router, or start a Retry unreachable batch.

Manifest is the same agreement events as a CSV, one row per publication. Use it to filter, join, or hand the list to someone else. Each row ties the publication and the agreement to the website, the address the package stated, the address that was resolved, how it was found, the search step, the match score, a fingerprint of the file, where the stored copy lives, and the review flag. Typical uses are spotting every mismatch or not-found row, checking that a resolved address belongs to the right agreement, or matching a fingerprint in the ZIP back to an event. Like the report, it is built from the current rows. Statutes are not in this file.

Documents ZIP is for reading the documents without visiting the publisher again. It packs the PDFs and HTML already stored for agreement events still tied to that batch, plus index.csv, which says whether each event’s file was included, missing, or could not be read. Use it to check a flagged find against the real text, to hand a set of located agreements to someone who is not in this screen, or to keep what that run collected. It does not fetch anything new. If the bundle is over the size limit, the download is refused and the set has to be split by website. Events that Cancel never ran are left out, because they are no longer tied to the batch.

Review queue

The review queue is where a person decides, because the automatic search is not sure. Flagged events are rows the search marked. Secondary holds are rows whose only link is not an official publisher; they wait until an official source replaces that link. Filter by the state, by the reason, by the instrument, by the website, and by the score. Accept, Reject, and Confirm not found are the decisions. Supply a URL or upload a PDF when you already have a better file.

How this differs from the watch inbox

This queue decides whether the search found the right document. The Watch inbox decides whether the copied text may be cited. A current text the search flagged visits this queue first, then the inbox.

• Review queue — flagged events, and secondary holds whose only link is not an official publisher. Accept means the found file is the right one. Supply a URL or upload a PDF when you already have a better file. Accept does not add the text to the library.
• Watch inbox — a page you already watch, including a draft this queue has opened. Approve on Review a draft adds a current text to the library. Reject there closes the copy.

A find the search treats as sure is registered as a watched page. Its draft waits in the Watch inbox when that page is Review required. While a row is still flagged, Approve on its draft is refused. Accepting the found file on a current text, or uploading its PDF, takes the row off this queue and leaves the draft ready to approve. Advisory can cite it only after that approval. A historical publication is kept as evidence and stays out of the knowledge base. Reject also refuses a draft that find opened, when no other row shares that source.

Reasons

All flags shows every flagged event. Choose one reason to see only those rows. The label on a card is the main reason that row is here. A high score can still be flagged, because the reason is why a person has to decide. Secondary holds have no reason label. The Reason menu applies to Flagged events.

Filters and bulk accept

Stated, resolved, and procedure

Each card is one event. The bold line is its identifier. The line under that is its official name. The small line names the reason, then the score when the search scored the file, then the verdict, then how the file was found. via stated means the search used the address the package recorded. The verdict is confirmed when the score is 0.9 or higher, and probable when the score is from 0.6 up to 0.9. Below 0.6 the verdict is mismatch.

The same line uses yes, no, and a dash for the other checks. A dash means that check does not apply to this row.

• stable_id — a document id in the file or the address matches the id the package expects.
• denomination — the official name appears in the title or the opening of the file. For an agreement that is not national, the place name has to match too.
• registry_code — the register’s code for this agreement is printed in the file.
• date_consistent — a date in the file is within seven days of the package date (the country profile can set a different window), or the gazette issue is dated that day. A dash means the row has no date, or the file shows no date to compare.
• gazette_reference — the gazette issue reference appears in the file or the address.

Addresses the search also considered are listed under the checks. Each line starts with where the address came from, then its score, then the address. stated on that line means the package address. excluded in front of a line means that address was set aside.

Gap class

Gap class is the reason stored when you confirm that this text will not be collected. The menu does nothing on its own. Choose the class, then click Confirm not found. The row is then stopped, which settles it for the release, and the class is what the coverage report counts. The menu opens on the class the row already has. When the row has none, it opens on missing_in_source.

Attempts

Attempts (1) is the button on the card. The number in parentheses is how many tries are logged for this row, including steps that did not apply. Click it to open the log. The button then shows how many lines it loaded. Each line is one try: L and a level number, the method that ran, and the result. An error, when the try failed, is in parentheses. An arrow introduces the address that try reached.

• L0 — the address the package stated.
• L1 — the same gazette: its issue, its reference, or its search.
• L2 — the country’s register.
• L3 — another official publisher, such as a neighbouring level of government.
• L4 — a site that points at the official text and is not itself the publisher.

A result of not_applicable means that step does not exist for this country or this row. skipped means the step was not run. Both still count in the number on the button.

Supply a URL or upload the PDF

Use these when you already have a better address or the file itself. They sit on every card, under the gap class.

Manual download

Some gazette sites have no address an automatic visit can call. Those sites are manual. A locate batch will not collect them. For each event, open the gazette, save the announcement, and upload that file — or paste a direct link to the file on a row that is still planned. Host is a list of the gazette websites on this release that are fetched by hand. Leave it on all gazettes, or choose one website. The line under Host and State says how many rows match. When more match than this screen lists, it also says how many are showing. Load more brings the next ones onto the screen.

1. Open the gazette with the button on the event.
2. Follow the host hint (calendar, date, gazette reference) and save the PDF.
3. Upload that PDF, or paste a direct PDF link if you already have one.

Source router

The source router is the instruction card for each official website: whether it is active, how long to wait between visits, and how its documents are fetched. The line under Country says how many websites match that country. A stub row is a placeholder for a site the package names and the router does not know yet. Fill it in after the package is planned. The self-test fetches one known document from that site. If that check is older than 90 days, the board marks it overdue.

Registry exports

A registry export is a results file the government register already produced. Uploading it lets later searches use addresses the register knows. Matched rows help locate items the official list already names. The package spreadsheets are not edited.

Registry watch

Registry watch looks for procedures the register publishes after this release. You sign in to the register in your own browser, complete its own check, and paste the saved session so later checks can reuse that sign-in. New finds appear here. Accept attaches a find to a matching open row. It does not change the package files.

If you see Registry watch is off, the platform team has not enabled this watch in this environment. Scheduled checks wait until it is turned on.

Everyday page watching (a single URL, a draft, approve or reject) is in Sources and the watch inbox.