composed experience90–120 min4 stages8 code languages

Application flow: A living operations map for the city

One governed view from daily operations to infrastructure investment planning.

The real-world moment

A city receives reports of waterlogging, failed streetlights and waste overflow across different channels. It needs one governed map without collapsing department ownership, must deduplicate related reports, dispatch the correct crew, preserve citizen privacy, publish honest status, and analyze service equity using versioned ward and asset data.

Make ownership visible before code.

Compose multiple capabilities while the application owns user intent, policy, and continuity.

Application state
hybrid
Planning calls
0
Credentials accepted
No
Write authority
None
01
Department systems of record

Catalog authoritative layers

Retain authoritative assets, work orders, ownership and service outcomes; the map does not become an ungoverned replacement master.

Layer ↔ steward, source, schema, CRS, sensitivity, version

GETStill Map Image API/{REST_KEY}/still_imageThis normalized operation matches the stage intent and remains subject to its source, lifecycle, authentication, entitlement, host, and regional gates.

Record stage 1 with the application identity, source fingerprint, request or aggregate identity, timestamp, and observable outcome.

Two departments claim the same incident

Keep one coordinating incident with explicit owning/participating work orders; never transfer authority by map edit alone.

02
Spatial data catalogue

Ingest live assets and citizen reports

mGIS registers layers, schemas, CRS, stewards, update cadence, license/sensitivity and immutable versions.

Report/alarm ↔ source identity, consent, event/receipt time, coarse/public projection

GETGets the live data of devices./deviceThis normalized operation matches the stage intent and remains subject to its source, lifecycle, authentication, entitlement, host, and regional gates.

Record stage 2 with the application identity, source fingerprint, request or aggregate identity, timestamp, and observable outcome.

Citizen report contains precise personal data

Restrict raw evidence, derive a coarse operational/public location and apply purpose-specific retention/redaction.

03
Event correlation

Dispatch and monitor work

Normalizes citizen reports and sensor alarms, preserves each source, and derives bounded incident clusters under a versioned rule.

Record stage 3 with the application identity, source fingerprint, request or aggregate identity, timestamp, and observable outcome.

Public status lags internal resolution

Version projections, display freshness, alert on reconciliation delay and correct with an attributable update.

04
Work orchestration

Publish role-specific dashboards

Creates department-specific tasks, routes capable crews, tracks progress/proof and reconciles closure to the owning system.

Work order ↔ owning department, asset, SLA, task/provider identity, closure proof

GETGets the historical location events of a device./devices/{deviceId}/eventsThis is a supporting operation from the selected product stack, not proof of an exact provider contract for this stage. Resolve the stage through its product source or adapter boundary before live implementation.

Record stage 4 with the application identity, source fingerprint, request or aggregate identity, timestamp, and observable outcome.

Two departments claim the same incident

Keep one coordinating incident with explicit owning/participating work orders; never transfer authority by map edit alone.

Edit once. Generate eight trusted-runtime implementations.

The recipe starts from the normalized GET /tasks contract. Execute six deterministic fixture outcomes before an issued account is involved.

Local request composerCode stays local · fixtures are explicit
GETRequest inputs
7 editable · 0 protected
Generated in eight languages
Environment-backed credentials
GEThttps://workmate.mapmyindia.com/apis/tasks?startTime=1700000000000&endTime=1700000000000&ownerId=1&assigneeId=1&clientDetails=true&activityDetails=true
Credential-free sandboxExecute this contract without a provider call
How fixtures work
Generated from your inputs
curl --request GET \
  --url 'https://workmate.mapmyindia.com/apis/tasks?startTime=1700000000000&endTime=1700000000000&ownerId=1&assigneeId=1&clientDetails=true&activityDetails=true' \
  --header "Accept: application/json" \
  --header "Authorization: Bearer ${MAPPLS_ACCESS_TOKEN}"

Credential-safe by constructionSet MAPPLS_ACCESS_TOKEN only in your trusted runtime. Code generation stays local. Sandbox execution sends only bounded fixture inputs to this developer platform and never reads a credential or calls Mappls.

Break the journey before customers do.

These controls are required at this operating depth; deeper recipes add durable truth rather than merely more API calls.

Application-owned intentStable cross-capability identityPartial-failure fallbackCancellation and teardownFreshness and provenanceQuota and latency budget

Definition of done

Every capability has one owner, bounded input, explicit timeout, and useful unavailable state.

Application intent survives refresh, back navigation, duplicate callbacks, and partial capability failure.

Provider identities, source fingerprints, request identities, and application decisions remain attributable.

Accessibility, privacy, quota, observability, support, and rollback evidence cover the complete user flow.

Contracts, tutorials, and journeys stay linked.

Airside Turnaround Desk

Coordinate a revision-safe aircraft turnaround, pause for airside exceptions, preserve four service milestones, and require independent airline, airport, and safety readiness decisions.

Source-grounded, not authority-granting

This recipe composes source-derived contracts, application architecture, fixtures, and maintained learning evidence. It does not prove package availability, provider payload shape, account entitlement, regional behavior, production compatibility, or release approval.