Releases: Iron-Signal-Systems/engineering-standards
Release list
ISRAS 0.1.4 — Solo Developer Baseline
ISRAS 0.1.4 Release Notes
Release date: 2026-07-19
Assurance status: RELEASE CANDIDATE — SELF-VALIDATION REQUIRED
Release tag: isras-v0.1.4
Purpose
ISRAS 0.1.4 repairs the release-publication defects discovered during the first
formal publication attempt for the signed isras-v0.1.3 tag. It also carries
forward the hosted SSH signer-trust and evidence-retention corrections introduced
after the failed 0.1.2 consuming-project hosted run.
The signed isras-v0.1.3 tag remains immutable but was never published. Its exact
empty failed draft was independently verified and deleted. ISRAS 0.1.3 is not an
accepted release or project-adoption authority.
Publication repairs
This release candidate:
- discovers releases through a complete paginated inventory that includes drafts;
- rejects any existing draft or published release for the selected tag;
- uploads each exact asset with
gh release uploadand never enables--clobber; - re-reads the exact draft by release ID after each upload;
- accepts an ambiguous upload-command failure only when authoritative release-ID
state proves the exact expected asset was uploaded; - inspects and deletes failed drafts only by the exact release ID created by the
current invocation; - requires an authenticated ID-based absence check after cleanup;
- rejects duplicate, altered, partial, or unexpected draft asset state; and
- retains truthful cleanup evidence.
Exact release assets
A completed 0.1.4 release contains exactly:
isras-validator-linux-amd64
isras-project-framework.tar.gz
isras-contracts.tar.gz
provenance.json
SHA256SUMS
SHA512SUMS
Release completion
Release completion requires the exact signed 0.1.4 source commit, signed annotated
tag, deterministic six-asset build, read-only publication preflight, controlled
draft-first publication, complete remote metadata and downloaded-byte
verification, and final post-publication re-verification.
Adoption readiness
Publication is not project-adoption readiness. A neutral clean GitHub-hosted
consuming-project fixture must pin the exact published 0.1.4 release and pass the
complete reusable hosted workflow while retaining both required evidence trees.
Limitations
- The release remains self-authored and self-validated.
- No independent audit, certification, regulatory approval, or universal
production-fitness claim is made. - The validator release artifact remains linux/amd64.
- A later defect must be corrected through a later immutable release identity.
ISRAS 0.1.2 — Solo Developer Baseline
ISRAS 0.1.2 Release Notes
Release date: 2026-07-18
Assurance status: SELF-VALIDATED
Release tag: isras-v0.1.2
Purpose
ISRAS 0.1.2 establishes the first accepted project-initialization and reusable
hosted-validation boundary for the pinned-project architecture. It builds on the
0.1.1 release-consumption foundation by adding fail-closed initialization of
clean Go repositories, immutable caller and called-workflow identity, published-
validator digest binding, project-owned command execution, and retained runtime
evidence.
The release remains a solo-developer, self-validated assurance baseline. It does
not claim independent audit, certification, regulatory approval, or universal
production fitness.
Included boundaries
This release includes:
- first project initialization through
project-pin initializefor one explicitly
selected accepted ISRAS release; - authority checks requiring the running executable to be the exact linker-bound
validator artifact from the selected release before network or target authority
is granted; - signed-tag, exact source-commit, six-asset, GitHub SHA-256, local SHA-256 and
SHA-512, manifest, provenance, and reusable-workflow verification before any
target publication; - one shared strict SSH/HTTPS GitHub-origin parser for initialization and project-
command authorization; - canonical project pins, immutable caller workflows, stable timestamp-independent
adoption evidence, and a non-mutating project-owned Go format checker; - atomic no-overwrite publication with complete idempotence, private temporary
preparation, rollback reporting, and final exact-file and repository-identity
verification; - rejection of dirty, partial, conflicting, tracked-evidence, symbolic-link,
wrong-origin, unsafe-path, and executable-mode-drifted targets; - runtime validation evidence fixed to untracked
.local/israsand rejection of
tracked paths below that boundary; - immutable reusable hosted validation using the exact called workflow repository
and SHA; - bootstrap verification of the release, download of the published validator,
exact size and SHA-256/SHA-512 verification, and execution of repository,
secret, pin, and project-command checks through that artifact; - retention of
.local/israsworkflow evidence through commit-pinned actions; - repository-wide hermetic Git test fixtures that do not inherit an operator's
personal commit-signing or tag-signing policy; and - native Ubuntu Server validation plus official Arch Linux and Fedora Server
userland validation within the documented evidence boundaries.
Exact release assets
The release contains exactly:
isras-validator-linux-amd64
isras-project-framework.tar.gz
isras-contracts.tar.gz
provenance.json
SHA256SUMS
SHA512SUMS
The output contains no additional release asset. Every non-manifest asset is
covered by both manifests. The project pin binds the final manifest bytes
separately to avoid self-referential manifest hashes.
Release identity and completion
Release completion requires all of the following to identify the same exact
source commit:
- stable
VERSIONvalue0.1.2; - verified signed release-source commit;
- successful pull-request and merged-
devvalidation; - successful commit-mode and clean-clone release-mode validation;
- signed annotated local tag
isras-v0.1.2; - separately reviewed push of that exact tag object;
- deterministic production and local verification of the six assets;
- controlled draft creation and exact asset upload;
- remote metadata and downloaded-byte verification before publication;
- publication of the verified draft; and
- final remote metadata and downloaded-byte verification after publication.
A stable source declaration, branch name, tag name, or GitHub Release record is
not sufficient by itself.
Project adoption status
After publication, a clean Go project may adopt this exact release only through
the accepted initialization command executed by the exact published validator.
The initializer verifies the selected release before writing the canonical pin,
caller workflow, format checker, and adoption evidence. Local and hosted
validation then use the same immutable release identity.
Before publication of the exact signed tag and verified six-asset release, this
source candidate does not authorize modification of a consuming project.
isras-v0.1.1 remains immutable and is not a complete adoption release because
its framework archive does not contain the reusable project-validation workflow.
Known limitations
- The release is self-authored and self-validated.
- The Go profile is the first supported reference profile; other language
profiles require their own accepted contracts and tooling. - Initialization targets a clean, explicitly selected repository and does not
migrate partial or conflicting prior adoption. - Project-upgrade application remains outside this release boundary.
- Container-userland validation does not establish complete native kernel,
systemd, SELinux, firewall, hardware, deployment, or recovery compatibility. - Publication verification establishes exact release identity and bytes; it does
not establish suitability for every consuming project or operating environment.
Recovery and immutability
Published tags, assets, manifests, and provenance are immutable. A defect in
0.1.2 must be corrected by a later release rather than replacing bytes under
the existing identity.
Recovery consists of checking out the signed release tag or exact source commit,
rebuilding or reacquiring the declared assets, and verifying their complete
identity and digests. Private validation, build, command, adoption, and
publication evidence under .local/ is intentionally excluded from the signed
source tree and should be retained according to operational policy.
ISRAS 0.1.1 — Solo Developer Baseline
ISRAS 0.1.1 Release Notes
Release date: 2026-07-18
Assurance status: SELF-VALIDATED
Release tag: isras-v0.1.1
Purpose
ISRAS 0.1.1 establishes the first complete release-production and
release-consumption foundation for the pinned-project architecture. It adds
machine-readable project declarations, exact artifact verification,
deterministic release artifacts, isolated external-target validation, bounded
project-declared command execution, and controlled GitHub Release publication.
The release remains a solo-developer, self-validated assurance baseline. It does
not claim independent audit, certification, regulatory approval, or universal
production fitness.
Included boundaries
This release includes:
- the ISRAS Engineering Standards emblem as a repository documentation and
identity asset, rendered from the README but excluded from the exact six-file
downloadable release artifact inventory; - portable fail-closed local release-tag discovery that accepts the expected
pre-tag absence while distinguishing existing refs, malformed output, and Git
execution failures; - the language-neutral ISRAS core and the first Go reference profile;
- the strict v1
.isras/project.jsondeclaration and semantic validator; - read-only project-pin validation and inspection;
- exact published-release acquisition and verification using the signed tag,
source commit, GitHub release record, SHA-256, SHA-512, both checksum manifests,
and v1 provenance; - deterministic production of the exact six-file release asset set;
- validator release identity bound through linker values rather than target-owned
metadata; - explicit external repository selection through global
--repohandling; - one exact project-declared command selected by name and invoked as an exact argv
without an implicit shell; - credential-minimized process environments, timeout and output budgets, Linux
process-group termination, repository-state drift detection, and private
redacted command evidence; - controlled draft-first GitHub Release publication with remote asset metadata
checks, bounded re-downloads, full byte verification before and after
publication, and safe cleanup of only the exact incomplete draft; - disabled legacy publication paths that could create an assetless release, push
tags, or movemainwithout the new verifier; - native Ubuntu Server 22.04 and 24.04 validation plus official Arch Linux and
Fedora Server 43 and 44 userland validation; - release-workflow output censoring and repository secret-scanner regression
coverage.
Exact release assets
The initial release contains exactly:
isras-validator-linux-amd64
isras-project-framework.tar.gz
isras-contracts.tar.gz
provenance.json
SHA256SUMS
SHA512SUMS
The output contains no additional release asset. Every non-manifest asset is
covered by both manifests. The project pin binds the final manifest bytes
separately to avoid self-referential manifest hashes.
Release identity and completion
Release completion requires all of the following to identify the same exact
source commit:
- stable
VERSIONvalue0.1.1; - verified signed release-source commit;
- successful pull-request and merged-
devvalidation; - successful commit-mode and clean-clone release-mode validation;
- signed annotated local tag
isras-v0.1.1; - separately reviewed push of that exact tag object;
- deterministic production and local verification of the six assets;
- controlled draft creation and exact asset upload;
- remote metadata and downloaded-byte verification before publication;
- publication of the verified draft;
- final remote metadata and downloaded-byte verification after publication.
A stable source declaration, branch name, tag name, or GitHub Release record is
not sufficient by itself.
Project adoption status
This release provides the declaration, validation, artifact, execution, and
publication foundation required by future project adoption. It does not yet
provide accepted project initialization or complete consuming-project adoption.
Until the initialization boundary passes its own hostile tests and acceptance
gates, a project shall not:
- create a provisional
.isras/project.jsonpin; - copy validator source from Engineering Standards;
- use the deprecated project-validator exporter for initialization;
- pin
dev,main, or another floating branch; - invent artifact hashes or release identity;
- treat publication of
0.1.1alone as modification authority.
Known limitations
- The release is self-authored and self-validated.
- Project initialization is not implemented or accepted.
- Complete existing-project adoption is not implemented or accepted.
- Reusable hosted validation is not implemented.
- Upgrade-plan application is not implemented.
- The Go profile is the first supported reference profile; other language
profiles require their own accepted contracts and tooling. - Container-userland validation does not establish complete native kernel,
systemd, SELinux, firewall, hardware, deployment, or recovery compatibility. - Publication verification establishes exact release identity and bytes; it does
not establish suitability for every consuming project or operating environment.
Recovery and immutability
Published tags, assets, manifests, and provenance are immutable. A defect in
0.1.1 must be corrected by a later release rather than replacing bytes under
the existing identity.
Recovery consists of checking out the signed release tag or exact source commit,
rebuilding or reacquiring the declared assets, and verifying their complete
identity and digests. Private validation, build, command, and publication evidence
under .local/ is intentionally excluded from the signed source tree and should
be retained according to operational policy.
ISRAS 0.1.0 — Solo Developer Baseline
ISRAS 0.1.0 Release Notes
Release date: 2026-07-17
Assurance status: SELF-VALIDATED
Release tag: isras-v0.1.0
Purpose
ISRAS 0.1.0 is the first practical release of the Iron Signal Repository
Assurance Standard Solo Developer Baseline. It provides a usable assurance
foundation for a single developer without discarding the broader long-term
ISRAS vision.
Included baseline
This release includes:
- signed-commit and signed-release-tag requirements;
- exact repository and commit identification;
- repository-owned Go validation with formatting, vet, tests, builds, module
consistency, module integrity, and reachable-vulnerability checks; - repository-owned secret detection with censored output, deterministic finding
identifiers, redaction guidance, and bounded exceptions; - a local
*.logfor every validation failure; - context-specific remediation commands labeled by effect;
- safe commit-signature diagnostics that do not automatically recommend history
rewriting; - repository-owned clean-clone release validation of the exact pushed commit;
- preservation of the earlier ISRAS v1 through v3 development history through
archive references and local recovery artifacts.
Supported platforms
The default support profile is:
- Arch Linux as the primary development platform;
- Ubuntu Server LTS releases that remain within upstream support;
- Fedora Server releases that remain within upstream support.
Projects adopting ISRAS may declare additional or narrower platform support.
Validation and release completion
Release completion requires all of the following against the exact release
commit:
- complete commit-mode validation;
- successful GitHub pull-request validation;
- successful clean-clone release-mode validation from canonical
origin; - a signed annotated
isras-v0.1.0tag; - verification that the local and remote tag resolve to the exact tested commit.
The release tooling creates no tag automatically.
Recovery and rollback
This release does not perform database migrations, operating-system changes, or
automatic deployment actions. Recovery consists of checking out a previously
trusted signed tag or commit and rebuilding the repository-owned tooling from
that source.
Before replacing or removing a working copy, preserve any required private
validation evidence under .local/validation/. That directory is intentionally
ignored by Git and is not part of the signed source tree.
Known limitations
- The release is self-authored and self-validated.
- It does not claim independent human review, certification, regulatory
compliance, or suitability for every production environment. - Vulnerability results reflect the Go toolchain, dependency graph, and
vulnerability data available at validation time. - Platform declarations do not replace project-specific deployment,
compatibility, backup, recovery, and operational testing.
ISRAS v1.0.1
ISRAS v1.0.1 formal acceptance
Decision status: ACCEPTED
Decision time: 2026-07-16T00:40:00Z
Repository:
Iron-Signal-Systems/engineering-standards
Accepted source commit:
c379417
Required source branch:
dev
Release branch:
main
Accepted predecessor:
isras-v1.0.0
Accepted predecessor source commit:
f9655dd
Validation gate:
tools/validation/phase-gates/validate_isras_v1_candidate.sh
Environment:
Native Arch Linux validation plus GitHub-hosted Ubuntu, macOS, and Windows validation
Runner identity:
John Wood kb2vhn@gmail.com; jwood on local Arch Linux validation workstation
Validation outcomes:
- Historical checkpoint validation: PASS
- Repository policy validation: PASS
- Source-manifest verification: PASS
- Portable validation: PASS
- Integration-tool validation: PASS
- Fresh-clone and remote-completeness validation: PASS
- ISRAS v1 candidate gate: PASS
- Hosted Ubuntu validation: PASS
- Hosted macOS validation: PASS
- Hosted Windows PowerShell validation: PASS
- Correctness result: PASS
- Resource observation: NOT_APPLICABLE
- Performance budget: NOT_EVALUATED
- Security findings: NOT_EVALUATED
- Operational readiness: NOT_EVALUATED
Hosted validation:
- Self-validation run: 29461113082
- Native OS matrix run: 29461114090
Acceptance evidence:
SHA-256: f2dda939b8c401c9e96fc35402291e50ed9f774eb5783eb3a41aec117a301cab
Location: https://github.com/Iron-Signal-Systems/engineering-standards/releases/download/isras-v1.0.1/isras-v1.0.1-acceptance-evidence.tar.gz
Warnings:
- Independent second-person human review was unavailable.
- Security findings were not evaluated by this acceptance campaign.
- Operational production readiness was not evaluated.
Non-claims:
- Acceptance does not prove adopting products are production-ready.
- Acceptance does not prove adopting repositories are vulnerability-free.
- Acceptance does not replace product-specific operational, security, legal,
accessibility, privacy, or regulatory acceptance.
Completion boundary:
Acceptance is complete only when the canonical remote confirms that this signed
annotated tag, refs/heads/main, and refs/heads/dev all resolve to the accepted
source commit; the evidence asset is published at the recorded location; and
the isras-* tag namespace remains protected.