A specification document package, distributed free of charge. It defines a strict freshness-governed boundary agent for import acceptance, receipt anchoring, watermark advancement, restoration eligibility, quarantine, and readmission across sources and devices.
When state moves between devices, the only thing worse than losing it is accepting an old version as current.
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.
4 public-facing structural properties, grounded in spec §§1.1, 2.1, 13, 15, and Appendix A and elaborated through the failure semantics, workflow, gate logic, and evidence contract sections:
Freshness strictly increases per source. The implementation must compare incoming freshness against the stored acceptance watermark and accept only newer values within the scoped source_id / ledger_uuid context.
Replay is deterministically rejected. A packet whose freshness is stale relative to the watermark is rejected without receipt emission or watermark update.
Temporal ordering is preserved across device boundaries. Ordering is based on freshness monotonicity and receipt-linked watermark advancement, not wall-clock timestamp.
Cross-device portability remains safe under ordering guarantees. The agent supports portability without device-bound counters while preserving receipt anchoring, restore eligibility boundaries, and fail-closed behavior.
These are properties of the specification. They are not warranties about a delivered running system.
| Freshness_Portability_Agent_Specification.md | Normative specification. The authoritative document. |
| Freshness_Portability_Agent_Semantic_Index.md | Semantic Index — Human Edition (D1). Canonical glossary of all 121 normative terms. |
| Freshness_Portability_Agent_Semantic_Index.yaml / Freshness_Portability_Agent_Semantic_Index.json | Semantic Index — Structured Edition (D2). The same glossary as data, 1:1 with D1. For tooling. |
| Freshness_Portability_Agent_Coverage_Matrix.md | Semantic Coverage Matrix (D3). Links term categories to the specification's sections. |
| Freshness_Portability_Agent_Ambiguity_Register.md | Ambiguity Register (D4). 12 lexical-overload resolutions. Read before normalization questions arise. |
| Freshness_Portability_Agent_Conformance_Tests.md | Conformance tests you run against your implementation, with fixtures, oracles, and minimal run note. |
| Freshness_Portability_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. |
| Freshness_Portability_Agent_README.md | Orientation and reading order. |
| Freshness_Portability_Agent_License.md | The license. |
| Freshness_Portability_Agent_Manifest.sha256 | SHA-256 integrity manifest. |
| verify.md | Self-audit runbook you run against the package you hold. |
Per spec §17 Implementation Assumptions and Execution Obligations, §18 Execution Acceptance Criteria, and §22 Reuse and Limitations, 8 deployment artifacts or implementation closures are built by your engineering team from this specification:
A concrete mechanism for stable, verifiable source_id and ledger_uuid binding.
A concrete policy_id / policy_version profile, algorithm identifiers, and trust-anchor material for SSM, TVC, and Evidence.bin where applicable.
A monotonic persistence layer with anti-rollback properties and no decrement/rewrite path.
A durable IRR journal implementing receipt anchoring, accepted-head linkage, and previous-receipt linkage.
Execution-layer mappings for VAL-001 through VAL-011 and their specified failure effects.
A restore-admission path that checks valid IRR linkage and GenesisConfirmed, emits only the admission token, and does not execute restore inside this agent.
Logging, event, or audit instrumentation for every field in the Evidence Contract.
Tests and release-gate checks for fail-closed behavior, stale replay, recovery/idempotence, optionality envelopes, and declarative authority obligations.
The specification is complete enough that none of these requires interpretation of ambiguous prose.
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 Freshness_Portability_Agent_Manifest.sha256
shasum -a 256 -c Freshness_Portability_Agent_Manifest.sha256
Get-Content Freshness_Portability_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 41 test records anchored to the specification: 30 directly runnable on the agent's projection surface, 5 parameterized against operator-declared inputs, and 6 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 30 runnable tests, satisfies the 5 parameterized tests under your declared parameter envelopes, and attests the 6 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 Freshness Portability Agent from the specification pack alone — in Python, Rust, Prolog, C, and Bash — and ran the agent's 41 Conformance Tests records against each reconstruction, under live toolchains with hash-attested binary provenance.
All 41 of 41 conformance records converged across all five paradigms, with zero divergent records. The convergence comprises 35 convergent PASS and 6 convergent SKIP (records FPA-D-01 through FPA-D-06). The Minimal Run Note lists FPA-D-01 through FPA-D-06 as the bounded external obligations not locally runnable: declarative obligations enforced at the gate-logic, authority-control, observability and journal layers. Per paradigm, each of the five reconstructions' own run reported the identical profile: 35 pass, 0 fail, 6 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 FPA-FRESHNESS-PORTABILITY-003. 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.
DT-01…DT-08 range in FPA-D-01Conformance Tests record FPA-D-01 cites its source as §6 DT-01…DT-08, while the Specification's §6 Decision Table has seven rows (DT-01…DT-07). This is not a missing row. §6 declares two enumerations that count different things: the seven decision rows, and the eight operational action tokens (Specification §6, the "Operational action tokens" line). FPA-D-01 obliges a reason_code drawn from those eight tokens, and the cited range spans them.
The pack states this in three places. The Specification defines reason_code as "produced by gate-logic mapping and the Decision Table" (§11). The structured Semantic Index, in its YAML and JSON editions, gives every action-token entry DEC-201…DEC-208 the source §6 Decision Table alongside §13 Gate Logic; the human-readable edition shows only §13. Conformance Tests §C names the layer: action-token granularity "is the gate-logic / Decision-Table layer". The pack's verify.md maps the same point in its row "Decision-Table range cited by declarative records".
Why the entry is there. The NNT companion records this range as an inconsistency in four of its five reconstructions (NNT_Companion/baselines/{python,rust,prolog,bash}/inconsistencies.md). Those reconstructions worked only from eleven files of the pack, without verify.md, and so without the key that explains the range. The entries stand in the delivered records exactly as the reconstructions wrote them. Had the reconstructions been steered toward the pack's explanation, the entry would not exist. Anyone can check this in the delivered files. The entry did not affect any result: FPA-D-01 is a declarative record, and all five reconstructions returned 35 PASS / 6 SKIP.
What the agreement shows, and what it does not. Four reconstructions reached the same reading, each through its own search of the pack. That is consistent with the isolated contexts the companion declares, but it does not establish that isolation: the four reconstructions used the same model, and a shared misreading can come from the model rather than from isolation.
A fifth reconstruction notes that the License says companion binary hashes appear in the Manifest, while the Manifest it received lists only the seven normative files. The reconstructions received the seven-file manifest of the frozen normative core; the delivered package's Manifest declares in its header that it covers the companion, including its binaries, and identifies the seven-file manifest as the frozen normative core from which the companion evidence was derived.
This supplement records five additional target paradigms for the Freshness Portability Agent (FPA-FRESHNESS-PORTABILITY-003): Common Lisp, Brainfuck, spreadsheet formulas, an Analytical Engine-style program, and AWK. It is separate from the canonical FPA package and its Non-Normative Tests (NNT) companion. The supplement Manifest names and hashes the canonical FPA package Manifest as its parent artifact. The FPA Specification, Conformance Tests, Semantic Index, Coverage Matrix, and Ambiguity Register define the rules and acceptance criteria.
The nine workflow states and fourteen triggers enumerated in Conformance Tests §B/§C and Specification §8, with the Boolean input validator_passed: 252 input tuples. Each tuple produces one output token: a canonical workflow state or E. E means the integrated canonical corpus does not determine the result for that tuple; it is not an FPA state, verdict, action token, or gate class. This is a bounded state projection, not a full-agent or deployment evaluation.
The actual GNU Awk run produced 35 PASS, 0 FAIL, 6 SKIP, and 0 ERROR. The workbook, after a full recalculation in native Excel, reports 35 PASS, 0 FAIL, and 6 SKIP; the AWK and Excel runs agree on all 41 records. FPA-D-01 through FPA-D-06 are SKIP because §F.D defines them as declarative obligations outside the locally runnable published surface.
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 FPA corpus 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 →