SALT19
Trust · security · validation boundaries

Trust is an engineering property, not a marketing adjective.

SALT19 separates software controls, runtime authority, public evidence and external certification. This page states what controls exist today, where validation comes from, and what has not been independently certified.

Security contact & policy ↗Validation recordReplication

Current trust controls.

These controls are implemented in the current public web/infrastructure or source architecture. They are not presented as equivalent to third-party compliance certification.

Public web

Baseline browser security headers

SALT19's static site declares HSTS, a Content Security Policy, same-origin opener/frame controls, MIME sniffing protection, a strict referrer policy and a restrictive browser permissions policy. Canonical pages are configured to revalidate rather than remain indefinitely stale at the edge.

Security reporting

Published security contact

/.well-known/security.txt publishes the canonical security contact, preferred language, policy location and expiration date. Security reports route to info@salt19.com.

Site integrity

Automated public-surface checks

Repository workflows enforce public-security integrity, link/site checks, responsive checks and canonical discovery surfaces. Search submission is gated on the updated canonical deployment being externally observable.

Agent Utility Grid

Payment and execution are separate evidence states

x402 challenges, settlement checks, semantic operation identity, idempotency, durable receipts and revenue reconciliation are treated as explicit machine-commerce contracts. An unpaid challenge, crawler hit or directory listing is not counted as a buyer.

TacWing-X

Models do not own physical authority

Current production policy keeps physical platform commands operator-authorized. Perception, localization, federation and the experimental meta-evaluator cannot bypass the canonical governor; the ROS 2 companion bridge has no actuator-command message.

TacWing-X release chain

Signer identity and model integrity are pinned

The Android release path records a canonical signer certificate fingerprint, verifies APK signer identity fail-closed, and separately verifies the pinned local ONNX perception model by SHA-256.

Evidence classes are kept distinct.

Source-code evidenceShows that a control, boundary or algorithm is implemented in the reviewed source. It does not prove physical behavior, customer value or regulatory approval.
CI / automated validationShows that defined tests or build gates pass in the tested environment. It does not replace hardware-in-the-loop, field or independent laboratory evidence.
Live production evidenceShows that a service or public surface is reachable and satisfies a defined runtime contract. It does not by itself demonstrate commercial demand.
External discovery / indexingShows that outside directories or research indexes can discover and classify work. It is not certification, peer review or independent replication.
Independent validationRequires a genuinely independent evaluator, benchmark, replication, pilot or testing body. SALT19 labels this separately and does not infer it from internal evidence.

Certification boundary.

SALT19 is early-stage. Where a certification or authorization has not been obtained, the site should say so rather than imply equivalence through engineering controls.

Not currently claimed: SOC 2 certification, ISO 27001 certification, FedRAMP authorization, government Authority to Operate, production-certified flight autonomy, independently certified AGI, universal hardware compatibility, or third-party validation of every published benchmark. Product-specific pages define narrower evidence boundaries.

Need to evaluate SALT19 before a pilot, partnership or investment?

Start with the public diligence, validation and replication surfaces. Qualified private diligence can go deeper into architecture, security controls and deployment requirements.

Public diligence roomTechnical diligence ↗