The product twin + the delivery harness
Know the product
behind the code.
Change it
with context.
A connected model of your code, data and requirements. A delivery harness that uses it to plan changes, guide coding agents and verify results, with people controlling the decisions.
Product direction preview · Application scaffolds available.
US-14-02 / CUSTOMER INTENT
Cancel a subscription.
Stop the next invoice.
billing-api / SubscriptionService
Proposed state transition
ACTIVE → CANCELLED
The new state changes what downstream code should do.
Direct edit
The customer action.
customer-web / BillingPage
Show cancellation inside the allowed window.
Affected consumer
The invoice job.
billing-worker / InvoiceScheduler
A status change must also stop future billing.
Unresolved: external proration is not indexed. Keep the gap in the plan.
One small change.
A whole product
to understand.
The requirement, the implementation and the downstream effect live in different places. Delivery is designed to connect them before the next change begins.
Find your starting pointTHE REQUIREMENT
A customer can cancel.
The ticket describes the change.
Within 14 days of starting a subscription.
THE IMPLEMENTATION
The API changes state.
The code describes one part of it.
Subscription.status = CANCELLED
THE DEPENDENCY
The job still sends an invoice.
The consequence lives somewhere else.
InvoiceScheduler → next billing cycle
- Illustrative example, carried through the delivery walkthrough below.
Two starting points / One product model
Start with working software. Or a product brief.
Make the product you have understandable.
Connect the repositories. Relate the code to the behaviour it implements, with source evidence and gaps kept visible.
Existing source → Connected baseline
Illustrative product flow
The existing software
billing-api
SubscriptionService.java
pause(subscriptionId) → PAUSED
Subscription.java
status: ACTIVE | PAUSED
RefundService.java
isEligible(days) → days <= 14
V003__subscriptions.sql
subscriptions.plan_id → plans.id
customer-web
billing/page.tsx
Subscription status and pause controls
billing-worker
InvoiceScheduler.java
Reads subscription status before invoicing
File and symbol references support the links between repositories.
A source-backed product baseline
Use case · Manage subscriptions
Story · Pause a subscription
The existing journey connects the billing page, subscription state and recurring invoice behaviour.
- Extracted fact
- status: ACTIVE | PAUSED
- Source: Subscription.java + schema evidence.
- Inferred behaviour
- A refund may be eligible within 14 days.
- Interpreted from RefundService.isEligible. The team can refine this meaning through text.
- Unresolved link
- Proration lives in an external billing service.
- External behaviour remains a gap until supporting evidence is available.
Next: Propose cancellation against this baseline, then inspect its impact.
Both paths lead to the same product twin, designed to stay current as connected code changes.
Product direction preview
One model of what your software does, why, and where.
Language-aware analysis extracts structure from source. The model connects that evidence to behaviour and requirements, retaining file and commit references where available. Unsupported features and unresolved relationships stay visible.
Rules, permissions, states and transitions, with the conditions that guard them.
INTENT
A customer can cancel within 14 days
US-14-02 · acceptance criterion
IMPLEMENTATION
SubscriptionService.cancel
billing-api · cancellation path
STATE
ACTIVE → CANCELLED
subscriptions · status transition
DEPENDENCY
InvoiceScheduler
billing-worker · future invoices
Selected layer: Behaviour
Subscription: ACTIVE → CANCELLED, only when days_since_start ≤ 14
Illustrative relationships. This preview is not connected to a project.
Let a customer cancel a subscription within 14 days.
Follow one illustrative cancellation story through the product twin and delivery harness. Each stage shows a different piece of the work.
US-14-02 · ILLUSTRATIVE
Cancel a subscription within 14 days of starting it
Acceptance criteria
- 01A customer can cancel from the billing page within 14 days of the start date.
- 02Cancellation stops future invoices immediately.
- 03Cancellations after 14 days are refused with a clear reason.
The team reads the twin
Find the code behind the rule.
The cancellation story touches more than a button. Inspect the status readers, billing path and missing evidence before proposing the change.
Source facts, inferred relationships and coverage gaps stay distinguishable.
A three-repository impact map
US-14-02 · proposed impactbilling-api
Direct edits
SubscriptionService.cancel · BillingController · V017
Proposed endpoint, status transition and cancelled_at migration.
customer-web
Direct edits
BillingPage · cancellation request
Proposed customer action and a clear refusal after the allowed window.
billing-worker
Affected consumer
InvoiceScheduler · subscription status reader
Verify future invoice selection. An affected consumer is not automatically a planned edit.
Coverage gap: external proration is not indexed. The proposal keeps it unresolved.
Illustrative example. Names, counts and results are invented to show the shape of the workflow.
03 / What the model will and will not claim
Three kinds of truth, always kept apart.
Source evidence, interpretation and missing context have different meanings. The model is designed to preserve those distinctions through each refresh, so an inference never promotes itself into a verified fact.
Subscription
Entitybilling-api · migration V003 · commit 8f21c4
status: ACTIVE | PAUSED | CANCELLED
Extracted
Enum read from the column definition and the Java type.
plan_id → plans.id
Extracted
Foreign key present in migration V003.
Cancellation allowed within 14 days
Inferred
Interpreted from a guard in RefundService.isEligible. The team can correct this.
Proration on cancel
Unresolved
Handled by an external billing service that is not indexed. Shown as a gap, not assumed.
Illustrative source excerpt
enum Status {
ACTIVE, PAUSED, CANCELLED
}
boolean isEligible(int days) {
return days <= 14;
}The enum is directly observable. What the eligibility rule means for cancellation is an interpretation.
- Extracted
- Read directly from source, with the file and commit attached.
- Inferred
- An interpretation the team can inspect, correct or reject. Its origin is always kept.
- Unresolved
- Something the model could not see. It stays visible so nobody plans around a blind spot.
An agent saying “done” is not proof. Captured changes and observed build, test and merge outcomes provide the evidence, with each result kept separate.
Illustrative entity and source. No customer project is connected to this preview.
Agents do the work. People own the decisions.
The intended harness keeps proposal, permission and execution distinct. Product context moves between them; approval never comes from the agent that wrote the plan.
Model proposal
GLM
Propose the change
Use cases, implementation impact and sprint order, grounded in the available product model.
A reviewable proposal
Human decision
Dev + PM / TL
Approve and start
Dev approves scope and plan. PM/TL approves sprint order and freezes scope. The assigned developer starts.
An approved version to execute
Agent execution
Claude Code
Build in the workspace
The agent edits source and tests. Dev steers through text; builds, migrations and test runs retain their outcomes.
Changes and execution evidence
Human decision
QA + Dev + PM / TL
Review and merge
QA reviews the test set. Dev reviews code. PM/TL decides when to merge with those states visible.
A recorded merge outcome
Changes and captured evidence refresh the twin for the next proposal. Merge does not mean deployed.
Specified execution safeguards
- Approved input versions
- Persisted execution order
- Failures pause the affected queue
A cancelled subscription was billed. Follow the evidence.
The same product model is designed to connect runtime events, business records and source code. Keep an observed failure separate from the explanation still being investigated.
Scoped, read-only investigation
Example scope: the subscriptions project, production build 4f1a and the relevant trace and redacted business record. No data repair, restart or write is shown.
POST /invoices/run · build 4f1a · prod
SQL selected a CANCELLED subscription.
An invoice record exists after cancellation.
Times, identifiers and events are synthetic. The assertion describes this example’s business failure, rather than claiming an exception proves its cause.
01 / Observed failure
An invoice followed cancellation.
The example invoice timestamp is later than cancelled_at. The linked SQL span selected that subscription. These records support the symptom.
Evidence: trace EX-240 · subscription EX-014 · invoice EX-092
02 / Suspected cause
A status filter may be too broad.
WHERE status != 'PAUSED'This example source predicate also permits CANCELLED. It is a cause hypothesis to check against the deployed revision and a reproduction, not an automatic root-cause verdict.
03 / Back to delivery
Propose a fix and keep the proof.
Link the scheduler guard and the cancelled-subscription regression to US-14-02. The team reviews the proposal through the same delivery workflow, then compares later evidence with the original failure.
No automatic repair or production change is implied by this investigation.
Illustrative provenance: project → billing-worker → commit → build 4f1a → prod → trace → business record. Production investigation is an intended capability.
A shared view is not a shared permission.
Active company members can read ordinary product and delivery records. Approval, execution and sensitive access follow their own roles and grants.
- Tenant CTO
Own company administration
Onboard the company, invite users and manage roles. Ownership applies within one isolated company tenant.
- CTO / CIO reporting
Read and question the evidence
Inspect permitted reports and delivery context. Reporting access alone does not grant user administration, SSH or sensitive database access.
A common way to correct the model
Every active role can refine a generated baseline or business interpretation through text and an explicit Apply. That does not grant delivery approval or merge authority.
QA approval, passing tests and developer code approval are visible states, not mandatory merge gates. PM/TL retains the merge decision.
The specification is ready. The product is taking shape.
A clear boundary between what is specified, what you can inspect today and what still needs implementation and runtime proof.
Readiness / Specification and runtime are separate
- Product specifications
- Specification locked
All 25 use cases are locked for development at revision 1. A locked contract is not a working feature.
- Design foundation
- Available to inspect
This landing preview, the component library and frontend/backend scaffolds are in place. The gallery interactions use local sample state.
- Product workflows
- Development work
No product use case is implemented or runtime-accepted. Identity, the twin, execution, verification and operations still need end-to-end implementation.
- Managed-codebase coverage
- Development work
Java, JavaScript, TypeScript and Python are required indexing scope. Adapter and framework qualification remains development work.
Explore the interface foundation we are building on.
Open the design system