Technical Facts vs Product Constraints
Keep discovered implementation behavior separate from intended business constraints and explicit assumptions.
These examples and illustrative results are independently authored teaching materials, not measured model results.
Use case
A developer asks for export functionality, and the existing query has LIMIT 100. The teaching note only says the first list screen fetches 100 rows; it contains no export entitlement policy. You can establish current list behavior without claiming free users have a 100-row export allowance.
Mechanism
Inspect implementation, documentation and requirements first, recording discoverable technical facts. Separately list constraints supplied by authoritative product artifacts and unresolved items. Determine whether the missing export cap is a necessary permission/completeness decision; ask focused questions when it is. Cite an existing explicit rule instead of asking for it again.
Bad example
Add export. The query contains LIMIT 100, so free users may export only 100 rows. Implement that entitlement policy.
Good example
Prepare an export implementation brief from the query and note above. Separate technical facts, product constraints and decisions: the first list screen currently fetches 100 rows, but no export entitlement cap is supplied. Inspect maintained PRDs or product rules first. If limits or permissions remain unspecified, ask the questions affecting this implementation. Do not infer pricing rights from LIMIT 100 or silently truncate export. Cite any explicit rule already available.
Why the change matters
LIMIT may implement list paging, a performance guard or a temporary choice rather than a pricing policy. Separating observations from requirements makes each restriction’s authority traceable and exposes behavior that cannot yet be safely decided.
Observable expectation
An illustrative brief records: fact—list queries fetch at most 100 rows, based on the query and first-screen note; product constraint—no export cap supplied; decisions—export scope, permissions and paging.
Preserve unknowns and reject an invented free-user policy. If an explicit export rule is later found, move it into product constraints with a reference rather than leaving it as a question.
Limits
Maintained product documents in the repository may supply authoritative rules; business information is not categorically absent from repositories. Evidence can settle ordinary technical choices, while permission, completeness or contractual unknowns cannot be decided through convenient defaults.