Authority order
-
01
Current code and visible behavior
The deployed PHP, data registries, JavaScript, headers, routes, and rendered content define what the site actually does.
-
02
Passing tests and release proof
Automated checks support claims about syntax, routes, local-only runtime, report hashes, memory pointers, and discovery parity.
-
03
Accepted decisions and architecture
Current .uai records and reviewed durable documents explain why the implementation has its present shape.
-
04
Reviewed research synthesis
Public pages promote bounded conclusions that recur across stronger report sources and preserve material uncertainty.
-
05
Preserved reports and proposals
Full reports remain available as inputs but do not automatically become current fact or product behavior.
Evidence hierarchy
| Class | Use on the site | Boundary |
|---|---|---|
| Official primary source | Doctrine, policy, program descriptions, standards, and formal requirements | Still evaluated for date, scope, and what it does not establish |
| Reviewed analytical report | Synthesis, comparison, questions, architecture implications | Claims remain qualified and traced to the underlying source class |
| Interactive explanatory model | Makes relationships and failure modes understandable | Uses abstract, deterministic teaching values only |
| Synthetic scenario | Demonstrates tradeoffs and recovery logic | Never represented as a real system, target, performance figure, or forecast |
Report promotion and .uai routing
Every uploaded report is stored under /docs/long-term-memory/reports with a stable ID and exact SHA-256 digest. The .uai long-term-memory ledger points to every body. Subject-specific conclusions are compacted into the memory file that owns them—architecture, constraints, context, decisions, or report synthesis—rather than copying full reports into startup memory.
A research-input label means the report is preserved and useful. It does not mean every claim is independently verified, current, or suitable for a concise public answer.
Synthetic model
The Explorer, scenarios, ACK Lab, interoperability checks, and authority controls use fictional nodes, abstract capabilities, illustrative scores, and deterministic rules. They are designed to teach structure, evidence, authority, and graceful degradation.
They do not model real targets, unit locations, weapon performance, casualty outcomes, operational latency, or command decisions.
Safety and non-operational boundary
- No real targets, exact operational coordinates, active unit locations, or vulnerable infrastructure
- No casualty assumptions, destructive-efficiency scoring, or weapon construction
- No functional malware, exploit commands, credential harvesting, or arbitrary external actions
- No ranking of countries, systems, or organizations by lethality or simulated harm
- No browser access to private .uai memory, internal reports outside the allowlisted controller, credentials, or unpublished files
Corrections and limitations
Readers can report an error using the public contact address. Corrections should identify the page, claim, source, and reason. The release line records accepted changes.
Public information about military systems is incomplete by design. The site distinguishes documented public facts, analytical synthesis, illustrative engineering values, allegations or disputes, and public unknowns.
Implementation basis: KW-RPT-001; doctrinal comparison basis: KW-RPT-014.