niseCore requirements
The following are repository responsibility candidates inferred from source and configured workflows. They link to project requirements but are not approved customer requirements.
| ID | Candidate responsibility | Evidence class | Approval/status |
|---|---|---|---|
| NC-REQ-001 | Expose a stable core API for capture, enrollment, matching, storage and device lifecycle through VFM and nise interfaces. | Implementation-derived candidate | Open until approved requirement/acceptance evidence is connected |
| NC-REQ-002 | Select sensor, matcher, storage, PAL and optional trusted/authenticator modules from customer build features. | Implementation-derived candidate | Open until approved requirement/acceptance evidence is connected |
| NC-REQ-003 | Support Windows customer builds for x64 and ARM64 inputs used by the configured delivery matrix. | Implementation-derived candidate | Open until approved requirement/acceptance evidence is connected |
| NC-REQ-004 | Keep platform-specific transport/crypto/runtime behavior behind PAL boundaries. | Implementation-derived candidate | Open until approved requirement/acceptance evidence is connected |
| NC-REQ-005 | Propagate failures across sensor, matcher, storage and transport boundaries without treating missing evidence as success. | Implementation-derived candidate | Open until approved requirement/acceptance evidence is connected |
See project requirements and traceability.