Architecture Vision & Principles
Jurisdiction-first architecture with modular domains, consent-aware assistance, constrained interoperability and accountable government decision-making.
Proposed Architecture Principles
| ID | Principle | Consequence |
|---|---|---|
| AP-001 | Jurisdiction by design | Permissions check jurisdiction, purpose, resource, subject and action |
| AP-002 | Privacy and least privilege | Default-deny and restricted-case segregation |
| AP-003 | Human-accountable decisions | AI cannot bind public decisions |
| AP-004 | Modular domain ownership | Modules communicate through controlled contracts |
| AP-005 | Traceable audit | Evidence and controlled corrections |
| AP-006 | Low-connectivity resilience | Carefully scoped offline experiences |
| AP-007 | Contracted interoperability | No unapproved provider or government connections |
| AP-008 | Secure defaults | Defense-in-depth and recovery planning |
| AP-009 | Configurable LGU variation | Tenant policy and workflows without bypassing isolation |
| AP-010 | Evidence before claims | Verify provenance and measurements |
| AP-011 | Accessible inclusive service | Assistive technologies and staffed channels |
| AP-012 | Evolvable delivery | Start operationally simple; scale when justified |
Five Source-Confirmed Logical Layers (v1.0, page 14)
- Access channels (resident web/PWA, counters, staff and executive experiences)
- Common platform (identity, roles, workflows, notifications, documents and reporting)
- Six independently configurable business pillars
- Information services (restricted data, attachments, audit, retention, backups)
- Approved integrations only (official formats, providers and optional AI sources)
Conceptual Domains
Residents / assisted staff / LGU officials
↓
Channel + identity + jurisdiction policy
↓
Registry / Requests / Council / Finance
Safety / Health & Social / Livelihood
↓
Audited reporting + controlled integration adapters
↓
Optional consent-governed AI assistance
Logical responsibility map, not a schema, authorized integration, or permission for a universal joined database.
Candidate Technology Direction
A modular monolith using ASP.NET Core/C#, SQL Server, mobile-first HTML/Bootstrap/TypeScript, assessed Windows/IIS hosting and adapters for official providers is a working Qentrix Labs option, not an adopted or source-mandated implementation architecture. Page 14 of the proposal explicitly leaves vendor and hosting choices open. Boundaries should permit future modular evolution and city/LGU governance.
Government and Provider Interfaces
DILG/BIMS, eGovPH/e-LGU, PhilSys, approved LGU offices, notifications, maps and payment gateways are only feasibility targets. Each integration requires legal basis, verified API/interface specifications, a controller agreement, validation and operational controls. No certified compatibility is claimed.
High-Risk Controls
- Health, VAWC, minors and household/location data are purpose-restricted, with segregation beyond role labels.
- Resident identity matching or migration across LGUs is not automatic.
- Offline device caches and synchronization must have assessed encryption, conflict and revocation rules.
- Optional AI has opt-in memory, human escalation, source-aware responses, limited authorized tools and no autonomous high-impact action.
G2 Exit Checklist
Resolve or bound data ownership, cross-LGU policies, privacy/threat model, offline scope, technology constraints, vendor assumptions, operational metrics and high-risk AI boundaries; secure recorded review decisions. See approval gates.
Authoritative Markdown: IUG-P0-002 source on private GitHub. Human-readable summary; refer to source for normative detail.