Reference methodology, sources & versioning

Source hierarchy

Prefer original evidence, official specifications, and primary technical documentation for questions they actually address. Use peer-reviewed research with attention to its data, method, and tested population. A source’s reputation does not establish transferability to a different platform, version, or case object.

Evidence and source dependence

Directly acquired records, documented integrity checks, controlled experiments, and independent corroboration can support different parts of a claim. There is no single ranking that makes one source decisive in every case. Evaluate authenticity, acquisition scope, completeness, and dependence for the particular proposition.

Two records can share a backend, tool, or upstream assertion. Label that relationship before calling them independent. A readable export is not inherently more complete than a database, and a database is not inherently more truthful than another source.

Verification and reproducibility

For software behavior, record environment, application version, account state, actions, repetitions, controls, raw observations, and limits. Link supporting objects with identifiers and hashes. This release publishes no application-specific artifact findings; the demonstration report is a format example only.

For external sources, store title, publisher, URL, source class, and last-verification date. A retrieved document and a successful link check do not amount to experimental validation. The standards catalog makes access limits explicit.

Confidence vocabulary

Use these labels for evidence-supported statements. They are descriptors, not a numeric scale, and they need not be mutually exclusive across all parts of a finding. Never convert them into invented percentages.

Vendor claims and neutrality

Vendor documentation is appropriate for that vendor’s stated interfaces and claims. It is not independent evidence of accuracy, completeness, recoverability, or performance. Mark a behavior as documented by a vendor separately from behavior observed and replicated under a stated test. Do not rank products or sell detector certainty.

Source verification and fact checking

Check technical sources against their official publications and record which edition and scope were examined. Source verification and independent technical review are distinct activities. Independent technical review is recorded separately from source checks and editorial updates. Project attribution identifies responsibility and does not imply a completed independent review.

Consequential factual claims require inspectable supporting material. Verify citations and the relationship between each source and the claim it supports. Corrections should replace unsupported wording and preserve material changes in the correction log.

Review cadence

Recommended review interval: every 90 days for AI artifact, agent, provenance, standards, and software-specific material, and after a consequential source or software change. General terminology and policy pages should be considered at least annually. These intervals guide maintenance; source checks, editorial updates, and independent review have separate records.

Keep source verification, editorial update, and independent technical review dates separate. A null last-reviewed value in JSON means no independent review date is recorded. Update an Artifact Report’s Last Verified only after an actual verification experiment.

Semantic versioning and archives

Preserve materially superseded versions

SFIF Draft 0.1 has its own specification version, separate from the website version. Preserve materially superseded references through Git history, tags, changelogs, and archived release packages where practical. This workspace began without Git; the release manifest therefore records a null commit rather than a fabricated identifier. A Git-backed release records its actual commit.

For a permanently renamed page, prefer a permanent redirect from the old canonical URL after checking links and fragments. Do not rename stable URLs for keyword changes. Stable canonical paths preserve existing links; application routes use their own scoped handlers.

Reference, Blog, and Journal

The root site is a versioned technical reference. Blog and Journal use private drafts, assigned human review, and explicit release decisions with separate publication lifecycles. A reference draft is not a peer-reviewed journal article, and commentary does not automatically become a tested Artifact Report.