ProtectionAI v1.6.0

101 registered [WorkspaceView] modules (was 95), 30 AI copilot tools (was 27), 4 AI providers,
7 UI languages, 3,055 tests. Ribbon: 17 tabs, 85 groups, 144 controls.

Commands that produced them:

powershell -NoProfile -ExecutionPolicy Bypass -File scripts\check-counts.ps1   # 101 modules, 30 tools
dotnet test tests\ProtectionAI.Tests -m:1 -nodeReuse:false                     # 3,055 passed / 0 failed

The theme of the wave is coverage of relay models and of the path from a settings file to a
reviewable test plan. Two of the three headline numbers are content, not code, and the honesty
question they raise is answered the same way throughout: a relay model's identity can be verified
from public sources; its settings and tolerances cannot, and anything generated from the former is
labelled an unverified estimate.

Added — relay model coverage

• Seven more curated relay packs, 14 → 21. ABB REF615 joins RED615 and RET615; Basler adds
  BE1-CDS220 alongside BE1-11f; GE adds F60 and L90 to D60/T60; MiCOM adds P642 to P143/P543; SEL
  adds 311C and 751 to 351/387E/421. Same schema, same per-parameter citation requirement as the
  v1.4.0 packs — a pack row states whether its tolerance came from a published specification or is
  an engineering estimate, and says which. Count with
  (Get-ChildItem src\ProtectionAI.Core\Templates\Packs\*.json).Count and subtract
  packs.schema.json (the folder holds 22 files).
• A relay model catalog — 539 entries. Templates\Catalog\*.json, loaded by RelayCatalog,
  compiled in two research rounds: the first covering the current lines of SEL, GE, ABB/Hitachi,
  Siemens/Reyrolle, Schneider heritage (MiCOM/Sepam/VAMP), the Asian manufacturers and the US/EU
  specialists; the second adding the legacy electromechanical and solid-state families utilities
  still test daily (Westinghouse CO, GEC Quadramho/Optimho, SIPROTEC 3-era) plus SEG/Woodward,
  Thytronic, Efacec, Sifang, Hyundai, LS Electric, Ashida and the recloser-control makers. Each entry
  carries manufacturer, family, model, a one-line description, category, the principal ANSI device
  numbers, current/legacy status, and the public sources each was checked against, with URLs.
  Models that could not be verified against a vendor page or manual were excluded rather than
  pattern-completed from a series naming grid — ABB's REQ670, for instance, does not exist.
• What the catalog is and is not. The verified facts are: the model exists, who makes it, what it
  protects, and which functions it documents. Nothing else. CatalogPackFactory materializes a
  catalog entry into a family-generic pack for the Relay Template Library, and every numeric value
  it generates is written as PackVerification.UnverifiedEstimate with a citation naming the
  standard convention it derives from. Generic rows deliberately carry no settable min/max,
  because ranges are model-specific facts nobody has verified. Every materialized pack and every
  generated plan carries CatalogPackFactory.ProvenanceNote verbatim.
• Total relay models representable: 560 — 21 detailed packs plus 539 catalog entries. Those two
  tiers are not interchangeable and must never be added together without saying which is which: the
  21 have per-parameter provenance, the 539 have verified identity and estimated numbers.
• The Relay Template Library browser gains a catalog section: search the 539 identities and create a
  template from one, with the provenance statement shown next to it. A malformed shipped catalog is
  reported on screen as a build defect rather than hidden.

Added — from a settings file to a reviewable plan

• Vendor settings-file importers (Core\Templates\Import\): SEL ASCII text, DIGSI 5 XML, and a
  generic name/value CSV/TXT reader, alongside the existing RIO/XRIO path.
  SettingsImportDetector picks the reader by content sniff, and proprietary binary containers
  (ACSELERATOR .rdb and friends) are refused rather than read as text into a garbage import.
• Settings Import module (Database ▸ Settings). Previews every parameter with its mapped or
  unmapped status, surfaces unparseable lines as warnings instead of guessing values, always prints
  the source format and the mapped/unmapped counts as provenance, and can promote the result to the
  application-wide active relay model through the same API the XRIO import uses.
• TestPlanGenerator turns an active settings model into a TestPlan: a pickup ramp and timing
  shots per enabled overcurrent element (×2/×3/×5 inverse-time, ×1.5/×3 definite-time), a check shot
  per enabled distance zone, and differential characteristic points across the slope regions.
  Anything configured that the existing step types cannot express is written into the plan as an
  explicit note — never a silent skip.
• Plan Generator module (Templates ▸ Test Plans). The generated plan is a starting point derived
  mechanically from settings; nothing in it is a measurement, it is saved to the template library
  only when the operator chooses to, and it carries a description saying a qualified protection
  engineer must review it before use. Where a built-in pack matches the active model the pack's
  published tolerance bands and their verification provenance are quoted; otherwise the IEC 60255
  convention defaults are stated as the defaults they are.
• A seeded test-plan template library — 12 starter plans in Core\Templates\Seeds\, installed by
  TemplateSeeder behind a version-suffixed marker file so a re-run does not duplicate them:
  definite-time and IDMT overcurrent (50, 51), directional and negative-sequence overcurrent (67,
  46), distance zones (21), transformer differential (87T), breaker failure (50BF), autoreclose (79),
  synchronism check (25), frequency (81), voltage (27/59) and thermal overload (49).

Added — modules

Six new registered workspaces (95 → 101). The ribbon grew by exactly six controls and two groups
(Database ▸ Settings and Templates ▸ Test Plans are the first registered views on those two tabs;
the other four joined existing groups). Verify with
powershell -NoProfile -ExecutionPolicy Bypass -File scripts\check-counts.ps1, not by adding up the
bullets below — this line said "five" and "95 → 100" until COMTRADE Replay landed later in the same
wave, which is exactly the arithmetic a reader would otherwise carry forward.

• Settings Import (Database) and Plan Generator (Templates), described above.
• Fleet Dashboard (Enterprise ▸ Overview) — age-of-last-test buckets across the asset register,
  stat cards, a per-substation heat list, the monthly archived-result trend and a sortable
  drill-down, all computed by FleetStats. Scope is stated on the page: every figure comes from
  the sessions archived in this ProtectionAI database only, testing recorded elsewhere is invisible
  to it, and the 12/24-month thresholds are review aids, not a PRC-005 compliance determination —
  the Compliance view still owns that.
• Integrations (Enterprise ▸ Overview) — file-based interoperability: an RFC 5545 .ics export
  of upcoming maintenance and scheduled work, a work-order CSV in generic, IBM Maximo or SAP PM
  column sets, and a pre-filled mailto: draft about the current session. That file-based half needs
  no credentials and is always available. Later in this same wave the view also gained an optional
  live half — WhatsApp Cloud, Slack, Microsoft Graph (mail and calendar), IBM Maximo and SAP PM,
  each driven by credentials the customer supplies and stores DPAPI-encrypted on their own machine.
  Those clients are written against the vendors' public API documentation and are certified or
  endorsed by none of them; every send is user-initiated behind a confirmation naming exactly what
  goes where, and the vendor's own error text is shown verbatim rather than being interpreted.
  "EAM integration" still overstates it: this is a customer-credentialled REST call, not a
  supported, vendor-tested connector.
• GOOSE Trip Transfer Time (Advanced ▸ Protocols) — publishes a test GOOSE state change with the
  simulation bit set on every frame and times the hand-off against the IEC 61850-5 classes (TT6 3 ms,
  TT5 10 ms, TT4 20 ms, TT3 100 ms). Transport provenance is printed with every figure. On the
  deterministic loopback both timestamps come from this application's clock, so the number is an
  in-process encode/dispatch/decode latency — a workflow and codec check, not network evidence. On a
  named Npcap interface the frames are real and the detection timestamp is a software capture
  timestamp: evidence about this host's publish-to-capture path on an isolated network, not about
  an IED's application-to-application transfer time, which spans two devices and both their stacks.
  Timestamp uncertainty is carried through and a class the uncertainty cannot support is refused.
• COMTRADE Replay (Test ▸ Waveform) — the view over the replay engine described below. It reads a
  .cfg/.dat pair through the existing Comms COMTRADE reader, projects each channel to secondary
  engineering units, previews the record on the waveform scope, maps channels to driver outputs and
  then runs the full injection contract: isolation attestation, timed phasor segments applied against
  one schedule clock, the watched binary input awaited with a timeout, the trip time assessed through
  ToleranceAssessor and recorded. It refuses out-of-range records by name and peak before
  energizing anything, and it carries ComtradeReplay.ProvenanceStatement on every surface: the
  record is replayed as cycle-by-cycle phasor segments, not as samples.

Added — drivers

• Generic SCPI source (TCP) — a third implemented driver in DriverRegistry, selectable in
  production alongside the simulator and the OMICRON CM Engine adapter. It speaks SCPI-1999 over a
  raw TCP socket to a programmable AC source; the dialect is configured rather than forked, and
  matching the instrument's manual is the operator's burden.
• Its limits are the interesting part, and they are enforced, not just documented. Capabilities
  are StaticAnalogOutput | LiveSetpointUpdate | MagnitudeRamp and nothing else. A bare
  programmable source has no binary sensing, so there is no trip detection — BinaryInputEvents is
  absent, BinaryInputChanged never raises, and every operation whose result would depend on sensing
  a trip refuses with a named reason rather than returning a fabricated one. Binary outputs, sampled
  waveform playback, generated-phase readback, segment and synchronized ramping, arm/trigger and
  auxiliary DC all refuse. PerChannelFrequency is deliberately absent even where an instrument
  might support it, because the driver cannot verify that it does. Output state is commanded, not
  measured: a raw SCPI socket gives no amplifier readback, and the driver labels it as commanded.
  Stop de-energizes every configured output rather than only the addressed ones, attempts all of
  them even after a failure, and does not let cancellation abandon the sweep.
• Useful for steady-state and manually observed work, or composed with a binary-sensing instrument
  through CompositeTestSetDriver. Doble F6150, Megger SMRT, ISA/Altanova DRTS and EuroSMC
  Mentor/Raptor remain documented stubs that throw DriverNotAvailableException, and the OMICRON
  adapter remains HIL pending — no physical-hardware validation has happened in this wave.

Added — COMTRADE replay

• ComtradeReplay reduces a parsed record to timed phasor segments a driver can apply, with a
  cycle-by-cycle single-frequency DFT, a MinimumSamplesPerCycle floor of 4 below which it refuses
  to estimate a fundamental, and coalescing of steady spans.
• comtradeReplay is a new TestPlan step type (additive: a new JsonDerivedType, nothing
  existing changes shape). Any runner executing it must carry ComtradeReplay.ProvenanceStatement
  verbatim: "Replayed as cycle-by-cycle phasor segments; raw sample fidelity requires a
  sample-streaming driver."
• The replay module landed later in the same wave. The engine and step type shipped first with
  no view; ComtradeReplayView (ctreplay, Test ▸ Waveform) followed, together with the App-layer
  adapter from the Comms COMTRADE reader and execution of comtradeReplay steps in the plan runner.
  It is the module that takes the registered count to 101.

Changed

• Global search results are ranked by Services\Search\SearchRanker rather than by registration
  order.
• Views\Grids\ gains a results-grid context-menu model, covered by its own tests.

Known limitations carried forward, unchanged by this wave

• The OMICRON CM Engine adapter is real late-bound COM code driving the customer's own licensed
  OMICRON software; it is not validated against physical hardware and the registry label is
  HIL pending. Four vendor drivers remain stubs.
• Npcap is a separate customer install and is not redistributed; SV publishing cannot reach
  merging-unit cadence from Windows user mode.
• Releases are unsigned. GridAPM holds no code-signing certificate; SmartScreen warns on
  download. The SHA256SUMS manifest, its Sigstore signature and the SBOM verify the published
  bytes and bind them to the release workflow; they are not Authenticode. GitHub-hosted SLSA
  provenance is unavailable for this private user-owned source repository, so no SLSA level is
  claimed for v1.6.0.
• Seven UI languages, every non-English one at LocCompleteness.Preview — shell chrome and dialogs
  only.
• The two timing tests known to fail under CPU contention were green on this idle run (3,055 / 3,055).

---

Installer

ProtectionAI-Setup.msi is a Windows Installer (MSI) package. It installs ProtectionAI in Program Files, creates a Start Menu shortcut, registers Apps & Features uninstall support, and supports in-place major upgrades. ProtectionAI.App.exe is the same application as a self-contained single-file executable, for people who cannot run an installer.

This release is not Authenticode code signed. Windows SmartScreen will warn you when you run it, and that warning is expected. The checks below prove integrity (the bytes are the bytes we built) and source binding (the signed manifest came from this repository, tag and commit). They are not a Windows trust decision and do not stop SmartScreen warning.

Artifact digests (SHA-256)

d0eec6dca9bba473b9f52e34835faf53c8b3c8470ce67bc4e5bdc6dd94c26021  protectionai-1.6.0-cyclonedx.json
1a8dd5005bb8ef5c277eef734c708745a67e51ced06fee810cce9ca0a22e8919  protectionai-1.6.0-cyclonedx.json.sha256
8557fad4a0a31aa9d5f862350058a01775936debe23ec27f6dca4727cae24ae5  ProtectionAI-Setup.msi
c129e4993b817c8ad86c798f448b4f5ea2f15df1bfc6657d4c80fffc38eb9c83  ProtectionAI.App.exe

Published alongside the artifacts as SHA256SUMS, with a detached Sigstore signature (SHA256SUMS.sig), the ephemeral signing certificate (SHA256SUMS.pem) and a self-contained bundle (SHA256SUMS.cosign.bundle). The software bill of materials (protectionai-1.6.0-cyclonedx.json) and its checksum sidecar (protectionai-1.6.0-cyclonedx.json.sha256) are both attached and covered by the signed manifest.

1. Verify integrity — the files are what we built

PowerShell:

foreach ($line in Get-Content .\SHA256SUMS) {
  $expected, $name = $line -split '\s+', 2
  $actual = (Get-FileHash $name.Trim() -Algorithm SHA256).Hash.ToLower()
  "{0}  {1}" -f $(if ($actual -eq $expected) { "OK  " } else { "FAILED" }), $name.Trim()
}

POSIX shell:

sha256sum -c SHA256SUMS

2. Verify authenticity — the digest list itself is genuine

Step 1 only proves the files match the list. This proves the list was produced by this release workflow. Install cosign and run:

cosign verify-blob SHA256SUMS \
  --signature SHA256SUMS.sig \
  --certificate SHA256SUMS.pem \
  --certificate-identity https://github.com/Cwgtshome/ProtectionAI/.github/workflows/release.yml@refs/tags/v1.6.0 \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-github-workflow-repository Cwgtshome/ProtectionAI \
  --certificate-github-workflow-ref refs/tags/v1.6.0 \
  --certificate-github-workflow-sha fe76fed30d3e0e653b2a308b49e27a3b574f72ea

Or with the bundle, which needs no separate certificate:

cosign verify-blob SHA256SUMS \
  --bundle SHA256SUMS.cosign.bundle \
  --certificate-identity https://github.com/Cwgtshome/ProtectionAI/.github/workflows/release.yml@refs/tags/v1.6.0 \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-github-workflow-repository Cwgtshome/ProtectionAI \
  --certificate-github-workflow-ref refs/tags/v1.6.0 \
  --certificate-github-workflow-sha fe76fed30d3e0e653b2a308b49e27a3b574f72ea

Pin all five certificate constraints exactly as shown: identity, issuer, repository, ref and SHA. Together they reject a signature from another workflow, repository, tag or commit. There is no long-lived private key: the certificate above was issued to this workflow's OIDC identity, is valid for minutes, and the signing event is recorded in the public Rekor transparency log.

3. Build provenance — not available for this release

No GitHub-hosted SLSA build-provenance attestation was recorded, so gh attestation verify will not find one. GitHub's attestation store is not offered to user-owned private repositories on this plan, and the source repository is private.

What still holds: the signed SHA256SUMS manifest binds every shipped content file by digest, and the Sigstore certificate in step 2 binds that manifest to this repository, tag ref and exact source SHA against a public transparency log. What is missing is GitHub's separate SLSA predicate and attestation-store record; no SLSA level is claimed.

Built from Cwgtshome/ProtectionAI@fe76fed. See docs/RELEASE-INTEGRITY.md for what each file is and why it exists.