PYX data product agentic engineering
Stage 01 · Requirement

The sentence somebody wrote, kept as they wrote it

A requirement arrives as prose, hedged and ambiguous. AI grills it into typed claims and blocking questions. A person answers them once, and the answers become part of the artifact.

How this worked before

A spec document, read once, contradicted in a channel, and dead by the time the table exists.

How it works here

The requirement is the artifact. It carries its own ambiguities, and it cannot progress while they are open.

Analytics has always started with a sentence somebody said in a meeting, and has always lost it immediately. The sentence becomes a ticket, the ticket becomes a spec, the spec becomes SQL, and by the time a number exists there is no artifact connecting it to the question anybody asked.

PYX keeps the sentence. Paste it as written: the hedging intact, because the hedging is the signal, and the model grills it rather than answering it. What comes back is a set of typed claims and a set of blocking questions: the four places the requirement is genuinely undecided, surfaced on day one instead of in week three when somebody hits them in code.

That inversion is the whole point. A language model is unreliable at deciding whether an executed move-out excludes the account, because that is a policy your business made and it is in neither the schema nor the training data. It is extremely good at finding every place the decision has not been made. Ask it for the questions; keep the answers.

Blocking questions gate progress

A question you cannot answer is the requirement's real cost, and it is visible before anyone spends a sprint on it. Answer it or park it: a parked question is a stated unknown that blocks what it should block, rather than a silent guess made by whoever writes the code.

Claims are typed, so nonsense is refused

A claim that compares a date to an identifier gets demoted before it can become a column. The lint runs at draft time, not at review time.

Scenarios come with the claims

Every claim implies at least two rows: one that passes on the boundary and one that fails by one. That set is the fixture the rest of the lifecycle tests against.

Demo · click through it

This stage, running

pyx · requirements / unbilled-revenue-by-age
Home
Estate
Design
Requirements
Data models
Control
Governance
Catalogue
Warehouse
Connections
Assistant
Requirement · REQ-114 · v3

Unbilled revenue by service-order age

Blocked
RequirementClarifiedModelBuiltGovernedVisualized

“Show unbilled revenue for meter-to-cash, split by how long the service order has been open, so we can see where billing is stalling.”
Submitted by A. Whitfield, Revenue Assurance · 12 Aug

4 claims seeded

Each bullet of the request becomes one claim: the engineering answer to it, checkable against the original wording.

2 open questions · 1 blocking

“Is revenue recognised at meter read or at invoice?”, nothing builds until that is answered. The other is parked, documented, and does not stop the work.

Blocker · 1 blocking question
One computation drives the dots, the blocker and the button, so nothing can disagree.