Tracking
Prompt:
Generate a short story (3000+ words) centred on a Project Manager in a fictional global courier company. He's working (along with the Director of Digital Customer Experience) on a major upgrade to the company's package tracking system. The short story should explore that process in depth, including enough technical detail and insight to engage professionals working in the field while remaining accessible to general readers.
The company operates globally but has its corporate HQ in London, where both key employees work. Feel free to alter job titles.
Three parts.
1. Initial assessments. Why is the upgrade necessary? Office politics. Scene setting.
2. Technical challenge. The build and launch. Developers. Engineers. Complications.
3. Post-launch. Evaluation. More office politics.
Temporal jumps between each section (actual length depending on realistic timeframes for such projects).
First part begins in December 2025, shortly after the death of the playwright Tom Stoppard. Our protagonist is very familiar with Stoppard's work. Themes from his plays should run through all three sections.
No dialogue. Include multiple digressive essayistic asides.
Stylistic influences: Ian McEwan and Julian Barnes.
Avoid tortured metaphors. Always choose readability over pseudo-profundity.
Responses: Gemini 3 Pro, Claude Sonnet 4.5
The story below was generated by GPT 5.1 Thinking.
Part One: Coin Tosses
In the first week of December 2025, London felt like an afterthought. The Christmas lights on Oxford Street had gone up in a perfunctory way, as if the city had agreed to observe the ritual but refused to take it seriously. On the morning train from Clapham Junction, Daniel Mercer scrolled through the news and found, wedged between election speculation and an article about a pop star’s divorce, a short notice announcing the death of Tom Stoppard.
The obituary was almost offensively compressed. A few hundred words to summarise decades of careful mischief: the games with language, the intricate structures, the way his plays pretended to be about one thing while quietly being about three others. To Daniel, the write-up felt like reducing a production schedule to a single milestone: “System decommissioned.”
It was not grief, exactly. More a sense of belatedness, of arriving in the lobby to discover that the performance had ended weeks ago and the ushers were stacking chairs. Stoppard had always seemed like a permanent fixture of the culture, a playwright who would go on spinning clever contraptions indefinitely. Learning that there would be no more plays felt oddly like discovering that a core platform had reached end-of-life.
It was not a comparison he would share at work.
Meridian Parcel Network, the company that paid him to think in Gantt charts and dependency matrices, described itself as the world’s most reliable courier. The claim was supported by a dense forest of graphics and selectively honest statistics. Its headquarters, a glass-and-steel slab by the Thames, resembled every other corporate HQ that had been designed via presentation deck: sufficient glazing for stock photos, sufficient neutrality to offend no-one.
Inside, the building felt older than its surfaces. Departments had been renamed, merged, re-segmented. Someone had once tried a colour-coded agile transformation and abandoned it halfway, so certain floors still had motivational slogans peeling off the walls. Posters for obsolete initiatives—“Project Horizon”, “NextGen Route Optimisation”—lingered in forgotten corners like characters who were meant to exit in Act Two and never quite got the cue.
Daniel was a senior project manager in what the org chart called the Group Transformation Office. Informally, people thought of it as a travelling circus of PowerPoint and RACI matrices, drafted whenever the company wanted something large to move without admitting that it would be painful. His latest assignment, freshly allocated after a Dubai secondment had spirited away the previous incumbent, was something called Global Track Visibility Modernisation.
Projects, he often thought, were a form of theatre. There was casting, blocking, a script of sorts. Someone wrote a treatment—the business case—full of foreshadowing and implied jeopardy, and then the whole ensemble tried to perform it in slow motion over eighteen months. As in theatre, success depended on how much of the illusion could be maintained before everyone started checking their phones.
The problem was simple to state: Meridian’s package tracking system was old. Not charmingly vintage, not blinking green text on black screens, but middle-aged and entrenched. It had begun life as a regional Java application for Western Europe more than a decade earlier, built by a consultancy that had since vanished into a merger. Over time, additional layers had accreted: an Asia-Pacific extension; a North American adapter; separate mobile apps bolted on top, each with its own assumptions. The result was a vaguely coherent monolith surrounded by a halo of integrations and compromises.
Customers experienced this in ways no internal dashboard captured. A parcel sent from Birmingham to Berlin might display eight meticulous tracking events: collected, departed facility, arrived at hub, cleared customs, out for delivery. A parcel from Seoul to Sydney would show three laconic statuses, one of them the eternally unhelpful “In transit.” Estimated delivery windows ranged from comfortably precise to suspiciously broad, like forecasts hedged by lawyers. Notifications arrived late, in the wrong language, or not at all. The web interface had the queasy look of something that had been redesigned three times without ever being properly replaced.
Competitors had noticed the gap before the board did. There were now courier startups offering real-time maps that showed your driver inching down your street, countdown timers accurate to the hour, optional carbon footprints per shipment. Meridian’s own tracking experience, when placed side by side, looked like stage scenery from an earlier production that had never been struck.
The board finally took an interest when Net Promoter Scores began to slope downward in certain segments. At the November strategy offsite, the failing system appeared as a series of bullet points under the heading Digital Customer Experience Risk. Line charts showed a correlation between poor tracking information and higher contact-centre volumes. A consultant’s slide helpfully summarised the situation as “Legacy Track Platform Constrains Brand Promise.”
Thus: Global Track Visibility Modernisation. The title alone implied that the existing platform was parochial and dim.
Meridian’s lobby displayed its own curated fiction. A video wall looped footage of parcels travelling in effortless choreography: conveyors humming, aircraft loading, smiling couriers in branded jackets. Next to it, a live dashboard showed the number of shipments processed that day, on-time percentages, average handling times. None of it hinted at the conversations happening in meeting rooms upstairs, where phrases such as End-to-End Visibility and Single Source of Truth were being thrown around as if they existed somewhere in the wild.
Daniel’s first official task was to run an Initial Assessment. In practice, this meant answering three overlapping questions, each for a different audience. Why was the upgrade necessary? How much would it cost? And who, exactly, would get to own it?
Ownership had already become the first quiet skirmish.
Global IT believed, with some justification, that tracking was theirs. They owned the current system. Their engineers patched it, shepherded its releases, negotiated support contracts with vendors whose logos had not been updated this decade. To them, replacing the platform was an architectural exercise: retire a monolith, stand up a more elegant arrangement of services, keep it all within the familiar boundaries of existing hosting and security.
Opposite them stood the Digital Customer Experience function, led by Priya Shah. Digital argued that tracking was not a system but an experience, a customer touchpoint no less important than the checkout flow. They cared about conversion funnels, notification open rates, and what happened when a user tapped the wrong part of a screen with one thumb while holding a baby with the other. To them, putting the upgrade under IT’s wing risked relegating it to a back-office concern.
Operations wanted a voice because any change that altered scans or statuses might disrupt depots, and depots were the spine of the company’s P&L. Customer Care insisted that the new system had to reflect the queries they actually received. Legal, once they heard the words real-time tracking, began muttering about data protection.
Every large organisation, Daniel believed, ran on overlapping fictions. The official fiction said there was one Meridian, one strategy, one shared reality expressed in slide decks. The unofficial fictions were departmental: IT as the beleaguered guardian of stability, Digital as the visionary interpreter of customer desires, Operations as the adult in the room who ensured that parcels actually moved. Each story contained enough truth to be persuasive, and enough distortion to be dangerous.
The assessment workshops took place in a glass-walled room overlooking the grey January river. People stood around whiteboards with marker pens and Post-its, as though rearranging coloured rectangles might fix the underlying reality. They mapped the current data flows: barcode scans at pickup; depot check-ins; linehaul departures; customs events trickling in from brokers with varying degrees of punctuality; partner updates arriving via brittle FTP jobs and unofficial APIs.
Words like heterogeneous and fragmented appeared frequently in Daniel’s notes. So did phrases such as no agreed definition and region-specific override.
Then came the slides describing the desired future state. These, naturally, were cleaner.
In the new world, every meaningful occurrence in a parcel’s journey would be an event on a global bus. A label printed in Manchester; a scan at a sorting centre in Rotterdam; an aircraft departure from Johannesburg; a failed delivery attempt in Lima: each would be an immutable message, time-stamped and tagged with origin, destination, product type, and a dozen other attributes. Upstream systems would publish events; downstream consumers—mobile apps, web interfaces, internal dashboards, billing processes—would subscribe.
There would be a unified event schema, a controlled vocabulary of statuses that meant the same thing in Bogotá as in Birmingham. Time zones would be normalised. A single public API would expose tracking data to external platforms in a predictable way, with sensible rate limits and documentation written in human language rather than generated sludge.
On paper, it was reassuringly coherent. On paper, many things were.
Daniel had read enough Stoppard to be suspicious of any narrative that moved too smoothly. In Rosencrantz and Guildenstern Are Dead, the characters carry on as if choices matter while the script has already decided their exits. In corporate life, the script took the form of constraints: budget caps, political alliances, regulatory deadlines. The assessment report, once complete, would be presented to the board not as an exercise in modest speculation but as a story in which the ending—A Modern, Unified Tracking Experience—is assumed.
His task was to make the story plausible without lying.
The final document, two dozen pages of careful prose plus annexes, did three things. It described the current system with enough candour to justify its replacement. It sketched the future architecture with enough abstraction to avoid fatal specifics. And it introduced risk in an acceptable register: not apocalyptic, but sufficient to suggest that delay would be more dangerous than action.
In one politely underlined paragraph, Daniel noted that the vendor providing core components of the existing platform would cease mainstream support in mid-2027. This was as close as the document came to shouting. Executives were curiously tolerant of functional degradation but allergic to the phrase out of support. Mortality had to be expressed in contractual terms.
The sponsorship question resolved itself—or rather, was resolved—in a familiar way. The CEO mandated a joint arrangement: the CIO and the Chief Customer Officer would co-sponsor the program, with Priya Shah and the Group Head of Architecture co-chairing the steering committee. Daniel would report “jointly” to both lines.
Joint reporting, in his experience, resembled quantum superposition. You belonged fully to two worlds until the moment they came into conflict, at which point you discovered which observer had more influence.
By the time he emailed the final assessment to the project mailbox, the year’s end had crept up. The office emptied out in stages. People muttered about skiing, about family obligations, about the oddity of celebrating anything in a world where headlines filled with graphs and obituaries.
In the quiet between Christmas and New Year, Daniel ate his lunch at his desk and reread a frayed paperback of Rosencrantz and Guildenstern. The coin tosses, the futile attempts to interpret probability as fate, felt uncomfortably familiar. Projects, after all, were full of small contingent decisions that later acquired the sheen of inevitability. A note not taken in a workshop. An assumption no one challenged because it was Friday afternoon. A compromise that became, silently, the cornerstone of the design.
The upgrade was necessary. That much was true. Everything else was a chain of coin flips he was about to call “plan.”
Part Two: Building the Machine
By late September 2026, the assessment report felt as remote as a first draft of a play that had since been rewritten beyond recognition.
Vendor selections had been made after months of demonstrations in which model parcels glided through perfect journeys. Statements of work had been negotiated to the point of mutual irritation. Architectures had been committed to diagrams. Jira projects had been created with optimistic start dates. The rehearsals were over; the show had technically opened.
The centrepiece of the chosen architecture was an event streaming platform. No one used the vendor’s name in slide titles; that would have felt unsophisticated. Instead, they spoke about the event bus in the abstract, as if it were a neutral substance rather than another dependency that would grow tentacles over time.
Every meaningful occurrence in a shipment’s life would be recorded as an event on this bus. A scan in a depot; a screenshot of a customs clearance; a handover to an airline; a truck leaving a hub fifteen minutes late because the driver’s previous delivery had involved a lost dog and an agitated family: all of it, in theory, could become data. In practice, a subset would be defined as operationally relevant, and everything else would be folded back into anecdote.
Around the bus, a constellation of services took shape. Ingestion services listened to scanners, depot systems and partner APIs, translating their idiosyncratic messages into the canonical event schema. Processing services enriched and transformed events, applying business rules. Read-model services materialised parcel timelines suitable for front-end consumption. A thin API layer provided the interface for mobile apps, websites and large customers pulling status in bulk.
Daniel learned a new vocabulary by osmosis. Event sourcing, idempotency, consumer lag, partitioning strategy. He developed an intuitive sense of how long it should take for an event generated at a scanner in a depot outside Warsaw to appear in the tracking timeline of a user in Manchester. When graphs deviated from that sense, his stomach tightened before his conscious mind found the anomaly.
An aside suggested itself: there was an eerie similarity between late-career Stoppard structures and modern distributed systems. Both were built from small, simple elements—lines of dialogue, events—whose interactions produced complexities no one entirely anticipated. In both cases, elegance on the page or in the diagram did not guarantee comprehensibility in performance.
The build was geographically distributed. In London, the core team of architects and senior developers defined the standards, implemented a handful of “golden path” services and set out what they thought were clear patterns. In Kraków, a near-shore partner took responsibility for wiring in older depot systems and scanners across Europe. In Bangalore, another partner focused on the customer-facing APIs and the SDKs that would eventually be embedded in mobile apps and partner portals.
Time zones created a sense of rolling present. A requirement clarified in a 4 p.m. call in London might be misunderstood in notes, recast into a ticket in Kraków, implemented overnight by a developer in Bangalore and merged into a branch before anyone in London had finished breakfast. A single ambiguous verb in a Confluence page could translate, twelve hours later, into an architectural decision that would take three sprints to undo.
The first services came online in a sandbox environment. Synthetic events flowed through the pipeline: parcels with fake postcodes and non-existent cities, journeys that crossed borders in improbable ways. Dashboards showed throughput, latency, error rates. Architects commented approvingly on p95 percentiles, as if watching critic scores tick in.
Compromises began to appear almost immediately, modest at first.
A service that had been declared stateless was given a small cache to sidestep a performance issue in a partner API. A rule about time-zone normalisation was quietly bent when confronted with the eccentric daylight-saving practices of certain territories. A requirement that “all status codes must map to the global vocabulary” collided with local exceptions that operations insisted on preserving.
Legacy systems, like ageing actors with big reputations, proved resistant to being written out.
The most egregious case was the billing mainframe in Slough. Officially, billing and tracking were to be decoupled. Unofficially, operations reminded everyone that certain tracking statuses—duties assessed, payment received, customs hold—were currently driven by events originating in billing. Customers had learned to rely on them. Removing the link would make the system more elegant and less useful.
The compromise was an adapter service that polled the mainframe in fifteen-minute intervals, translated changes into events and pushed them onto the bus. It was a batch handshake bolted onto a real-time system, an architectural anachronism everyone agreed to tolerate. In diagrams, the adapter was rendered as a small, inoffensive box. In the code, it was more temperamental.
The data science team entered the picture as soon as they saw the word event stream.
They had waited years for a reliable, high-volume feed of shipment data. With it, they promised, they could build models that predicted delivery windows more accurately, flagged likely exceptions earlier and perhaps even suggested routing adjustments. They produced charts showing current ETA accuracy: pessimistic ranges designed to reduce complaints at the cost of delight.
In return for access to the firehose, they offered a predictive ETA service. Given a parcel’s origin, destination, product type, historic performance on similar routes, current hub congestion, weather and perhaps the phase of the moon, it would output a probability distribution over delivery dates.
The trouble, predictably, lay in translation.
The models worked in probabilities and confidence intervals. A parcel might have a 68 percent chance of arriving Thursday, a 24 percent chance of arriving Friday, and a thin tail of possibilities out to Monday. Marketing, product and Customer Care did not want to tell a customer “68 percent chance.” They wanted to say “Expected by Thursday” or “Expected between Thursday and Friday afternoon.”
An argument flared, mutedly, across several meetings. The data scientists insisted on being allowed to express uncertainty; they cared deeply about calibration. The customer-facing factions demanded clear promises. You could almost see the epistemological clash made flesh: the probabilistic sensibility versus the deterministic demand.
Daniel watched the argument with the detached interest of someone who recognised a familiar Stoppardian pattern. In Arcadia, equations describe motion perfectly, but human behaviour refuses to be captured. Here, the models could predict flows, but no one could agree how honestly to present the uncertainty.
Test environments became stages for rehearsed catastrophe. Performance engineers pushed tens of thousands of synthetic events per minute through the system, watching for lag in consumer groups. One afternoon, a senior developer noticed that under heavy load, the event bus lag spiked sharply. After an hour of frantic investigation, they discovered that an innocuous logging library was writing synchronously to disk for every event on one critical path.
The fix was trivial once identified; the identification was not. The incident demonstrated, in miniature, how systems accumulate invisible fragilities. To find them, someone had to imagine that the problem might live in a place everyone else regarded as solved.
As the build hardened, attention shifted to deployment strategy. No one wanted an all-or-nothing cutover. The plan that emerged was a combination of blue-green deployments and canary releases. The new tracking system would be stood up alongside the old. A controllable fraction of traffic—defined by origin-destination pairs or customer segments—would be routed through the new path while the old system continued as a safety net. Feature flags, configuration toggles and routing rules would allow for rapid rollback if things went sideways.
Risk mitigation techniques, Daniel thought, were a kind of corporate equivalent to theatrical previews. You put a version of the show in front of a smaller audience, watch for failures, tweak, and only then dare the full opening. The difference was that in theatre, even a messy preview ended with applause. In distributed systems, the applause took the form of absences: no spikes in error rates, no sudden blizzards of complaints.
Choosing a date for the first canary release became its own little drama. It had to miss the Black Friday peak, regional holidays, a major marketing campaign in Asia-Pacific, scheduled data-centre maintenance and, informally, anything that looked like tempting fate. Eventually, a week in late November was selected, when volume was significant but not overwhelming.
On the evening of the release, London was soaked in a wind-driven rain that made umbrellas performative. Daniel stayed in the office long after he had any operational reason to be there. The actual deployment would follow a rehearsed script; the engineers responsible had done this sort of thing dozens of times. But absence, at such moments, felt like cowardice.
In the project room, four large screens showed different dashboards: CPU and memory for the new services; event bus lag and throughput; synthetic transactions that mimicked customers checking tracking pages; error logs filtered for words like exception and timeout. The glow gave the room the feel of a control tower, although the actual control lay mostly in Bash scripts and Terraform plans written weeks earlier.
At the agreed time, a change request was approved. Traffic for a small set of shipments—certain postcodes in the UK and Germany—was switched to the new engine. For those parcels, the reassuringly banal page that said In transit, Out for delivery, Delivered was now backed by an entirely new set of components.
For a while, nothing happened. Which, of course, was the best possible outcome.
Then the anomalies began, not with a bang but as a series of confused tickets.
The first came not from the pilot region but from New Zealand. A QA engineer there reported bizarre test results: predicted delivery dates falling on days that did not exist, or apparently moving backwards. Investigation revealed a tangle of time-zone assumptions, daylight-saving rules and a reused test dataset. Months earlier, a developer had created a small set of parcels with edge-case dates to test an unrelated reporting feature. Another team, pressed for time, had reused that dataset to test the predictive ETA logic and accidentally pushed some of its configuration into a shared environment.
New Zealand, living perpetually in tomorrow, surfaced the inconsistency.
The bug never affected production traffic; it was isolated and fixed within hours. But its shape was instructive. It showed how seemingly innocuous shortcuts—reusing test fixtures, skimping on documentation—propagate into systemic fragility. The code assumed that calendars behaved nicely. Reality, as usual, did not.
A more serious incident flared in Spain. A cluster of older handheld scanners, still running an ancient firmware version, began sending malformed scan messages that failed the new system’s stricter validation. The old tracking application had quietly corrected these quirks for years without making a fuss. The new ingestion service, designed by people who believed in schemas, rejected them.
From Operations’ point of view, the new system had broken something that wasn’t broken. From the perspective of the architects, the scanners had been violating the contract all along; the fact that the old system forgave them was a historical accident. In a tense call, senior depot managers argued for loosening validation rules; the developers argued for upgrading scanners.
Daniel watched, aware that this was not just a technical debate but a clash of institutional histories. One side believed in explicit contracts; the other believed in things that had worked yesterday.
Issues of this kind cropped up for weeks. A rarely used status code in Italy combined with a specific delivery product to generate nonsense text on the tracking page. A partner in South America misinterpreted a field and began marking shipments as Delivered when they had merely arrived at a regional hub. An internal dashboard rounded times in a way that made on-time performance look half a percentage point worse than it was, provoking outrage in a regional leadership team.
Each problem was contained; each fix was deployed. The team wrote post-incident reviews, drew diagrams, added tests. In aggregate, the incidents taught them something more uncomfortable: the more you illuminate, the more mess you see.
The old system, with its limited transparency, had masked inconsistencies. The new one surfaced them. Now someone had to decide which stories to tell customers.
Priya pushed for as much honesty as possible. If a parcel had been misrouted to the wrong country, why not say so and apologise? Some operations leaders preferred euphemism: “Unexpected delay” sounded less incriminating. Legal fretted about admissions of liability. Marketing wanted to maintain an aura of competence. The tracking page, ostensibly a technical artifact, became a small axis on which reputational risk, ethics and customer psychology turned.
By late February 2027, most regions were on the new system. The cutover was less a single moment and more a series of thresholds crossed in configuration files. One afternoon, almost anticlimactically, the last remaining feed to the old monolith was turned off. A few people in IT marked the occasion by posting a screenshot of its final log line in a chat channel. There was no ceremony; the actor exited without applause.
Externally, Meridian issued a modest announcement about “enhanced tracking visibility” and “more precise delivery estimates.” Internally, a CEO email thanked “everyone involved in this multi-year effort” without listing names. The program code name featured in a bullet point. Daniel’s did not. This was entirely expected. In Stoppard’s plays, the stagehands never get lines.
He allowed himself, that evening, a thin sense of completion. The machine worked well enough. Events flowed, services stayed up, the dashboards sat within acceptable ranges. Customers could now track parcels with a sense that someone, somewhere, understood what was happening.
Of course, that was never the whole story.
Part Three: After the Curtain
By June 2027, the tracking platform had settled into an uneasy normal.
Meridian’s annual leadership summit took place at a conference centre near Heathrow, a choice that signalled both global ambition and a lack of imagination. Through floor-to-ceiling windows, attendees could see aircraft rising and lowering in disciplined arcs, each the visible token of an immense and invisible organisational apparatus. It was as literal a metaphor as any consultant could wish for, which made it slightly embarrassing.
The Global Track Visibility program occupied one section of the agenda, between a session on decarbonisation initiatives and a workshop on “inclusive leadership behaviours.” Daniel spent the morning half-listening to talks about emission targets and coaching models, half-reviewing the slides he would present that afternoon with Priya and the Head of Architecture.
By the numbers, the project looked good.
Customer satisfaction scores related to delivery information had climbed. The dreaded “Where is my parcel?” calls to contact centres had dropped significantly, freeing agents to deal with genuinely complicated situations instead of reading out status messages. The predictive ETA service, now iteratively retrained and tuned, delivered estimates that landed within the promised window in a very high percentage of cases. Large marketplace partners integrating via the new API reported fewer issues and faster onboarding.
Graphs told a gratifying story. One slide showed call volumes before and after rollout, lines diverging neatly. Another displayed a heatmap of event coverage, with glaring white gaps replaced by reassuring tones of completion. A particularly seductive visualisation animated global flows of parcels in near real time, arcs pulsing between cities like network cables.
If you looked only at the slides, you might have believed in the simple narrative: Old system bad, new system good.
Outside the deck, things were more complicated.
Drivers in several countries had begun complaining that customers now behaved differently. When tracking said Out for delivery, people waited by the door, peering through windows, sometimes stepping out to intercept vans. Small deviations from the implied promise—a route re-sequenced because of traffic, a driver taking a short break between stops—led to an immediate spike of anxiety.
Depot staff, meanwhile, found their day reframed by dashboards that counted exceptions, micro-delays and scan quality. Events that had previously been invisible—late departure from a regional hub, an extra dwell in a cage at an airport—were now exposed in reports. Some managers used this data to improve processes. Others used it as a blunt instrument to chastise underperforming depots.
Measurement, once introduced, changes the thing measured. Stoppard returned to this truth in different registers: the way knowledge alters behaviour, the way observation collapses possibility into fact. The new tracking platform, by making parcel journeys legible, had made them available for new kinds of pressure.
The political ripples at senior levels were predictable and no less real for that.
The Chief Customer Officer showcased the uplift in satisfaction metrics as evidence that investing in Digital experiences produced concrete returns. The CIO stressed the reliability and scalability of the new platform, using uptime and latency statistics to argue for the value of disciplined architecture. The COO pointed to operational improvements—reduced repeat deliveries, better route adherence—as proof that data-driven operations worked. Each told a story in which their function’s contribution was pivotal.
In these stories, project management featured only as background scenery. This, Daniel accepted, was part of the role. Project managers existed to create the conditions under which other people could claim success. If you did the job well, it vanished.
More interesting, to him at least, was what the system had done to the company’s sense of itself.
With consistent event data available globally, Meridian could now compare performance across regions with a clarity that had never previously been possible. Dashboards could rank countries by on-time delivery percentage, average transit time for specific lanes, frequency of misroutes, incidence of customs holds. Patterns emerged: certain regions consistently outperforming others, some corridors prone to delay regardless of investment.
Leaders in high-performing regions embraced the dashboards; they wanted more. Leaders whose metrics sat stubbornly near the bottom questioned data integrity. They asked whether the definitions of “on time” and “exception” were fair, whether certain local realities were being ignored. Arguments about operational constraints—road quality, customs bureaucracy, labour market conditions—were reframed as arguments about filters and thresholds.
Priya argued, sometimes publicly and often in smaller conversations, that discomfort was a feature, not a bug. Visibility, she liked to say, was a gift you gave yourself. Only by seeing the full pattern of performance could the company improve.
Operations leaders nodded politely and then, in private, worried that visibility would be weaponised. They imagined weekly reviews in which outlier depots were named and shamed, without any meaningful support to fix the issues. The system, in other words, could become a surveillance tool as easily as a diagnostic one.
External pressures shifted as well.
Real-time tracking raised regulatory questions about data. Some regulators in Europe began to inquire about how location data was handled, especially when it could be tied, even indirectly, to drivers. The company’s official position was that the system tracked parcels and vehicles, not people; that driver identifiers were abstracted away and used only for operational purposes. Lawyers, however, dealt in edge cases. What about small rural routes where a single driver operated in a fixed pattern? What about disciplinary processes that used location histories as evidence?
An incident in a large European city sharpened these concerns. A newspaper investigation into gig-economy labour practices at one of Meridian’s subcontractors used publicly accessible tracking information, combined with doorstep interviews, to reconstruct drivers’ days. The article’s thesis was that algorithmic route optimisation and tight ETAs imposed inhuman demands: too many stops, not enough breaks, penalties for tardiness masked as performance metrics.
The tracking system was not solely responsible for any of this; optimisation had been happening long before APIs exposed delivery windows. But the visibility it provided made patterns legible to outsiders. The article’s screenshots of tracking pages, annotated with journalist commentary, had a damaging clarity.
Meridian responded with careful statements about standards, subcontractor audits, the difference between guidance and compulsion. Internally, the incident forced the company to confront questions that had previously been deferred: What exactly was the system for? To reassure customers? To empower operations? To squeeze more efficiency from the same labour? All of the above? And if so, in what order?
At the leadership summit, none of this nuance made it into the main plenary session.
Daniel’s presentation, shared with Priya and the Head of Architecture, was smooth, controlled, almost bland. He walked the audience through a narrative arc: the legacy problem, the architectural shift to event-driven tracking, the deployment strategy, the post-launch metrics. Priya spoke about customer satisfaction, reduced friction, opportunities for personalisation. The architect described how the platform could support future initiatives: dynamic delivery options, richer post-delivery experiences, new analytics products for large shippers.
Questions from the floor were mostly practical. When would the last few partner integrations be completed? How resilient was the system to a major hub outage? What was the plan for peak season? No one asked whether more knowledge had made the company better in any moral sense.
Later, in a smaller breakout room with managers from Operations and Customer Care, voices were less controlled.
A regional operations head admitted that his depots felt “judged by graphs they don’t fully understand.” A Customer Care manager pointed out that while volumes of simple tracking calls had dropped, the remaining contacts were more emotionally charged—customers who had already stared at a tracking page for days and arrived at the call already angry. Someone from HR mentioned, carefully, that drivers’ unions were beginning to ask about how performance data would be used.
Daniel listened, taking notes. His job was no longer to defend design decisions but to capture feedback for a backlog that would outlive his involvement. The platform was now infrastructure: not something to be launched but something to be maintained, tuned, occasionally patched. He felt oddly ghost-like: central to the system’s history, peripheral to its current operation.
Back at his hotel that evening, he lay on the bed with his conference badge still clipped to his belt and opened the book he had brought almost absently: Stoppard’s The Invention of Love. He reread a passage about the difference between living and remembering, about how experience is messy, contingent, unstructured, and memory insists on ordering it into narrative.
It seemed an embarrassingly obvious analogy, but he allowed himself the thought anyway. Projects are lived in spreadsheets, calls, hastily updated tickets, half-heard objections in rooms with bad acoustics. They are remembered as slide decks with clean arcs: problem, intervention, result. The tracking upgrade would, in a year or two, harden in organisational memory into a bullet point on a timeline: 2027 – New global tracking platform delivers enhanced visibility.
The assessment workshops, the time-zone bugs, the arguments about validation rules versus scanner upgrades, the quiet, stupid shortcuts in test data that nearly leaked into production—those details would decay.
Within a few weeks of the summit, Daniel was formally reassigned. His next project involved integrating sustainability metrics into customer invoices: per-shipment estimates of emissions, options for customers to pay extra for mitigation projects, internal dashboards that would translate operational data into carbon accounting. It would have its own architecture diagrams, its own joint sponsorship tensions, its own rhetorical insistence on inevitability.
In design sessions for the new program, the tracking platform already appeared as a given: a box on diagrams labelled Shipment Telemetry, a source of timestamps and locations that could be fed into emissions models. The events he had worried over for months had become, to the new team, just data: taken for granted, like electricity or running water.
Organisational memory had folded the project into infrastructure.
He did not feel particularly sentimental about this. Sentimentality, in his view, belonged to the audience, not the stagehands. Still, a small, private desire for closure pushed him one evening into a gesture that would have struck anyone else as unremarkable.
He was expecting a parcel at home: a single hardback book, pre-ordered months earlier. A newly published critical biography of Tom Stoppard.
Over breakfast, he opened Meridian’s tracking page on his phone and entered the consignment number. There it was: Created, Collected, Departed facility, Arrived at hub, In transit. The events marched down the screen with the flat assurance of stage directions.
As the day went on, he watched the ETA contract—from “Tomorrow, 9 a.m.–6 p.m.” to “Tomorrow, 11 a.m.–2 p.m.”—in response to flights that landed on time, a clear stretch of motorway, known patterns of driver performance on similar routes. Somewhere, models were recalculating distributions based on histories no human would ever see as more than a chart.
When the doorbell rang in the middle of the predicted window, he felt, absurdly, as if a line had been delivered with just the right timing. A small success of choreography. He signed on the handset, took the parcel, and, purely out of habit, glanced at his phone to see the status flip to Delivered.
It would have been very easy, in that moment, to over-invest the event with meaning. To pretend that the neat concurrence of prediction and reality justified the entire project. He resisted the temptation. He knew too much about the contingencies: about trucks that break down, scanners that fail, drivers who get sick, storms that close airports. A hundred coin tosses could have gone the other way.
The system he had helped shepherd into existence had not tamed chance. It had provided a better vocabulary for describing what chance had done.
Systems, he thought, were like plays in one limited respect: they imposed a frame on chaos. Within that frame, patterns could be seen, causes tentatively linked to effects, stories told. But outside the frame, contingency still ruled.
The tracking upgrade had not made Meridian more moral or the world more ordered. It had made certain parts of the company’s operations more visible, certain decisions more accountable, certain conversations harder to avoid. It had given customers a more accurate picture of where their parcels were and when they might arrive.
In a world as random and uninterested as this one, that seemed, in its modest way, enough.
