Success Criteria

Neemias is considered successful when it meets the 6 criteria below. Each criterion has a measurable target that guides product and engineering decisions.

1. Offline Resilience

Users continue working without internet, with no data loss.

• The application must start and operate fully offline, including student creation and attendance marking.
• No user action may be lost due to lack of connectivity — every write is stored locally in IndexedDB and queued for synchronization.
• The online/offline transition must be transparent, requiring no manual user action.

2. Sync Reliability

Changes made offline are synchronized safely and without data corruption.

• Conflicts are resolved deterministically by the ADMIN_PRECEDENCE rule (or LAST_TIMESTAMP_WINS on ties).
• Losing events are preserved and marked with isConflictLoser: true — never silently discarded.
• Idempotency ensures accidental resends do not duplicate data.
• The sync queue uses exponential backoff to avoid overloading the server.

3. WCAG Level AA Accessibility

The experience meets WCAG 2.1 Level AA accessibility criteria.

• Color contrast, keyboard navigation, alt text on images, and screen reader compatibility.
• Visual and auditory feedback on success and failure actions.
• Student photos with textual descriptions for accessible identification.

4. LGPD Compliance

The product respects the principles of the Brazilian General Data Protection Law.

• Personal data is protected with encryption at rest (AES-GCM) and in transit (HTTPS).
• Immutable audit trail (audit_logs) records every operation with actor_user_id, correlation_id, and details.
• Soft-delete preserves history without destroying personal data.
• Mandatory justification for student deletion ensures decision traceability.
• Principle of least privilege applied across all roles.

5. Performance

Attendance capture with the fewest possible steps and immediate feedback.

• Marking a student's attendance must take at most 2 interactions (search + confirm).
• Perceived response time for local operations must be under 200 ms.
• Student photos must be displayed during search with no perceptible delay.
• The PWA must load in under 3 seconds on first access (3G) and instantly on subsequent accesses (Service Worker).

6. User Satisfaction

A new user understands the purpose and operation of the system from documentation alone.

• Documentation covers installation, roles, attendance flow, and frequently asked questions.
• The interface follows familiar patterns for users with little software experience.
• The product remains small, modular, and friendly to open-source contributors — an essential factor for long-term sustainability.

---

Source: PRD §10

Current Baseline (measured on 2026-06-23)

Performance

• Lighthouse CI: pending configuration in the deployment pipeline
• API response time: < 100ms (tested via curl, p95)
• PWA loading: pending formal measurement

Accessibility

• axe-core integrated into E2E tests (spec 11-accessibility)
• Pages tested: Login, Dashboard, Students, Attendance, Classes
• Coverage: 5 main pages

Post-MVP (not measured)

• Perceived response time < 200ms — pending Lighthouse CI
• 3G load time < 3s — pending Lighthouse CI
• 2 interactions to mark attendance — pending usability testing
• New user understands the system from documentation — pending usability testing