The rules that decide what gets published, and what stays empty.

Sourcing and verification

A record that makes a factual claim carries a verified field. Setting it to true requires a source and a check date; the validator rejects the record otherwise. Templates are forbidden from rendering an unverified claim without a visible marker.

Absent means absent. A missing number renders as a typed slot with the source an editor must check — never as a zero, a dash without explanation, or an estimate. Three of the four items on the homepage evidence strip are currently empty for exactly this reason.

Primary sources are preferred and secondary summaries are not sufficient to flip a verification state. Where a claim rests on an inference rather than a source, the page says which sentence is the inference.

Corrections

• A correction that changes a factual claim moves the page’s editorial-check date and is listed in the next Pulse issue.
• A correction that changes an interpretation is applied and noted inline where the interpretation was.
• We do not silently edit a published claim. If it was wrong, the change is visible.
• Contributors are credited by the name they give unless they ask not to be.

Comparisons

• One task, stated first. A comparison without a task statement and constraints does not publish.
• No ratings. There is no score, star or grade field in the content model. Dimensions carry a lean, a confidence level and the basis for both, or they are not published.
• Benchmarks or silence. If no benchmark was executed on measured hardware, the results section says not run and stays empty. We do not repeat numbers from hardware we did not measure.
• Limitations are mandatory. The validator rejects a comparison with an empty limitations array.
• Conclusions against Perl publish identically to conclusions for it, in the same template, with the same prominence.

Code examples

• Every article carries a codeTested flag, and it is rendered on the page. It is false across this build, and the badge stays until an automated run exists.
• Examples name the versions they were written against.
• Historical code that demonstrates a vulnerability is reconstructed rather than quoted, is labelled as a reconstruction, and carries a do-not-deploy marker.

Independent Perl review

Technical pages have a machine-readable review record. Editorial source checking is not the same as independent Perl approval, and the register never invents a reviewer, timestamp or reviewed commit.

1. Classify the claims. Executable Perl guidance, security conclusions, production-readiness claims, benchmark verdicts and any codeTested: true Perl claim require independent review.
2. Declare independence and scope. The reviewer states relevant Perl experience, conflicts and exactly which claims and examples were reviewed.
3. Review a fixed packet. The packet contains the public page, exact Git commit, primary sources, runnable tests and the stronger claims currently blocked.
4. Record one outcome. Approval, corrections required or rejection is written to the register. Approval requires the reviewer’s consented name, timestamp and reviewed commit.
5. Keep pending honest. Until approval, the page visibly says review is pending and cannot claim independent approval, production readiness, a security guarantee, a benchmark result or tested Perl code without matching evidence.

A pending independent review does not automatically unpublish or noindex an existing page. It limits the strength of its claims. A separate factual, legal or safety blocker can still require correction or removal.

The Archive

• Entries record software that is discontinued and carry that status visibly at the top of the page, in the same words every time.
• No source code, binary, screenshot or manual is redistributed. Entries hold the product name, historical URLs and a neutral description.
• A download control renders only when a record explicitly sets downloadAllowed: true. No record currently does.
• A reconstructed purpose is labelled as reconstructed. Where nothing is known, the field stays blank and the page says so.
• An empty advisory list still requires a written note, so that absence is never read as a safety claim.

Historical artifacts

An image renders only with a complete rights record: rights holder, rights status, source URL and capture date. Without all four, the artifact is recorded as a reference and not displayed. There is no “probably fine” category.

No event on the current Timeline displays an artifact. That is not an oversight — it is what the rule produces when nothing has cleared it yet.

Community submissions

• No submission is published without editorial review. There is no path from a form to a public page that bypasses a person.
• We store what you send and a reply address. Nothing else, and nothing is passed to a third party.
• Comment threads are hosted on GitHub Discussions and load only after explicit consent.
• The code of conduct applies to every channel we operate.

Community metrics

There is no member count, reaction count, view count or leaderboard on this site, and those fields do not exist in the content model. If a future release adds them they will be derived from real recorded events and will carry the same verification discipline as everything else.

Disclosure

• Common ownership never creates an editorial recommendation, a sitewide link or a reason to publish a page.
• A research report names any material tool or dataset used to produce its result.
• There is no sitewide keyword link, homepage banner, navigation entry, or call to action on history and archive pages.
• Archive and history pages do not carry product calls to action.
• No advertising, no sponsored content, no affiliate links in this build. If that changes, this section changes first.

Generated content

Editorial tooling may be used in drafting. It does not change any rule above: a claim still needs a source and a benchmark still needs a run. A reviewer identity or approval date appears only after a real, consented review. Nothing publishes because a tool produced it.