TRANSPARENCY — HOW WAE KNOWS

A SYSTEM THAT CAN SHOW ITS WORK.

This page explains the machinery of knowing: the status vocabulary, the Evidence Trace, the public projection boundary, and what WAE deliberately does not expose. Written for a serious outsider.

STATUS VOCABULARY

Every claim and every entity carries exactly one canonical status:

  • OBSERVED

    The thing exists and was recorded as seen.

  • ASSERTED

    Attributed to a source that stated it — no qualifying evidence chain.

  • VERIFIED

    A complete, passed verification chain binds eligible real evidence to the claim.

  • INCOMPLETE

    Partial support recorded; not resolved.

  • UNAVAILABLE

    Known to be absent or inaccessible.

  • UNKNOWN

    Not established in available evidence — a precise state, never hidden.

  • DISPUTED

    Recorded disagreement over the item's standing.

The public interface derives its states from canonical records. Display code cannot upgrade ASSERTED to VERIFIED, and cannot downgrade a canonical state to make a page look safer.

THE EVIDENCE TRACE

Every claim renders as a six-stage chain:

SOURCE → EXPORT → NORMALIZATION → VALIDATION → VERIFICATION → RECORD

A stage is OBSERVED only when an activity connected to the claim's evidence graph materializes it. Absent stages render as NOT ESTABLISHED — visible, not hidden. For the asserted 1.25B+ claim, only SOURCE and RECORD are observable; the chain honestly shows the gap.

VALIDATION vs VERIFICATION

Validation checks data and process against defined technical rules — checksum equality, structure, numeric sanity, missingness. Verification evaluates whether validated evidence supports a specific claim under an explicit method. They are different stages in the same chain, and only the last can resolve a claim.

THE PUBLIC PROJECTION

Canonical evidence records contain sensitive fields: raw per-asset rows, account handles, internal source paths, repository identities, and full digests of internal artifacts. These never leave the internal record.

One projection boundary converts canonical records into public material. It is an allowlist, not a serializer: undisclosed fields are dropped, entity names are policy-mapped, and digests follow a deliberate policy —

  • TRUNCATED

    Non-vendored artifacts referenced by the kernel: a 16-character public fragment, clearly labeled.

  • DENIED

    Internal derivatives and everything else — no digest appears. Full SHA-256 digests of internal artifacts are never published: a full deterministic fingerprint can be tested against candidate files.

Public HTML, JSON-LD, the machine surface, and the ASK WAE corpus all consume this same boundary — including the frozen answers, which resolve only against public-safe structures. The build fails if the boundary is bypassed or its output goes stale.

WHAT IS NOT EXPOSED

  • Raw export rows and per-asset sensitive content.

  • Account handles and private repository identities — WAE's development record is internal.

  • Full SHA-256 digests of internal artifacts (only labeled 16-character fragments are published).

  • Internal source paths, repository coordinates, commits, and operational details.

The aggregate derivative behind the verified record is maintained within WAE's governed evidence source. Its public surface is the record itself: 1,269 content assets, 272,807,236 lifetime views, and the trace that binds them — never the derivative bytes or their storage coordinates.

FRESHNESS & REVISION

Public material is generated deterministically from canonical records and carries a fingerprint. Before every build, the committed public corpus and the machine surface are recomputed and compared byte-for-byte against the canonical records. If source records change without regeneration, the build fails — stale machine output cannot silently ship.

Current public corpus fingerprint:3a676e062712…· materialized 2026-08-30· machine surface