innovation register

{
  "id": "inn-p02-001",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "EARS-slotted requirement as the internal ProductSpec representation: trigger, precondition, system, response are mandatory slots so an unfilled slot is both the confidence signal and the next interview question",
  "evidence_class": "hypothesis",
  "source": "com-b-013 EARS notation",
  "limitations": "EARS was designed for engineered systems; fit to fuzzy business outcomes untested",
  "disposition": "top10"
}

{
  "id": "inn-p02-002",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "UNCOVERED as a computed state on every requirement: a ProductSpec cannot be called complete while any requirement lacks a linked acceptance criterion",
  "evidence_class": "hypothesis",
  "source": "com-b-045 Xray",
  "limitations": "Requires acceptance criteria to exist as linkable objects, raising authoring cost",
  "disposition": "top10"
}

{
  "id": "inn-p02-003",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Elicit into slots, emit Gherkin: close the disjointness by making elicitation write into an EARS structure whose temporal clause order maps mechanically onto Given/When/Then",
  "evidence_class": "hypothesis",
  "source": "cross-survey gap (51 commercial + 60 OSS surfaces)",
  "limitations": "The bridge is structurally clean but unproven end-to-end; no surveyed system does both",
  "disposition": "top10"
}

{
  "id": "inn-p02-004",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "NEEDS-CLARIFICATION markers embedded at the point of ambiguity, each carrying candidate answers, making unresolved intent countable and mechanically gateable",
  "evidence_class": "hypothesis",
  "source": "oss-a-001 spec-kit",
  "limitations": "Nothing prevents a model emitting zero markers by guessing confidently; needs an independent ambiguity detector",
  "disposition": "top10"
}

{
  "id": "inn-p02-005",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Provenance pointer per requirement: every ProductSpec clause links to the client utterance or evidence item that produced it, converting scope disputes from opinion into lookup",
  "evidence_class": "hypothesis",
  "source": "com-b-003 BuildBetter; com-a-002 Cloobot X",
  "limitations": "Requires captured discovery evidence; cold-start clients have no corpus",
  "disposition": "top10"
}

{
  "id": "inn-p02-006",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Blocking Accept/Revise gate before any build: a spec the client never explicitly accepted is not a spec, and acceptance baselines the artifact",
  "evidence_class": "hypothesis",
  "source": "com-b-024 Replit; com-b-014 DOORS Next baselining",
  "limitations": "Gate fatigue if conflated with billing approval (Replit's design smell)",
  "disposition": "top10"
}

{
  "id": "inn-p02-007",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Change-scoped spec deltas (ADDED/MODIFIED/REMOVED against a baseline) so repeat engagements never re-elicit settled requirements",
  "evidence_class": "hypothesis",
  "source": "oss-a-002 OpenSpec",
  "limitations": "Nothing validates delta internal consistency or baseline accuracy",
  "disposition": "top10"
}

{
  "id": "inn-p02-008",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Maturity-typed spec artifacts (hypothesis → prd → committed proposal) so the same document graduates rather than being rewritten",
  "evidence_class": "hypothesis",
  "source": "oss-a-005 ProductSpec artifact_type enum",
  "limitations": "Standard has 275 stars and no ecosystem; adopt ideas not format",
  "disposition": "top10"
}

{
  "id": "inn-p02-009",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Suspect-link propagation: editing a requirement automatically flags dependent acceptance criteria and bindings as suspect, turning change impact into a work queue",
  "evidence_class": "hypothesis",
  "source": "com-b-011 Jama; DOORS family",
  "limitations": "Can generate noise if link granularity is wrong",
  "disposition": "top10"
}

{
  "id": "inn-p02-010",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Example-driven formulation: elicit one concrete example, then generalise into a criterion, instead of asking clients for abstract requirements they cannot articulate",
  "evidence_class": "hypothesis",
  "source": "com-b-044 Cucumber three practices (discovery/formulation/automation)",
  "limitations": "Generalisation step can overfit a single example",
  "disposition": "top10"
}

{
  "id": "inn-p02-011",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "ProductSpec as a typed graph with a document as one rendering, rather than a document with links bolted on",
  "evidence_class": "hypothesis",
  "source": "com-b-011 Jama semantic product graph",
  "limitations": "Graph tooling cost; vendor's own schema was never disclosed",
  "disposition": "candidate"
}

{
  "id": "inn-p02-012",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Non-goals as first-class mandatory fields, not prose asides — an unstated non-goal is the most common source of scope dispute",
  "evidence_class": "hypothesis",
  "source": "com-b-006; parts.json P02 owns non-goals",
  "limitations": "Clients find non-goals hard to state before seeing something",
  "disposition": "candidate"
}

{
  "id": "inn-p02-013",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Technology-agnostic measurable success criteria (SC-###) enforced by grammar, so 'make it feel fast' becomes verifiable without naming an implementation",
  "evidence_class": "hypothesis",
  "source": "oss-a-001 spec-kit SC criteria",
  "limitations": "Measurability sometimes requires instrumentation the client lacks",
  "disposition": "top10"
}

{
  "id": "inn-p02-014",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Prototype for look-and-feel, ask for data and behaviour: a formal rule deciding when a mockup replaces a question",
  "evidence_class": "hypothesis",
  "source": "com-b-024/com-b-026 builder-intake consensus",
  "limitations": "Boundary cases (workflow shape) fit neither cleanly",
  "disposition": "top10"
}

{
  "id": "inn-p02-015",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Portable canonical spec format: plain, documented, and readable by something other than Actionist, so a tool's death does not strand the client",
  "evidence_class": "hypothesis",
  "source": "SpecFlow discontinuation; Gherkin survival",
  "limitations": "Portability constrains schema richness",
  "disposition": "candidate"
}

{
  "id": "inn-p02-016",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Independently testable prioritised user stories (P1/P2/P3) where implementing only the top story still yields a viable slice",
  "evidence_class": "hypothesis",
  "source": "oss-a-001 spec-template.md",
  "limitations": "Independence is often aspirational in integrated workflows",
  "disposition": "candidate"
}

{
  "id": "inn-p02-017",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Assumptions section as a mandatory artifact region recording every default chosen where the client was silent",
  "evidence_class": "hypothesis",
  "source": "oss-a-001 spec-kit Assumptions",
  "limitations": "Long assumption lists get skimmed; needs ranking by blast radius",
  "disposition": "candidate"
}

{
  "id": "inn-p02-018",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Role-differentiated interrogation as a coverage axis: analyst/architect/QA lenses ask structurally different questions; a spec is incomplete while an axis is unexamined",
  "evidence_class": "hypothesis",
  "source": "oss-a-003 BMAD personas",
  "limitations": "Ceremony cost; BMAD's own persona prompts were unverified",
  "disposition": "candidate"
}

{
  "id": "inn-p02-019",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Decision trace as a first-class validatable object beside the spec, answering 'why does the build not match what I asked for'",
  "evidence_class": "hypothesis",
  "source": "oss-a-005 decision-trace.schema.json",
  "limitations": "Discipline decays without enforcement",
  "disposition": "candidate"
}

{
  "id": "inn-p02-020",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Client review annotations captured as structured data rather than email, feeding directly into spec revisions",
  "evidence_class": "hypothesis",
  "source": "oss-a-005 review-annotation.schema.json",
  "limitations": "Clients prefer the channel they already use",
  "disposition": "candidate"
}

{
  "id": "inn-p02-021",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Two-tier scope split: durable org conventions vs per-project facts, so client-wide preferences are stated once",
  "evidence_class": "hypothesis",
  "source": "com-b-023 Lovable Knowledge",
  "limitations": "Conflict resolution between tiers must be explicit, not 'generally'",
  "disposition": "candidate"
}

{
  "id": "inn-p02-022",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Structured selection over blob-stuffing: spec clauses selectable into a prompt by relevance rather than pasting the whole document and hoping",
  "evidence_class": "hypothesis",
  "source": "com-b-023 documented degradation in long contexts",
  "limitations": "Selection errors silently drop requirements",
  "disposition": "top10"
}

{
  "id": "inn-p02-023",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Acceptance fixtures generated from the spec at acceptance time, becoming the P14 verification input without a second authoring pass",
  "evidence_class": "hypothesis",
  "source": "parts.json P02 outputs AcceptanceFixtures; cucumber-js two-audience artifact",
  "limitations": "Generated fixtures may be shallow; needs human review gate",
  "disposition": "top10"
}

{
  "id": "inn-p02-024",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Spec completeness score gating handoff to P12 composition: named, computed, and refusable rather than a judgement call",
  "evidence_class": "hypothesis",
  "source": "lane reasoning joining Xray UNCOVERED to the P02→P12 seam",
  "limitations": "Thresholds arbitrary until pilot data exists",
  "disposition": "candidate"
}

{
  "id": "inn-p02-025",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Implementation-independence linter: reject spec clauses naming a repository, database or framework, enforcing framework invariant 3 mechanically",
  "evidence_class": "hypothesis",
  "source": "knowledge/00-MASTER-SYNTHESIS invariant; A-ledger",
  "limitations": "Some clients have legitimate stack constraints that must be recorded elsewhere",
  "disposition": "top10"
}

{
  "id": "inn-p02-026",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Outcome statement that survives into acceptance, rejecting task-list-as-spec (which says what will be done, never what must be true afterwards)",
  "evidence_class": "hypothesis",
  "source": "com-b-024 Replit spec-shape critique",
  "limitations": "Task lists are more legible to clients; outcome framing needs UX work",
  "disposition": "top10"
}

{
  "id": "inn-p02-027",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Authority clauses in the spec: every side-effecting requirement names who may approve it, inheriting the atom contract's authority family",
  "evidence_class": "hypothesis",
  "source": "12-atom contract authority field; industry authority_boundary priors",
  "limitations": "Clients under-report real approval practice",
  "disposition": "candidate"
}

{
  "id": "inn-p02-028",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Failure-state enumeration as a mandatory spec region (what happens when the date passes, the record is missing, the payment is pending)",
  "evidence_class": "hypothesis",
  "source": "parts.json P02 owns failure states; Replit reviewer's reminder-date example",
  "limitations": "Enumeration is unbounded without a stopping heuristic",
  "disposition": "candidate"
}

{
  "id": "inn-p02-029",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Spec-level denominator capture: each requirement carries the volume it must handle, so composition can reject an under-scaled capability early",
  "evidence_class": "hypothesis",
  "source": "lane denominator discipline; inn-p01-016",
  "limitations": "Clients often cannot supply volumes without instrumentation",
  "disposition": "candidate"
}

{
  "id": "inn-p02-030",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Five-workflow proving harness: validate the ProductSpec schema against five concrete target workflows drawn from different archetypes before declaring it canonical",
  "evidence_class": "hypothesis",
  "source": "parts.json P02 agent brief ('prove it against five target workflows')",
  "limitations": "Five may be too few to expose schema gaps",
  "disposition": "top10"
}

{
  "id": "inn-p02-031",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Industry-vocabulary rendering layer: the same canonical spec renders in the client's own terms (matters, jobs, cases, shipments) without changing the underlying structure",
  "evidence_class": "hypothesis",
  "source": "industry-discovery-priors.jsonl vocabulary layer",
  "limitations": "Mapping table maintenance across 17 industries",
  "disposition": "candidate"
}

{
  "id": "inn-p02-032",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Spec diffing at client sign-off: show exactly what changed since the last accepted baseline rather than re-presenting the whole document",
  "evidence_class": "hypothesis",
  "source": "oss-a-002 delta framing; DOORS baselining",
  "limitations": "Diff readability for non-technical clients",
  "disposition": "candidate"
}

{
  "id": "inn-p02-033",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Evidence-grade labels on spec clauses (client-stated, observed, inferred, assumed) so a reader sees which requirements rest on inference",
  "evidence_class": "hypothesis",
  "source": "AGENTS.md evidence discipline applied to the spec artifact",
  "limitations": "Label inflation if everything is marked client-stated",
  "disposition": "candidate"
}

{
  "id": "inn-p02-034",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Refusal path in the spec: an explicit region recording what Actionist declined to build and why, preserving the non-goal decision rationale",
  "evidence_class": "hypothesis",
  "source": "lane reasoning; sweep-spec candidate admission rule",
  "limitations": "Commercially awkward to surface; may belong in an internal view",
  "disposition": "candidate"
}

{
  "id": "inn-p02-035",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Regulated-industry spec profile: healthcare/law/mortgage specs must name their excluded data classes as explicit constraints, inheriting the discovery-mode exclusion",
  "evidence_class": "hypothesis",
  "source": "industry priors; inn-p01-026",
  "limitations": "Wider uncertainty must be priced, not hidden",
  "disposition": "candidate"
}

{
  "id": "inn-p02-036",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Single-mastering decision recorded in the spec: name once whether the spec or the repo masters acceptance scenarios, rejecting dual-mastering drift",
  "evidence_class": "hypothesis",
  "source": "com-b-045 Xray's own documented tension",
  "limitations": "Mastering choice may differ per client engagement model",
  "disposition": "candidate"
}

{
  "id": "inn-p02-037",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Spec-to-prompt compiler with receipts: record exactly which clauses were selected into which build prompt, so a build failure traces to a selection decision",
  "evidence_class": "hypothesis",
  "source": "lane reasoning joining inn-p02-022 to P12/P14",
  "limitations": "Adds a logging surface; receipts must be storable per build",
  "disposition": "candidate"
}

{
  "id": "inn-p02-038",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Client-readable acceptance rendering: generate Gherkin as an output artifact but never require the client to author it",
  "evidence_class": "hypothesis",
  "source": "com-b-044 reject-mandatory-Gherkin finding; cucumber-js stakeholder-readability failure mode",
  "limitations": "Generated scenarios can drift from client intent without review",
  "disposition": "top10"
}

{
  "id": "inn-p02-039",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Estimation ranges rather than point estimates where scope is still soft, made honest by tying the range to unresolved slots",
  "evidence_class": "hypothesis",
  "source": "com-b-043 parametric estimation",
  "limitations": "Only meaningful once scope exists; ranges can be gamed",
  "disposition": "candidate"
}

{
  "id": "inn-p02-040",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Zero-open-markers release gate: mechanically refuse to promote a spec to composition while any NEEDS-CLARIFICATION or UNCOVERED state remains",
  "evidence_class": "hypothesis",
  "source": "oss-a-001 + com-b-045 combined",
  "limitations": "Rigid gate may block low-stakes work; needs a documented waiver path",
  "disposition": "top10"
}

{
  "id": "inn-p02-041",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Spec authored against the 12-atom vocabulary so every requirement declares which atom it instantiates, inheriting that atom's verification and recovery obligations",
  "evidence_class": "hypothesis",
  "source": "niche-atom-block-join 12-atom contract",
  "limitations": "Atoms may not cover novel requirements; needs an escape hatch",
  "disposition": "top10"
}

{
  "id": "inn-p02-042",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Acceptance criteria written before implementation options are discussed, preventing the spec from being shaped by what happens to be easy to assemble",
  "evidence_class": "hypothesis",
  "source": "framework invariant 3; AutoSaaS spec-before-code",
  "limitations": "Occasionally the feasible set genuinely should inform scope",
  "disposition": "candidate"
}

{
  "id": "inn-p02-043",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Shadow-mode spec generation: draft the spec automatically from discovery, but require human formulation review before it becomes the client-facing artifact",
  "evidence_class": "hypothesis",
  "source": "oss-a-028 OASIS shadow mode applied to spec authoring",
  "limitations": "Review capacity becomes the bottleneck",
  "disposition": "candidate"
}

{
  "id": "inn-p02-044",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Contradiction register inside the spec: when discovery produced conflicting requirements, record both with sources rather than silently choosing",
  "evidence_class": "hypothesis",
  "source": "inn-p01-006; phase-2 preserved-contradiction discipline",
  "limitations": "Unresolved contradictions must not reach composition unflagged",
  "disposition": "candidate"
}

{
  "id": "inn-p02-045",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Spec expiry: an accepted spec carries a validity window after which client circumstances must be re-confirmed before build",
  "evidence_class": "hypothesis",
  "source": "com-a-007 content decay; oss-b-044 bi-temporal validity",
  "limitations": "Expiry windows arbitrary without engagement data",
  "disposition": "candidate"
}

{
  "id": "inn-p02-046",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Minimum viable ProductSpec defined by what composition actually needs, derived backwards from P12's inputs rather than forwards from documentation habit",
  "evidence_class": "hypothesis",
  "source": "parts.json P02 open question 'what is the minimum ProductSpec'; P12 deps",
  "limitations": "P12 contract is itself unsettled in Sprint 1",
  "disposition": "top10"
}

{
  "id": "inn-p02-047",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Per-statement quality gating at authoring time: check each requirement sentence for testability as it is written, making quality and testability the same operation",
  "evidence_class": "hypothesis",
  "source": "com-b-011 Advisor granularity (mechanism itself unverified)",
  "limitations": "The reference implementation's rule set was never published; must be built from scratch",
  "disposition": "candidate"
}

{
  "id": "inn-p02-048",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Explicit systems-of-record binding section: the spec names which client system owns each entity, carrying P01's SourceOfTruthConflict findings into composition",
  "evidence_class": "hypothesis",
  "source": "inn-p01-020; SISOCRM one-owner rule",
  "limitations": "Binding may change during build; needs versioning",
  "disposition": "candidate"
}

{
  "id": "inn-p02-049",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "Spec artifacts are data, not instructions: content quoted from client documents is escaped so it cannot steer the downstream build agent",
  "evidence_class": "hypothesis",
  "source": "C04 stop condition; inn-p01-039",
  "limitations": "Detection imperfect; needs adversarial fixtures",
  "disposition": "candidate"
}

{
  "id": "inn-p02-050",
  "part": "P02",
  "observed": "2026-08-27",
  "claim": "One-page client-facing rendering of a structurally rich spec, so rigour lives in the schema while the client reads something humane",
  "evidence_class": "hypothesis",
  "source": "lane reasoning; DOORS usability-tax warning",
  "limitations": "Summarisation can hide load-bearing clauses",
  "disposition": "candidate"
}