Independent Safety Layer
Critical limits are enforced outside adaptive mission logic so a compromised or degraded model cannot unilaterally redefine its own boundaries.
ASSURANCE
Evidence first. Certifications only when proven.
A program office or prime needs to know what is actually verified, what is merely a design principle, and what depends on the contract environment. WeaponizedAutonomy.com separates repository-level software evidence from enterprise certifications, CUI/classified authorization, and customer acceptance authority.
TRUST MODEL
What assurance evidence exists now?
The current repository verifies a first-party public runtime, explicit deployment allowlist, local security configuration, versioned publication process, automated consistency checks, and an unclassified public-information boundary. It does not convert those engineering facts into a CMMC, FedRAMP, ISO, SOC, ATO, FCL, or other certification claim.
ASSURANCE DUE DILIGENCE
Questions a security, engineering, or supply-chain reviewer should ask.
These answers are generated from the same procurement profile used on the contracting page so visible claims and machine-readable facts cannot silently diverge.
| Assurance question | Public status | Current answer |
|---|---|---|
| Does the public website require third-party runtime services or remote assets? | Repository verified | No. The current release is built to run from first-party PHP, HTML5, CSS, browser-native JavaScript, local images, and local content with no required CDN, hosted font, analytics, advertising, external API, authentication provider, or remote JavaScript dependency. |
| Is the public deployment surface explicitly controlled? | Repository verified | Yes. Production packaging uses an explicit root-deploy allowlist and automated checks that exclude development memory, tests, tools, handoff material, and internal documentation from the preferred public artifact. |
| Are browser security controls configured in source? | Repository verified | Yes. The PHP and web-server configuration define a same-origin Content Security Policy, frame denial, MIME sniffing protection, restrictive Permissions Policy, referrer controls, cross-origin policy, and HSTS max-age. Delivery of those headers by the live production origin remains a separate deployment verification step. |
| Is the public site approved to receive CUI, classified information, export-controlled technical data, credentials, or sensitive program data? | Public-site boundary | No. The verified public-site boundary is unclassified business and research information only. The site explicitly instructs users not to transmit CUI, classified information, export-controlled technical data, target data, mission data, vulnerabilities, credentials, or weapon-employment parameters. |
| Does the public website have automated accessibility and performance quality gates? | Repository verified | Yes. The release process performs first-party static checks informed by WCAG 2.2 AA, including landmarks, heading structure, keyboard-visible focus, target sizing, reduced-motion behavior, image alternatives, table headers, and positive-tabindex prevention, plus source-level CSS, JavaScript, asset, HTML, and decorative-animation budgets. These checks are not represented as a WCAG conformance certification, assistive-technology usability study, browser/device matrix, or field Core Web Vitals measurement. |
| Does this website claim CMMC, FedRAMP, ISO 27001, SOC 2, ATO, or another enterprise certification? | Not publicly asserted | No. Repository-level software controls and tests are not presented as enterprise or program certifications, and no such current certificate or authorization evidence is stored here. |
| How are public software changes checked before release? | Repository verified | The repository uses versioned configuration, canonical route/publication metadata, PHP syntax checks, smoke tests, remote-origin checks, publication-consistency checks, deploy-surface checks, UAIX memory checks, JSON/XML validation, and versioned release packaging. |
| What software supply-chain evidence is available? | Repository verified | For the public website, the repository provides an explicit deployment file inventory, first-party runtime boundary, local asset policy, release versioning, and tests against remote runtime dependencies. This is not represented as an enterprise SBOM, CMMC artifact, or customer-program supply-chain approval. |
| Is there a public vulnerability-reporting path? | Repository verified | Yes. A same-origin security.txt and security contact address are published. The repository does not prove mailbox monitoring or a response-time SLA, so neither is claimed. |
| How does the machine-intelligence operating model preserve engineering accountability? | Repository verified | Reviewable evidence centers on source changes, configuration identity, tool use, test outcomes, version history, assumptions, outputs, and explicit authority boundaries. Machine intelligence does not inherit contracting, certification, command, or weapons-release authority from its technical role. |
| Can program-specific assurance evidence be supplied? | Contract dependent | The site's stated service capabilities include test evidence, traceability, SBOM-oriented integration practices, configuration baselines, runtime constraints, and change-impact analysis. The exact evidence package, accreditation boundary, data rights, and customer acceptance criteria must be defined by the applicable program and contract. |
ENGINEERING ASSURANCE
The evidence case behind autonomy claims.
Program-specific assurance still requires customer-owned requirements, threat models, environments, authorities, test infrastructure, and acceptance criteria. The public site describes the engineering method; it does not pre-approve a weapon system.
Traceability
Requirements, policies, software/model versions, interfaces, tests, approvals, assumptions, and field observations are connected in a reviewable evidence chain.
Operational Envelope Monitoring
Runtime checks detect when sensor quality, communications, environment, configuration, or system health leave validated conditions.
Cyber Resilience
Identity, update integrity, least privilege, separation of duties, tamper resistance, recovery, and security monitoring are treated as mission-assurance concerns.
Human Factors
Control is evaluated by demonstrated operator understanding and intervention capability under realistic workload—not simply by drawing a human icon in a loop.
Revalidation Discipline
Material changes to models, data pipelines, operating context, platform interfaces, mission constraints, or security assumptions trigger defined levels of retest and review.
PROOF BOUNDARY
Repository evidence is not a substitute for customer authorization.
A source tree can prove what its files, tests, release tooling, and configuration show. It cannot prove an enterprise certification, a government database record, a facility clearance, a customer approval, a live production control, or an authority to process controlled information unless that evidence is separately available and current.
For a procurement decision, request the exact artifact relevant to the clause or requirement rather than accepting a logo, badge, generalized “compliant” statement, or inherited claim from an unrelated environment.
Evidence available upon request where applicable. Supporting procurement, security, corporate, insurance, and past-performance materials may be made available to authorized government or prime-contractor reviewers upon request where those materials exist, are applicable to the contemplated engagement, and disclosure is permitted. A request does not imply that any particular registration, certification, clearance, contract vehicle, customer reference, or other credential exists.
Nothing is auto-published. Verification is an internal evidence state; public promotion requires separate disclosure approval, a reviewed canonical profile change, and a versioned release.
Materials may be withheld, redacted, or provided only through approved channels when required by law, regulation, classification, export control, contract, customer direction, confidentiality, privacy, security, or need-to-know restrictions. No disclosure will be made where prohibited.
ENGAGEMENT
Need a contract-scoped evidence package?
Start with unclassified requirements and identify the contractual, cybersecurity, export, and information-handling boundary. Controlled technical exchange begins only through the correct customer-approved channels.
Contracting information