durable operation2–3 hr5 stages8 code languages

Operating journey: Operate the network from tower to doorstep

Faster restoration with better prioritization and fewer repeat dispatches.

The real-world moment

A fibre cut triggers alarms across cabinets and cell sites while customers report outages. Operations must correlate evidence to the affected topology, estimate customer impact, create skill/tool/access-aware repair work, route teams around road disruption, capture splice/test proof, and avoid declaring restoration until network telemetry and customer-impact projections reconcile.

Make ownership visible before code.

Operate the full lifecycle with versioned state, hostile-path recovery, audit, and release evidence.

Application state
stateful
Planning calls
0
Credentials accepted
No
Write authority
None
01
Network inventory/topology

Model towers, links, cabinets, and service areas

Owns towers, fibre, links, cabinets, service areas, dependencies, maintenance windows and authoritative asset versions.

Network asset ↔ topology/inventory version, geometry and owner

GETTo get the list of tasks and their details/tasksThis 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 1 with the application identity, source fingerprint, request or aggregate identity, timestamp, and observable outcome.

Many alarms represent one fibre cut

Preserve every alarm, derive one incident using a versioned topology/correlation rule and allow operator correction.

02
Alarm and impact correlation

Correlate alarms with impacted customers

Appends source alarms, maps them to exact inventory versions and derives incidents/affected customers under a versioned topology rule.

Alarm ↔ source/event/content identity, event/receipt time, mapped asset

GETTo get the task details for the given task id./tasks/{taskId}This 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 2 with the application identity, source fingerprint, request or aggregate identity, timestamp, and observable outcome.

Inventory geometry/topology is stale

Mark confidence, route to data-steward correction and never rewrite prior incident lineage after the new version.

03
Repair orchestration

Create skill-aware repair tasks

Creates Workmate tasks with skill, tools, access, safety and SLA requirements; eligible teams are ranked by fresh network ETA.

Impact projection ↔ topology rule/version and affected service IDs/counts

POSTTo create new Task/tasksThis normalized operation matches the stage intent and remains subject to its source, lifecycle, authentication, entitlement, host, and regional gates.

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

Technician closes before alarms clear

Keep work proof submitted but incident in reconciliation; query authoritative telemetry and escalate mismatches.

04
Field evidence

Navigate and capture repair proof

Offline-safe guidance, asset identity, images/readings/test results and reviewer decisions produce an immutable repair timeline.

Repair ↔ task/provider identity, required capability, evidence and restoration checks

GETRouting API/{REST_KEY}/{resources}/{profile}/{geopositions}This normalized operation matches the stage intent and remains subject to its source, lifecycle, authentication, entitlement, host, and regional gates.

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

Many alarms represent one fibre cut

Preserve every alarm, derive one incident using a versioned topology/correlation rule and allow operator correction.

05
Restoration reconciliation

Analyze chronic failure clusters

Requires network alarm clearance, task proof and impact recovery before closure; chronic clusters derive from versioned evidence.

Network asset ↔ topology/inventory version, geometry and owner

PUTTo update the task description & status./tasks/{taskId}This 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 5 with the application identity, source fingerprint, request or aggregate identity, timestamp, and observable outcome.

Inventory geometry/topology is stale

Mark confidence, route to data-steward correction and never rewrite prior incident lineage after the new version.

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.

Idempotent commandsOptimistic aggregate versionsEvent and receipt timeTransactional outboxUnknown-outcome reconciliationIndependent human decisionsRestart recoveryImmutable audit evidence

Definition of done

Every aggregate has an invariant, expected version, stable command identity, and attributable actor.

Duplicate, late, reordered, invalid, stale, timed-out, and restarted execution preserve one durable truth.

Unknown provider outcomes reconcile by original identity before replay or compensation.

Terminal decisions, human review, audit, outbox delivery, privacy, retention, and rollback remain independently evidenced.

Contracts, tutorials, and journeys stay linked.

Contract set

GETTo get the list of tasks and their details/tasksGETRouting API/{REST_KEY}/{resources}/{profile}/{geopositions}GETTo get the task details for the given task id./tasks/{taskId}GETRouting API with driving profile/{REST_KEY}/{resources}/driving/{geopositions}GETGet users movement details/reports/movements/{userId}GETRouting API with trucking profile/{REST_KEY}/{resources}/trucking/{geopositions}POSTTo create new Task/tasksGETRouting API with biking profile/{REST_KEY}/{resources}/biking/{geopositions}PUTTo update the task description & status./tasks/{taskId}GETRouting API with walking profile/{REST_KEY}/{resources}/walking/{geopositions}GETGet users attendance details with travelled distance./reports/attendancesGETDistance Matrix Predictive ETA API/{REST_KEY}/distance_matrix_predictive/driving/{coordinates}

Durable state machines

statefulField-service task lifecycle8 states · 8 transitionsstatefulCoordinated incident response7 states · 8 transitionshybridRecoverable navigation session6 states · 6 transitionshybridGoverned spatial analysis7 states · 6 transitionshybridDurable multi-stop itinerary6 states · 9 transitionshybridiOS direction planning and navigation handoff8 states · 8 transitionshybridiOS feedback report and review9 states · 9 transitionshybridConsent-bound location capture evidence8 states · 9 transitionsstatefulGoverned place contribution and publication7 states · 8 transitions

Grid Restoration Desk

Correlate an outage, govern independent switching approval, dispatch an assigned crew, preserve rework, and reconcile restoration from telemetry and customer-impact evidence.

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.