UAIX has moved part of the launch-stage trust posture from roadmap prose into observable runtime behavior by adding a public security-header layer to WordPress-rendered responses and documenting the result directly on the site.
What changed
- Policy and Security now publishes the current response-header posture, including what is enforced in WordPress and what still belongs to deployment infrastructure.
- API Reference now shows the same hardening beside the live REST handbook so machine-facing review does not depend on scattered notes.
- Public WordPress-rendered HTML and REST responses now emit
X-Content-Type-Options,Referrer-Policy,Permissions-Policy,X-Frame-Options, andContent-Security-Policy: frame-ancestors 'self', while any host-added version headers remain a deployment-side cleanup task.
How to use this update
- Use Policy and Security when a launch review needs the current trust posture in one place.
- Use API Reference, Validator, and Conformance Pack when the next check is whether the machine-facing surface and the written posture still agree.
- Keep Governance, the Changelog, and News attached when broader HTTPS or edge changes land, because those deployment-facing steps are still separate from the WordPress response layer.
Boundary note
This hardening makes the public WordPress surface more honest and reviewable, but it does not replace edge responsibilities. HTTPS redirects, HSTS, parity for directly served static root files, and suppression of host-level version disclosure should still be validated on the launch host.
Why this matters
UAIX becomes easier to trust when the security posture published on the policy page is visible on real responses instead of existing only as roadmap text. This update closes part of that gap while keeping launch claims narrower than a full production security program.