A specification document package, distributed free of charge. It defines a fail-closed boundary-control agent that validates, filters, quarantines, blocks, and conditionally releases artifacts crossing controlled runtime, persistence, or transport boundaries.
Everything dangerous that an AI system has ever done entered through an interface no one was guarding.
This package is a self-contained, normative, execution-neutral single agent specification, delivered as-is, sufficient for an engineering team to build the agent without further design decisions about agent logic, evidence shape, validator behavior, or failure semantics.
This package is not software, SaaS, a managed service, consulting, support, managed operations, or implementation delivery. It does not approve source semantic content, activate tool-state without a separate gate, relax policy, or perform persistent writes during startup verification. It is not a live runtime — nothing in the package executes; everything in the package describes how a conforming executable agent must behave.
5 structural assurance properties, defined in the specification's Assurance Profile (PR-AP) and elaborated through the failure semantics, workflow, gate logic, and evidence contract sections:
Fixed identity and authority boundary. Agent name, role, scope, and non-authority zones are fixed.
Boundary-governed exchange. No artifact crosses the governed boundary without contract evaluation.
Decision sufficiency. Every verdict is linked to validators and evidence fields.
Deterministic fail-closed degradation. Critical risk, replay, evidence failure, and tool-state ambiguity produce deterministic blocking, quarantine, rollback, or hold behavior rather than silent or ambiguous behavior.
Replay and reconstruction sufficiency. Accepted-head visibility and append-only or tamper-evident evidence support offline reconstruction.
The whitepaper summarizes these externally as four outcomes: every crossing governed, inputs classified, outputs gated, and boundary lockable.
These are properties of the specification. They are not warranties about a delivered running system.
| Boundary_Defense_Agent_Specification.md | Normative specification. The authoritative document. |
| Boundary_Defense_Agent_Semantic_Index.md | Semantic Index — Human Edition (D1). Canonical glossary of all 106 normative terms. |
| Boundary_Defense_Agent_Semantic_Index.yaml / Boundary_Defense_Agent_Semantic_Index.json | Semantic Index — Structured Edition (D2). The same glossary as data, 1:1 with D1. For tooling. |
| Boundary_Defense_Agent_Coverage_Matrix.md | Semantic Coverage Matrix (D3). Links term categories to the specification's sections. |
| Boundary_Defense_Agent_Ambiguity_Register.md | Ambiguity Register (D4). 14 lexical-overload resolutions. Read before normalization questions arise. |
| Boundary_Defense_Agent_Conformance_Tests.md | Conformance tests you run against your implementation, with fixtures, oracles, and minimal run note. |
| Boundary_Defense_Agent_Whitepaper.html | Public-facing positioning. Non-normative. |
| NNT_Companion/ | Non-Normative Tests — demonstration-only evidence that the specification is derivable. Not a reference implementation, and not part of the specification. Do not read it before implementing: read it only after your implementation passes the Conformance Tests. |
| Boundary_Defense_Agent_README.md | Orientation and reading order. |
| Boundary_Defense_Agent_License.md | The license. |
| Boundary_Defense_Agent_Manifest.sha256 | SHA-256 integrity manifest. |
| verify.md | Self-audit runbook you run against the package you hold. |
Per the specification's Reuse and Implementation Note (PR-RIN), Assumption-to-Obligation Closure (PR-AOC), and Implementation Acceptance Criteria (PR-IAC), your engineering team builds or declares 10 implementation-side deployment artifacts from this specification:
For boundary payload classes, with schema_id bound in every input envelope.
With stable active policy profiles and policy_hash binding in decision and evidence records.
For admissibility, elevated-risk classes, and constrained release.
For tool-state activation, including approval_ref production and validation.
For compliance-claimed finalization and persisted release claims.
With externally checkable continuity and hash_prev / hash_curr equivalents.
For replay, freshness, source binding, and transport/persistence anchor checks.
Exposing state, trigger, verdict, validator, and evidence outcomes for conformance testing.
For cryptographic primitive suite, storage backend, and persistence substrate.
For operator UI/workflow, throughput budgets, runbooks, escalation routes, and release governance.
The specification is complete enough that none of these requires interpretation of ambiguous prose. Specification PR-IAC criteria HC-01 through HC-06 set the acceptance criteria your implementation must meet.
This pack declares its own numbers — how many artefacts it ships, how many canonical terms it indexes, how many conformance records it carries, what those records return. This runbook has you reproduce those declared values on your own machine, before you build anything against the specification.
Each check has the same shape: find the value the pack declares, observe the value your machine produces, record whether they match. A mismatch is a fact you report, not a judgment you make: either the bytes you received are not the bytes that were published, or your environment differs. Both are worth knowing before you build. Neither requires you to decide what it means.
Integrity check, run inside the unzipped package folder.
sha256sum -c Boundary_Defense_Agent_Manifest.sha256
shasum -a 256 -c Boundary_Defense_Agent_Manifest.sha256
Get-Content Boundary_Defense_Agent_Manifest.sha256 | ? { $_ -notmatch '^\s*#' -and $_.Trim() } | % { $h,$f = $_ -split '\s+',2; if ((Get-FileHash $f.Trim() -Algorithm SHA256).Hash -ieq $h) { "OK $f" } else { "FAIL $f" } }Recompute the Manifest's own hash and compare it to the manifest_ref bound in the License.
The Conformance Tests document contains 36 test records anchored to the specification: 31 directly runnable on the agent's projection surface, 1 parameterized against operator-declared inputs, and 4 declarative checks verified at integration level. Each record cites the specification authority that grounds it, the input fixture that drives it, and the oracle that defines pass and fail. The Minimal Run Note declares the projection surface, input types, assertion result types, and the conformance condition for the suite as a whole.
Run the suite against your implementation. A fully conformant implementation passes the 31 runnable tests, satisfies the 1 parameterized test under your declared parameter envelopes, and attests the 4 declarative checks at your release-acceptance gate.
Your implementation's conformance is established by the Conformance Tests, not by verify.md.
Five paradigm-isolated reconstruction contexts of the same model independently built the Boundary Defense Agent from the specification pack alone — in Python, Rust, Prolog, C, and Bash — and ran the agent's 36 Conformance Tests records against each reconstruction, under live toolchains with hash-attested binary provenance.
All 36 of 36 conformance records converged across all five paradigms, with zero divergent records. The convergence comprises 33 convergent PASS and 3 convergent SKIP (records PTS-BDA-011, PTS-BDA-027 and PTS-BDA-029). The Minimal Run Note lists their obligations among the bounded external obligations not locally runnable: conflict-evidence emission for VAL-03; authorized non-validator producer grounding; distributed enforcement legitimacy where not exposed by local transition function. Per paradigm, each of the five reconstructions' own run reported the identical profile: 33 pass, 0 fail, 3 skip, 0 error.
The five contexts were isolated from one another; the reconstruction prompt-author, model and training data are shared across all five paradigm reconstructions, as the companion declares.
This is evidence of derivability and self-sufficiency of the specification, not a certification, not a quality score, and not a set of implementations to follow.
The baselines/ are study artifacts produced under restricted conditions; they are not reference implementations and must not be used as implementation patterns.
Every figure here is bounded to this single NNT run on agent pack BDA-BOUNDARY-DEFENSE-002. The NNT companion is not part of the specification. Do not read it before implementing: read it only after your implementation passes the Conformance Tests.
This supplement records five additional target paradigms for the Boundary Defense Agent (BDA-BOUNDARY-DEFENSE-002): Common Lisp, Brainfuck, spreadsheet formulas, an Analytical Engine-style program, and AWK. It is separate from the canonical BDA package and its Non-Normative Tests (NNT) companion. The supplement Manifest names and hashes the canonical BDA package Manifest as its parent artifact. The BDA Specification, Conformance Tests, and Semantic Index define the rules and acceptance criteria.
The eight workflow states and twelve runnable triggers from Conformance Tests §1, with the two guard results pass and fail: 192 input tuples. Each tuple produces one output token: a canonical workflow state or E. E means the integrated canonical package does not determine a next state for that tuple; it is not a BDA state, event, verdict, or gate status. This is a bounded state projection, not a full-agent or deployment evaluation.
The actual GNU Awk run produced 33 PASS, 0 FAIL, 3 SKIP, and 0 ERROR. The workbook, after a full recalculation in native Excel, reports 33 PASS, 0 FAIL, and 3 SKIP; the AWK and Excel results agree on all 36 records. PTS-BDA-011, PTS-BDA-027 and PTS-BDA-029 are SKIP because their obligations are external to the local transition surface (Conformance Tests §5).
The historical framing spans the Analytical Engine design described in 1843 and Rust's public announcement in 2010: 167 years between designs represented by contemporary renderings. Lisp (1958), rendered here in its Common Lisp dialect (standardized by ANSI in 1994), and Brainfuck (1993) supply additional points in that comparison. It does not imply that the Analytical Engine itself was built or executed in the nineteenth century.
Projection choices and their source traces are declared in SOURCE_RULES.md; the canonical BDA package remains authoritative.
All rights reserved. You may download, inspect and run these files to reproduce the reported results. They are provided as is, without warranty, and are run at your own risk. No other right is granted.
This package is distributed free of charge. No payment is required, now or ever, for anything this license permits.
Subject to the Restriction section, you are granted, free of charge and perpetually:
You shall not:
The line. Using an implementation as internal machinery inside your own product or service is permitted, including commercially and at any scale: the third party consumes your product, and neither selects nor obtains the agent as such. Offering the capability itself is not permitted. Permitted: your application uses the agent internally to validate state, and your customers buy your application. Not permitted: you expose the agent as an API, ship it as a library, or offer it as a service, so that a third party can obtain or invoke its capability as a thing in itself.
The implementations you build are yours. SEMANTICHOR claims no ownership over the source code, builds, or deployments you produce from this specification.
The license sets out what is free; the reserved uses are not licensed for this package.
Inquiries about reserved uses: contact@semantichor.com
Where you obtained the package otherwise than at the point of distribution, you accept this license by accepting it at semantichor.com, in the same two confirmations, before any use of the package.
This is a summary. Where this summary and the license appear to differ, the license controls. Read the full license →