Direct answer
Begin by identifying exactly which inquiry data exists and who can use it. Redesign the system to avoid identity linkage and durable raw records before relying on policy. Bind staff, vendors, and public authority to narrow purposes, deletion, notice, appeal, and sunset rules. Test those claims against all eighteen audit domains. Prepare only a minimized publication derivative, verify its exact packet structure, compare independently received copies against a byte-bound receipt, and record only explicitly reproduced continuity relationships. These checks make artifacts challengeable; they do not prove the underlying claims, approve publication, or justify retaining private inquiries.
Download first. Record locally. Publish only what accountability requires.
The templates are static first-party files. Each optional browser tool reads only files you explicitly select and only after activation. They make no application network request, create no server record, and use no cookie or persistent browser storage. The register preserves unknowns, unavailable evidence, contradictions, critical-gate failures, and supersession.
Set four non-negotiable boundaries.
Inquiry is not confession.
A query, prompt, book, draft, topic, or controversial phrase does not by itself prove belief, character, ideology, dangerousness, or harmful intent.
Safety needs a defined harm.
Name the conduct or capability, evidence, likelihood, severity, affected population, and less intrusive alternatives before collecting more information.
Architecture outranks promises.
A system that never creates a general inquiry dossier provides stronger protection than a policy promising not to misuse one.
Evidence must remain contestable.
No favorable label should conceal missing evidence, failed critical gates, unresolved limitations, lifecycle changes, or unavailable remedies.
Preserve proof without preserving private inquiry.
A downloadable-first, institution-ready record for preserving provenance, version and configuration scope, policy authority, deletion evidence, remediation ownership, incident triggers, and re-review dates without collecting private inquiry submissions.
Choose a format you can inspect offline.
All formats carry the same stable register, area, kit-crosswalk, and audit-crosswalk identities. The bundle also includes an ID-only crosswalk, operating instructions, and SHA-256 checksums.
Inspect a completed register without submitting it.
A user-initiated, browser-local structural validator for completed NAV-CL-E001 CSV or JSON files that produces bounded non-certifying derivatives without transmitting or retaining selected content.
Before selecting files · E002
- Required · One completed NAV-CL-E001 register; current v1.19.0 projection
- CSV or JSON; maximum 1 file(s), 2,097,152 bytes per file.
Exact local action: Validate locally reads that register, reports stable diagnostics, and offers a JSON report and Markdown checklist. No ZIP input.
Files are read only after activation. Reset, replacement or leaving the page cancels pending presentation; in-flight computation and browser memory cannot be securely erased by this page. Use intact producer files, preserve unfavorable diagnostics, and review any output before sharing.
Offline distribution v1.26.0: extract the complete toolkit and use the documented tools/ entry point. It includes the original v1.19 engine, authority files, fixtures and historical projection dependencies. The earlier flat v1.19 archive remains unchanged and its standalone limitation is historical; it is not the current entry point. A successful check or checksum is not evidence truth or approval.
Explicit selection only
The page reads only the one CSV or JSON file chosen with the file picker and only after Validate locally is activated.
No transmission path
No upload, fetch, beacon, socket, analytics, form submission, or evidence-locator request is used by the validator.
No persistence claim
The validator does not write cookies, local storage, session storage, IndexedDB, Cache Storage, or a service worker. Browser and operating-system behavior remain outside this page’s control.
Structure, not truth
Diagnostics identify bounded structural and publication risks. They do not verify source truth, independence, legal compliance, privacy, security, or provider behavior.
Limit: 2,097,152 bytes, 5,000 records, strict UTF-8. ZIP and other archive inputs are rejected.
No local file selected.
The first-party script reads a selected file only after the user activates validation, performs processing in the current browser context, creates downloads only on explicit request, makes no fetch, XHR, beacon, WebSocket, form submission, cookie, localStorage, sessionStorage, IndexedDB, Cache API, service-worker, or remote-asset call, and releases application references on reset. Browser, operating-system, endpoint-security, swap, backup, extension, print, and download behavior remain outside the site proof.
Local validation result
Every result requires human review. Generated outputs contain diagnostic metadata and source binding, not the selected evidence values.
What the NAV-CL-E002 report checks
Structural validity
Evidentiary completeness
Privacy and dossier risk
Critical-gate state
Contradictions
Unavailable evidence
Human review
Create a minimized derivative without uploading either source.
A user-initiated, browser-local and command-line deterministic builder that packages only allowlisted, metadata-minimized derivatives of a NAV-CL-E002 validation report and an optional separately selected NAV-CL-E001 register. It never uploads, stores, signs, certifies, or independently verifies the selected content.
Before selecting files · E003
- Required · NAV-CL-E002 v1.19.0 validation report
- JSON; maximum 1 file(s), 1,048,576 bytes per file.
- Optional · Exact NAV-CL-E001 v1.19.0 register bound by that report
- CSV or JSON; maximum 1 file(s), 2,097,152 bytes per file.
Exact local action: Generate local packet reads these selections and the selected minimization profile. Report-only preparation is permitted. No source original is included.
Files are read only after activation. Reset, replacement or leaving the page cancels pending presentation; in-flight computation and browser memory cannot be securely erased by this page. Use intact producer files, preserve unfavorable diagnostics, and review any output before sharing.
Offline distribution v1.26.0: extract the complete toolkit and use the documented tools/ entry point. It includes the original v1.19 engine, authority files, fixtures and historical projection dependencies. The earlier flat v1.19 archive remains unchanged and its standalone limitation is historical; it is not the current entry point. A successful check or checksum is not evidence truth or approval.
Deliberate action only
The builder reads a validation-report JSON and, only when separately selected, its source register after Generate local packet is activated.
Originals stay outside
The packet never includes either selected original: no supported profile places the selected validation-report original or register original inside the packet. The derivative records source hashes and transformations instead.
Unfavorable findings remain
Errors, critical blockers, contradictions, unavailable evidence, not-reviewed critical states, and the human-review requirement remain visible without a hidden score or badge.
No transmission or storage workflow
No fetch, upload, beacon, socket, analytics, cookie, browser database, service worker, or evidence-locator request is used by this builder.
- 01Select a NAV-CL-E002 validation report.
- 02Optionally select the exact register bound by its source hash.
- 03Inspect displayed file identities before processing.
- 04Choose the safe or advanced profile.
- 05Generate and review exclusions and unresolved findings.
- 06Inspect the text-only manifest preview.
- 07Download the deterministic ZIP.
- 08Complete human sign-off outside automation.
- 09Reset page-held references and generated URLs.
Maximum 1,048,576 bytes. The report must match the current validator, register, diagnostic, and human-review contracts.
No validation report selected.
Maximum 2,097,152 bytes. A mismatch with the validation report’s source hash blocks packet generation.
No register selected; report-only packet is permitted.
Generate remains disabled until a validation report is selected. File names and byte counts may be displayed after selection, but file contents are not read until generation is explicitly activated.
The first-party browser script reads selected files only after explicit user action, makes no fetch, XMLHttpRequest, beacon, WebSocket, WebTransport, EventSource, form submission, cookie, localStorage, sessionStorage, IndexedDB, Cache API, service-worker, BroadcastChannel, SharedWorker, remote-font, CDN, telemetry, or third-party-code call, and releases application object URLs and references on replacement, reset, page hide, and completed download when technically safe. Browser extensions, endpoint monitoring, swap, backups, print systems, download history, user-selected storage, and garbage collection remain outside the proof.
Local packet result
Generated files contain only the selected profile’s allowlisted derivative, bounded validator findings, a transformation ledger, checksums, limitations, and a blank sign-off worksheet. Human review remains required.
Inspect text-only manifest preview
Review before any derivative leaves local control.
Human review remains required. Packet generation is preparation, not approval or publication suitability.
- Confirm the selected report is current and belongs to the selected register hash.
- Preserve every unfavorable diagnostic and unresolved critical state.
- Exclude raw queries, prompts, reading histories, inferred beliefs, sensitive traits, person-level curiosity records, credentials, private contacts, device identifiers, exact internal paths, active content, and unknown fields.
- Inspect every optional value included by the advanced profile line by line.
- Complete accountable human review; never present the packet as a certification, seal, grade, score, or independent verification.
Inspect the fixed publication contract
Deterministic packet
Stored ZIP members, fixed timestamp and mode, normalized UTF-8, canonical JSON, fixed order, and SHA-256 checksums.
Stable findings
Input integrity, minimization, active-content, gate-preservation, human-review, and output-integrity identities.
Public by default
Controlled identifiers, statuses, dates, versions, and lifecycle links remain subject to inert-content screening.
Optional after review
Withheld by the safe profile; eligible only after explicit advanced-profile selection and screening.
Always excluded
High-risk locators, provenance text, account state, logs, confidential bases, and similar content stay outside supported packets.
- NAV-CL-E003-M01
public-register.jsonMetadata-minimized NAV-CL-E001 projection. - NAV-CL-E003-M02
validation-summary.jsonBounded NAV-CL-E002 summary with diagnostic observations removed. - NAV-CL-E003-M03
redaction-and-unresolved-issues.mdHuman-readable exclusions, unresolved states, and publication checks. - NAV-CL-E003-M04
transformations.jsonField-level inclusion and removal ledger that never echoes removed values. - NAV-CL-E003-M05
manifest.jsonMachine manifest, source hashes, rule-set identity, selected profile, and member contract. - NAV-CL-E003-M06
human-sign-off.mdPrintable accountable-review worksheet. - NAV-CL-E003-M07
LIMITATIONS.txtPlain-language authority, privacy, security, and publication limitations. - NAV-CL-E003-M08
SHA256SUMS.txtSHA-256 checksums for every other packet member.
Verify the packet contract before relying on a copy.
Locally checks one NAV-CL-E003 publication packet against the exact archive, checksum, authority, privacy, and critical-gate contracts, then produces a deterministic transparency receipt that still requires human review.
Before selecting files · E004
- Required · NAV-CL-E003 v1.19.0 publication packet
- Intact eight-member ZIP; maximum 1 file(s), 20,971,520 bytes per file.
Exact local action: Verify locally reads the packet and produces an E004 transparency receipt. It does not require running the builder first.
Files are read only after activation. Reset, replacement or leaving the page cancels pending presentation; in-flight computation and browser memory cannot be securely erased by this page. Use intact producer files, preserve unfavorable diagnostics, and review any output before sharing.
- 01Select one E003 packet ZIP.
- 02Inspect the displayed file identity.
- 03Activate bounded local verification.
- 04Review fatal findings and preserved uncertainty.
- 05Download the receipt and checklist.
- 06Reset page-held references.
No packet selected.
Packet conformance result
Inspect structure without mistaking it for truth.
- Require exactly the eight E003 members, in the committed order, with stored compression, fixed timestamps, mode 0644, LF text, and no undeclared metadata.
- Recompute every checksum and verify the manifest, builder identity, profile, contract hash, transformation count, diagnostic summary, and human-review state.
- Reject source originals, excluded fields, removed values, reversible encodings, hidden value hashes, active content, formula-triggering prefixes, path ambiguity, and favorable overclaim language.
- Preserve contradictions, unavailable evidence, unresolved critical states, failed gates, and
HUMAN_REVIEW_REQUIRED.
Inspect the fixed E004 contract
Bounded findings
Stable input, archive, checksum, authority, minimization, gate-preservation, active-content, and output-integrity identities.
Deterministic receipt
transparency-receipt.json, transparency-receipt.md, LIMITATIONS.txt, SHA256SUMS.txt.
No passing badge
A conformant result still says human review is required; a fatal finding yields nonconformant.
Byte binding
The receipt binds the observed packet bytes and member hashes at one verification event.
Determine whether selected artifacts bind to the same bytes.
Locally compares Packet A, an E004 transparency-receipt bundle, and an optional independently received Packet B, proving only bounded byte, hash, and contract agreement while preserving human review.
Before selecting files · E005
- Required · Packet A from NAV-CL-E003 v1.19.0
- ZIP; maximum 1 file(s), 20,971,520 bytes per file.
- Required · NAV-CL-E004 v1.20.0 transparency receipt
- ZIP; maximum 1 file(s), 4,194,304 bytes per file.
- Optional · Packet B from NAV-CL-E003 v1.19.0
- ZIP; maximum 1 file(s), 20,971,520 bytes per file.
Exact local action: Compare locally reads Packet A, its selected receipt and optional Packet B, preserving mismatch and unavailable states.
Files are read only after activation. Reset, replacement or leaving the page cancels pending presentation; in-flight computation and browser memory cannot be securely erased by this page. Use intact producer files, preserve unfavorable diagnostics, and review any output before sharing.
- 01Select required Packet A.
- 02Select its E004 receipt bundle.
- 03Optionally select independently received Packet B.
- 04Run fresh E004 observations.
- 05Review binding and copy differences.
- 06Download the comparison record, then reset.
No file selected.
No file selected.
No optional Packet B selected.
Artifact comparison result
Distinguish three different questions.
- Receipt binding: does the selected receipt identify Packet A’s exact bytes, member observations, E004 contract, and diagnostic state?
- Byte equality: when Packet B is present, is its SHA-256 exactly the same as Packet A?
- Human judgment: do the packet’s claims deserve publication, reliance, or institutional approval? E005 does not answer this question.
- Do not treat a match as identity, authorship, custody, notarization, trusted time, legal sufficiency, evidence truth, or publication fitness.
Inspect the fixed E005 comparison contract
Ordered observations
Stable input, receipt, binding, fresh-verification, optional-copy, overclaim, and output-integrity identities.
Deterministic record
packet-receipt-comparison.json, packet-receipt-comparison.md, LIMITATIONS.txt, SHA256SUMS.txt.
Precise mismatch states
Byte match, packet drift, binding mismatch, nonconformant receipt, and indeterminate input remain distinguishable.
No blind receipt trust
Packet A is re-observed under the current immutable E004 contract before receipt comparison.
Record reproduced byte relationships without inventing a chain of custody.
Locally verifies a bounded set of current E005 comparison records and optional corresponding E004 receipts and E003 packets, preserving reproduced byte bindings, missing materials, contradictions, duplicate observations, and disconnected components in a deterministic human-review ledger.
Before selecting files · E006
- Required · NAV-CL-E005 v1.21.0 comparison records (at least one)
- ZIP or JSON; maximum 12 file(s), 4,194,304 bytes per file.
- Optional · NAV-CL-E004 v1.20.0 receipts
- ZIP; maximum 12 file(s), 4,194,304 bytes per file.
- Optional · NAV-CL-E003 v1.19.0 packets
- ZIP; maximum 12 file(s), 20,971,520 bytes per file.
Exact local action: Build continuity ledger reads the selected batch and records only relationships supported by the existing contracts. At most 24 selected files overall; repeated selections count.
Aggregate byte limit: 67,108,864 bytes across all selected files.
Files are read only after activation. Reset, replacement or leaving the page cancels pending presentation; in-flight computation and browser memory cannot be securely erased by this page. Use intact producer files, preserve unfavorable diagnostics, and review any output before sharing.
- 01Read the authority and endpoint limits.
- 02Select one or more current E005 records.
- 03Optionally add exact E004 receipts and E003 packets.
- 04Run bounded local parent checks.
- 05Review connected, disconnected, and contradictory components.
- 06Download the deterministic ledger, then reset.
No comparison record files selected.
No receipt bundle files selected.
No packet files selected.
Continuity-ledger result
Artifact inventory
Explicit relationships
Diagnostics and unresolved state
Connect only relationships reproduced from explicit byte bindings.
- Do not infer continuity from filenames, selection order, dates, release labels, nearby files, similar prose, or shared values.
- Keep disconnected components disconnected. Missing receipts or packets remain unavailable rather than silently bridged.
- Label timestamps inside selected files as source-declared and untrusted; they are not proof of existence, receipt, custody, signing, or publication.
- Repeated identical bytes are repeated observations, not independent corroboration.
- Every outcome preserves
HUMAN_REVIEW_REQUIREDand the unresolved v1.20 release-custody discontinuity.
Inspect the fixed E006 continuity contract
Bounded findings
Stable input, archive, parent-contract, binding, duplicate, gap, timestamp, active-content, and limit identities.
No inferred bridges
12 explicit states keep match, mismatch, unavailable, malformed, contradiction, and not-reviewed meanings separate.
Deterministic ledger
artifact-continuity-ledger.json, artifact-continuity-ledger.md, LIMITATIONS.txt, SHA256SUMS.txt.
No continuity badge
Consistent, partial, contradictory, parent-failure, nonconformant, and limit states all require human review.
Verify the E006 ledger contract without turning conformance into provenance.
Verify one NAV-CL-E006 continuity-ledger ZIP and optionally reproduce exact parent-byte observations locally, without uploading artifacts or converting conformance into provenance, custody, trusted time, identity, or approval.
Before selecting files · E007
- Required · NAV-CL-E006 v1.22.0 continuity ledger
- Four-member ZIP; maximum 1 file(s), 8,388,608 bytes per file.
- Optional · NAV-CL-E005 v1.21.0 comparisons for parent replay
- ZIP or JSON; maximum 12 file(s), 4,194,304 bytes per file.
- Optional · NAV-CL-E004 v1.20.0 receipts for parent replay
- ZIP; maximum 12 file(s), 4,194,304 bytes per file.
- Optional · NAV-CL-E003 v1.19.0 packets for parent replay
- ZIP; maximum 12 file(s), 20,971,520 bytes per file.
Exact local action: Verify continuity ledger locally checks the ledger independently. At most 24 optional parent files overall. This page also preflights each parent against its E006 producer-class bound; receipt identity and computation contracts are unchanged.
Aggregate byte limit: 67,108,864 bytes across all selected files.
Files are read only after activation. Reset, replacement or leaving the page cancels pending presentation; in-flight computation and browser memory cannot be securely erased by this page. Use intact producer files, preserve unfavorable diagnostics, and review any output before sharing.
- 01Read the scope and endpoint limitations.
- 02Select one exact E006 four-member ledger ZIP.
- 03Optionally add exact E005, E004, and E003 parent artifacts.
- 04Run bounded ZIP, JSON, artifact, edge, graph, and parent checks.
- 05Review contradictions, unavailable materials, and WIP ancestry.
- 06Download the deterministic receipt, then reset.
No E006 ledger file selected.
No E005 comparison files selected.
No E004 receipt files selected.
No E003 packet files selected.
Continuity-ledger verification result
Ledger structure and graph observations
Optional parent-material coverage
Diagnostics and unresolved state
Conformance does not repair missing provenance.
- Require exactly the four E006 members, their fixed order, stored compression, 1980 timestamp,
0644mode, strict UTF-8, canonical JSON, and exact checksums. - Recompute artifact identities, relationship directions, positive-edge components, diagnostic catalog bindings, human-review state, and the WIP custody boundary.
- Match optional parent artifacts only by exact hashes and accepted E003–E005 identities. Filenames, dates, proximity, and similar prose never create an edge.
- Keep reproduced, contradicted, unavailable, malformed, version-divergent, repeated, and not-reviewed observations separate.
- Every E007 outcome preserves
HUMAN_REVIEW_REQUIRED; none is a signature, notarization, trusted timestamp, authenticity, identity, custody, approval, or legal conclusion.
Inspect the fixed E007 verification contract
Bounded conformance findings
Stable ZIP, checksum, authority, artifact, relationship, graph, parent-recomputation, content, claim, and limit identities.
No inferred reproduction
Reproduced, contradicted, unavailable, malformed, version-divergent, and not-reviewed meanings remain separate.
Deterministic receipt
continuity-ledger-verification-receipt.json, continuity-ledger-verification-receipt.md, LIMITATIONS.txt, SHA256SUMS.txt.
No verification seal
Conformant, partial, contradictory, nonconformant, parent-input, and limit outcomes all require human review.
Unknown and unavailable evidence remain visible.
These values describe support for one bounded claim. They do not replace the audit protocol’s domain result, create a composite score, or authorize favorable summary language after a critical failure.
Supported
The bounded claim is supported by identified evidence for the stated version, configuration, date, and scope.
May be described as supported only with provenance and limitations.Partially supported
Some required evidence exists, but the claim is narrower, conditional, incomplete, or configuration-dependent.
State exactly which part remains unsupported or unknown.Unsupported
The available record does not establish the claim.
Do not restate the claim as fact.Contradicted
Available evidence conflicts with the claim for the documented scope.
Expose the contradiction and require remediation or a corrected claim.Evidence unavailable
Relevant evidence was requested or identified but could not be accessed, produced, or independently reviewed.
Unavailable is not equivalent to pass, fail, or not applicable.Not applicable
The claim or control does not apply to the documented system boundary, with a written reason.
Name the exclusion and reopen it after boundary changes.Not reviewed
The item is in scope but has not yet received the required review.
Keep it open; do not infer a favorable result.Use the register as a challengeable record, not a badge generator.
Set the register boundary
Name the institution, service, decision, deployment context, review period, accountable owner, and explicit exclusions. State that raw inquiry content is outside the register unless a separately authorized, minimized, and documented need exists.
OutputA scope statement that can be challenged before evidence collection begins.Open one record for each material claim
Create a stable record for each claim about privacy, retention, identity, safety, due process, deletion, resilience, or remedy. Do not combine unrelated claims into one favorable narrative.
OutputA traceable set of claim-level records rather than a single score.Classify the evidence
Use the existing AUDIT-E01 through AUDIT-E08 evidence classes. Record observed behavior separately from policy claims, inference, allegation, capability, scenario, and proposal.
OutputEvidence whose type and limits are visible without inventing a second evidence taxonomy.Expose unknown and unavailable evidence
Use explicit status values. Missing records, inaccessible vendor evidence, untested configurations, and unresolved contradictions remain visible; they are never converted into a pass.
OutputA record that preserves uncertainty and refusal boundaries.Apply critical gates before summary language
Resolve every referenced AUDIT-CL-001 critical domain. A critical failure blocks passing or reassuring summary language even when other evidence is strong.
OutputA critical-gate statement with failures, owners, due dates, and retest conditions.Publish a bounded record and schedule the next challenge
Release only the evidence and explanation needed for accountability. Preserve confidential-evidence reasons, limitations, supersession, incident triggers, and the next review date.
OutputA non-certifying public or controlled register that can be re-run after change.Record the minimum proof needed to make each claim inspectable.
Provenance
Make every material claim traceable to a source, observation, custodian, collection date, and integrity reference so a reviewer can distinguish evidence from assertion.
Privacy limit: Do not preserve raw lawful inquiries, named reading histories, prompts, drafts, or inferred beliefs merely to prove provenance. Prefer system-level records, bounded samples, synthetic tests, and redacted receipts.
Required template columns
record_idcontrol_or_claimevidence_statusevidence_tier_idsevidence_locatorprovenance_sourceprovenance_custodiancollected_onintegrity_referenceknown_unknownslimitations
Configuration and version scope
Bind findings to the exact system, model, release, configuration, region, account state, data flow, and test date that produced the evidence.
Privacy limit: Describe configuration and test conditions without embedding a person’s lawful inquiry history or exporting production cognitive dossiers.
Required template columns
system_or_processproduct_or_model_versionbuild_or_releaseconfiguration_scopedeployment_region_or_contexttest_account_statetest_datedata_flow_scoperetention_scopeknown_unknownslimitations
Policy authority
Identify the rule, decision body, approval date, scope, vendor obligation, exception, and sunset authority that governs the control being claimed.
Privacy limit: Authority records should govern data and power; they should not become a justification for collecting more inquiry content than the control requires.
Required template columns
policy_or_authority_titlepolicy_or_authority_locatorapproving_body_or_roleapproval_dateeffective_dateauthority_scopevendor_clause_scopeemergency_exception_scopesunset_or_expirylimitations
Deletion evidence
Record what data or inference was deleted, under which rule, by which method, when deletion completed, how downstream copies were addressed, and what receipt or test supports the claim.
Privacy limit: A deletion record should prove control operation without retaining the deleted inquiry content inside the evidence register.
Required template columns
data_or_inference_classdeletion_ruledeletion_methoddeletion_completed_ondeletion_verification_methoddownstream_deletion_statusdeletion_receipt_or_logexceptions_or_holdslimitations
Remediation ownership
Give every finding an accountable owner, bounded corrective action, due date, retest method, challenge state, and closure evidence.
Privacy limit: Assign responsibility for systems and controls, not suspicion scores or labels attached to people because they asked lawful questions.
Required template columns
finding_or_issue_idremediation_owner_roleremediation_actionpriority_or_gatedue_dateretest_methodretest_datechallenge_or_appeal_stateclosure_evidence_locatorresidual_risklimitations
Incident triggers
Predefine the event, threshold, owner, containment action, affected evidence areas, notification duty, and re-audit scope that reopen the register after harm or material change.
Privacy limit: Incident response must target a defined failure or harmful event; it must not treat curiosity, privacy-tool use, or controversial lawful inquiry as an incident by itself.
Required template columns
incident_triggertrigger_thresholdobserved_onincident_owner_rolecontainment_actionaffected_evidence_area_idsnotification_or_notice_dutyreaudit_scopeincident_record_locatorlimitations
Re-review dates
Preserve the last review, next review date, lifecycle assumptions, material-change triggers, monitoring owner, and supersession chain for every material claim.
Privacy limit: Review schedules should track controls, versions, authorities, and incidents—not maintain a longitudinal profile of what named people read or ask.
Required template columns
last_reviewed_onnext_review_datereview_cadencematerial_change_triggerslifecycle_assumptionsmonitoring_owner_rolesupersedes_record_idsuperseded_by_record_idreview_outcomelimitations
Complete one sheet for each material control or claim.
Compare continuity-verification receipts
Keep matching bytes, matching structural results and changed observations separate. Drift is not improvement. Structural conformance is not provenance. This comparator checks two current E007 receipt bundles; it does not judge the underlying evidence or approve publication.
Before selecting files
Processing stays in this browser after you explicitly activate Compare. There is no upload, application network request, account, telemetry or browser storage. Local processing is not anonymity, privilege, confidentiality, endpoint protection or secure deletion. Extensions, operating-system tools, swap, backups, print, downloads and later disclosure remain outside this boundary.
An E007 receipt ID is not a signature. Its existing derivation does not directly bind all diagnostic text. This tool verifies complete receipt bytes and reports fresh reproduction separately when you select the exact ledger and recorded supporting artifacts.
Baseline and candidate are the roles you choose, not proof of which was created first. Missing optional artifacts remain unavailable; repeated identical artifacts are not independent corroboration. The unresolved accepted-v1.20 release ancestry remains WIP.
Comparator contract
First-party current contract and dependency-free offline implementation.
Offline toolkit v1.26.0 (contract v1.24.0)
First-party current contract and dependency-free offline implementation.
Six-step review workflow, including without JavaScript
- Obtain two current E007 receipt ZIPs and choose their baseline and candidate roles.
- Inspect the selection counts and byte sizes before activating local comparison.
- Review fatal input findings before interpreting any recorded differences.
- Read changed diagnostic codes, component checks, coverage, contradictions and source-declared dates without inferring improvement or chronology.
- For fresh replay, select the exact recorded E006 ledger and E005, E004 and E003 artifacts. Complete replay, incomplete replay and unavailable replay are distinct.
- Download the comparison record, perform human review, then reset. Preserve removed diagnostics as historical observations.
The offline toolkit performs the same bounded checks without a browser. From the extracted toolkit, run:
python -B tools/continuity_receipt_comparator.py --baseline first.zip --candidate second.zip --output comparison-result
Optional repeatable flags: --ledger, --comparison, --receipt, --packet. Do not overwrite selected originals. No dependency installation or network access is required.
Limits: two receipt bundles up to 2 MiB each; up to 16 optional files; 8 MiB per ledger; 20 MiB per other parent; 32 MiB total. Only the exact four-member stored-ZIP contract is accepted. No decompression is attempted. JSON, member, diagnostic and output bounds are also enforced.
Before selecting files · E008
- Required · Baseline NAV-CL-E007 v1.23.0 verification receipt
- Intact ZIP; maximum 1 file(s), 2,097,152 bytes per file.
- Required · Candidate NAV-CL-E007 v1.23.0 verification receipt
- Intact ZIP; maximum 1 file(s), 2,097,152 bytes per file.
- Optional · Exact NAV-CL-E006 v1.22.0 ledgers for fresh replay
- ZIP; maximum 16 file(s), 8,388,608 bytes per file.
- Optional · Exact NAV-CL-E005 v1.21.0 comparisons, E004 v1.20.0 receipts and E003 v1.19.0 packets
- Producer ZIPs in the matching selectors; maximum 16 file(s), 20,971,520 bytes per file.
Exact local action: Compare selected receipts locally checks both receipt bodies and reports differences. At most 16 optional files overall. Complete replay requires the exact ledger and every recorded supporting input, including repeated observations. Missing or incomplete inputs remain unavailable; an accepted receipt alone is an assertion.
Aggregate byte limit: 33,554,432 bytes across all selected files.
Files are read only after activation. Reset, replacement or leaving the page cancels pending presentation; in-flight computation and browser memory cannot be securely erased by this page. Use intact producer files, preserve unfavorable diagnostics, and review any output before sharing.
Local receipt comparison
Choose both receipt bundles to enable Compare. File selection only inspects counts and sizes; it does not read contents. All output requires human review.
Optional exact supporting artifacts for fresh replay
Only a recorded hash-and-class match can support replay. Filenames, selection order and dates are not evidence of a relationship.
JavaScript is required for local comparison. Offline instructions remain available.
Bounded observation differences
Findings and unresolved state
Download review records
Use one register contract across institutions without duplicating any kit body.
Libraries and knowledge institutions
Connect circulation, search, authentication, vendor, records, deletion, and challenge evidence to the library kit without retaining patron reading or inquiry histories.
Priority evidence areasSchools, universities, and research institutions
Connect student, educator, classroom, assessment, vendor, safeguarding, appeal, and incident evidence while preserving age- and power-sensitive limits.
Priority evidence areasJournalists, independent newsrooms, and exile media
Connect newsroom, source-protection, exile-media, publication, archive, operational-security, and continuity evidence without exposing source or research trails.
Priority evidence areasPublic-interest software, privacy engineering, and rights-respecting AI
Connect architecture, model and dependency versions, tests, remediation ownership, reproducibility, and lifecycle evidence to public-interest technology delivery.
Priority evidence areasRights-respecting public institutions, regulators, courts, and public-sector AI
Connect legal authority, procurement, records duties, deletion, due process, emergency powers, remediation, and public accountability to institutional operations.
Priority evidence areasResolve each domain to evidence areas while AUDIT-CL-001 remains authoritative.
The source crosswalk stores IDs only. Domain names, questions, and critical-gate classes below are resolved at render time from AUDIT-CL-001.
Defend the conditions of private inquiry.
Cognitive liberty means having room to ask, learn, doubt, remember and change your mind without handing a government or company a standing claim over that process. The tools through which people think should widen their choices, not turn lawful inquiry into a series of permission requests.
Private preparation must not become a premium privilege
People should not have to buy an expensive professional relationship merely to think privately with a tool. Protect the private work of understanding a problem without turning the tool into a hiding place for underlying evidence.
Objection. Protecting machine-assisted preparation would hide evidence, so users should lose confidentiality when they use inexpensive computational assistance.
Response. The remedy does not follow from the concern. A protected-deliberation rule can leave underlying records, independently obtainable evidence and evidence of fabrication or concealment available through appropriate process. Protecting a private route through the facts need not shield the facts themselves. Price and machine mediation are poor substitutes for examining genuine confidentiality and the actual material sought.
An evidence demand is not a license to redesign everyone's privacy
A demand for one record should not become a standing power over everyone's future conversations. Judge the reach of an access mechanism by what it can expose, not only by promises about who will use it.
Objection. Investigators need access to evidence, and a warrant limits each use; therefore providers should maintain a reusable access mechanism.
Response. A decision about access to one target does not settle the separate decision to expose other users to a persistent capability. Administrative limits on authorized use do not establish the technical reach or security of the mechanism. The proposed architecture needs its own necessity, scope and non-target-risk analysis; its effects cannot be justified solely by invoking the later warrant.
Keep anonymous access practical
Reading should not routinely require an identity transaction. Where eligibility must be checked, reveal no more than necessary and do not turn a failed check into permanent exclusion from lawful information.
Objection. An identity or age check is only a minor inconvenience, and deleting the submitted information resolves the privacy issue.
Response. Deletion addresses one stage, not the whole restriction. It does not by itself remove forced identification at entry, a verifier's gatekeeping role, an issuer's separate record, or denial caused by a mistaken result. A claim that the service sees only a yes/no answer is not proof that the entire process is anonymous. The burden must be assessed across the full access path.
Distinguish chosen inquiry from imposed exposure
A person deliberately asking a question is not the same as an audience being pushed toward a harmful feed. Protect inquiry by addressing the actual harm, not by making the subject itself unavailable.
Objection. If a subject can be harmful in an online feed, access to that subject should be restricted in private research as well.
Response. The comparison changes the activity, audience and mechanism. Deliberate study is not the same as unsolicited amplification, and discussing harmful conduct is not identical to carrying it out or encouraging it. Evidence about one exposure pathway does not establish the necessity of suppressing another. An applicable restriction should identify the actual harmful mechanism rather than use the topic as a proxy.
Evaluate restrictions against the realistic no-help alternative
A protection that leaves a person with no usable help must account for that loss. Evaluate tools by the task, the evidence and the choices people actually have—not against an ideal professional service they cannot obtain.
Objection. Automated help can be wrong, so compulsory professional intermediation is necessarily safer than allowing people to choose it.
Response. That comparison assumes affordable, timely professional help is actually available. For preliminary understanding, the practical alternative may be no help. Evidence of errors in one task supports testing and safeguards for that task, not a conclusion that all assistance must be withheld. A permanent provider-identity barrier also prevents future evidence of competence from changing eligibility.
Match the remedy to the demonstrated harm
Correct the demonstrated harm without erasing unrelated lawful work. Temporary danger must not become permanent power over a person's memory, projects or access to tools.
Objection. A system has used improper data or presents a dangerous capability; therefore its whole operation and every associated memory may be permanently eliminated.
Response. The concern supports addressing the proven problem, not automatically destroying unrelated lawful work. Identify the affected object and test whether a narrower effective remedy removes the harm and any retained wrongful benefit. Where emergency containment is needed, urgency does not itself establish permanent necessity. Review, duration and restoration must remain real.
Make these protections practical. Check live conversations, retained memory, backups, integrations, keys and administrator access separately; no-training is not no-retention. Test whether an export is usable elsewhere. Respect another person’s withdrawal of private material: continuity is not a reason for hidden copies, revived revoked credentials or access beyond valid authority. The local checking tools do not establish legal privilege, successful deletion or restored rights.
An exit or appeal must remain usable
An alternative service is not a meaningful choice when leaving means losing the lawful work you came to do. A right to appeal is equally hollow when a suspension destroys the records or blocks the access needed to challenge it.
Objection. A provider can end a service, and any mistake can be corrected later, so a transition path or preservation measure is unnecessary.
Response. That assumes the work can be moved and the loss can be repaired. Preserve a usable export, a reasonable non-emergency transition, and the minimum safe means to retain relevant records and seek review. This need not keep a disputed harmful operation running or transfer another person’s private material, unlicensed assets or revoked credentials. A remedy for a specific problem should not silently destroy unrelated lawful work.
Editorial adaptation of selected passages in AEA Infrastructure Purchasing Rights, AEA Financial Capabilities Research and AEA Procedural Protections Research. These reports concern proposed Autonomous Economic Agents; this passage applies selected distinctions to people’s private inquiry. The underlying preservation and escrow designs are proposals, not newly verified legal duties.
These are reform arguments, not newly verified legal findings or additional record fields. See protection against mental profiling, origin without a credibility penalty, and how the argument is tested.
Argument origins. Editorial synthesis from selected passages in the supplied related-site reports: Machine Deliberation Legal Research; UK and AU Access Architecture; Age Assurance Legal Comparison; Online Safety Duties Research; AI Legal Boundaries Assessment; Remedy and Shutdown Legal Analysis. These report titles identify the source of the argument, not independently verified legal authority. The objections are editorial paraphrases, not quotations attributed to a regulator.
A complete pathway leaves evidence, not a badge.
Record each item below with an accountable owner, version or date, evidence location, known limitation, and next review trigger. Do not attach raw query, prompt, reading, or draft histories merely to prove that privacy work occurred.
Owner: ____________________ Date/version: ____________________
Evidence and limitation: ____________________________________________
Owner: ____________________ Date/version: ____________________
Evidence and limitation: ____________________________________________
Owner: ____________________ Date/version: ____________________
Evidence and limitation: ____________________________________________
Owner: ____________________ Date/version: ____________________
Evidence and limitation: ____________________________________________
Owner: ____________________ Date/version: ____________________
Evidence and limitation: ____________________________________________
Owner: ____________________ Date/version: ____________________
Evidence and limitation: ____________________________________________
Reopen the decision after material change.
Repeat the affected stages and supersede the affected evidence records after a new vendor, model, data flow, identity requirement, legal demand, security incident, retention practice, standards revision, project maintenance transition, unavailable-evidence change, or failed retest. Preserve the prior decision and its limits; do not rewrite history merely because the current answer changed.
Print note: this page is fully server-rendered. Browser print produces a multi-page pathway and register without navigation chrome, decorative backgrounds, or JavaScript. The downloadable templates remain the machine-readable and offline working formats.