Technology ecosystem & capabilities

Field operations, made legible.

A working technology practice built around the full path from conditions on the ground to usable decisions: collect the signal, structure it, test the logic, communicate the result, and improve the operation.

Download the two-page PDF → PDF · 1.6 MB

Practice: Operations leadership · systems design · civic technology
Primary role: Translator and builder between field teams, data, and decision-makers
Evidence: Three representative architectures documented below

01 / Ecosystem

Capabilities, with the level of ownership made explicit.

This is not a logo inventory. Each domain describes how the tools are used and separates systems personally designed or implemented from platforms configured, operated, or explored.

Designed & implemented — owned the workflow or build Integrated & operated — connected or ran the system Working knowledge — used for bounded analysis or prototyping

01 · Operations systems

Field workflows

Turns service goals into repeatable staffing, fleet, safety, warehouse, and incident-response practices.

Fleet operationsAsset controlQR workflowsSOPs

Designed & implemented

02 · Data & analytics

Operational intelligence

Structures messy operational data into measures, comparisons, exception queues, and decision-ready reporting.

SQLPythonPandasSheetsTableauMetabase

Implemented · integrated · working knowledge

03 · Geospatial systems

Place-based analysis

Joins fleet, service, and civic data to neighborhoods, operating zones, demand patterns, and field priorities.

GBFSGTFSGeoJSONArcGISLeafletpydeck

Integrated & applied

04 · Software delivery

Useful, maintainable products

Builds small web products, dashboards, automations, and public artifacts that remain understandable after launch.

HTMLCSSJavaScriptReactGitHubAPIs

Designed & implemented

05 · AI & automation

Human-in-the-loop workflows

Uses models for bounded synthesis, drafting, classification, and monitoring while preserving review and clear stop conditions.

OpenAIClaudeGeminiApps ScriptTasker

Workflow design & implementation

06 · Product & communication

Systems people can use

Pairs information architecture, documentation, accessibility, and visual explanation with the underlying system.

UXDesign systemsTechnical writingBriefingsAccessibility

Designed & delivered

02 / Architecture evidence

Three systems, traced from problem to operational outcome.

These diagrams describe representative patterns and public-safe implementation detail. They are intended to support a technical interview: ownership, data movement, decision logic, users, cadence, and limitations are visible.

Evidence 01 · Service response

311 monitoring & response

Public service requests become actionable only when reports can be normalized, located, prioritized, assigned, and closed with a documented response.

ProblemScattered reports

Requests arrive with uneven descriptions, location quality, and urgency.

InputsService-request feed

Category, timestamp, status, public location, and narrative fields.

ProcessingNormalize & geolocate

Clean categories, remove duplicates, validate coordinates, and group nearby reports.

Decision rulesPriority queue

Age, safety signal, repeat location, operating area, and available field capacity.

Output & usersField worklist

Map and queue for operations leads, field staff, and public-agency partners.

OutcomeTraceable closure

Faster triage, fewer missed reports, and a record of action and recurring conditions.

Role: Workflow design, categorization logic, operational routing, and documentation
Cadence: Scheduled monitoring with exception-driven follow-up
Tools: Open-data feed, Python or Apps Script, geospatial view, team workflow
Control: Human review before assignment or external response

Limits: public records may be delayed, duplicated, miscoded, or imprecisely located; the workflow supports prioritization but does not replace field verification.

Evidence 02 · Fleet intelligence

GBFS fleet intelligence

Live vehicle feeds show where fleets are now, but operations need a dependable way to compare providers, detect patterns, and convert snapshots into deployment decisions.

ProblemEphemeral supply

A live map cannot explain persistence, imbalance, coverage quality, or change over time.

InputsPublic GBFS feeds

Provider endpoints, vehicle status, coordinates, timestamps, and operating geography.

ProcessingCollect & normalize

Scheduled snapshots, schema alignment, freshness checks, deduplication, and spatial joins.

Decision rulesDetect exceptions

Supply gaps, persistent clusters, inactive vehicles, provider divergence, and zone-level imbalance.

Output & usersMaps & briefings

Comparative views and concise summaries for operations planning and civic analysis.

OutcomeBetter allocation

Evidence for deployment, maintenance concentration, coverage conversations, and follow-up analysis.

Role: Pipeline concept, data normalization, geospatial analysis, and decision framing
Cadence: Repeated snapshots; reporting windows selected for the operating question
Tools: GBFS, JSON, Python, Pandas, GeoJSON, pydeck or web mapping
Control: Feed-health checks and explicit separation of observation from inference

Limits: GBFS represents provider-reported availability, not trip demand or operational intent; outages, stale timestamps, and provider-specific semantics require validation.

Evidence 03 · Asset accountability

Battery accountability

High-volume battery movement across charging, storage, vehicles, and field teams requires a low-friction record that improves accountability without slowing the operation.

ProblemUnclear custody

Manual handoffs create gaps between physical inventory, charged status, assignments, and returns.

InputsScan events

Battery or batch ID, operator, timestamp, location type, movement, and condition.

ProcessingValidate movement

Append transactions, check required fields, reconcile expected states, and flag impossible transitions.

Decision rulesException handling

Missing return, unexpected custody, damaged unit, count mismatch, or aging unresolved event.

Output & usersInventory view

Shift-level status and exceptions for warehouse leads, field leads, and operators.

OutcomeAccountable flow

Clearer handoffs, quicker reconciliation, fewer avoidable shortages, and better coaching evidence.

Role: Process mapping, scan workflow, exception logic, rollout, and operator communication
Cadence: Event-driven scanning with shift and daily reconciliation
Tools: QR identifiers, mobile form, structured sheet or database, exception report
Control: Role-based access, minimal personal data, and supervisor resolution of exceptions

Limits: the record is only as reliable as scan compliance and identifier durability; physical counts and supervisor review remain necessary controls.

03 / Accessibility evidence

The explanation is part of the system.

Accessibility decisions are documented alongside the architecture so a visual diagram is never the only way to understand ownership, sequence, controls, or limitations.

Structure: Ordered headings, landmarks, definitions, and list semantics expose the evidence independently of layout.
Non-color meaning: Track labels, stage names, and written outcomes accompany amber and teal distinctions.
Reflow: Architecture stages become a readable vertical sequence on narrow screens and at enlarged text sizes.
Motion: No animation is required to understand the system; print and reduced-motion contexts retain the complete narrative.

Known limitation: complex architecture diagrams can still create cognitive load. The adjacent problem, stage, outcome, and limits prose is the accessible text alternative; an additional plain-language or alternate-format version is available on request.

The common architecture is deliberately practical: observe the work, create a trustworthy record, make decision rules visible, keep people in the loop, and return the result to the people responsible for the operation.

Return to portfolio →