Sinetti Admin Guide

What one nightly run does, in order

1. Hydrate the last verified release into a throwaway workspace (the job never works on the app's own data).
2. Refresh ISCC (certificates, compliance list, blocklist) and REDcert. Each source must pass a contract check — expected columns, plausible row count, parseable dates. A source that fails keeps yesterday's data (kept_previous) and the run is marked partial; one bad source never poisons the rest. Every ISCC certificate without a PDF link gets one here: withdrawn and suspended certificates take the link from the compliance block; the rest cost one register search each, newest in-force first, capped by ISCC_PDF_LINK_MAX_LOOKUPS (default 500). The map rides the data release. Receipt key refresh.ISCC.pdf_links. A miss is retried the next night. The PDF queue only takes certificates that already have a link. Hand backlog: python scripts\resolve_iscc_pdfs.py.
3. Rebuild the app database from that workspace (including whatever PDF artifacts hydrate already had).
4. Trust Review that candidate (§9).
5. Publish a register candidate to the dataset repository and restart the app so it notices it. A receipt and job_heartbeat.json are flushed after this step. Hugging Face SIGKILL cannot write a final receipt; the heartbeat is the in-run pulse. A running receipt is not a successful night.
6. Optional tail — geocode, certificate PDFs, ISCC audit reports, REDcert PDF hosting — only if time remains (the process keeps a 75-minute reserve for the second rebuild, review, publish and mail). New tail work is not started inside that reserve. Certificate PDFs take new documents first. The 1,200-PDF cap is split evenly across schemes that still have candidates (ISCC and REDcert on this job); unused share spills back, so a straight ISCC-first prefix cannot leave REDcert with an empty night. Audit reports take known-template and URL-identity repairs first, then new documents. In both stages, previous failed parses may use at most 20% of the cap. Parser-version repairs do not count against that retry share. A cap of 0 skips that stage.
7. Second publish if the tail changed artifacts and time remains. If the tail is killed, the register candidate from the first publish stays.

Verified against the nightly PDF retry policy, the registered nightly job settings, and the INS weekly task registration (register_ins_weekly_task.ps1: caps 1,200, four-hour cutoff), 25 September 2026.

The nightly job downloads the Space code revision at the start of its bootstrap and records it as config.space_revision on last_daily_refresh.json. The existing Data ops last-run caption shows its first ten characters; Space unknown means the receipt has no usable recorded revision, including older receipts, malformed values and private code rehearsals. A parser fix on the operator machine runs in the cloud only after that code is deployed. The revision is the code the job downloaded, not the dataset release or proof that the app has activated it. After deploying this receipt change, the Sinetti operator must re-register the nightly job once to install the new bootstrap, then check its next receipt; until then the revision stays unknown. A job error or missing receipt still requires checking the true job status on Hugging Face.

Receipt and caption behavior verified against local bootstrap, receipt and Data ops tests, 9 October 2026. Deployment and job re-registration remain separate operator actions.

Pending certificate PDFs (policy approved 10 October 2026). Once compatible code is deployed, a positively diagnosed scanned certificate PDF or a REDcert document positively confirmed unavailable may remain pending during otherwise checked publication. Pending documents remain in the backlog and failed/remaining counts; they are not successful parses. The Sinetti operator must inspect the per-document evidence and the final activation receipt. Missing or malformed evidence, unknown errors, identity or date conflicts, refused replacements, lost material evidence, audit failures, worker failures and failed quality or Trust Review still hold publication of that night's PDF results. Since 23 October 2026 (SIN-0904) they no longer hold the night's register data: the nightly activates its register-only commit, and the activation receipt shows tier "core". A PDF left for the next night because time ran out is not a hold. A hold requires investigation or correction, never a weaker check. This local policy approval does not authorize deployment, another paid run or a schedule change. See the daily refresh runbook.

Preparing an additional PDF drain

The Sinetti operator can prepare a bounded proposal with scripts/prepare_pdf_drain.py; the detailed procedure is in docs/pdf-drain-runbook.md. Preparation is local-only: it starts no job, enables no schedule and reads no credentials. It does not change the nightly settings or enable automatic promotion. Recurring drain scheduling stays off.

Two authorised publishing trials finished on 25 September 2026. Both published a reviewed core revision and a reviewed tail revision, left auto-activation off, and kept the ISCC, REDcert and INS register files unchanged. The first selected 50 certificates and added no new parses. The second, on the repaired parser, selected 100: 79 were re-reads that stayed parsed, and 4 previously unsupported certificates became parsed (349 pathway rows). Sixteen stayed unsuccessful. Receipts, durations and costs are in docs/pdf-drain-runbook.md. Another paid run needs a new explicit approval with an exact job count and cost ceiling. Do not promote while any cloud job is running.

The prepared drain requires Trust Review of the retained certificate sources before both publications, without recording a new register fetch. It preserves the existing business overrides and Trust Review history, while keeping its report, heartbeat, history and PDF cache separate. A failed or incomplete required review stops publication; findings still need the normal manual decision. Concurrent promotion remains blocked while another cloud job runs.

A completed job or an overall ok report is not proof that PDF work was saved. The Sinetti operator must verify tail_publish.status = ok, the published revision, and useful PDF results retained by the next baseline. A hard interruption before publication can lose work and require a repeat. There is no recurring drain schedule. Turn one on only after a later trial shows durable parsed-document progress, and stop or reduce it when the backlog clears.

Verified against both 25 September 2026 trial receipts in docs/pdf-drain-runbook.md. Recurring drain remains disabled.

Morning cloud OCR job

Publication policy approved on 9 October 2026: the nightly data refresh and morning OCR run should each make their checked release live after finishing. This is being rolled out under SIN-0481; both live schedules were still set to candidate-only at the last configuration check. After enablement, failed data checks keep the previous release live, and a failed website restart triggers recovery to the previous release. The Sinetti operator confirms success from the final activation receipt and the live revision under System health. A completed upload alone does not prove customers received the update. Application-code deployments remain separate.

Scanned ISCC and REDcert certificates cannot be read by the nightly: its machine has no OCR engine. A separate Hugging Face job reads them each morning at 07:00 local time (06:00 in winter), after the nightly has published. It takes up to 60 ISCC and 20 REDcert certificates by default; an explicit REDcert cap of zero disables that lane. Known unchanged scans stay out of nightly text-parser retries. An unsuccessful OCR attempt is retried once when its OCR reader or applicable ISCC layout family improves, then its new ledger entry closes it again. Successful OCR and accepted exceptions remain protected; new document URLs, positive file changes and reviewed rereads remain eligible. The job keeps only readings the approved quality rules accept, merges both lanes, and publishes one candidate release. Production changes only when the Sinetti operator promotes a release. The job refuses an unpinned OCR engine and refuses publication if another job moved the dataset revision. Register it with python scripts\register_hf_cloud_ocr_job.py --apply after the deploy that ships it; the runbook section “Morning cloud OCR job” has the settings, rehearsal and checks.

Verified against scripts/run_iscc_cloud_ocr.py, iscc_cloud_ocr.py and scripts/register_hf_cloud_ocr_job.py, 29 September 2026. Not registered yet: ships with the next deploy.

The calendar

If the operator machine is off on Monday, INS simply ages and the app says so honestly in its freshness line — visible degradation, never silent. The three INS PDF stages default to a cap of zero in the runner, so an unset machine never parses an INS PDF. Registering the weekly task (scripts/register_ins_weekly_task.ps1) raises each cap to 1,200 when .env omits it or sets it lower — the same drain budget as the nightly certificate-PDF cap — and sets a four-hour cutoff. Re-register after pulling that script; the cutoff is stored on the task, and the caps are stored in .env. Leave the uncached switches unset unless you deliberately want the local task to refetch from GSE. With INS_PDF_SITE_REEXTRACT=1 the site stage also re-reads documents that already have sites, and replaces them only when nothing is lost. A criteria batch that cannot improve is a Trust Review finding, not a failed run that withholds the whole publication.

How to tell a run really happened

• Admin → Data ops shows a card per register with a status pill (ok · error · held · not due · no data), what changed (“+12 new · 40 renewed · 3 withdrawn”, and suspended, delisted and terminated on their own — a termination is the holder’s exit and is not a withdrawal), and how the PDF queues moved. Below the briefing, Parse inflow, next 12 months counts certificates still in force onto the day each one ends: one renewal PDF that day, and for ISCC one summary audit report. The numbers are read from the serving release when you open the page. A section bar stays pinned at the top while you scroll the long Data ops pages (Refresh, Sources) and the other long admin pages (Data Trust, Regulatory monitor, System health): the hub tabs plus one pill per section, with the pill of the section in view highlighted; click a pill to jump to that section (a closed section opens). Right after the three summary tiles, Documents still to read — day by day shows line charts, one point per day a refresh ran, ending at the data the live app serves: the last point is the promoted data release’s own count, so the charts move when new data is promoted, and a nightly count on data not yet promoted is not drawn. They keep Digital and Scanned documents apart. A digital PDF has a text layer the parser reads directly; a scanned PDF is an image that needs OCR before anything can be read. Digital certificate PDFs waiting has one small chart per register, each with one line per reason a digital PDF is still waiting (layout not read yet, because the parser does not know the layout; waiting for a check; download to retry), each chart with its own scale. Scanned certificate PDFs waiting keeps one line per register; under the scanned chart a line says how many scanned ISCC certificates the morning OCR run has already tried (and still could not read) against how many it has not tried yet — ISCC and REDcert report the morning OCR queue; INS reads “no OCR job”. ISCC audit reports waiting draws a Digital and a Scanned line. Hover a day for the numbers: on the scanned and audit charts the split into parser, check and retry (scanned days read “needs OCR”); the 30 days / 90 days / All switch sets every chart. A day without a point had no refresh for that register (INS runs weekly). Days recorded before 9 October 2026 were not split when written: they are estimates, shaded and labelled, worked out by sorting the documents that were waiting that day by their reason today (a scan that was later read counts as digital on the days before). In the digital charts only the “layout not read yet” line is estimated on shaded days; check and retry were recorded exactly. From the next nightly data refresh each day stores its own split and is exact. For ISCC and REDcert the waiting counts include only certificates still in force, the same rule as Data Trust Accounted; INS is unchanged. The charts mark the day this rule started with a vertical line labelled “Current certificates only”: the drop on that day is the rule change, not reading, and hovering that day says how many waiting PDFs of ended certificates stopped counting. Under those charts, Holders on the map — in force only counts, per scheme, the holders with a certificate, pathway or registration in force that draw a point on the maps (one unit per holder and country, so a holder in two countries counts twice). One card lists the certification schemes, one the regulatory programmes: a bar for the share on the map, located against in force, the percentage and how many are not on the map (no plant, address or postcode point, so missing from Browse, Certified Sites and the deep-dive maps). The count is taken on the data the live app serves, so it moves when new data is promoted; each nightly data refresh also records its own count, and once two nights exist each card draws a Not on the map — day by day line. The Queue tables section further down carries the full daily movement per register, and Register history shows the last 14 nights (a link shows all of them). Under the three summary tiles, Serving on sinetti.ch compares each register's data on the live app with the newest release in the dataset repository. It recommends a release only when every served register remains present with a valid date that has not moved backwards, and at least one register is newer or newly added. The command to run on your PC is pre-filled with that release (Copy button); the app never moves production itself. When newer data waits, the card headline names the register and the date of its waiting data (for example Newer ISCC waiting 25 Oct 26 · 02:00), and the line under it says what promoting changes and which registers on the same schedule have nothing newer; the table lists only each register’s schedule, live date and status. When the newest release holds newer data but the code deployed on sinetti.ch cannot pull it (for example a register folder that code does not know), the card headline reads Needs a code deploy first, a red strip quotes the reason, and no command is offered until a deploy ships code that can read it; promote_release_on_space.py --list marks the same release. An invalid or regressed candidate is shown as needing review, and an equal-date release with possible PDF work needs manual review. A green newest-data line requires trustworthy evidence or the already served release. While the server is running on partial data (a slow start left company identities out, so holder pages show no company links), the same card shows a terracotta strip saying so and roughly how many seconds remain until it reloads by itself; nothing needs doing unless it is still there after a few minutes, then restart the server.
• Admin → Data ops → Sources tags each source on schedule, overdue n days or manual. “Overdue” is computed purely from how old the newest evidence is — the one signal a killed job cannot fake.
• For the nightly job, the authority is the job's own status on Hugging Face (completed / error). In August 2026 every night for two weeks died of a timeout and wrote no receipt; the app's log kept showing the last good night.

Procedures

Who may move the pointer

The strict shrink rule exists because a real accident was a 0.65 % loss — 507 certificates — that a percentage threshold would have waved through. Registers do shrink legitimately; that judgement is reserved for a person.

Reading /api/ready

Procedures

The screens

Map coordinate delivery (checked 8 October 2026). The Sinetti operator reads coordinate_workspace in the Data ops refresh receipt. Newly recovered holder, address and site points reach Browse, Producers / Certified Sites and the deep-dive maps after the rebuilt data candidate is accepted and activated. An unchanged checkout baseline protects nightly positions; an actual later hand correction supersedes them. Town/postcode fallback evidence stays approximate. A workspace error preserves unreadable inputs and stops the candidate: restore a verified usable copy, keep the receipt and rerun the isolated job. Interrupted coordinate/provenance writes recover from their transaction journal; do not delete it. A successful receipt alone does not establish activation or complete address coverage. Procedure: docs/daily-refresh-runbook.md, “Coordinate delivery and hand corrections”.

Map coverage accounting (checked 8 October 2026). The raw refresh report now includes coordinate_coverage: the familiar distinct World holder total, separate certificate-address and physical-site counts, pending/ambiguous/negative work, and changes on retained identities. New holders are shown separately from lost coordinates. A stored singleton pin avoids an unnecessary paid request; another unresolved address remains in scope. Town/postcode evidence is approximate and leaves the site task open. An advisory audit error or damaged prior inventory says coverage/history unavailable and preserves the last readable report. The Sinetti operator can propose zero-cost recovery in a separate bundle using verified published caches and strict local place evidence; acceptance and activation remain separate. The large postcode index is never loaded by nightly accounting. Procedure: docs/daily-refresh-runbook.md, “Coverage inventory and zero-cost catch-up”.

“Balanced operating lanes” and “Acquisition retry preview” on the Overview are planning aids. The lane caps are read from the nightly receipt, not from a number baked into the page. They suggest cadence and show what a retry would pick; they cannot start or schedule anything. Reason codes on this page and on Certificate formats use plain labels (for example “Ticked box could not be read”).

A customer report of a wrong or missing record starts with docs/enterprise/hosted-bilateral/data-correction-procedure.md. The report lands in User reports and does not itself create a finding. Record the intake, the reply to the customer, and the source-versus-served evidence before you change anything.

Verified live PDF coverage

The Sinetti operator reads three separate results: current source checks, production reconciliation, and reciprocal monitor liveness. The existing Accounted and read screen describes the selected artifact; a local parse or published candidate does not establish production completeness. Reconciliation needs the verified active revision/hash, full expected inventory including required annexes, and independent code, source, API and customer evidence. Missing evidence is unknown. INS live recovery/publication is owner-deferred while ISCC and REDcert are prioritized; INS remains visibly unresolved in the full target, with its local support and history retained.

Every expected current document needs a successful source check within seven days, including successes and accepted exceptions. Full current bytes or an authoritative digest establish freshness; unchanged URL, HEAD or file length does not. Source-only checks can acquire new PDFs without earlier Read/customer proof, while production coverage stays unknown. A changed file immediately supersedes old current proof, even if earlier good rows are preserved after a failed replacement. Source blockers stay in the denominator, are rechecked weekly and never count as Read. Keep diagnosed Failure A–E labels separate from OCR residual Types.

The new lanes default off. SINETTI_PDF_SOURCE_AUDIT_ENABLED=1 and SINETTI_PDF_COVERAGE_MONITOR_ENABLED=1 are separate explicit opt-ins; audit caps default to zero. An independent request and its SHA256 must be configured through SINETTI_PDF_COVERAGE_INPUT_REQUEST and SINETTI_PDF_COVERAGE_INPUT_REQUEST_SHA256. Local code changes leave existing jobs, flags and schedules as configured. Enabling, source runs, publication, activation and deployment are separate authorized operations; Environment has no control for these flags.

The exact audit caps are SINETTI_PDF_SOURCE_AUDIT_MAX_CHECKS, SINETTI_PDF_SOURCE_AUDIT_ISCC_MAX, SINETTI_PDF_SOURCE_AUDIT_REDCERT_MAX and SINETTI_PDF_SOURCE_AUDIT_INS_MAX. Inspect refresh/pdf_coverage/source-audit.json, exactly {state, report, receipt_binding}, against both full six-field inventories and their independent inventory pins. Latest negative observations and unbound changed requirements remain holds despite retained older success. Only genuine processing adds report_json.pdf_source_freshness; operational job reports use source_version_audit. An unchanged source check creates no generic parse run. The shipped acquisition adapter checks full bytes; independently required ISCC audit reports use verified bytes in both existing sequential and overlap parser routes under existing audit caps. Required REDcert/INS audit-report roles remain explicit unknown/pending in the full denominator because their processing routes are unsupported; unrelated audit reports are not added.

Source-audit JSON reads allow 16 MiB without truncation; narrow heartbeat/hosted-check reads remain 1 MiB. Actual full-population payload capacity is unmeasured. The 14-date/two-activated-INS operational gate remains open after the local code merge: current full-population proof, measured capacity, actual deployed/scheduled operation, source/customer evidence and reciprocal liveness remain necessary.

Proposed targets are acquired text PDFs within 24 hours, daily-lane scans within 48 hours, and INS discovery within seven days followed by 48-hour processing. Measure successful checks and queue ages inside the existing runtime/caps before claiming capacity. Local fixtures prove behavior and arithmetic only. Operational acceptance needs 14 consecutive Zurich scheduled dates with completions at most 26 hours apart, plus two distinct genuine scheduled weekly INS accepted revisions activated and reconciled. In-deadline arrivals lower literal coverage without alone resetting operational consistency. Visible, evidence-bound weekly-checked blockers may coexist with operational consistency; literal 100% sustained additionally needs zero incomplete/blocker cases at every counted checkpoint. Expiry is not recovery, and checkpoints do not prove continuous completeness between runs.

Findings: states and what they mean

Each finding type is also classed Blocking or Advisory. The class matters only to automation: a candidate carrying a blocking-class finding is not promoted by itself. It never stops you. Unclassified types count as blocking. Priorities are critical · high · normal · information.

Procedures

Material evidence held: a failed or incomplete reparse keeps the last verified source and creates a review item. Unavailable or unreadable documents do not mean no materials. Dataset publication stops when source owners, certificate periods or material rows disagree between the register, raw extraction and served release. The Sinetti operator reviews the actual source, repairs and reparses it, then rebuilds all three layers. The last accepted release remains available; deleting a review item or changing a count band is not a repair. A refused re-read where the kept file and the new read both have no material rows (for example "no materials declared" read again as an unsupported layout) loses nothing: it stays listed for review but no longer counts toward the 50-document hold ceiling and never holds publication. The 50-document ceiling counts only documents newly held in the last three days, and never a failed download: older holds keep their own certificate on its last verified reading but do not stop the night's publication. A reading held for more than 14 days is named on a Held PDF readings line in the daily admin email until it is reviewed.

Data Trust starts with Accounted and read, for in-force certificates only. Accounted is certificates that are read or closed as an accepted exception with a named reason; Read includes parser reads and manually verified PDFs, shown in separate columns. An exception counts as accounted, never as read, is bound to the exact PDF file, and reopens when a new file arrives. A cover that prints more pages than its official PDF holds (“Page 1 of 2” on a one-page file) is never counted as declaring no materials: it shows as Official PDF misses a printed page until reviewed, then as the exception Page missing from the official PDF. The target is accounted 100% after every morning OCR run. Not accounted lists each certificate with why: Needs a decision (the only rows that need you), Not tried yet, Download retry (three mornings, then closed) or Reader fix open with its backlog item. 2BSvs and RSB read “Not read — frozen scheme”. The same list downloads as CSV.

For a certificate that needs a decision, select Review manually to compare its source PDF with editable pathway and site rows. Existing material names and scopes are suggested as the admin types; free text remains available for the exact printed wording. A partial save keeps the certificate open. Marking it manually verified requires a reason and confirmation that every row and site annex was checked. The review is tied to the PDF SHA-256, and review history records each save, reviewer and time. These corrections stay in the operator review record; run the normal PDF promotion process before they appear in customer-serving pathways.

Trust Review findings follow. Open Document overview, audit reports and reconciliation for document coverage, operating lanes and retry work. Entity identity and related-company reviews each have their own disclosure below. Related-company review shows ten pairs per page, with x–y of N pairs, Previous and Next; all candidates remain available. After a decision removes the last row on the last page, the screen returns to the last valid page.

Ownership second opinions. The Sinetti operator can recheck a bounded slice of pending, known-form ownership proposals once through the stored ChatGPT subscription login. The independent researcher sees the original form and parent, but no original sources, website or notes. The existing proposal note shows First and Second form/parent summaries and the outcome. Matching form and normalized parent need a new source domain and the existing source-trust checks before the row becomes provisional; Confirm/Revert stays the same. Disagreement, unknown, invalid or reused-source answers remain pending. Failed and interrupted attempts are also spent once. The original answer and complete second evidence remain in data/company_group_proposals.json; no new review control is added. The manual procedure is in docs/company-groups-runbook.md.

How a material name travels

Counts and examples: certificate pathway rows and the local material map, 8 October 2026. Spelling groups and kind are shown read-only in Admin → Materials → All names (tick Group spellings; the Kind filter is next to Family).

How a company name travels

Where it is decided: Admin → Data Trust (Entity identity review, Related companies review) · the quarterly company-groups job · the rest is set in code and read-only. Real Neste example; counts as of 8 October 2026.

Procedures

A regulatory case moves New → Reviewing → Action required / No action / Superseded, and from Action required to Implemented once you link the revision that changed Sinetti. Every step needs a written reason; the evidence is immutable.

Dated watches (procedure verified 2026-09-26). The same morning task also checks a short list of pages that are not due every day: a URL, the first day to look, and the text that counts as news. The list covers France and the other mandate countries (Germany, the Netherlands, Belgium, Italy, Spain, Sweden, and Finland). A hit is an ordinary review case. It does not change a mandate rate. The runbook section "Dated watches" names each page, the signal, and the window.

North American watch (procedure verified 2026-09-26). The daily monitor checks California LCFS, EPA, Canada CFR, Oregon and BC registers, plus official rules and guidance indexes. It compares content before parsing and verifies downloads at least weekly. The legal action email carries legal-source review cases and source failures. A separate Register monitor email groups pathway/register value changes, data quality or extraction changes, uncertain differences, and register check failures. It names each register in plain words, describes each observation in full once, folds Sinetti-side row renames (the register did not change) and re-issued pathways into single blocks, counts large changes instead of listing them, and then keeps unpublished observations as one line each under “Still waiting for a data release” until the active data release was built after them. Parser enrichment is not automatically a publisher change. “Not yet in a data release” is not confirmation of live publication: verify the source, use Data ops → Refresh now, review the candidate, then follow the publication workflow. Rules/index alerts never change legal interpretations automatically.

Check <state>/refresh/north_american_monitor/latest.json for source outcomes and events.jsonl for before/after evidence. A failed check is unknown, not unchanged; a receipt older than 30 hours is overdue. Keep the last good baseline during recovery. A British Columbia Laws line that only says the act or regulation is current to a new date is not a review case. Gateway timeouts (HTTP 502, 503 and 504) and a dropped connection are tried again up to three times inside that request's time budget. A source that failed yesterday is checked again the next morning, even when the failure was after 06:30. The daily legal action mail keeps naming a legal source whose latest check is still a failure, and an open legal case stays until marked. The separate register mail keeps an observed difference eligible while a refresh is pending and the latest check has not read the file unchanged. If a change is uncertain, compare the official source and full stored evidence before treating it as a business update. A 06:30 run that never starts is named by the 05:30 job monitor when the last receipt is missing or older than 30 hours. EUR-Lex discovery allows 90 seconds. A publisher that keeps failing stays a visible failure. Oregon's Secretary of State rules page rejects this host; leave that source visibly failed and retry on the normal schedule. The Oregon DEQ program index does not replace the rule text. An official https page with no law-allowlist probe is on the weekly check; a change opens a review case and does not write an optimizer value. Drafts, discovery feeds that are not yet proven, and sources with no official URL stay off that check. Re-register with scripts/register_regulatory_monitor_task.ps1 after updating the operator checkout; the task action must include --include-registers. This task needs the operator machine online. Merged code is not cloud monitoring. The runbook covers verification, retry and the separate cloud-authority option.

Agreement coverage in Ask

Ask applies the caller's scheme access before reading or counting evidence. This applies to signed-in callers, including administrators. The agreement must permit every scheme covered by a mixed source. Sources without a reliable scheme classification are excluded. An explicit request for an excluded scheme receives the line “X is not in your plan”; Ask can still answer the permitted part.

Until their sources are classified, Ask cannot provide material-label lookups, RED default values, trade codes, fuel conversion and specification facts, or market, mandate and GHG-value calculations through its reference tools. A document listed in Knowledge is therefore not necessarily available to that caller.

Ask also omits holder production units and Certified Sites reads because they include unclassified capacity evidence. This applies to every signed-in caller, including administrators with access to all schemes. The ordinary holder pages and Browse maps remain available.

For callers with limited scheme access, Ask also omits saved views, monitor sets and activity history whose mixed content cannot be reliably scoped, plus the shared briefing and product vocabulary. Nothing is deleted. Reduced coverage is intentional; an unavailable source does not mean the underlying information is absent.

Questions where Ask found nothing good enough to cite are logged on the server (the “miss log”). That list is your shopping list for documents worth adding.

Procedures

Settings the mail needs (Space secrets): INFOMANIAK_API_TOKEN, SINETTI_INFOMANIAK_MAILBOX_UUID, SINETTI_EMAIL_FROM, SINETTI_PUBLIC_BASE_URL (the address put into invite and reset links — wrong value, dead links), and SINETTI_ADMIN_EMAIL / SINETTI_ACCESS_NOTIFY_EMAIL for mail addressed to you.

When a customer questions an alert (“this certificate is not withdrawn”), check two sources before answering: the delivery record with the ordinary certificate row, and the register's own compliance status. The ordinary row keeps its original dates even after the scheme suspends or withdraws the certificate, so either source alone can mislead. A voluntary termination (the holder left while the certificate was still valid) is not a red flag and is not in the default Flags priority or the watchlist alert mail. The daily subscriber digest lists each one in its own section, under the red flags, and says the exit was voluntary and is not an enforcement action. It also names a new certificate for that holder when one starts within three days, or when the holder comes back within 90 days. That section is not counted in the red-flag subject. The admin overnight brief lists the same exits. INS, California LCFS, EPA, Canada CFR, Oregon, and BC land on the same Flags page and in the same daily digest; each weekly refresh still keeps its own staging log. The Saturday US mail is the operator brief only. Withdrawn is the authority cancellation. Delisted is Sinetti's own inference that a certificate disappeared between snapshots.

Watchlist digests draw the holder's country flag and the scope and material chips, and a reinstatement says which end-state the certificate came back from.

Ask safety

Question retention and customer purge. Permanently deleting an organisation also deletes its Ask abuse incidents, export cohorts and organisation-tagged retrieval-miss entries through the guarded customer purge (section 4). Other organisations' records remain. Abuse incidents expire 180 days after creation, including dismissed incidents; repeated hits do not extend that deadline. A hit after the deadline starts a new incident with its own 180-day lifetime. Alert deduplication stays within the same organisation. Export cohorts remain usable for one hour. A cleanup worker runs when the app starts and hourly thereafter: it deletes expired cohorts, expired abuse incidents and retrieval misses at 90 days. Miss entries retain up to 500 characters of question text for diagnosis and carry the organisation resolved by the server.

Where a hit came from. The abuse rules read the typed question and also the page context the browser sends and the earlier turns it sends back. A hit outside the question shows its source as a prefix on the rule name, page_context: or history:, in the Safety inbox and in the alert email. A high-severity hit in any of the three is refused the same way and a watch hit is only recorded. Document passages, tool results and page context also reach the model inside labelled data blocks that it is told never to obey; that needs no admin action.

Older retrieval misses without an organisation tag cannot safely be attributed to a customer: an organisation purge leaves those rows for their 90-day expiry. Rows with missing or invalid dates require operator review and are preserved. If cleanup reports ask_retention_failed in server logs, fix access to the named store; the next hourly pass retries it. Before treating a customer purge as complete, confirm all three Ask categories completed in its deletion receipt. A failed category requires the existing preview/Resume deletion procedure; never clear a shared log manually.

Questions that match abuse rules, or sessions that hit the tool-call ceiling, open an incident. Alert emails never contain the question; the full text is readable only on this screen. There is one action: read, optionally note, Dismiss. Repeated incidents from one member are a conversation with the customer, and a reason to consider Disable (§4).