“Build us an AI dispatch app.”
A solution-shaped request with no agreed workflow, success measure, offline policy, or evidence.
ONE REALISTIC CUSTOMER PROBLEM
Can Omkara turn a messy field-service workflow into verified software—without losing why it matters?
Shakti Field Services coordinates 60 appliance-repair technicians through WhatsApp, phone calls, and spreadsheets. Jobs are missed, technicians receive incomplete addresses, and dispatch cannot prove whether a visit happened. The owner asks for “an AI dispatch app.” Omkara prevents the requested technology from replacing the real operational problem.
CUSTOMERShakti Field Services
USERS60 technicians · 5 dispatchers
SURFACESAndroid + Web
PRODUCT LANGUAGESKannada · Hindi · English
→
Jobs disappear between handoffs.
The primary problem is ownership, complete job information, offline continuity, and proof of completion—not autonomous AI scheduling.
The delivery fragments
- Meeting notes live in separate documents.
- Each coding agent receives a different summary.
- The Executor invents a map-heavy interface.
- Testing proves features, not the customer workflow.
- The deployed version is disconnected from approval.
- No one measures whether missed jobs declined.
One versioned delivery chain
- Discovery evidence retains source and classification.
- Stakeholders approve the workflow visually.
- Every agent receives the same bounded contract.
- Visual drift becomes a blocking finding.
- Parity tests the exact commit and languages.
- Deployment stays linked to adoption and outcome.
The reason to build Omkara
The coding agents are replaceable. The durable value is the trusted relationship between what the customer experienced, what was approved, what was built, what was tested, what was deployed, and what outcome changed.
STAGE 1 · DISCOVERY RECORD
Capture reality before proposing software.
Omkara separates facts, claims, recommendations, and machine inference.
“Yesterday three technicians reached the wrong address, but the spreadsheet still says every job was assigned correctly.”
Observed evidence
VERIFIED17 of 126 jobs last week had incomplete address or contact fields.
Stakeholder claim
CONFIRMEDDispatch says technicians often forget to confirm job acceptance.
FDE recommendation
PROPOSEDUse explicit assignment acceptance and an offline job queue before considering AI routing.
Agent inference
REJECTEDTechnicians may need live GPS tracking throughout the day.
Current workflow
Call received → dispatcher enters spreadsheet → WhatsApp assignment → technician replies → visit → photo shared → dispatcher closes row.
Primary failure
No reliable ownership or completeness check between assignment and visit.
Non-negotiable
Technician app must work offline; continuous location tracking is prohibited.
Baseline
14% of jobs need dispatcher recovery; median assignment confirmation is 23 minutes.
Pilot outcome
Reduce recovery to below 5% and confirmation to below 5 minutes.
Confidentiality
Customer records remain local; reusable patterns must remove names, addresses, and proprietary workflow terms.
STAGE 2 · INTENT PROOF
Show stakeholders what will change.
The visual contract is derived from approved discovery—not an agent’s preferred UI.
DISPATCHER WEB CONSOLE · ENGLISH
Today’s service jobs
Washing machine repair · JP Nagar
Customer contact ✓ · address ✓ · parts note ✓
Awaiting technicianRefrigerator repair · HSR Layout
Accepted by Ravi · confirmation 2m ago
Accepted↔
ತಂತ್ರಜ್ಞರ ಅಪ್ಲಿಕೇಶನ್ · KANNADAಇಂದಿನ ಕೆಲಸಗಳು
Offline · 3 jobs saved on this device
ಮುಂದಿನ ಕೆಲಸವಾಷಿಂಗ್ ಮೆಷಿನ್ ರಿಪೇರಿ
ಜೆಪಿ ನಗರ · ಗ್ರಾಹಕರಿಗೆ ಕರೆ ಮಾಡಿ
COMPLETIONPhoto + customer confirmation
Syncs automatically when online.
STAKEHOLDER APPROVAL GATE
APPROVEDIntent Proof · v4
PURPOSEPrevent lost handoffs
Every job has one accountable owner and complete information.
PERMITTED UXList-first, offline-first
Maps are optional navigation links, not the primary workflow.
NOT ALLOWEDNo continuous tracking
No autonomous reassignment and no hidden customer-data transmission.
6 screens · 12 states
Interactive dispatcher Web console and technician Android experience with assignment, offline, language, completion, and synchronization states.
Open approved product mockup ↗Kannada · Hindi · English
Kannada default for technicians; English default for dispatch; runtime switching and fallback defined.
9 observable outcomes
Assignment, offline access, acceptance, completion, sync, accessibility, and prohibited tracking.
STAGE 3 · MULTI-AGENT DELIVERY
Agents rotate. Product truth does not.
Roles determine permissions and deliverables; vendors remain replaceable.
Planner
Maps approved screens to modules, identifies offline sync risk, and defines the implementation sequence.
→
Executor
Builds Web and Android worktrees against the exact Visual and Localization Contracts.
→
Tester + Parity
Runs approved journeys and locale coverage against the exact implementation commit.
→
Integrator
Evaluates intent alignment, evidence, security, conflicts, and merge readiness.
▣
Context Packet · Executor · hash 98f2…a17
ACKNOWLEDGEDDiscovery v3 · Intent Proof v4 · Visual Contract v4 · Localization v2 · scope · worktree · decisions · prohibited behavior · completion gate
No manual status document
- Commands and changed files
- Commit and worktree
- Plan decisions and deviations
- Tests and evidence references
- Context added during execution
Machines cannot approve intent
- Does the plan solve the customer problem?
- Is a deviation acceptable?
- May data leave the customer boundary?
- Is the tested version ready to deploy?
- Did the workflow outcome improve?
STAGE 4 · VISION-DRIFT GATE
A plausible UI can still be the wrong product.
The Executor optimizes for a live map. Omkara compares it with the approved customer purpose.
“Smart live dispatch map”
Technician locations dominate the screen. The system auto-reassigns nearby workers and depends on continuous connectivity.
Live technician map60 always-on location markers · automatic route optimization
≠
“Reliable assignment handoff”
Complete job information, explicit acceptance, offline continuity, manual accountability, and no continuous tracking.
Job ownership queueComplete fields · accepted owner · offline state · evidence
BLOCKING DEVIATION VC-04: The map-first UI changes the approved workflow, violates the tracking prohibition, and cannot work offline. Integration is disabled.
Why this is not stylistic feedback
The rejection links to the technician privacy policy, offline connectivity observation, dispatcher workflow approval, and Intent Proof v4.
Fix or request a new decision
The Executor restores the list-first workflow. If stakeholders truly want live tracking, Omkara requires a new Discovery/Intent version and impact review.
RESOLVED: Commit `8e91c4f` restores the approved queue, explicit acceptance, offline cache, and privacy boundary. Parity can now test it.
STAGE 5 · EXACT-COMMIT PROOF
Parity proves the approved journey—not an agent’s confidence.
Evidence is tied to the same commit the Integrator reviews.
✓
Job available without network
Screenshot · semantic tree · action trace
✓
Technician accepts ownership
Local state recorded and later synchronized
✓
No continuous location collection
Permission and network assertions passed
commit 8e91c4f · intent v4 · locale v2
✓
Incomplete jobs cannot be assigned
Required contact, address, and service details
✓
Acceptance appears within refresh
Owner, timestamp, and sync state visible
✓
Completion evidence is reviewable
Photo reference and customer confirmation
commit 8e91c4f · parity run P-1042
PR EVALUATION RECORD
HUMAN APPROVAL REQUIREDMerge-ready · reviewed commit 8e91c4f
INTENTAligned
9/9 criteria traced to approved intent.
EVIDENCEComplete
Android and Web critical matrix passed.
INTEGRATIONReady
No blocking conflicts or unapproved deviations.
STAGE 6 · DEPLOYMENT RECORD
The tested version stays connected to rollout.
Approval does not silently transfer across commits or environments.
Android 1.0.0-pilot
Web 2026.08.21
Run P-1042
Evidence compatible
South Bengaluru
Owner: Kavya Rao
Web prior release
Android feature flag
Expand only after
2-week pilot gate
Evidence lineage
Discovery v3 → Intent v4 → commit 8e91c4f → Parity P-1042 → PR evaluation E-19.
Configuration
Offline cache 7 days · location permission disabled · Kannada default · sync retry policy v1.
Operational owner
Kavya Rao owns dispatcher training, pilot support, and daily exception review.
Expansion gate
Recovery rate below 5%, median acceptance below 5 minutes, no privacy or lost-sync incident.
STAGE 7 · OUTCOME RECORD
Did the delivered software improve the workflow?
Omkara distinguishes measured results, customer reports, and inference.
Baseline before pilot
Measured after two weeks
Down from 23 minutes
Daily active technicians
Pilot gate passed
Recovery and confirmation targets were met with no lost-sync or prohibited-location event.
Less dispatcher chasing
Kavya reports the morning reconciliation routine fell from 70 minutes to roughly 20 minutes.
One technician did not adopt
Do not infer usability failure. Schedule an interview and attach the evidence to the next Discovery Record.
REUSABLE DELIVERY PATTERN
PRIVACY REVIEW REQUIREDOffline assignment-and-acceptance workflow
CAN REUSEGeneric workflow
Assignment ownership, completeness gate, offline queue, acceptance evidence.
MUST REMOVECustomer identity
Names, addresses, operational metrics, terminology, recordings, and credentials.
REQUIRES NEW DISCOVERYLocal policy
Tracking, language, evidence, labor, and approval rules never transfer silently.
What Omkara contributed
It did not merely coordinate four agents. It prevented the customer’s “AI dispatch” request from becoming the wrong product, caught a privacy-breaking redesign, tied proof to the exact commit, preserved rollout accountability, and showed whether the intended business outcome improved.