City & Municipality Data Reporting Framework
What operational data SYIBE shares with a city or municipality, and the privacy rules that constrain it. The framework is aggregated and anonymised by default; rider-level reporting is not created as a routine feature of city cooperation.
- Dependency class
- C · Jurisdiction-dependent
- Needs Syrian/local legal review or country-specific adaptation.
- Consent
- Not a consent document
- Not revocable while the account is active
Version 0.1-draft · v1 Working Draft — frozen
Version & effective date
No effective date while the status is working draft. On approval the version becomes 1.0, an effective date is set at least 14 days ahead for material rider-facing changes (immediate where a change is legally required or purely clarifying), and the previous version stays archived with its own effective window.
Jurisdiction & city applicability
Per city. A reporting arrangement exists only where a city has requested or a permit requires it, and its scope is recorded per city with the aggregation level agreed. Damascus is the first city; no reporting feed is active while operations are simulated. [REGULATORY CONFIRMATION REQUIRED]
CMS integration
- Published document; the per-city reporting scope, aggregation level, frequency and recipient are configuration records, and each transmission is logged with what was sent.
- Any request for rider-level data is refused at the framework level and re-routed to the Law-Enforcement & Government Data Request Policy.
Draft clauses
City & Municipality Data Reporting Framework
- 01
Purpose: to give a city the information it legitimately needs to manage public space, plan infrastructure, verify permit compliance and assess safety — and nothing beyond that purpose.
- 02
Default form of reporting is aggregated and anonymised. Standard reports cover fleet size deployed and available, trips and trip minutes by period, average trip distance and duration, origin–destination movement at zone level, parking compliance and violation rates, vehicle relocation and rebalancing activity, response times to reported obstructions, safety incidents by category, and service availability. Figures are reported per zone and per period, never per person.
- 03
Privacy-by-design controls applied before any report leaves the platform: rider identifiers, phone numbers, payment data and verification results are never included; trip identifiers are replaced with per-report pseudonyms that cannot be linked across reports; precise coordinates are generalised to zones or a coarse grid; start and end points are truncated so that a trip cannot be traced to a building; timestamps are rounded; and a minimum-count threshold suppresses any cell small enough to single out an individual.
- 04
Rider-level reporting is not created by default. SYIBE does not build a routine feed of individual rider identities, individual full trip traces, contact details or account histories to any government body. A rider-level disclosure happens only in response to a specific, valid legal instrument for a specific case, handled under the Law-Enforcement & Government Data Request Policy — not under this framework.
- 05
Operational exception, narrowly drawn: to clear a specific obstruction or hazard, a city may be given the vehicle identifier, its location and its status — the information needed to identify the vehicle, not the rider. The last rider's identity is not part of that exchange.
- 06
Minimisation and challenge: SYIBE reports only fields that serve a stated purpose in the permit or agreement, declines fields that add nothing to it, and asks a city to justify or narrow any request that goes beyond the agreed scope, including any request for raw or individual-level data.
- 07
Transmission and governance: reports are delivered through an agreed secure channel to named recipients, with access limited to the stated purpose, a defined retention period on the city side, and a prohibition on re-identification, onward sharing or commercial re-use, recorded in a written data-sharing agreement. [LEGAL REVIEW REQUIRED]
- 08
Standardised feeds: where a city requires a recognised mobility data specification, SYIBE can support it, provided the privacy controls in this framework are applied to the fields it carries and any rider-identifying field is excluded or pseudonymised. [REGULATORY CONFIRMATION REQUIRED]
- 09
Transparency to riders: the categories of data reported to cities, the aggregation applied and the recipients are described in the Privacy Policy and in this document, so a rider can see what leaves the platform without asking.
- 10
Internal review: the reporting scope for each city is reviewed at least annually and whenever a permit changes, to remove fields that are no longer needed and to re-test that published figures cannot single out an individual.
Open questions for legal review
- Whether Damascus requires an operational data feed as a permit condition, and its fields and frequency.
- The minimum-count suppression threshold and the grid or zone resolution to be used.
- Whether a specific mobility data standard will be mandated, and whether its rider-level fields are acceptable under local privacy duties.
- Retention and onward-use limits the city will accept in a written data-sharing agreement.
These documents are professional working drafts prepared for the SYIBE operating model. They are not legal advice and are not approved production legal language. Before public launch, every jurisdiction-sensitive document must be reviewed by qualified local legal counsel once the corporate entity, regulatory classification, municipal permissions, insurance structure, payment provider, KYC provider and hardware structure are finalised.