Intentset
Product truth as code · v0.1 draft
Keep product intent connected to what you ship.
Intentset connects what a product is meant to do with the slices that implement it, the checks that verify it, and the knowledge you share with customers.
Start with readable files in your repository. Build a product model that people and agents can follow.
The specifications are ready for review. A first reference toolchain, version 0.1, is published to try them against.
Readable files → connected model
- Intent Prepare learning in advance
- Observable behavior Schedule an assessment
- Rule Future release time
- Slice Assessment scheduling
- Verification Named checks + evidence
- Knowledge Reviewed guidance
Illustrative connections · not a live coverage report
The problem
Faster code needs a clearer product model.
A ticket explains why a change started. A test checks a result. A document describes a promise. Keeping them connected as the product changes is the hard part.
Intentset gives those connections a durable place in the repository—centered on observable product behavior.
What you get
Six questions your repository can answer.
What does the product promise?
Every observable behavior is written down once, with its rules, examples and failure cases, in words a product reviewer can check without reading code.
Who owns it in the code?
Each behavior has one accountable slice, and an architecture check keeps other code out of that slice's internals.
Is it verified right now?
A pass counts only on the commit under review. Linked checks and current passes are reported apart, so coverage never looks better than it is.
What does this change touch?
Before a change merges, see the behaviors, owners, checks and customer explanations it could reach, and the path to each.
What should an agent read first?
Hand an agent the bounded context around the code it is about to change: the promises, rules, contracts and decisions, and nothing beyond them.
What may we tell customers?
Publish reviewed explanations for one audience and one release. Drafts, internal notes and unreleased work stay out by default.
See how it works, step by step, from the first file to a published explanation.
A worked model
One behavior. A connected view.
Example: Schedule an assessment
A teacher chooses when a published assessment becomes available to a class.
- Intent: Help teachers prepare learning in advance.
- Behavior: Schedule an assessment for a future time.
- Rule: The assessment must be published and the teacher must be allowed to assign it.
- Implementation: One accountable slice, with explicit contracts and backend ownership.
- Verification: Named checks, with evidence tied to a particular snapshot.
- Knowledge: Reviewed guidance for the right audience and release.
Illustrative model. These links describe the proposed structure, not a live verification report.
Start broad. Inspect the details when you need them.
For product teams
Review capabilities and behaviors without reading every implementation detail. See where a promise is still unclear, unimplemented, or missing evidence.
For engineers
Find the slice that owns a behavior, the contracts it exposes, and the rules a change must preserve.
For people building with agents
Give an agent a bounded set of product context before it edits code. Review the resulting behavior, implementation, tests, and knowledge together.
Adopt one useful connection at a time.
- Describe a behavior. Choose one promise your product makes.
- Name its owner. Connect it to the slice that delivers it.
- Attach verification. Identify what is checked and which evidence is current.
- Publish with context. Review the explanation for its audience and release.
Keep your existing workflow. Expand the model as its value becomes clear.
Project status
Specifications first. A reference toolchain next.
The v0.1 package defines the product model, traceable vertical slices, and a TypeScript + AWS Amplify Gen 2 reference profile.
Validation, architecture checks, change-impact reports, a Product Atlas, reviewed publication, and agent context ship in the 0.1 reference toolchain. They are early releases, to try against one real capability.
Help make product intent easier to maintain.
Review the draft. Walk through the example. Try the model against one real capability and bring back what does not fit.