feat(classifier): add multilingual ECP inherence classifier POC
This commit is contained in:
@@ -0,0 +1,61 @@
|
||||
# POC Readiness & Requirements Quality Checklist: Multilingual NLP Entity Inherence Classifier
|
||||
|
||||
**Purpose**: Validate requirement quality, clarity, and completeness for the POC implementation before code execution
|
||||
**Created**: 2026-08-20
|
||||
**Feature**: [spec.md](../spec.md) | [plan.md](../plan.md)
|
||||
|
||||
**Note**: This custom checklist is generated by the `/speckit-checklist` command based on feature context and requirements.
|
||||
**Review Ownership**: This checklist is a reviewer-owned requirements-quality review artifact. Mark an item `[x]` only when the reviewer determines the requirements-quality criterion is satisfied.
|
||||
**Marker Semantics**: `[x]` means the criterion has been reviewed and satisfied for requirements quality. It does not mean implementation work is complete.
|
||||
|
||||
---
|
||||
|
||||
## 1. Requirement Completeness & Scope Boundaries
|
||||
|
||||
- [x] CHK001 Are the required and optional fields of the ECP Snapshot explicitly specified with defaults? [Completeness, Spec §FR-003]
|
||||
- [x] CHK002 Is the CLI execution contract completely specified with argument names, flags, and file path requirements? [Completeness, Spec §FR-002]
|
||||
- [x] CHK003 Are explicit out-of-scope boundaries (no REST API, no live Neo4j, no worker queues) clearly stated to prevent scope creep? [Scope, Spec §Assumptions & Scope]
|
||||
- [x] CHK004 Is the behavior for missing `--output` (printing to stdout) explicitly defined? [Completeness, Spec §FR-002]
|
||||
|
||||
---
|
||||
|
||||
## 2. Requirement Clarity & Decision Semantics
|
||||
|
||||
- [x] CHK005 Are the 4 decision categories (`DIRECT_INHERENT`, `CONTEXTUAL_INHERENT`, `TANGENTIAL`, `NOT_RELATED`) defined with unambiguous conditions? [Clarity, Spec §FR-005]
|
||||
- [x] CHK006 Is the deterministic derivation rule for `is_inherent` (`true` for DIRECT/CONTEXTUAL, `false` for TANGENTIAL/NOT_RELATED) mathematically unambiguous? [Clarity, Spec §FR-006]
|
||||
- [x] CHK007 Is the 3-tier hybrid execution order explicitly defined such that clear cases never invoke Tier 2/Tier 3? [Clarity, Spec §FR-004]
|
||||
- [x] CHK008 Are all standardized error codes (`invalid_ecp_json`, `invalid_markdown`, `unsupported_language`, `empty_content`, `missing_required_field`) enumerated? [Clarity, Spec §FR-008]
|
||||
|
||||
---
|
||||
|
||||
## 3. Requirement Consistency & Alignment
|
||||
|
||||
- [x] CHK009 Do the example filenames in `spec.md`, `plan.md`, `quickstart.md`, and `tasks.md` align consistently without discrepancies? [Consistency, Plan §Project Structure]
|
||||
- [x] CHK010 Is the benchmark test file name (`tests/test_benchmark_24.py`) consistent across all documentation artifacts? [Consistency, Quickstart §3]
|
||||
- [x] CHK011 Are dependencies strictly limited to `pytest` without mandatory external AI/cloud packages? [Consistency, Plan §Technical Context]
|
||||
|
||||
---
|
||||
|
||||
## 4. Acceptance Criteria & Measurability
|
||||
|
||||
- [x] CHK012 Is the POC benchmark suite quantified with an explicit test count (24 cases = 6 languages × 4 decision types)? [Measurability, Spec §SC-002]
|
||||
- [x] CHK013 Is the accuracy target (≥ 90% precision) bounded specifically to the controlled 24-case benchmark suite? [Measurability, Spec §SC-002]
|
||||
- [x] CHK014 Is the execution latency target (< 200ms for Tier 1) testable and quantified? [Measurability, Spec §SC-004]
|
||||
|
||||
---
|
||||
|
||||
## 5. Scenario & Edge Case Coverage
|
||||
|
||||
- [x] CHK015 Are requirements specified for malformed Markdown or empty content files? [Edge Cases, Spec §FR-008]
|
||||
- [x] CHK016 Are requirements specified for corrupted JSON or missing required ECP fields? [Edge Cases, Spec §FR-008]
|
||||
- [x] CHK017 Are negative anchor suppression rules specified for homonym disambiguation? [Coverage, Spec §FR-005]
|
||||
- [x] CHK018 Are graph snapshot relationship matches (weight, scope, relation_type) accounted for in contextual inherence decisions? [Coverage, Spec §FR-003, §FR-005]
|
||||
|
||||
---
|
||||
|
||||
## Notes
|
||||
|
||||
- Mark items `[x]` only after review confirms the requirement-quality criterion is satisfied.
|
||||
- Leave items unchecked when they still require clarification, correction, or reviewer evaluation.
|
||||
- `/speckit-implement` reads checklist checkbox state as a gate and must not modify markers.
|
||||
- `checklists/requirements.md` has a separate built-in lifecycle maintained by `/speckit-specify` and `/speckit-clarify`.
|
||||
@@ -0,0 +1,40 @@
|
||||
# Specification Quality Checklist: Multilingual NLP Entity Inherence Classifier
|
||||
|
||||
**Purpose**: Validate specification completeness and quality before proceeding to planning
|
||||
**Created**: 2026-08-19
|
||||
**Feature**: [spec.md](../spec.md)
|
||||
|
||||
## Content Quality
|
||||
|
||||
- [x] No implementation details (languages, frameworks, APIs)
|
||||
- [x] Focused on user value and business needs
|
||||
- [x] Written for non-technical stakeholders
|
||||
- [x] All mandatory sections completed
|
||||
|
||||
## Requirement Completeness
|
||||
|
||||
- [x] No [NEEDS CLARIFICATION] markers remain
|
||||
- [x] Requirements are testable and unambiguous
|
||||
- [x] Success criteria are measurable
|
||||
- [x] Success criteria are technology-agnostic (no implementation details)
|
||||
- [x] All acceptance scenarios are defined
|
||||
- [x] Edge cases are identified
|
||||
- [x] Scope is clearly bounded
|
||||
- [x] Dependencies and assumptions identified
|
||||
|
||||
## Feature Readiness
|
||||
|
||||
- [x] All functional requirements have clear acceptance criteria
|
||||
- [x] User scenarios cover primary flows
|
||||
- [x] Feature meets measurable outcomes defined in Success Criteria
|
||||
- [x] No implementation details leak into specification
|
||||
|
||||
## Notes
|
||||
|
||||
- Initial requirements documented from user audio brief and refined with POC constraints.
|
||||
- ECP defined as Entity Context Profile with materialized JSON snapshots.
|
||||
- Tier 1 (deterministic rules) defined as mandatory core; Tier 2 (embeddings) and Tier 3 (LLM) defined as optional/configurable (LLM off by default, no API key required).
|
||||
- Decision rules explicitly codified for all 4 categories and derived `is_inherent` boolean.
|
||||
- Success criteria scoped to a controlled 24-case POC benchmark suite (6 languages × 4 decision types).
|
||||
- Structured error codes defined (`invalid_ecp_json`, `invalid_markdown`, `unsupported_language`, `empty_content`, `missing_required_field`).
|
||||
- Explicit out-of-scope declarations enforced (No REST API, No package publishing, No queues/workers, No runtime DB/Neo4j).
|
||||
Reference in New Issue
Block a user