City Gateway: Innovative, Social, and Learning

 We need high-velocity verification (<30 seconds), offline-first functionality, and strict adherence to EU data regulations.

The following requirements and suggestions are based on the architectural blueprints and technical evaluation reports for the Rietavas Digital Gateway:

1. Compliance Requirements

• GDPR/BDAR Article 25 (Privacy by Design): The PoP module must ensure that sensitive user attributes (e.g., disability markers or NEET status) never leave the device during the verification process.

• Universal Design & Accessibility (WCAG 2.1 AA): To meet the 100% accessibility pass rate for seniors and individuals with mobility impairments, the PoP interface must support multi-modal validation. This includes alternatives to QR scanning, such as Bluetooth Low Energy (BLE) proximity beacons or audio-watermark checks, to assist users who struggle with precise camera alignment.

• Legal & Security Certification: Given the collection of personal data for civic rewards, the project budget must include a formal legal audit and security certification.

2. Security Requirements

• Asymmetric Cryptographic Verification: The system should utilise the Ed25519 signature scheme. This allows the mobile app to verify time-sensitive, salted cryptographic strings generated by a physical site's QR code in under 5 milliseconds without requiring a network connection.

• Hardware-Backed Key Storage: All localised user tokens and cryptographic keys must be stored in the device's hardware-backed keystore (Android Keystore System or iOS Keychain Services) to prevent unauthorised extraction.

• Time-Sensitive Salting: To prevent replay attacks (where a user attempts to reuse a check-in code), the verification string must contain dynamic, time-sensitive salted data that expires shortly after generation.

• Zero Network Egress for Raw Data: The network configuration must block the transmission of raw profiling metrics. Verification is limited to sending cryptographically signed, aggregate completion tokens to the ledger.

3. Audit & Traceability Requirements

• Sync History and Audit Log: Following "Offline-First" best practices, the module must maintain a persistent Layer 5 Audit Log. This log must track:

  • The timestamp and device ID of every local check-in.

  • The synchronisation status and latency between the mobile edge and the central ledger.

  • Detailed conflict resolution records if a check-in is contested by the server.

• Machine-Readable "Agentic Proof of Work": The backend must expose structured, machine-readable validation schemas to the Model Context Protocol (MCP). This ensures that the user's earned credentials are not locked in a frontend silo but are globally auditable by authorised AI agents.

• Centralised Server-Side Integration Testing: To ensure the PoP logic is consistent across iOS and Android, the project must implement a Backend for Frontend (BFF) architecture with a centralised testing suite. This is projected to reduce critical incidents by over 60% compared to fragmented client-side testing.

4. Technical Suggestions for Implementation

• Pre-Cached Public Key Infrastructure (PKI): The app should maintain a locally cached directory of verified regional partner public keys (updated daily) to eliminate the need for synchronous network calls during check-in.

• Idempotent Ingestion Design: Every PoP event must carry a unique idempotency key (e.g., SessionID + EventType + Timestamp) to ensure that replayed or retried sync operations do not result in duplicate credit issuance in the WTA ledger.

• Reactive UI Listeners: Points should be reflected on the user interface in milliseconds via reactive listeners as soon as the local cryptographic check passes, even if the backend webhook sync is still queued for a later internet connection