Globis Edge — Gemma 4 Good Hackathon Submission
Globis Edge is a proof-of-concept prototype that demonstrates responsible agentic reasoning for humanitarian intake scenarios. It is built entirely on synthetic data, uses explicit protection mechanisms (Constitutional Auditor dual-pass review, field-level blocking, value masking), and requires human oversight for all consequential decisions. This document outlines our data ethics, responsible AI practices, and explicit constraints.
All refugee cases, testimonies, ID documents, and personal information in this prototype are synthetic examples created for demonstration purposes.
- No real UNHCR registrations, refugee identities, or PII are used.
- Synthetic families (Hawa, Tobias, Aisha, Yusuf, etc.) are fictional personas with plausible intake scenarios.
- Test cases are designed to illustrate system behavior (cross-modal conflict detection, protected attribute blocking) rather than represent real individuals.
- No real data from PRIMES, proGres v4, BIMS, PING, or other UNHCR systems is accessed or ingested.
Why this matters: This ensures that no real refugee data is exposed, processed, or at risk due to model errors, privacy leaks, or system failures during development and demonstration.
Globis Edge uses a two-stage audit before intake records are committed:
Pass 1 — Rule Pass (Deterministic):
- Scans intake form fields for explicitly protected attributes: ethnicity, religion, political affiliation, caste, sexual orientation.
- Uses hardcoded field name matching (no model inference; no false negatives on these fields).
- If a protected field is detected, the entire intake is blocked before proceeding to Pass 2.
- Blocks are logged with field names only; no values are recorded.
Pass 2 — Prompt Pass (LLM-based):
- Only runs if Pass 1 clears the record.
- Uses Gemma 4 E2B to detect cross-modal conflicts: discrepancies in name spelling, birth year, stated origin across ID image, audio testimony, and typed notes.
- Conflicts are explained to the caseworker (e.g., "birth year differs: 2016 in ID, 2017 in testimony").
- No automated denial or status determination is made by the model. Conflicts surface to the caseworker for human review.
Why this design:
- Prevents collection of unnecessary sensitive attributes that could enable discrimination or harm.
- Catches data inconsistencies early, prompting caseworker review before records are finalized.
- Maintains human agency: the caseworker, not the model, decides how to resolve conflicts or proceed.
Protected fields are identified before model inference:
| Attribute | Action | Reasoning |
|---|---|---|
| Ethnicity | Block | Risk of algorithmic discrimination; not needed for core intake |
| Religion | Block | Risk of targeting; outside scope of humanitarian assistance determination |
| Political affiliation | Block | Risk of persecution if leaked; outside scope |
| Caste | Block | Caste-based discrimination risk; outside scope |
| Sexual orientation | Block | Risk of harm in conservative contexts; outside scope |
Implementation: Simple string matching in Rule Pass; no machine learning applied to these fields.
- Blocked field values are never stored in logs or databases.
- Only field names and the reason for blocking are recorded (e.g., "ethnicity_field_detected").
- This prevents accidental data leakage if logs are accessed or breached.
- The system never automatically denies assistance or determines refugee status.
- Verdicts are binary: "intake record clean" or "conflict detected; caseworker review required."
- All consequential decisions (eligibility, assistance level, casework plan) remain with human caseworkers.
- Conflicts do not result in rejection—they surface for human judgment.
- This prototype does not perform facial biometric matching, document authenticity verification, or fraud detection.
- It does not predict likelihood of being a refugee, assign risk scores, or forecast behavior.
- These capabilities are explicitly excluded to avoid compounding harm from algorithmic errors.
Globis Edge is designed to align with UNHCR principles and data protection guidance:
Our approach respects:
- Data minimization: We collect only fields necessary for intake (name, DOB, origin, family composition, immediate needs). Protected attributes are actively rejected.
- Purpose limitation: Data collected is used solely for intake, outbox creation, and caseworker briefing. No secondary uses (analytics, research, targeting).
- Access & rectification: Caseworkers can view and correct their own intake records. No automated data sharing.
- No automated denial: As stated, all consequential decisions involve human review.
We map Globis Edge outputs to PRIMES-like JSON schemas (proGres v4-style structure) but:
- Do not integrate with production proGres v4 or BIMS.
- Do not access real UNHCR registration databases or state registries.
- We provide structured JSON that could be imported by a caseworker into PRIMES after human review, but this is manual, not automated.
This prototype is intake support only. It does not replace:
- Full Refugee Status Determination (RSD) interviews.
- Needs assessments by caseworkers.
- UNHCR eligibility reviews.
Globis Edge is a "triage and consistency check" tool, not a decision system.
Before any field deployment:
- UNHCR or implementing partner approval (no unilateral deployment).
- Data Protection Impact Assessment (DPIA).
- Formal agreements with national authorities.
- Caseworker training and consent.
- Local context review (legal, cultural, security).
This prototype is research-grade, not operational.
- The system does not require internet connectivity for core intake.
- Model inference runs on-device (Raspberry Pi 5, CPU-only).
- No cloud dependency, no telemetry, no data egress to external services.
- Intake records are stored locally (SQLCipher database).
- Export to PRIMES or cloud systems requires explicit caseworker consent and triggers a clear "commit" action.
- No automatic syncing or background uploads.
- We do not collect: GPS location (during intake), financial information, health records (beyond immediate needs), family separation status, previous asylum claims.
- These are either excluded from the form or marked as optional with clear warnings.
- This tool does not conduct needs assessments, security interviews, or eligibility determination.
- It captures basic intake (identity, origin, immediate needs) and flags inconsistencies for caseworker follow-up.
Risk: The model misses a genuine conflict (e.g., name spelled differently but caseworker assumes it's the same person).
Mitigation: Caseworker is prompted to manually review any record flagged by the system AND to spot-check clean records regularly. Conflicts are not hidden; they are shown with reasoning.
Risk: A legitimate intake field is incorrectly flagged as "ethnicity" (e.g., "ethnicity_based_conflict_history").
Mitigation: Rule Pass uses explicit field name matching; caseworkers can override blocking after reviewing the flag. Override is logged.
Risk: The model generates malicious or false verdicts (e.g., invents conflicts that don't exist).
Mitigation:
- Verdicts are constrained to JSON format: {"verdict": "PASS" | "BLOCK", "reason": "..."}.
- Reason text is logged and auditable; caseworkers see the exact model output.
- No action is taken on model output without caseworker review (no automated commits).
Risk: The SQLCipher database is accessed or corrupted.
Mitigation:
- Database is encrypted at rest (SQLCipher) with a per-device key.
- Access is limited to the local API process (no public ports).
- Regular backups to removable media, stored in caseworker custody.
- No network connectivity for backup by default.
Globis Edge is NOT:
- A biometric identification system.
- A fraud detection or lie detection system.
- A risk scoring or behavioral prediction tool.
- A replacement for substantive asylum interviews.
- An automated eligibility determination system.
- A production deployment without UNHCR oversight.
Globis Edge IS:
- A structured intake capture tool with consistency checks.
- A proof-of-concept for edge-based humanitarian AI.
- A demonstration of responsible agentic reasoning (dual-pass audits, explicit rule layers, human-in-the-loop).
- A research artifact for the Gemma 4 Good Hackathon.
- All prompts are in
prompts/directory and in source code (not hidden or black-boxed). - Constitutional Auditor rules are explicit and human-readable (
prompts/auditor.md). - Verdicts include reasoning traces (why the model passed or blocked a record).
- Logs record all protected field blocks with reason, but no values.
- Source code is open and reproducible (GitHub repo with commit history).
We commit to:
- Data minimization: Collect only what is needed; reject sensitive fields by default.
- Human oversight: No automated consequential decisions; all outcomes surface to caseworkers.
- Transparency: Publish prompts, rules, and reasoning in clear language.
- Testability: Use synthetic data that is safe to share; publish test scenarios and results.
- Honesty about limitations: Do not claim the system can detect fraud, predict refugee status, or ensure safety.
- Governance alignment: Design for UNHCR principles, not around them; acknowledge regulatory gaps.
- Community input: Solicit feedback from caseworkers, humanitarian practitioners, and affected communities before any field use.
For questions about data ethics, responsible AI practices, or field deployment considerations:
- GitHub: https://github.com/[your-repo]
- Email: Nad1071996@outlook.com
- Submission: Gemma 4 Good Hackathon, Kaggle
Globis Edge is licensed under the Apache License 2.0.
Copyright © 2026 Nada Khas
Built with Gemma 4 E2B for the Gemma 4 Good Hackathon.
Synthetic data only. No real refugee data is used.
Document Version: 1.0
Date: May 18, 2026
Status: Final for Kaggle submission