The public repository should optimize for engineer verification, not ceremonial language.
First-screen order
What VELION is.
What can be run now.
Five-minute demo.
Test and benchmark commands.
Current limitations.
Architecture and roadmap.
Authorship and governance references.
Claims policy
One canonical explanation per concept; link instead of repeating.
No keyword stuffing or duplicated SEO paragraphs.
No fabricated stars, users, partners, deployments, benchmarks, revenue, or adoption.
Use concise authorship once in the README footer/about section.
Keep internal organizational hierarchy out of the quick-start path unless needed to explain a security boundary.
Visibility policy
Visibility must be earned through useful public artifacts: runnable code, releases, reproducible examples, issue discussions, technical write-ups, and external references. Never fake engagement.
Status rule
A public claim may only move from PLANNED to IMPLEMENTED, TESTED, DEPLOYED, or LIVE_VERIFIED when matching evidence exists.