site: trace reviewed field evidence to exact ARSAS releases

.github/ISSUE_TEMPLATE/device-compatibility.yml

@@ -14,6 +14,22 @@ body:
       placeholder: 1.6.18
     validations:
       required: true
+  - type: input
+    id: tested-release-tag
+    attributes:
+      label: Tested release tag (or "unknown")
+      description: Use the tag of the binary actually tested, e.g. v1.6.40; do not substitute today's latest release. An unknown tag cannot establish a release-specific field-test claim.
+      placeholder: v1.6.40 or unknown
+    validations:
+      required: true
+  - type: input
+    id: tested-source-commit
+    attributes:
+      label: Tested release source commit (if documented)
+      description: Optional for initial submission. For release-specific publication, the maintainer must verify the exact source commit against the tagged release.
+      placeholder: 40-character commit SHA or unknown
+    validations:
+      required: false
   - type: input
     id: evidence-date
     attributes:

docs/evidence-intake-review.md

@@ -32,4 +32,14 @@ A maintainer may open a separate PR to update `landing/device-evidence.json` and
 4. Reconcile registry, service-to-record links, coverage gaps, English/Indonesian pages and claim boundaries; run source, rendered-site, adoption/field-proof and exact-head PR CI.
 5. Merge only after review and required checks pass; verify the final production Pages deployment. The published matrix is authoritative only after this gate.
 
+## 4. Link a reviewed field test to an exact release
+
+The `releaseTraceability.reviewedTests` ledger inside `landing/device-evidence.json` starts empty. It is the only registry list of accepted **release-specific field-test records**; historical service statuses, an issue, a merge, package SHA-256 and green CI never populate it automatically. The current stable package identity comes only from `landing/latest.json`, not the profile date or a guessed tested version.
+
+For an accepted field test, add **one ledger record per profile, service and exact release** in a separate reviewed PR. The record requires: unique `id`, existing `profileId`, declared `service`, actual ISO `testDate`, exact `arsasVersion`, `releaseTag`, 40-character `sourceCommit`, exact tagged `releaseUrl`, bounded `result`, `evidenceKind` (`sanitized-field-test`), detailed `expectedObserved`, explicit `conditions`, `deviceDisclosure`, authorized sanitized `publicEvidenceUrl`, `reviewIssueUrl`, and `reviewPrUrl`. Link a public, safely redacted test record—not an implementation PR, private attachment or unsupported issue assertion. The maintainer confirms that the public material genuinely describes the tested service and release; CI can check internal consistency, **not the physical truth** of a relay test.
+
+For a record naming the currently published stable version, its tag and source commit must match `latest.json`. A historical tagged release must use its own exact version, tag, source commit and release URL, not a retroactive current-stable mapping. An older test never becomes a current-stable retest solely because the website or registry changed. Negative and conditional results remain bounded and must not be silently promoted to success. A sanitized diagnostic alone without a documented field test remains review material, not a release-specific field-test record.
+
+Update the English and Indonesian traceability surfaces, record count, release-specific rows and current-stable state in the **same PR**. Reconcile any profile `lastRetest` claim, service status and coverage plan only with the matching reviewed record. Source/rendered/adoption CI must reject ledger–page drift and mismatched current release identity. Never backfill the July 2026 profiles' unknown tested version merely from present-day release metadata.
+
 An issue may remain open or be closed without a registry change. A green CI validates consistency of the published claims and links, **not the physical truth of a device test**.

landing/adoption.css

@@ -160,6 +160,7 @@
   line-height: 1.55;
 }
 .matrix-boundary strong { color: var(--text); }
+.evidence-gap-panel [data-release-source] code { overflow-wrap: anywhere; word-break: break-word; }
 .evidence-profile .evidence-trace { margin: .7rem 0 .9rem; padding: .7rem .8rem; font-size: .76rem; }
 .evidence-profile .evidence-records { margin: .65rem 0 .85rem; font-size: .78rem; line-height: 1.55; }
 .evidence-records a { color: #dff7ff; text-underline-offset: 2px; }

landing/device-evidence.json

@@ -1,7 +1,7 @@
 {
   "schemaVersion": 2,
   "product": "ARSAS",
-  "updatedAt": "2026-09-22",
+  "updatedAt": "2026-09-23",
   "namedDeviceCount": 0,
   "statusVocabulary": {
     "verified": "Repeated evidence exists for the declared historical service scope. The tested ARSAS version must be disclosed when known; this is not IEC 61850 conformance certification.",
@@ -141,5 +141,31 @@
         "Positive and negative service result with sanitized diagnostics and acquisition conditions"
       ]
     }
+  },
+  "releaseTraceability": {
+    "schemaVersion": 1,
+    "currentStableSource": "latest.json",
+    "reviewPolicyPath": "docs/evidence-intake-review.md",
+    "currentStableFieldTestState": "not-publicly-documented",
+    "reviewedTests": [],
+    "requiredRecordFields": [
+      "id",
+      "profileId",
+      "service",
+      "testDate",
+      "arsasVersion",
+      "releaseTag",
+      "sourceCommit",
+      "releaseUrl",
+      "result",
+      "evidenceKind",
+      "expectedObserved",
+      "conditions",
+      "deviceDisclosure",
+      "publicEvidenceUrl",
+      "reviewIssueUrl",
+      "reviewPrUrl"
+    ],
+    "claimBoundary": "A release package identity, green CI, an issue, and implementation history are not evidence of a field test. Only a separately reviewed service-specific public test can enter reviewedTests; absence of entries is not a product failure."
   }
 }

landing/templates/bukti-kompatibilitas.html

@@ -62,6 +62,13 @@ <h2>Lihat service IEC 61850 mana yang memiliki evidence publik—dan mana yang b
           </table>
         </div>
         <p class="matrix-boundary"><strong>Cara membacanya:</strong> satu service yang berhasil tidak berarti service lain otomatis bekerja, dan tidak ada row yang menjadi sertifikasi conformance IEC 61850. Buka profile di bawah untuk melihat kondisi exact dan engineering record publik di balik statusnya.</p>
+        <div class="evidence-gap-panel" id="release-traceability" data-release-traceability="reviewed-tests-only" data-current-stable-field-test="not-publicly-documented" data-reviewed-release-test-count="0">
+          <div class="section-head"><span class="kicker">Evidence → release exact</span><h3>Identitas release bukan bukti pengujian field.</h3><p>Paket release bisa diperiksa; interoperabilitas memerlukan hasil pengujian terpisah untuk service tertentu.</p></div>
+          <p class="matrix-boundary" data-release-source="latest.json" data-release-version="{{STABLE_VERSION}}" data-release-tag="{{STABLE_TAG}}" data-release-commit="{{STABLE_SOURCE_COMMIT}}"><strong>Paket stable saat ini:</strong> v{{STABLE_VERSION}} · tag <code>{{STABLE_TAG}}</code> · source commit <code>{{STABLE_SOURCE_COMMIT}}</code>. <a href="{{RELEASE_URL}}" target="_blank" rel="noopener">Periksa release exact</a> atau <a href="unduh.html">verifikasi SHA-256 dan provenance paket</a>. Evidence paket/CI bukan bukti pengujian device.</p>
+          <p class="matrix-boundary" data-release-trace-profile="field-profile-a-file-service"><strong>Profile A · Juli 2026:</strong> riwayat file-service, versi ARSAS saat diuji belum tercatat secara publik; <a href="#field-profile-a-file-service">kondisi dan jejak engineering</a>. Tidak otomatis dikaitkan dengan stable saat ini.</p>
+          <p class="matrix-boundary" data-release-trace-profile="field-profile-b-rcb-export"><strong>Profile B · Juli 2026:</strong> riwayat RCB/SCL, versi ARSAS saat diuji belum tercatat secara publik; <a href="#field-profile-b-rcb-export">kondisi dan jejak engineering</a>. Tidak otomatis dikaitkan dengan stable saat ini.</p>
+          <p class="matrix-boundary" data-release-records="none"><strong>Record pengujian field per-release yang diterima dan dapat ditelusuri secara publik: 0.</strong> Retest pada v{{STABLE_VERSION}} belum terdokumentasi secara publik dalam registry. Ini menunjukkan cakupan publikasi, bukan kegagalan device atau software. Record baru wajib memuat versi, tag, source commit, service, tanggal aktual, hasil, kondisi, evidence publik yang disanitasi, dan PR review. <a href="device-evidence.json">Periksa ledger pengujian release</a> dan <a href="https://github.com/masarray/arsas/blob/main/docs/evidence-intake-review.md" target="_blank" rel="noopener">persyaratan review</a>.</p>
+        </div>
         <div class="evidence-gap-panel" data-evidence-coverage="published-anonymized-profiles-only">
           <div class="section-head"><span class="kicker">Gap evidence · capture berikutnya</span><h3>Apa yang belum dibuktikan secara publik pada kedua profil ini?</h3><p>GOOSE dan Control berstatus Not tested pada kedua profil. Ini gap evidence field publik, bukan pernyataan bahwa ARSAS tidak memiliki kemampuan tersebut. Service yang tidak dicantumkan oleh satu profil tetap Not declared, bukan Not tested.</p></div>
           <div class="feature-grid">

landing/templates/compatibility.html

@@ -62,6 +62,13 @@ <h2>See exactly which IEC 61850 services have public evidence—and which do not
           </table>
         </div>
         <p class="matrix-boundary"><strong>How to read this:</strong> one successful service does not imply another service works, and no row certifies IEC 61850 conformance. Open the profile below to see the exact conditions and public engineering records behind each status.</p>
+        <div class="evidence-gap-panel" id="release-traceability" data-release-traceability="reviewed-tests-only" data-current-stable-field-test="not-publicly-documented" data-reviewed-release-test-count="0">
+          <div class="section-head"><span class="kicker">Evidence → exact release</span><h3>Release identity and field-test evidence are different records.</h3><p>The release is verifiable as a package; interoperability requires a separate service-specific field result.</p></div>
+          <p class="matrix-boundary" data-release-source="latest.json" data-release-version="{{STABLE_VERSION}}" data-release-tag="{{STABLE_TAG}}" data-release-commit="{{STABLE_SOURCE_COMMIT}}"><strong>Current stable package:</strong> v{{STABLE_VERSION}} · tag <code>{{STABLE_TAG}}</code> · source commit <code>{{STABLE_SOURCE_COMMIT}}</code>. <a href="{{RELEASE_URL}}" target="_blank" rel="noopener">Inspect the exact release</a> or <a href="download.html">verify SHA-256 and package provenance</a>. Package/CI evidence does not prove a device test.</p>
+          <p class="matrix-boundary" data-release-trace-profile="field-profile-a-file-service"><strong>Profile A · July 2026:</strong> file-service history, tested ARSAS version not publicly recorded; <a href="#field-profile-a-file-service">conditions and engineering trail</a>. Not associated with the current stable by inference.</p>
+          <p class="matrix-boundary" data-release-trace-profile="field-profile-b-rcb-export"><strong>Profile B · July 2026:</strong> RCB/SCL history, tested ARSAS version not publicly recorded; <a href="#field-profile-b-rcb-export">conditions and engineering trail</a>. Not associated with the current stable by inference.</p>
+          <p class="matrix-boundary" data-release-records="none"><strong>Accepted, publicly linked release-specific field-test records: 0.</strong> No retest on v{{STABLE_VERSION}} is publicly documented in the registry. This describes publication coverage, not a device or software failure. Future reviewed records must identify the exact version, tag, source commit, service, actual date, outcome, conditions, sanitized public evidence and review PR. <a href="device-evidence.json">Inspect the release-test ledger</a> and <a href="https://github.com/masarray/arsas/blob/main/docs/evidence-intake-review.md" target="_blank" rel="noopener">review requirements</a>.</p>
+        </div>
         <div class="evidence-gap-panel" data-evidence-coverage="published-anonymized-profiles-only">
           <div class="section-head"><span class="kicker">Evidence gaps · next capture</span><h3>What is missing from these two published profiles?</h3><p>GOOSE and Control are marked Not tested in both profiles. This is a gap in public field evidence, not a claim that ARSAS lacks either capability. A service omitted from one profile remains Not declared, not Not tested.</p></div>
           <div class="feature-grid">

landing/templates/technical-review.html

@@ -34,7 +34,7 @@
 
     {{> trust-architecture}}
 
-    <section class="section section-tight"><div class="container comparison-grid"><article class="comparison-panel highlight"><span class="kicker">Current evidence</span><h3>Claims must point to inspectable behavior.</h3><ul><li>Current application screenshots and visible UI states</li><li>Deterministic source and rendered-site validation</li><li>Tagged release package identity, SHA-256, SPDX SBOM and provenance evidence</li><li>Exact source commit, source history, CI regression evidence and implementation boundaries</li><li>Published July 2026 field profiles are historical; their capture-version is not publicly recorded and a retest on v{{STABLE_VERSION}} is not documented. <a href="compatibility.html#service-matrix">Review service-level scope</a>.</li></ul></article><article class="comparison-panel"><span class="kicker">Not a conformance certificate</span><h3>Evidence narrows causes; it does not replace project acceptance.</h3><ul><li>Final conclusions depend on the approved design and test procedure</li><li>Vendor-specific behavior must be checked against vendor documentation</li><li>Network access, permissions and IED configuration remain project inputs</li><li>Independent verification remains required where the project demands it</li></ul></article></div></section>
+    <section class="section section-tight"><div class="container comparison-grid"><article class="comparison-panel highlight"><span class="kicker">Current evidence</span><h3>Claims must point to inspectable behavior.</h3><ul><li>Current application screenshots and visible UI states</li><li>Deterministic source and rendered-site validation</li><li>Tagged release package identity, SHA-256, SPDX SBOM and provenance evidence</li><li>Exact source commit, source history, CI regression evidence and implementation boundaries</li><li>Published July 2026 field profiles are historical; their capture-version is not publicly recorded and a retest on v{{STABLE_VERSION}} is not documented. <a href="compatibility.html#service-matrix">Review service-level scope</a> and <a href="compatibility.html#release-traceability">trace evidence to an exact release</a>.</li></ul></article><article class="comparison-panel"><span class="kicker">Not a conformance certificate</span><h3>Evidence narrows causes; it does not replace project acceptance.</h3><ul><li>Final conclusions depend on the approved design and test procedure</li><li>Vendor-specific behavior must be checked against vendor documentation</li><li>Network access, permissions and IED configuration remain project inputs</li><li>Independent verification remains required where the project demands it</li></ul></article></div></section>
 
     <section class="section"><div class="container"><div class="section-head"><span class="kicker">Claim governance</span><h2>Four labels keep product communication honest.</h2><p>ARSAS pages and guides are written to preserve the difference between implemented behavior and future intent.</p></div><div class="feature-grid"><article class="card"><span class="kicker">Available</span><h3>Implemented and inspectable</h3><p>The workflow is present in the current software and can be examined through the application, release artifact or source.</p></article><article class="card"><span class="kicker">Conditional</span><h3>Depends on device or project conditions</h3><p>Support can depend on IED services, writable attributes, network capture access, control model, permissions or configured engineering data.</p></article><article class="card"><span class="kicker">Preview</span><h3>Useful but still maturing</h3><p>The workflow is available for evaluation while interoperability breadth, UX or diagnostic coverage continues to mature.</p></article><article class="card"><span class="kicker">Roadmap</span><h3>Planned, not promised as current</h3><p>Roadmap content describes direction and is never presented as part of the current stable capability set.</p></article></div></div></section>