Product Intent

Intent split across notes and books has no single answer to the question an agent asks before building. One home per kind gives every reader one place to look.

litespec consumer fails a why-layer record outside its home folder.

Marked checkable: the tool named here checks it.

One product gives every reader one answer to what the business is. The never list refuses what the product does not become.

litespec consumer fails a brief without one product, boundary, and audience.

Marked checkable: the tool named here checks it.

An unanswered constraint is a law the product may break unknowingly. A project with no outside rules records that answer too.

litespec consumer fails a constraint without source and applicability, or a project with unanswered constraints.

Marked checkable: the tool named here checks it.

The fixed shape puts the present, the future, and the past of one topic on one page. The chapter sections are Summary, The situation, What we do, Why it is better, A worked example, Costs and risks, and How sure we are. The commitment sections are Rules, Position, Refusals, Open questions, Next, History, and Evidence. Rules holds every testable commitment as a Requirement entry. Position holds choices with their decisions, including choices no system carries. A reader learns where each answer sits once and finds it on every topic.

litespec consumer fails a topic page missing a required section or reviewBy.

Marked checkable: the tool named here checks it.

A rule list states what was decided and convinces nobody of why. The chapter carries the situation, the voices, the numbers, the comparison, and one worked example, so you understand the choice before reading its rules. Sources keep the story checkable rather than a pitch, as litespec/core/product#cite-sources-for-chapter-claims states.

litespec consumer fails a topic whose chapter follows its commitments.

Marked checkable: the tool named here checks it.

A number without its source cannot be rechecked. The chapter convinces only when its claims are checkable.

Does each claim in the chapter cite its source?

Marked guidance: a reviewer answers this question.

An identifier lets a record name the commitment it fulfills, and lets the model resolve the name. A commitment written only as prose cannot be traced. Kinds are promise, behavior, quality, target, and practice. A target names what is counted in measure and the date or milestone in by. A practice is a commitment kept in how the company works. Any requirement may name in deliveredBy the planned, later, or refused feature that carries it.

litespec consumer fails a Requirement entry without identifier, kind, or statement, or a promise without effective-dated values.

Marked checkable: the tool named here checks it.

The link runs from behavior to intent, so a product change shows which records to revisit.

Does every record that carries a requirement name it in fulfills?

Marked guidance: a reviewer answers this question.

A product page that describes behavior becomes a second specification, and it drifts from the first. Behavior records own behavior and name the requirements they fulfill.

Does any product page name a state, entry point, failure code, or handler?

Marked guidance: a reviewer answers this question.

A fact without its source cannot be rechecked. The read date shows when the outside fact was true.

litespec consumer fails a Research record without question or source read date.

Marked checkable: the tool named here checks it.

Problems without owners attract solutions nobody needs. A refused feature keeps its reason so the refusal is not relitigated.

litespec consumer fails a problem or feature missing its required fields.

Marked checkable: the tool named here checks it.

A position with no decision behind it is an opinion that nobody approved. The link lets a reader check who chose it, when, and on what evidence.

Does every Position and Refusals entry link an unretired decision, approved when the page is approved?

Marked guidance: a reviewer answers this question.

A business choice is argued from options and evidence, and it is reopened by a condition rather than by a date. The sections are Context, Options, Decision, Consequences, and Evidence.

litespec consumer fails a decision missing a required section or decides target.

Marked checkable: the tool named here checks it.

Product, commercial, and legal choices belong to an accountable person, as litespec/core/system#keep-decision-authority-with-accountable-people states. The decider is named while the decision is a draft. Approval gates the release, while building may start on a draft. An agent drafts the decision for the decider.

Did the named decider approve the decision, and does the record carry the date?

Marked guidance: a reviewer answers this question.

A decision edited in place loses the reason it once held, and the topic pages that cited it silently change meaning. A replaced record stays readable as the past.

Does the new decision name the old one in replaces, with the old one retired?

Marked guidance: a reviewer answers this question.

A past typed by hand drifts from the records it claims. Only the model builder writes the region. Regions are fenced as the model page defines.

Does History list exactly the decisions that decide the page, as generated?

Marked guidance: a reviewer answers this question.

Generated research mixes verified facts, inferences, and recommendations in one voice. A recommendation from an agent that reads as a decision gets built without anyone having made it.

Does every new position trace to a Research record or an approved decision?

Marked guidance: a reviewer answers this question.

A stale strategy misdirects every plan built on it, and nothing in the code fails when a market or a price moves. A date makes the reread due rather than optional.

litespec consumer fails a topic page whose reviewBy date has passed.

Marked checkable: the tool named here checks it.

Commercial behavior that contradicts the business position compiles and passes its tests. Only the product pages say it is wrong.

Does the change report list the product pages read before the change?

Marked guidance: a reviewer answers this question.

A requirement no record fulfills is intent the system does not carry yet. The model lists each requirement with the records that fulfill it.

Does the coverage list come from the model rather than hand-kept notes?

Marked guidance: a reviewer answers this question.

The order makes each layer checkable before the next builds on it. A specification written before its decision argues from code. Approval follows litespec/core/principles#refuse-approval-behind-a-draft-decision: nothing is approved behind a draft.

A price change lands its research note, then decision decision/0011-raise-the-monthly-plan and requirement requirement/pricing.monthly-plan-fee, then the billing fulfills link, then the code.

The running library example lands its loan period in the same order: research research/loan-period-benchmarks asks how long city libraries lend, decision decision/0001-loan-period chooses 21 days and names requirement/borrowing.loan-period-days in decides, use case use-case/lending.extend-loan names that requirement in fulfills, and only then does the ExtendLoanCommand code carry it. A decision written after that code would be a defect.

The order of work: intent, then the choice and its commitment, then specification records, then code and tests.

Did intent, research, decision, requirement, records, code, and tests land in order?

Marked guidance: a reviewer answers this question.

A rule, use case, or journey fulfills a requirement, and a planned, later, or refused feature delivers it. A target or practice is measured or kept outside the code, so deleting one to clear the check loses intent. Planned work belongs to its feature, so a Known gap marks only what nobody owns.

litespec model check reports no requirement-unfulfilled finding outside an open Known gap.

Marked checkable: the tool named here checks it.

Approval before every edit stalls agent work on a queue of one person. The release still needs the approval, so nothing ships on a draft alone.

Does the release hold approval for every decision the code builds on?

Marked guidance: a reviewer answers this question.