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.
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.
Repository first
Open files. Explicit meaning.
Write in Markdown with YAML frontmatter. Give behaviors stable IDs. Link the rules, slices, checks, and explanations that belong together.
The repository stays authoritative. Graphs and review pages are views of those files.
---
markset: 0
intentset:
spec: "0.1"
profile: intentset/behavior/0.1
id: BEH-ASMT-SCHEDULE
type: behavior
title: Schedule an assessment
# Further required metadata omitted
---
# Schedule an assessment
A promise people can read.
A connection tools can follow.
The document layer
Rich documents, with Markset.
Intentset defines what the product model means. Markset provides the document layer for reading and sharing it.
Intentset profiles add metadata and document conventions without adding product-specific rendering syntax. The publisher turns reviewed product knowledge into portable Markset documents for people, support teams, and customer-facing answers.
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.