Final Requirements and Rubric Traceability¶
| Document information | Details |
|---|---|
| Related issues | #809 (original matrix); #884 (final feature/requirement/implementation verification) |
| Evidence cut-off | 10 October 2026 — #810 release-readiness update; historical #809 baseline retained |
| Scope | Course-wide requirements; Sport Analytics Basic, Intermediate and applicable Advanced requirements; Milestone 4 rubric |
| Evidence policy | The matrix links retained implementation, test/validation and documentation evidence. It does not treat an issue, branch or closed Pull Request as proof on its own. |
| Final-submission refresh | Required before #810 release/tagging. Re-check the deployed revision, current CI, final user-testing disposition and every Partial/Not implemented row; update this page with the release SHA and date. |
Status key and marker route¶
| Status | Meaning |
|---|---|
| Implemented | Retained implementation exists with representative automated, integration, deployment or user-facing evidence linked below. |
| Partial | A meaningful portion exists, but a stated limit, unverified final-release step or remaining capability prevents a complete claim. |
| Not implemented | The final product does not claim this capability. |
| Not applicable | The capability is outside the chosen final product scope; the reason is recorded rather than silently treating it as complete. |
Start with the final automated audit, the final database audit, Testing & Validation Evidence, and Project Records & Evidence. They identify the commands, evidence records, methodology and limitations behind the compact references below.
Requirement-tier interpretation¶
The final map keeps the original course tiers visible instead of treating later work as a new requirement: the Sprint 1 traceability baseline defines the Basic requirement interpretation, the Sprint 2 traceability record defines the Intermediate one, and the Sprint 3 record names the deliberately selected Advanced work. A tier label describes the requirement that the implementation serves; it is not a claim that every capability in a higher tier shipped.
Course-wide requirements¶
| Requirement | Status | Implementation and meaningful evidence |
|---|---|---|
| Version control | Implemented | Git methodology, protected-PR quality-gate process in CI/CD, and retained sprint/process evidence. |
| Responsiveness | Implemented | Responsive React application conventions in frontend baseline; audited in #273 accessibility/responsiveness evidence. Final browser/accessibility lane is recorded in #805. |
| Accessibility | Implemented | Semantic/accessibility requirements in brand and frontend guidance and automated/browser evidence in #273 and #805. |
| CI/CD | Implemented | Change-aware PR quality gate, database and browser lanes, and deployment routing documented in CI/CD; CI-routing and deployment suites are recorded in #805. |
| Non-monolithic frontend/backend architecture | Implemented | Separate React frontend, Express API and worker boundaries in repository structure and system architecture. |
| Hand-written API | Implemented | Public read API states that all application data uses the handwritten Express API; public/API-contract suites are listed in #805. |
| Authentication | Implemented | Authentication and authorisation documents Google OAuth/Supabase identity and backend token validation; role tests are retained in #44 evidence. |
| Sign up | Implemented | The managed Google OAuth action on the documented /sign-in page creates or signs in an identity; see authentication. |
| Sign in | Implemented | Managed Google OAuth/session flow is documented in authentication and covered in public/auth browser evidence indexed from validation. |
| Password reset | Implemented (provider-owned) | The product deliberately has no password credential: password recovery ownership maps recovery to Google Account recovery and explains the security boundary. |
| Account deletion | Implemented | Server-side deletion/tombstoning and retention boundary in privacy and retention, with regression evidence in #66. |
| External integration | Implemented | The runtime weather integration is documented in Weather API, while authentication is separately provider-managed. |
| Public documentation website | Implemented | This MkDocs source is deployed through the documented documentation deployment workflow; strict documentation checks are part of CI/CD. |
Sport Analytics Basic and Intermediate requirements¶
| Tier | Requirement | Status | Implementation and meaningful evidence |
|---|---|---|---|
| Basic | Event-derived data and statistics | Implemented | Fixture statistics derive results from accepted delivery revisions; database and API coverage appears in #805. |
| Basic | Approved and scoped submitters | Implemented | Application roles and competition-scoped submitter/reviewer access are enforced server-side; see roles and permissions, provenance and #120 workflow evidence. |
| Basic | Validation and correction history | Implemented | Shared event validation and source-row errors are described in submission API; current revision selection and immutable correction lineage are documented in provenance. |
| Basic | Traceability/provenance | Implemented | Private source-to-statistic chain and aggregate provenance are documented in provenance and audited in the final database audit. |
| Basic | Fixtures/events/statistics API; stable identifiers; filtering/pagination | Implemented | Canonical public resources, stable identifiers, filters, deterministic ordering and cursor behaviour are documented in public read API; API and contract results are in #805. |
| Basic | Filtered data export | Implemented | Filtered event JSON/CSV export is documented in dataset exports and public read API. |
| Intermediate | Batch/season submission; staging; review/publication | Implemented | Durable single-fixture, season and back-catalogue packages, their stored states and reviewer decisions are documented in submission API, batch packages and the batch ingestion pipeline. |
| Intermediate | Idempotency/resume behaviour | Implemented | Batch receipt/idempotency and publication checkpoints are documented in batch persistence and mapped in the database audit. |
| Intermediate | Aggregate statistics; reference-result validation | Implemented | Deterministic season, competition and career aggregates, plus licensed Cricsheet reference figures, are documented in participant aggregates and the final database audit. |
| Intermediate | Representative-scale operation | Implemented | Representative workload/query-plan evidence is retained under #289, with current suite health in #805. |
| Intermediate | API versioning; API keys; rate limits/quotas | Implemented | URI-major versioning and consumer controls are documented in API versioning and consumer keys. |
| Intermediate | Caching and reproducible dataset releases | Implemented | Versioned cache behaviour is documented in fixture statistics; immutable release/snapshot and export design is documented in dataset exports and the database audit. |
Selected Advanced requirements and boundaries¶
| Requirement/capability | Status | Implementation and boundary |
|---|---|---|
| Incremental recomputation | Implemented | Versioned fixture-cache invalidation, correction dependency targeting and selective participant refresh are defined in fixture statistics and participant aggregates. |
| Deprecation/contract behaviour | Implemented | The selected Advanced API work retains a major-version policy and consumer deprecation/link headers; see API versioning, consumer keys, and the Sprint 3 selected-work record. |
| Analyst-defined statistics/definitions | Not implemented | The product implements documented cricket fixture and participant aggregates, not a separate analyst-defined advanced-statistics product. The README explicitly keeps this as future work. |
| Live/disordered events | Partial | The model correctly represents delivery occurrence order, repeated displayed ball labels and miscounted-over reference data (database audit); it does not claim live-feed or arbitrary out-of-order event ingestion. |
| Historical/as-of/change behaviour | Partial | Current-versus-superseded event revisions and correction history are retained (provenance), but there is no general bitemporal/as-of public query interface. |
Shipped natural-language query feature¶
The public, anonymous POST /api/v1/natural-language-queries endpoint and home-page prompt are
implemented as an Intermediate query enhancement. A server-side language-model adapter translates
a bounded question into one of the existing published-statistics query definitions, returns the
interpretation with the result, and applies per-client and global limits; it does not calculate a new
statistic or accept analyst-defined expressions. The contract, outcome and privacy boundaries are in
Analytics Query, and the final implementation/evidence path is in
Natural-Language Query Evidence.
This is a shipped capability with documented limitations, not a blanket claim that every natural-language request is answered. The final #868 evaluation runs recorded 62/64 accepted translations; the remaining delimiter-escape refusal-label issue and variable refusal suggestions, plus the requested floating assistant, are retained as linked follow-up work in #924.
Milestone 4 rubric map¶
| Rubric criterion | Status | Marker evidence |
|---|---|---|
| Database | Implemented | Final database audit: migration rebuild, schema/constraint/index/provenance audit and deployed read-only compatibility checks. |
| API | Implemented | Public read API, OpenAPI, versioning, and API/API-contract/deployment results in #805. |
| Application | Implemented | System architecture, frontend baseline, #273, and final browser suite result in #805. |
| Git methodology | Implemented | Git methodology, project methodology, and PR quality-gate implementation in CI/CD. |
| Integration | Implemented | Frontend/API/database/worker boundaries in repository structure, external weather integration in Weather API, and deployment checks in #805. |
| Testing | Implemented | #805 final automated audit records unit, frontend, API, contract, database, browser, deployment and CI-routing results; testing strategy documents the method. |
| Tools | Implemented | Technology stack, CI/CD, and the exact final-test commands/results in #805. |
Criterion-level Milestone 4 rubric evidence crosswalk (20 weighted criteria)¶
The COMS3011A Project Brief §3.4 lists 20 separately weighted criteria (100% in total). The seven broad rows above remain a quick orientation; the following crosswalk is the reviewer route to each specific criterion. A documentation link is not proof of final deployed performance, availability, feature acceptance or a passing mark. The results below are limited to the retained evidence and scope of the named checks.
| Category | Criterion | Weight | Marker-facing evidence and qualification |
|---|---|---|---|
| Database | Data | 3% | Final database audit and schema: migrated PostgreSQL data model, source/event provenance and representative integration tests; final release state remains #810's check. |
| Database | Deployment | 2% | Azure backend deployment and database audit: migration/compatibility procedure and retained checks; exact deployed release revision pending #810. |
| Database | Structure | 5% | ERD, schema and database audit: relationships, constraints, indexes and source-of-truth migrations. |
| API | Availability | 3% | Final API audit reports dated, anonymous read-only hosted checks. #874 deployed anonymous-read evidence is now retained; API-TECH-03 still fails strict response-schema validation. #810 released-candidate smoke remains pending. |
| API | Architecture | 5% | System architecture, API contracts and OpenAPI explain handwritten backend, shared contracts and public/privileged boundaries. |
| API | Deployment | 2% | Azure backend deployment and final API audit document the development target; released SHA, hosted verification and deployment proof remain #810. |
| API | Performance | 5% | Representative baseline and #876 execution: PERF-TECH-01 is BLOCKED; both local timing reports missed configured targets and an approved representative environment was not established. Do not claim a pass. |
| API | Design | 10% | OpenAPI, consumer controls and #886 API documentation review document endpoints, security, errors and contracts. #874 final execution is recorded as PASS WITH ONE FAIL; deployed GET /api/v1/participants includes undocumented totalRecords per record (API-TECH-03). |
| App | Accessibility | 5% | #876 execution: local Axe suite 69/69 PASS, plus focused keyboard/semantics/contrast checks. Does not establish all-device or deployed accessibility. |
| App | Aesthetics | 3% | Brand guidelines, final frontend UX audit and #800 review provide design decisions, implementation review and visual evidence; no numerical aesthetics score is asserted. |
| App | User Experience | 5% | Final human-testing summary and #800 review: team-approved two real sessions, four self-reported Success and nine coached Partial outcomes; no AI simulation counted as human, and limitations are retained. |
| App | Deployment | 2% | Cloudflare frontend deployment and final submission reviewer entry points: documented target, not a substitute for #810's released artifact SHA and final live smoke. |
| App | Performance | 5% | #797 Lighthouse evidence and #876 execution: hosted CI uses a relative regression baseline, not universal Performance ≥90; four parameterised mobile routes missed the target and protected routes remain unverified. PERF-TECH-03 is BLOCKED. |
| App | Features | 10% | Product & API and the Basic/Intermediate and Advanced requirement rows map implemented capabilities and explicit partial/not-implemented boundaries. #874 is recorded with one unresolved contract failure; #810 final release acceptance is separate. |
| App | Responsiveness | 5% | #876 execution: two RESP-TECH cases PASS on local responsive checks (including mocked admin routes at 320px); not real hosted authenticated-role testing. |
| App | Structure | 5% | Frontend component baseline, information architecture and system architecture document shared shell/components, route organisation and role boundaries. |
| Misc | Git Methodology | 5% | Git methodology, project methodology and CI/CD document protected branches, PRs, review and traceability. Live final PR/CI sign-off must be checked, not presumed. |
| Misc | Integration | 7% | System architecture, weather integration and deployment overview describe React/Express/PostgreSQL/worker boundaries and the runtime external API. #874 records deployed anonymous weather/API reads and existing suite evidence; authenticated and shared-limiter live checks were not executed. |
| Misc | Testing | 8% | Testing strategy, final technical verification bank, coverage and human-testing summary expose executed versus BLOCKED/NOT RUN checks. #877 local PASS does not prove final hosted CI. |
| Misc | Tools | 5% | Technology stack, CI/CD and project methodology explain the selected runtime, development, documentation, test and deployment tooling. |
Release boundary: The original #809 evidence-cut-off map is preserved. The
criterion-level links above make final technical limitations visible instead of
promoting specialist BLOCKED/NOT RUN results to PASS. In particular, #874 reports PASS WITH ONE FAIL (API-TECH-03; see the
#874 execution record),
while #810 must establish exact-revision hosted CI, production deployment/smoke
and final acceptance before submission.
AI declaration: This criterion-level source-evidence crosswalk was researched and drafted with assistance from ChatGPT-Web[GPT-6]; it records only the reviewed evidence and requires student verification against authoritative Gitea.
Final verification timing¶
The final-system-verification bank remains incomplete as a release-wide claim.
Retained PASS outcomes for #871–#873 and #875 apply to their tested candidates;
877 records local automated-quality passes while CI-TECH-02 and DEP-TECH-03¶
remain BLOCKED pending final hosted CI and deployment evidence under #810.
876 was closed by the original owner's explicit scope disposition on¶
9 October 2026, not because every case passed. Its six local accessibility and
responsive checks are PASS; its four performance/hosted checks remain
BLOCKED. The retained API timing comparisons missed their configured targets,
and neither all-route Lighthouse Performance ≥90 nor production-scale/background
load verification is established. Those limitations are explicitly carried to
810 rather than falsely upgrading #876's case statuses or reopening it.¶
874 has now delivered retained execution evidence and merged through PR #949¶
(10 October 2026). The bank records PASS WITH ONE FAIL, not a full pass:
API-TECH-03 is FAIL because the deployed participants collection returns an
undocumented per-record totalRecords field that violates its strict OpenAPI
Participant schema. The original tester classified the finding as
non-submission-blocking, but the contract discrepancy needs explicit follow-up
and a future deployed-schema retest; no fix is inferred from the merge.
The #874 checks combine deployed anonymous reads and existing local suite coverage. Consumer-key lifecycle, live quota exhaustion and privileged success paths were not exercised against the deployed service. Release-candidate SHA, current hosted CI, final deployment and smoke-test confirmation belong to #810. This audit does not infer a result from an issue's closed state alone.
Known limitations and release actions¶
This audit found no new untracked material gap. The following are deliberately not marked complete and must remain visible to #810/reviewers:
| Item | Status/action |
|---|---|
| Final release confirmation | This document is an evidence-cut-off audit, not deployment proof. #810 must refresh it immediately before submission with the deployed release SHA, current CI and final user-testing disposition. |
| Advanced analyst-defined statistics | Not implemented by the selected product scope; the README records it as future work. |
| Live feed and general bitemporal/as-of querying | Not implemented; the partial historical/disordered-event support above must not be represented as a live-feed or bitemporal capability. |
| Batch-processing direct coverage | #805 records the remaining direct package-coverage weakness and explicitly treats broader coverage as follow-up work. |
Final refresh checklist for #810¶
- [ ] Confirm the released commit SHA and deployed frontend/backend artifacts.
- [ ] Replace the evidence cut-off/date with the final release date.
- [ ] Re-run or link the current required CI and release smoke evidence.
- [ ] Reconcile final structured user-testing findings and dispositions without converting an unresolved finding into a pass.
- [ ] Re-check every Partial, Not implemented and Not applicable row.
- [ ] Obtain peer review, then record the final release/tag state.
#810 final release-readiness reconciliation — 10 October 2026¶
The original #809 requirements map and its seven aggregate categories are retained; #808 added the separately linked 20 weighted Milestone 4 rubric criteria above. The 10 October release-owner update is documented in the #810 release-readiness ledger. It records observed Gitea main/GitHub parity at 6338bd46, successful change-aware Gitea quality/coverage/docs deployment and real public/API/DB reads, plus live Healthy Azure backend/worker images built at 98bb853f.
Acceptance boundary: #874 API-TECH-03 remains FAIL (participant-item totalRecords not described by the strict public schema); #876's four performance/hosted checks remain BLOCKED, including response-time targets and unapproved representative workload; #797's strict all-page Lighthouse >=90 has not been universally demonstrated; #877's specialist candidate lacks its own exact-SHA hosted/deployed acceptance despite later #810 baseline CI. These are documented, reviewable limitations and not evidence that the rubric row has passed every strict acceptance check. The shipped product still does not implement analyst-defined Advanced statistics, general live feeds or bitemporal/as-of querying. The two approved real human sessions, their outstanding retests and local participant-data limits remain stated in the human-testing record.
The final submitted source is identified by the future annotated final-submission tag created from approved main after the closing #810 documentation PR merges. At this 10 October evidence cut the tag does not yet exist; it is therefore not represented as a completed release result. The backend and worker currently use healthy tested images from 98bb853f; a documentation-only merge does not require those images to have the documentation commit SHA. The current exact Cloudflare production source revision was not independently available to the release owner, although Wrangler deployments, their smoke checks and public site availability were observed. The reviewer should use the linked #810 evidence for this qualification rather than infer full release acceptance from Implemented in the high-level matrix.
AI declaration: This #810 current-evidence reconciliation was researched, drafted and reviewed with assistance from ChatGPT-Web[GPT-6]. It preserves existing requirement classifications and labels no unobserved technical test as a pass.
AI Declaration¶
This evidence map was prepared with the assistance of Codex[GPT-5] and later reviewed and edited for final-state traceability with the assistance of ChatGPT-Web[GPT-5.6 Sol] and Codex[GPT-5]. Its claims are limited to linked retained implementation, documentation and validation records; it does not assert unobserved deployment, review or release results.