Specification clarity
An agent builds the wrong thing faithfully, fast, and at scale. Ambiguity is now a throughput problem.
The Program Operating System
The operating system for
complex engineering programs.
An operating system keeps one true state, runs every process with permissions, schedules the work, and logs everything. Progros does that for a program — requirements, plans, work, proof, and acceptance in one live graph that your engineers, coding agents, and customer all work from.
Built to be the best way to take a complex system from what the customer asked for to what they signed off.
Start with one requirements document. No migration, no process change.
- One stateThe program graph: needs, requirements, plans, work, proof, acceptance. Every screen and report is a view of it.
- Processes with permissionsAgents and people, each with a role. Agents propose; people decide; nothing an agent drafts counts until it is reviewed.
- A schedulerRequirements become a work breakdown for engineers and coding agents. Branches, merges, and test runs move it.
- A log that can't be rewrittenEvery change attributed, versioned, hash-chained. Change one line and see everything it touches.
01 Why now
AI made building fast. Nothing around it got faster.
An agent can turn a precise, testable spec into working, tested code in minutes. So the constraint moved — to knowing what to build, proving it works, and getting it accepted. That is the work Progros manages.
Verification capacity
Test benches, device labs, hardware, qualified witnesses, customer experts. None of it got faster.
Stakeholder trust
Output volume rose. The rate at which customers absorb, train on, and accept change did not.
Judgment
What should be true, what risk is acceptable, what evidence is enough. Not delegable — and never delegated.
02 What it costs
Four failures every program lead has lived.
- 01
We built the wrong thing — fast.
The requirement was ambiguous. The agent didn't ask. Nobody noticed until the demo.
- 02
"Verified" — three architecture changes ago.
The results are real. Which ones still hold, nobody can say.
- 03
Month five: the test bench is booked until month nine.
The binding constraint was physical, and invisible to every tool in use.
- 04
Shipped. Refused.
The customer wouldn't operate a capability nobody had agreed how to accept.
Every one of them was knowable in week two — by a tool that modeled intent, evidence, and reality.
03 The structural gap
A ticket records activity.
A claim records what's true.
Implement session timeout
Done5 ptsSprint 14test-results-final-v2.xlsx
- Which requirement does this satisfy?
- Proven on which build — and is that still true?
- Which customer need does it serve?
- Has the customer agreed what "done" means?
Sessions expire after 30 minutes of inactivity.
- Serves
- N-2 · Users distrust apps holding health data
- Accepted when
- Given an idle session, after 30 minutes the next request is refused · agreed with the customer
- Proven by
- 2 tests at
9f1c2ab7on main · evidence current - Method
- Automated test · @verifies in auth.spec.ts
- Scenario
- C-2 Returning user on a shared device
- Provenance
- Proposed by the Elicitor agent · approved by the security lead
Your tracker isn't bad at this. It's structurally incapable of it.
04 The diagnostic
Each one looked like a finished requirement.
- User Authentication – Secure login with email/password and optional social login.
- Goal Setting – Users can create and update fitness goals.
- Activity Tracking – Log workouts, distance, and calories burned.
- Progress Reports – Generate weekly/monthly summaries.
- Notifications – Send reminders for workouts and milestones.
- Data Export – Export activity data in CSV format.
- Performance: App must load within 2 seconds on mobile devices.
- Security: Data encrypted at rest and in transit; comply with GDPR.
- Reliability: 99.9% uptime during business hours.
- Usability: Intuitive UI; accessible to users with basic literacy.
- Scalability: Support up to 10,000 concurrent users.
- Must be developed using React Native.
"comply with GDPR"CriticalHealth data is special-category data.
Explicit consent, a mandatory impact assessment, rights to access and erasure. Three words expand to a quarter of the real scope.
"99.9% uptime"CriticalUnverifiable before launch. Ever.
It needs weeks of production observation. A launch gate of "all requirements verified" is arithmetically impossible.
(not in the document)CriticalOffline logging is missing entirely.
People log workouts in basements and on trails. No line-by-line review finds a requirement that isn't there.
"during business hours"HighThe SLO is silent when it matters.
Fitness apps peak mornings, evenings, and weekends — precisely outside the window. Whose time zone, anyway?
A line-by-line review reads the text. Progros checks what the text implies — and what it leaves out. Minutes after upload, with every claim citing the line it came from.
05 How it works
From the customer's words to proof they'll accept.
One graph, built by agents that propose and people who decide. Every screen and report is a view of it — so none of them can drift.
-
01
Capture
Upload a spec, statement of work, or feature list — PDF, Word, or text, scanned pages included — or import from a spreadsheet or ReqIF. The Elicitor proposes atomic, testable claims, each quoting the exact line it came from.
R-7 The system shall let users log workouts, distance, and calories.“Log workouts, distance, and calories burned.” · line 3 -
02
Diagnose
The Analyst reads the whole specification: implied obligations, unverifiable claims, conflicts, gaps. You acknowledge, resolve, or dismiss with a reason — and dismissals stay dismissed.
Critical Implied obligation · GDPR Art. 9 health data targets R-12, CON-1 · 2 proposed requirements -
03
Agree what "done" means
Progros derives the customer's intent, end-to-end acceptance scenarios, and criteria for every requirement — and asks the customer instead of inventing a number.
Given no connectivity, a logged workout is kept and syncs within [TBD: maximum sync delay]Question for the customer · R-26 -
04
Plan
The Decomposer proposes components, work items with a definition of done, and how each requirement will be proven — for any number of requirements. Your leads review it like everything else.
CMP-3 Pump controller → W-12 Occlusion trip · satisfies R-7 · done when the pump stops within 100 ms at 6 bar on the bench -
05
Build — people and agents
Work lands on a board with its requirements and criteria attached. Coding agents take it over MCP. A branch named for the work starts it; the merge finishes it — no status updates.
feature/W-12-occlusion merged → W-12 done · by the repository webhook -
06
Prove it
Tests that name a requirement land as evidence pinned to the commit. Bench runs, inspections, and analyses are recorded with their files and, where rigor demands it, a witness.
✓ R-7 3 tests at 9f1c2ab · ✓ R-8 bench run 17, witnessed · ✗ R-3 1 failed -
07
Absorb change
When a requirement changes, every plan, work item, and piece of proof made against the old text turns suspect — shown in review before anyone accepts the change, and to agents before they build on it.
⚠ R-7 changed after W-12 was planned · proof out of date · still valid? -
08
Deliver the proof
A live view of what is proven, failing, and out of date. Seal a baseline, and hand the customer an evidence package: every claim, its proof and files, checksummed.
06 For engineers
Engineers never open it to update a status.
Work arrives with the requirements, criteria, and test method attached. Name the branch for it and the merge closes it. Annotate the test you were writing anyway, and every CI run lands as evidence pinned to the commit it proves. People make only the judgment calls.
- Proposed agent drafts
- Baselined you decide
- Allocated inferred
- Designed inferred
- Implemented inferred
- Verified from evidence
- Validated you decide
- Accepted the customer signs
Conventions are encouraged — never a merge gate. Bookkeeping must never block shipping.
// auth.spec.ts — the test you were writing anyway
test(
'session expires after 30 min idle @verifies("R-1.3")',
async () => {
// …
});$ node progros.mjs report-tests results/*.xml
Progros: 214 tests (213 passed, 1 failed) at 9f1c2ab7e0d4
✓ R-1.3 2 test(s)
✓ R-2.1 4 test(s)
✗ R-3.4 3 test(s), 1 failed
→ R-3.4 verified → implemented
⚠ unknown requirement refs: R-9.9 — check the annotationsWorks with any CI that writes JUnit XML — Bitbucket, GitHub, GitLab, and the rest. Coding agents connect over MCP: they read the work and its acceptance contract, ask your team when the spec is unclear, and can never edit the specification.
07 Bid mode
Price the program before you win it.
The same system scopes a bid. Requirements become the customer's intent, a reviewed work breakdown, and estimates with their basis — priced with your own rates and costs. Win, and the bid is already the program.
- 01
Estimates with a basis.
The Estimator proposes three-point hours for every work item, with its reasoning and risks. Your leads adjust them. Hours or story points.
- 02
Your rates, your costs.
Rate cards by labor category, subcontracts, materials, travel, and any line you need — through overhead, G&A, contingency, and fee.
- 03
Price to win.
Model competitors' likely prices and the customer's budget; see the chance of winning and the expected profit at every price.
- 04
A document to send.
Scope, assumptions, schedule, and price in a bid document — with your price-to-win analysis kept out of it.
| Direct labor 9,675 h across 6 categories | $1,018,400 |
|---|---|
| Overhead 38% of labor | $386,990 |
| Subcontracts & materials | $214,000 |
| Travel & other direct costs | $36,500 |
| Contingency from estimate risk | $96,800 |
| G&A 12% | $210,320 |
| Fee 10% | $196,300 |
| Price | $2,159,310 |
Price to win at this price: 58% chance to win · expected profit $114k
08 Governed AI
AI you can hand to an auditor.
- 01
Agents propose.
Narrow roles, not one chatbot — an Elicitor, an Analyst, a Decomposer, an Estimator — each with a registered, versioned prompt.
- 02
People baseline.
Every proposal goes through review: accept, amend, or reject. How much agents may do on their own is set by the program's rigor.
- 03
Provenance is permanent.
Every contribution records who or what made it, which model and prompt, and who approved it — on a tamper-evident, hash-chained log. Every model call is on a ledger with its cost. Your data never trains a model.
› Show everything in this baseline that came from an AI proposal, and who approved it.
| Claim | Origin | Decision | By |
|---|---|---|---|
| R-1.3 | Elicitor | Approved | Security lead |
| R-8.11 | Analyst | Approved with edits | Data protection officer |
| W-14 | Decomposer | Rejected | Engineering lead |
| R-3.7 | Elicitor | Approved | Product owner |
214 of 312 claims agent-originated · 100% human-reviewed · 0 unattributed
09 The rigor dial
One product, from prototype to defense program.
LeanPrototype
CommercialMost teams start here
RegulatedMedical · fintech
Safety-criticalAuto · aerospace
Defense programGovernment
Change controlAuthor approves Quorum board, e-signature
VerificationImplementer may verify Independent and witnessed
FindingsAdvisory Gate-blocking
Lifecycle from evidenceCI moves claims to Verified Evidence recorded, a person attests
Rigor profiles, the evidence-driven lifecycle, and witnessed verification are available today; e-signature arrives with the regulated tier.
Per program
Run a prototype at Lean and a certified subsystem at Safety-critical — same people, same benches, same tool.
Raise without migrating
Go from your first customer to your first certification by turning a dial, not by switching to a heavyweight ALM.
Built for it from day one
Tenant isolation enforced by the database, immutable baselines, and a hash-chained audit log — not bolted on later.
10 Every engineering discipline
Link versions, not copies.
Progros doesn't mirror your repository or your PDM vault. It records which revision of which work product proves which requirement — the same model whether that's a commit, a board revision, or a stress report. Any discipline can record a result today: the method, the unit or revision it was run on, the files that prove it, and a witness.
- SoftwareCI, git, and coding agents
- Test & labRecorded, witnessed results
- Firmware & embeddedJUnit and recorded results
- SystemsReqIF and spreadsheet import
- ElectricalRecorded results · connectors planned
- MechanicalRecorded results · connectors planned
- StructuresRecorded results · connectors planned
- Thermal & fluidsRecorded results · connectors planned
- Manufacturing & qualityPlanned
11 Where it fits
Everything exists somewhere. Nothing in one graph.
| Intent & requirements | Evidence & verification | Acceptance from intent | Governed AI | Engineer-grade UX | Resources & plans against reality | |
|---|---|---|---|---|---|---|
| Issue trackersJira · Linear · Azure DevOps | ||||||
| Requirements / ALMDOORS · Polarion · Codebeamer · Jama | ||||||
| Test managementTestRail · Zephyr · qTest | ||||||
| AI coding agentsMake the new bottleneck worse, faster | ||||||
| ProgrosBy design |
Core strengthPartialStructurally absentOn our roadmap
12 Getting started
Start with a diagnostic. Change nothing.
- 1
Bring one spec
Upload a requirements document. Within minutes you have cited claims and a diagnostic of what's missing, implied, or unprovable.
- 2
Agree acceptance
Review the derived intent, scenarios, and criteria — then take the open questions to your customer before anyone builds.
- 3
Plan and connect the work
Accept the work breakdown, connect your repository and coding agents, and add one step to your pipeline. Evidence starts flowing from the next build.
- 4
Raise rigor when you need it
Regulated customer, certification, government contract: turn the dial for that program. Same tool, same data.
Get started
Bring one spec.
See what it finds.
Create a workspace in a couple of minutes and run your first diagnostic today.
- Create your workspace with your work email.
- Confirm your email — the link opens Progros, ready to go.
- Upload one spec and read what it finds.
Already have an account? Sign in. Questions first? Read the FAQ.
Received
Thank you — we'll be in touch.
We'll reply to about your program. Meanwhile you can create a workspace and try a spec.
Questions
Asked, answered.
Does Progros replace Jira?
Not on day one, and you don't need it to. Start with a diagnostic of one specification and keep your tracker. Progros holds what a tracker can't — what must be true, how it's proven, and whether the customer accepts it. When you're ready, its work breakdown and board can carry the work too: derived from the requirements, moved by branches and merges, and flagged when a requirement changes underneath it.
Does my data train AI models?
No. Your data is never used to train any model. Every model call is recorded on a ledger with its inputs, outputs, model, and prompt version, so you can see exactly what the AI did with what.
Which AI does it use?
Claude, by Anthropic, through Progros's own inference gateway — which records every call, attributes it to the program it served, and keeps the agents' prompts registered and versioned.
Can the AI change our requirements?
Agents propose; people decide. Every claim, criterion, and scenario an agent drafts goes to a review queue where you accept, amend, or reject it. At higher rigor levels, agents may only propose. Coding agents connected over MCP can read requirements and ask questions — they can never edit the specification.
We're regulated, or a defense program. Is it ready for us?
It was designed for you from the first line: database-enforced tenant isolation, immutable baselines, a hash-chained audit log, and rigor profiles up to Defense, and witnessed verification. The architecture is built so dedicated, government-cloud, and air-gapped deployments run the same code; e-signature arrives with the regulated tier. Tell us about your program when you sign up and we'll talk through what you need.
Is it only for software?
No. Software connects through CI, git, and coding agents, and firmware and lab tests that produce JUnit results take the same path. Every other discipline records results directly — a bench run, an inspection, an analysis — with the files that prove it, the unit or revision it was run on, and a witness where needed. Connectors to electrical, mechanical, and PDM tools are on the roadmap. Tell us what you use.
Can it help us bid?
Yes. Bid mode takes the customer's requirements through intent, a work breakdown, and estimates with their basis, then prices them with your rate cards, subcontracts, materials, and other costs — with a price-to-win analysis and a bid document to send. If you win, the bid becomes the program, with nothing re-entered.