Requirements.Pull requests.Tests.Releases.Seal ALM.Build with AI.Prove every change.
Coding agents write pull requests faster than anyone can document them. Neil reads each one, traces it to its requirements, risks and tests, and drafts the change record for your people to sign.
A firmware change at K. Ibarra's company, the fictional Skerry Neuro, on its change record in Seal on Tue 10 Nov. At 09:12 K. Ibarra opens pull request #482, “Stop stimulation within 200 ms of contact loss”, and Seal opens CHG-118. At 09:14 Neil has traced it to requirement SRS-061, hazard HZ-14 and the 9 test cases that verify it, found one case no test covers and drafted TC-207. K. Ibarra accepts it at 09:40; at 09:59 the pipeline's second run fails it at 240 ms, against a limit of 200 ms; at 11:39 the fix passes, 412 of 412. M. Reyes signs for Software at 13:02, A. Lindgren signs for Risk at 14:10 and R. Halloran signs for QA at 15:40. The pull request is merged at 15:46. From pull request to signed change, 6 h 28 min
ALM › S2 firmware › CHG-118
Merged 15:46
Opened
Read by Neil
Tested
Signed
Merged
skerry/s2-firmware #482Tue 10 Nov, 15:46
Stop stimulation within 200 ms of contact loss
6 h 28 minFrom pull request to signed change
RequirementSRS-061 v4, 200 ms
RiskHZ-14, RC-22
Tests10 pass
Signatures3 of 3
09:0011:0013:0015:00
Change record
CHG-118
Neil reads, traces and drafts. Your people sign.By K. Ibarra. Seal opened CHG-118 from the template “Firmware change”To SRS-061, HZ-14 and the 9 test cases that verify it. None loses contact during ramp-upThe test Neil drafted for the gap: contact lost during ramp-upRun 2, on a41f9c2: 411 of 412 pass. The limit is 200 msRun 3, on c7d0e15, the fix. Every run is kept, the failed one tooM. Reyes, with password and authenticator codeA. Lindgren, with password and authenticator codeR. Halloran, with password and authenticator codeBy K. Ibarra, once Seal approved the pull request at 15:40
Proof, kept as the work is done.
Today a pull request is documented after it merges, and the trace matrix is rebuilt by hand before an audit.
Compared on
Today
Seal ALM
A pull request
Documented after it merges
Traced by Neil 2 minutes after it opens
The trace matrix
Rebuilt in a spreadsheet before an audit
A view of links made as the work is done
A case no test covers
Found at the audit, or in the field
Found by Neil, with a test drafted
Code an agent wrote
Merged on a green pipeline
Marked, reviewed by a named person, signed
After design transfer
Another system and another team
The release on every unit's build record
Skerry Neuro is a fictional company. What a customer measured is below.
Neil reads every pull request
It traces the change to its requirement, its hazard and its tests, finds the case none of them covers, and drafts the test.
Neil's reading of pull request #482 to the S2 firmware, change CHG-118, which K. Ibarra opened at 09:12 on Tue 10 Nov. By 09:14 Neil has read its 4 files, 3 of them in stim_control, an IEC 62304 Class C item, and traced the change to requirement SRS-061, which goes from v3 to v4: stimulation stops within 200 ms of losing skin contact, where it was 2 s. SRS-061 implements risk control RC-22 for hazard HZ-14, stimulation with poor skin contact. 9 test cases verify it, and none loses contact during ramp-up, so Neil drafted TC-207, contact lost during ramp-up, and K. Ibarra accepted it at 09:40. 10 test cases now verify SRS-061.
ALM › S2 firmware › CHG-118
Gap closed
Pull request #482Tue 10 Nov, 09:40
What this change reaches
4 filesSRS-061HZ-141 gap10 testsOpened 09:12 by K. IbarraIts limit changes from 2 s to 200 msStimulation with poor skin contactNo test loses contact during ramp-upNeil drafted TC-207 to cover it9 standing, 1 drafted by Neil, accepted 09:40
stim_control/output_stage.c+41−18Class C
stim_control/contact_monitor.c+29−9Class C
stim_control/limits.h+2−2Class C
tests/stim/test_contact_loss.c+14−12
SRS-061v3 to v4
Stimulation stops within 2 s 200 ms of losing skin contact
TC-2079 test cases verify SRS-061None loses contact during ramp-upTC-207 drafted by Neil10 test cases verify SRS-061
Neil's reading
Drafts only
Neil drafts. Your people accept, change or reject.Accept TC-207stim_control is an IEC 62304 Class C item: a fault in it could cause serious injuryNeil drafted v4 with the new limit. It is not in force until the change is signedHZ-14, stimulation with poor skin contact. A. Lindgren signs for riskEach ran in the pipeline on this pull requestContact is checked once stimulation is steady. During the 3 s ramp-up nothing tests itContact lost during ramp-up: stimulation must stop within 200 msAccepted at 09:40 and pushed as a41f9c2. The pipeline ran it at 09:59
Evidence from your pipeline
Every run lands on the change, test by test. The pipeline was green until it ran the test Neil drafted.
The test evidence on CHG-118, a change to Skerry Neuro's S2 firmware, on Tue 10 Nov, each run from the team's own pipeline. Run 1, on commit 5b1e3a9 at 09:31, passes 411 of 411 test cases, none of them for contact lost during ramp-up. At 09:40 TC-207, a test for that case drafted by Neil, Seal's AI agent, and accepted by K. Ibarra, is added. Run 2, on a41f9c2 at 09:59, passes 411 of 412: TC-207 fails, stimulation stopping 240 ms after contact is lost against a limit of 200 ms. The fix, c7d0e15, written by K. Ibarra with a coding agent for M. Reyes to review before signing, is pushed at 11:20, and run 3, at 11:39, passes 412 of 412. SRS-061 v4 is verified by 10 tests, its 9 standing test cases and TC-207, each on c7d0e15. Every run is kept, the failed one too.
ALM › S2 firmware › CHG-118 › Test evidence
412 of 412 pass
Run 3 of 3 on c7d0e15Tue 10 Nov, 11:39
Every test passes
412 of 412passRunning 412 testsNo test for contact lost during ramp-upDrafted by Neil, accepted by K. IbarraStimulation stopped after 240 ms. The limit is 200 msWritten by K. Ibarra with a coding agentTC-207 passes. Stimulation stops within 200 ms
skerry/s2-firmware412 test cases
TC-207
Test evidence
CHG-118
Every run is kept, the failed one tooEvery test there was. None lost contact during ramp-upDrafted by Neil at 09:14, accepted by K. IbarraThe same 411, and TC-207Contact lost during ramp-up. The output stage stopped 40 ms lateWritten with a coding agent. M. Reyes reviews it before signingTC-207 passes. Stimulation stops within 200 ms9 standing test cases and TC-207, each on c7d0e15
Signed in Seal, merged in GitHub
Your engineers stay in GitHub. The pull request waits on one check until the people responsible have signed.
Pull request #482 in skerry/s2-firmware as its author, K. Ibarra, sees it in GitHub on Tue 10 Nov: Stop stimulation within 200 ms of contact loss. Beside it, the signatures on change CHG-118 in Seal. Of its 5 commits, 2 were written with a coding agent and 1 is Neil's drafted test, TC-207, accepted by K. Ibarra. Tests pass, 412 of 412, at 11:39. The pull request's one check, Seal Change Control, links to the change record and waits for 3 signatures in Seal, each with password and authenticator code: Software, M. Reyes at 13:02; Risk, A. Lindgren at 14:10; QA, R. Halloran at 15:40. M. Reyes reviewed every commit before signing. When the last signature lands, Seal passes the check, and K. Ibarra merges the pull request at 15:46. It took 6 h 28 min from pull request, opened at 09:12, to signed change. Neil cannot approve, sign or merge, and Seal never merges or deploys.
ALM › S2 firmware › CHG-118 › Approval
Merged 15:46
Opened
Tests pass
Software
Risk
QA
Merged
GitHubskerry/s2-firmware
#482 Stop stimulation within 200 ms of contact loss
0 of 3signedTests pass on c7d0e15. Waiting for signatures
1 of 3signedSoftware signed 13:02
2 of 3signedRisk signed 14:10
3 of 3signedQA signed 15:40. Approved
6 h 28 minFrom pull request to signed change
5 commitsOpened 09:12
Merging is blockedMerge pull requestMerged 15:46 by K. Ibarra
Signatures
CHG-118
Neil cannot approve, sign or mergeRun 3 on c7d0e15. The record asks for 3 signaturesReviewed all 5 commits, 2 written with a coding agent. Signed with password and authenticator codeRC-22 still controls HZ-14, now within 200 ms. Signed with password and authenticator codeRequirement, risk and test evidence complete. Signed with password and authenticator codeSeal passes the pull request's check the moment the record is approvedMerged in GitHub by its author. Seal never merges or deploysWritten by K. Ibarra at 08:21Written by K. Ibarra with a coding agent at 08:47. Reviewed line by line by M. ReyesWritten by K. Ibarra at 09:10Drafted by Neil, accepted by K. Ibarra at 09:40Written by K. Ibarra with a coding agent at 11:20. Reviewed line by line by M. ReyesSeal writes it, linked to CHG-118. It passes when the record's 3 signatures are in
A release you can open
Every requirement 2.4.1 touches, with the tests that verify it: complete on the day, not the week before an audit.
Release 2.4.1 of the S2 firmware as a record in Seal, on Thu 12 Nov: its 6 changes, CHG-113 to CHG-118, touched 14 requirements, and every one is verified by passing test cases on the release's commit, 66 in all. Each is listed with the change that touched it, its test cases and, for the 4 that implement one, its risk control. The release's 2 known anomalies are kept as GitHub issues, neither in a Class C item; Neil assembles the release file from the records, and R. Halloran signs the release for QA
ALM › S2 firmware › Release 2.4.1
Released 2.4.1
Release 2.4.1Thu 12 Nov
Every requirement touchedEvery requirement verified
14 of 14verifiedRequirements touched by 6 changesEach by passing test cases on the release's commit
Every requirement release 2.4.1 touches, with its change, test cases and risk control
Requirement
Change
Tests
Risk control
CHG-113
6 of 6
CHG-113
3 of 3
CHG-114
4 of 4
CHG-114
3 of 3
CHG-115
5 of 5
CHG-115
2 of 2
CHG-115
2 of 2
CHG-116
7 of 7
CHG-116
4 of 4
CHG-116
8 of 8
RC-15
CHG-117
5 of 5
RC-18
CHG-117
4 of 4
RC-19
CHG-117
3 of 3
CHG-118
10 of 10
RC-22
Release 2.4.1
Release record
A requirement with no passing test stops the releaseEach a signed change record with its pull requestEvery requirement a change in this release edits or re-verifiesRun by the pipeline on the release's commitEach control still linked to the requirement and tests that implement itGitHub issues kept as records. Neither is in a Class C itemRequirements, risk file, test evidence and anomalies, from the records as signedSigned Thu 12 Nov with password and authenticator codeSRS-102, battery level within 5%. In the power itemSRS-103, low battery warning at 15%. In the power itemSRS-140, pairing times out after 60 s. In the radio itemSRS-141, at most 4 bonded phones. In the radio itemSRS-171, session log holds 90 days. In the session_log itemSRS-172, log export carries a checksum. In the session_log itemSRS-173, clock drift under 2 s a day. In the session_log itemSRS-055, ramp-up reaches intensity in 3 s. In the stim_control itemSRS-056, intensity in steps of 0.5 mA. In the stim_control itemSRS-058, output never above 30 mA. In the stim_control item. Implements RC-15SRS-064, no stimulation while charging. In the power item. Implements RC-18SRS-065, a charge fault stops charging. In the power item. Implements RC-19SRS-066, charger detected within 1 s. In the power itemSRS-061, stops within 200 ms of contact loss. In the stim_control item. Implements RC-22Open release file
On every unit built
Seal runs manufacturing too, so each of the 48 units keeps the firmware it was programmed with on its own record.
Work order WO-0312 on Mon 16 Nov, the first build with firmware 2.4.1, the release signed Thu 12 Nov. At step 7 of each unit's build record, Program firmware, the station programs the order's 48 units, S2-004401 to S2-004448, one after another, and each unit's record keeps the version and the checksum read back from it. By 11:42 all 48 are programmed. Beside them, the build record of S2-004417: step 7, run by D. Varga, done; firmware 2.4.1 programmed; checksum 9be2…f04a, matching the release; the 6 changes it carries, CHG-113 to CHG-118; requirement SRS-061 v4, stops within 200 ms; and a complaint on this unit opens on this record. Asked which units stop within 200 ms of contact loss, Neil answers: 48, all built on WO-0312 with firmware 2.4.1.
Work orders › WO-0312 › Step 7
48 of 48 programmed
WO-0312, step 7Mon 16 Nov, 11:42
Program firmware 2.4.1
48of 48 unitsEach unit's record keeps the version and its checksum
S2-004401 to S2-004448
Asked of Neil
Which units stop within 200 ms of contact loss?
S2-004417
Build record
One record from the pull request to the unitStep 7 of the unit's build record, run by D. VargaThe release signed Thu 12 Nov, pinned to this unit at this versionRead back from the unit and compared with the release's fileEvery change in the release, each with its signatures and test evidenceThe requirement as signed on Tue 10 Nov, verified by 10 test casesThe complaint links to this build, its firmware and its lotsFound by Neil in 48 build records, each linked to SRS-061 v4S2-004417. Firmware 2.4.1, checksum matches the releaseS2-004417. In hand at step 7S2-004417. Waiting at step 7
Measured by a team that builds its device on Seal.
No. They open, review and merge pull requests as they do today. Seal adds one check to each, which links to its change record and passes once the people responsible have signed. Merging and deployment stay in your own delivery workflow.
Can we ship code a coding agent wrote?
Yes, and the record says which. A commit written with an agent is marked, a named person reviews it, and it passes the same tests and carries the same signatures as any other. What an auditor asks is who was responsible for a change, and that is the people who signed it.
Can Neil approve or sign a change?
No. Neil reads, traces, drafts and assembles. It cannot approve, sign or merge, and nothing it drafts is in force until your people have signed it.
Does Neil write our code?
Only where you ask it to. A pull request Neil opens is reviewed, tested and signed like any other. Most code is written by your engineers and the coding agents they already use, and Neil's work is the proof: the trace, the missing test, the change record and the release's file.
Is our code used to train AI?
No. Customer data trains no AI. Neil reads a pull request to trace it for you, and for nothing else.
Which standards is the record shaped for?
The software lifecycle of IEC 62304, the risk management of ISO 14971 and design controls under ISO 13485 and 21 CFR Part 820: software items and their safety classes, requirements, risk controls, verification, known anomalies and releases. Signatures and audit trails for 21 CFR Part 11 and EU Annex 11 are part of Seal. You validate your own intended use, and Seal keeps the evidence for it.
We do not make devices. Is it for us?
Yes, if the software you write is regulated: a GxP system built in house, a laboratory's analysis pipeline, a digital therapeutic. The record is the same one: what the software must do, what could go wrong, the tests that show it, and who signed.
How is it different from Ketryx, Jama Connect or Polarion?
They hold the design side, and some connect more engineering tools than Seal does today. They stop at design transfer. Seal also runs manufacturing and quality, so a release is on the build record of every unit, a complaint opens on the unit it is about, and Neil works across all of it. Seal against Ketryx, in detail.
How do we start?
With one repository and one kind of change. In a 48-hour evaluation, once the scope is agreed and the inputs received, your pull requests open change records from your own template, with your signatures and your pipeline's evidence on them. Requirements, risks and tests come across from where they are kept now.
See your pull requests in Seal.
Opening change records from your own template, with your signatures, 48 hours after we agree the scope.
