When Two Cross-Format Systems Compete: Resolving Workflow Conflicts at the Structural Level

You have a PDF-initial editorial pipeline and a CMS that loves Markdown. Or a data staff exporting CSV while your pattern framework lives in JSON. Two systems, two formats, one workflow that should just work—but it doesn't. The friction is real. I have seen units spend months building connectors that break the moment someone updates a schema on either side. This article is not a magic fix. It is a bench guide to understanding the structural conflicts when cross-format systems compete, and how to resolve them without losing your sanity.

Where Format Wars Actually Happen

An experienced operator says the trade-off is speed now versus rework later — most shops lose on rework.

Publishing pipelines: PDF vs. HTML vs. ePub

The worst format fight I ever watched happened in a mid-sized textbook publisher—two units, same company, same deadline. The editorial group produced everything in InDesign, exporting locked PDFs with meticulous page breaks. The digital staff needed clean, reflowable HTML and ePub for web and app delivery. Every export from InDesign introduced phantom breaks, broken cross-references, and images that refused to float. Someone would open the file, sigh, and manually rebuild the chapter from scratch. That’s where friction lives—not in format specs, but in the gap between how content is authored and how it’s consumed.

The PDF is a photograph of a page. The ePub is a liquid layout. They share no structural DNA.

Most units skip this: the real conflict isn’t technical—it’s what each format demands from the creator. The PDF author thinks in spreads and margins. The HTML author thinks in semantic tags and responsive breakpoints. When you force one person to produce both, the output bleeds. Tables collapse, footnotes vanish, and the editorial review cycle doubles. I’ve seen a assembly manager literally print out an HTML version, scribble corrections with a red pen, and hand it back to a developer who had to guess intent.

The odd part is—nobody owns the decision. The format war is really a workflow war wearing a file extension.

Data exchange: CSV vs. JSON vs. Parquet

Ask any analytics staff what format they prefer for data exchange, and they’ll give you a confident answer—then immediately qualify it with, “but it depends on who’s consuming it.” That’s the tell, according to a data engineer I interviewed. CSV is universal, human-readable, and utterly treacherous. Strings containing commas break the schema. Date formats shift between regional settings. One analyst exports a CSV with semicolons as delimiters because Excel did it automatically, and the pipeline silently eats four thousand rows.

JSON fixes the comma problem but introduces nesting chaos. Parquet is fast, but unreadable in Notepad.

The friction point surfaces during handoff: a data engineer generates a Parquet file that loads in three seconds flat. The business analyst can’t open it in Excel. They ask for CSV. The engineer converts it, losing column type metadata. The analyst re-types dates. What usually breaks initial is trust—everybody blames the format, but the real problem is the mismatch between tooling expectations. I fixed this once by inserting a small, ugly middleware step that logged every row count before and after conversion. The numbers told the story: no format survives an unspoken schema.

concept handoff: Sketch vs. Figma vs. code

flawed order. You don’t pick a pattern instrument—you inherit the group that picked it two years ago. One designer exports layered Sketch files; another sends Figma links with auto-layout; a third drops a screenshot into Slack and says, “make it look like this.” The developer opens each asset, finds missing spacing tokens, and hand-codes the layout from memory. That hurts.

“The concept handoff is an act of translation, not delivery. And translation always introduces loss.”

— Front-end lead, after rebuilding a checkout flow three times

Figma’s auto-layout creates predictable box models—if you inspect the API, you can extract CSS almost directly. Sketch files require manual layer flattening. The trade-off is speed versus structure. Units that skip the alignment step end up with a assembly site that looks “close” but breaks on hover states, font scaling, or the third breakpoint. The catch is that nobody budgets slot for handoff reconciliation. It’s treated as overhead, not engineering.

API payloads: XML vs. JSON vs. Protobuf

The sneakiest format war happens between services that never share a repo. A legacy payment gateway returns XML with attributes in namespaces. The new microservice expects JSON with snake_case keys. The integration middleware expands both into a canonical model, but every payload transformation adds latency and surface area for bugs. I watched a startup spend six weeks debugging a one-off Protobuf schema mismatch—floor numbers had shifted between releases, and the receiver silently dropped the flawed bytes.

What most people get flawed: they treat format choice as permanent. It never is.

JSON wins on readability; Protobuf wins on wire speed. But the conflict emerges when two systems built three years apart try to talk. The older one sends XML with a DTD nobody remembers. The newer one expects gRPC. Both units claim their format is “standard.” The resolution isn’t to pick one—it’s to admit that the abstraction layer between them is where the real spend lives. Measure the slot spent debugging payload mismatches. That number is your format-war tax.

What Most People Get off About Format Compatibility

Assuming Semantic Equivalence Between Formats

The most common mistake I see is treating two formats as if they mean the same thing. A JSON field called price and an XML attribute called costValue — units map them one-to-one and declare victory. That sounds fine until you discover the JSON side expects pre-tax integers and the XML side ships post-tax decimals with three trailing zeros. The values serialize identically in a trial harness. In output, the seam blows out on the initial order with a coupon. The assumption of semantic equivalence hides the real work: defining what the data means, not just how it looks on the wire.

flawed order. Units reach for a format converter before they align domain models. I have watched two engineering groups spend six weeks building a JSON-to-XML transformer, only to find that one side considered 'null' a valid deletion signal and the other treated it as 'no change'. That was a Tuesday morning discovery. Wednesday they rewrote the mapping anyway.

Confusing Serialization with True Transformation

Serialization is the easy part — bytes to bytes, a pipe you run after dinner. Transformation requires understanding state: what gets lost when a nested object flattens into a CSV row? Most tools handle the structural shift but drop the rules. A CSV export from your CMS strips the lastModified timestamp because the target framework 'doesn't use it'. Three months later, auditors ask why records show a created date that predates the import. Nobody billed for that forensic deep-dive.

The odd part is — engineers know this. They still approve the mapping because the POC passes. Then the maintenance rot sets in.

“We have a JSON schema and a SQL view. They look the same in the check environment. In staging, the view returns strings for numeric columns. Nobody caught it because the consumer silently coerces them.”

— Data engineer, post-mortem for a failed batch pipeline

Overlooking Metadata and Implicit Context Loss

Metadata is the opening thing dropped when two systems compete. The source format carries encoding hints, validation provenance, and a last-updated chain. The target format accepts a flat payload and discards everything outside the defined envelope. What breaks initial is not the data — it is the ability to prove the data is correct. A CSV file loses character encoding flags. An API call drops the X-Request-Id that correlates back to the original transaction. Units revert to manual checks. That is the moment the brittle workflow solidifies.

I have seen this pattern repeat across three companies. The fix is never a smarter serializer. The fix is admitting that some context must survive the boundary — and that requires a contract, not just a format.

The catch: contracts overhead slot to negotiate. So units skip it. That hurts.

Patterns That Actually Survive assembly

According to internal training notes, beginners fail when they optimize for shortcuts before they fix the baseline.

Canonical intermediate representation (CIR)

The units that survive format divergence have one thing in common: they stop trying to make framework A speak framework B natively. I watched a pattern-to-code pipeline collapse because Figma tokens were being translated directly into CSS custom properties — every Figma update broke the mapping. CIR — an intermediate schema that both sides map into rather than mapping between — breaks that coupling. You lose the illusion of real-slot fidelity. You gain a stable middle layer that absorbs version drift on both ends. The catch is discipline: someone has to maintain that CIR as a living contract, not a snapshot. Most units skip this.

flawed order.

They build the CIR after the initial assembly blow-up, rewriting mappers under deadline pressure. By then the schema is shaped by whatever broke last, not by what survives. A well-designed CIR is boring — flat fields, nullable slots for format-specific quirks, and a hard rule against polymorphic types. The excitement comes later, when the upstream format swaps XML for JSON and your pipeline barely flinches.

That said, a CIR won't save you from semantic misalignment. One staff I worked with stored 'price' as a decimal string in their CIR; the downstream framework interpreted it as a currency code. Three days of debugging. The schema was technically compatible. The meaning wasn't.

Schema-opening negotiation

Most output battles aren't about format parsing — they're about implicit assumptions baked into field order, optionality, and null behavior. Schema-opening negotiation means both systems expose a machine-readable contract before any payload moves. Not a Markdown spec. Not a verbal agreement from the sync meeting. A real schema that either side can validate against at integration slot.

The pattern works because it surfaces mismatches early — before they embed into cached transforms or cron jobs. You send a payload, the receiver compares it against the published schema, and the error message tells you exactly which field violates what constraint. No “we think it works” handshake. The trade-off? Schema negotiation adds a handshake round-trip that latency-sensitive systems can't stomach. For real-slot audio or frame-by-frame video, the overhead blows the budget. For everything else — config files, metadata pipelines, export sequences — it's a cheap guardrail.

What usually breaks primary is the optional field that became required in v2 of the producer but never got flagged. Schema negotiation catches that. The producer's CI pipeline rejects the build. The fix happens before the PR merges. That is production survival.

We stopped debugging format mismatches when we started reading the schema before the payload. The error messages got boring. That was the goal.

— Principle adopted at a media-asset exchange I observed

Idempotent transformation chains

Here's a trial: run your conversion pipeline twice on the same input. If the output changes — metadata appended, format strings slightly shifted, order mutated — you have a rot problem. Idempotent transformation chains guarantee that applying the same transform sequence again produces identical output. Not just visually identical. Byte-identical.

This matters because production pipelines retry. They reprocess. They fan out to workers that may or may not have intermediate state. Without idempotency, every retry risks drift: a timestamp inserted differently, a casing normalization skipped. I have seen an export pipeline produce 17 subtly different output files from the same input batch, simply because retries landed on differently configured nodes. The fix was forcing every transform to hash its source and check it against the previous run's output hash. If the hash matches, skip. If it doesn't, re-transform from scratch — but never mutate in place.

The downside: idempotent chains are verbose. You track more state. You benchmark against a hash comparison that feels wasteful for small payloads. But for any pipeline that runs unattended — scheduled exports, nightly batch jobs, CI/CD artifact generation — the verbosity buys exactly one thing: trust. You can look at the output and know, without diffing a thousand lines, that nothing drifted.

Try this tonight: pick one format conversion in your active pipeline. Make it idempotent. Add a hash check. Measure the retry rate before and after. The numbers will either confirm you're over-engineering — or reveal the rot you've been ignoring.

Why Units Revert to Copy-Paste and Excel Hacks

The Seduction of One-Off Scripts

I have watched smart units write a Python script to “just fix the alignment once.” It runs beautifully. Three columns merged, headers renamed, trailing spaces stripped. Everyone high-fives. The catch? That script lives on one developer’s laptop. Nobody commits it. Six weeks later, the same mismatch appears in a different data set, and the original author is on holiday. So somebody rebuilds it—slower, wronger, and with no error handling. The script itself becomes the process, not a instrument for the process. That is not automation. That is an expensive habit wearing a trench coat.

One-off scripts feel like freedom. But they are isolation masquerading as efficiency. The next person who inherits the workflow has no context, no test data, no idea which flags produce the correct output. They run it blind. It fails halfway. They patch the failure manually. Within three cycles, the “script” is really a ritual: run this, check that, fix these cells by hand, rerun, pray.

“We wrote a converter in an afternoon. Two years later, it still runs every Monday—and nobody knows why it works.”

— Senior engineer, mid-size publishing operation

Manual Normalization as a Trap

Most units revert to copy-paste because it feels faster than teaching the framework to cooperate. You have two CSV exports that label the same customer field differently: one calls it client_id, the other CustomerNumber. Technically, a mapping table would solve this. But nobody has slot to write the mapping, test it, deploy it, and update documentation. So you copy three thousand rows into a shared spreadsheet, correct the headers by hand, and paste the result into the pipeline. Fine. It works. For now.

The tricky bit is that manual normalization builds muscle memory. The staff learns to trust the spreadsheet as the source of truth. They develop rituals: “Always sort column B before pasting.” “Never trust the date format from Finance.” These are not processes. They are grief strategies. And they hide the real problem—the upstream framework that keeps sending misaligned headers—because the downstream group has already built a coping mechanism.

flawed order. That hurts. The coping mechanism becomes the concept.

What usually breaks initial is the edge case nobody scripts for: a new region appends three extra columns. The paste shifts right. Data lands in the flawed cells. Nobody notices until the weekly report prints negative inventory values. Then the late-night triage begins—and the staff blames “the format,” not the manual step that filtered out the structural mismatch.

When ‘Just Fix It in Post’ Becomes the Only Process

This is the most seductive anti-pattern of all. A designer says, “The export looks fine to me—just reorder the columns in Tableau.” A developer says, “I can trim those extra spaces in the ETL script, no big deal.” Every fix is small. Every fix is reasonable. But the accumulation of post-hoc patches creates a hidden layer of transformation logic that exists in nobody’s codebase. It lives in bookmarks. In comments on shared screenshots. In the memory of the person who quit last quarter.

Soon the question shifts from “How do we align these two formats at the structural level?” to “Who knows the current workaround for the invoice mismatch?” That is a devolution. The framework never learns. It never stabilizes. Each output is a fresh negotiation between the data and the person who happens to touch it last. And when that person is out sick—yes, returns spike.

I fixed a version of this once by forcing a 45-minute meeting where the two units agreed on a lone header convention. That was it. No new aid. No automation. Just a shared vocabulary. The copy-paste hacks died the following week. What you can try tonight: find the one manual fix your staff repeats every cycle. Write down exactly what you change. Then ask why the framework cannot do that change for you. The answer is rarely technical. It is almost always that nobody stopped to name the difference.

The Slow Rot: Maintenance Costs Nobody Bills For

Schema Drift on Both Sides

You build a pipeline. Both systems match — fields line up, types cast cleanly, everyone high-fives. Six months later the transforms quietly fail. One group added a region_code field; the other renamed territory_id to geo_zone. Nothing broke loudly. Reports just started printing nulls in column twelve. The odd part is — nobody remembers approving either change. Schema drift is never malicious. It’s just two units, two roadmaps, zero shared vocabulary. That silence costs roughly three developer-days per field collision, amortized across Slack threads, rollback panic, and the midnight post-mortem.

Multiply by fifteen fields. You do the math.

Hidden Dependencies in Transformation Layers

Every ETL script becomes a slot bomb. I have seen a twelve-line Python transform — written by someone who left nine months ago — become the sole bridge between a CRM export and a billing dashboard. No tests. No contract. Just a brittle chain of str.replace() calls. When the CRM vendor changed date formatting, the seam blew out. Not in staging. No alert fired. The CEO’s Monday morning revenue report showed negative sales. That was, strictly speaking, impossible. The staff spent three days tracing the failure, and eight hours of that was just decoding the original author’s variable naming. (They named the field tmp in production. Why. Why.)

Most units skip this: transformation code is the place format wars never officially end — they just go underground.

“We didn’t realize the two systems had grown incompatible until the quarterly close showed a half-million dollar discrepancy. Turned out we were mapping ‘net’ to ‘gross’ for eighteen months.”

— Finance Ops lead, after a cross-format reconciliation audit

Staff Churn and Undocumented Workarounds

The real rot is human. When the engineer who built the bridge leaves, the knowledge leaves with them. New hires inherit a black box that works — until it doesn’t. Then they patch it. Then they leave. Each patch adds one more conditional, one more fallback, one more “hotfix that should be temporary.” I have walked into units where the integration layer contained seven nested if environment != prod: blocks, each one a memorial to a specific format mismatch nobody dared refactor.

That hurts.

Morale drains fastest not from hard work but from pointless hard work. units burn out re-solving the same incompatibility every sprint because the structural fix felt too expensive. Department heads rarely see this line item on a budget sheet. It does not appear in Jira stories. But it shows up in churn statistics, in pull requests that sit for ten days, in the Slack channel where engineers commiserate about “the format monster” instead of building product.

What usually breaks opening is trust. Once units stop believing the integration will hold, they start duplicating data in spreadsheets, running manual cross-checks, and treating the pipeline as an advisory framework rather than a source of truth. That overhead — the mental double-entry bookkeeping — is the maintenance expense nobody bills for. But it amortizes across every meeting, every report refresh, every anxious midnight refresh of the dashboard.

The fix? Start tracking integration failure slot the way you track incident response slot. Measure the gap between “it broke” and “we knew.” Then decide whether the structural pain is cheaper than the structural fix. Usually it is not — but you cannot prove that until you count the hours. Count them tonight.

When the Best Fix Is to Keep Systems Separate

Low cross-frequency: rare data exchange

If your two systems talk once a quarter or after every major release, merging them is cargo-cult engineering. I have seen units weld together a pattern aid and a production database because “everything should be connected.” Then the connector sat unused for eleven months — except it still consumed maintenance. Every platform update broke the bridge. Every security patch required retesting. The seam cost more than the data it carried. That sounds fine until you realize the integration consumed forty percent of the staff’s integration budget for a pipe used twice a year. A manual handoff — even a clunky CSV export — would have been cheaper in phase, money, and cognitive overhead.

The catch is obvious once you examine the transaction log. Low-frequency exchanges do not justify shared schema. Keep an offline sync script. Keep a human approval step. Automation for rare events is a trap dressed as progress.

High format instability: both sides still evolving

Neither framework has settled its internal structure yet. One group is rewriting its data model monthly. The other is chasing a new vendor contract with unknown output specs. Trying to align them is welding girders onto a moving train. I have watched this destroy a promising pipeline: every sprint brought three schema changes, each requiring a connector rebuild, and the integration staff spent more phase on version negotiation than on actual work. The systems diverged faster than the bridge could adapt.

What breaks opening is the error handling — the null fields, the renamed parameters, the dropped endpoints. Then trust erodes. People stop believing the data in either framework. And that is the real loss: not the broken connector but the degraded confidence in both tools. When both sides are unstable, alignment multiplies instability. The smarter play is to keep a buffer zone — a staging area where each stack writes its latest output, and consumers read with version-tolerant parsers. Not a merge. A loose dock.

Organizational silos that resist alignment

The trickiest condition is human. The layout staff owns setup A. Operations owns setup B. Neither group trusts the other’s priorities. Merging workflows forces joint ownership of a shared liability — and nobody signs up for that. I have seen a solid architecture fail because the two leads refused to share incident rotation. The connector became a blame magnet: “Your side changed the spec” vs. “Your side dropped the packet.” The integration rotted not from technical debt but from political friction.

The odd part is — separation can be the healthier move. Each group keeps its own data model, its own release cadence, its own bug tracker. Cross-setup flows happen through a thin, agreed-upon contract that either side can reject. The cost is some duplication. The benefit is autonomy. And autonomy, in a siloed org, prevents the integration from becoming a hostage.

“We kept our workflows separate because merging would have forced a truce we didn't have phase to broker.”

— Engineering lead, after retiring a year-long integration project in six weeks

So when do you keep them apart? When the exchange is rare enough that manual steps cost less than automation. When the internal schemas are still moving targets. When the teams won’t (or can’t) share ownership. In those cases, merging is not a technical problem — it is a self-inflicted wound. Separate systems, paired with a clear handoff protocol, run faster and break less. Try the separation experiment tonight: disconnect the connector for two weeks. See what breaks. If nothing does, you had your answer all along.

Open Questions You Will Face on Monday Morning

Who owns the canonical schema?

Monday morning arrives, and two teams point at each other. The concept stack staff insists Figma is source of truth. The frontend crew swears by TypeScript types checked into GitHub. Neither is faulty, exactly—but the seam between them bleeds every solo sprint. I have watched a mid-size product lose three days because a designer renamed a padding token from spacing-md to spacing-4 in a Figma branch that nobody merged. The developer caught it during QA. The fix? Find-and-replace across forty components. Then repeat next month.

The hard truth: no solo aid wins ownership. What works is a cold, explicit agreement about what the schema touches. If a token changes, who must approve the downstream definition? Most teams skip this and instead build a microservice that syncs both directions. That works until one side pushes a breaking change at 4:57 PM on a Friday. The odd part is—the sync service itself becomes the schema, and nobody audits it. You end up debugging a YAML pipeline instead of shipping a button.

Pick one directional flow. Figma → code. Or code → Figma. Bidirectional ownership is a myth that burns budget.

— Senior frontend architect, after his crew’s third rollback

How often should we re-sync?

Every hour sounds safe. Every minute sounds better. But sync frequency is a trap—the question hides a deeper problem: what happens when the sync fails? I have seen teams set a cron job at 5-minute intervals, only to discover that a misnamed layer in a Sketch file cascaded into 1,200 broken CSS variables. The sync ran fine. The data was wrong.

The real trade-off is between staleness and noise. Sync every push and your designers learn to hate the constant merge conflicts. Sync nightly and your developers ship last week’s concept spec. The pragmatic answer I’ve seen survive production: trigger re-sync on explicit version increments, not on every keystroke. Let designers draft in private, then stamp a version. That cuts the noise by 70% and still catches true drift within a day. The catch is—you need a human to say “this is the one.” That discipline rarely survives a tight deadline.

Don’t automate what you don’t understand. Manual stamps hurt less than automated chaos.

• Version-stamped sync: cleaner diff, slower feedback
• Continuous sync: immediate collision, higher burn rate
• No sync: you are running two products

What do we test when formats change?

Visual regression tests catch color shifts. Snapshot tests catch DOM structure changes. But what catches the moment a dimension token gets rounded to an integer when it should be a float? Nothing off the shelf. That gap costs real money. I once watched a crew ship a misaligned card grid because the layout system exported margin: 12px instead of margin: 12.5px. The visual diff fixture passed—both looked identical at 100% zoom on a Retina screen. On a 1080p monitor, the fifth card broke to the next row. A quiet bug, the kind that rots trust.

So what do you test? Test the boundary, not the pixel. If a token value lives in a range (say, 8 to 24), verify that the out-of-range path behaves predictably. Most teams test happy paths. The structural conflict hides at the edges—a 0px gap, an overflow, a missing fallback. Write one test per token type that asserts the unit isn’t lost. That catches the float-to-int truncation. It’s a twenty-line script. Nobody writes it. You will, after the fourth incident.

Not yet convinced? Ask your QA lead if they have a test for “integer coercion during export.” The silence will tell you everything.

Is there a ‘good enough’ level of fidelity?

Yes. And it’s lower than you think. Here is the pitfall: teams chase perfect parity between a design file and a browser render, then spend 40% of their sprint on near-zero-value adjustments like shadow blur radius mismatches of 0.3px. That is not flow—that is friction theater. The question is not can we match exactly, but what breaks the user’s mental model?

Good enough means: spatial relationships hold, spacing scales consistently, typography hierarchy survives a zoom change, and interactive states map correctly. Everything else—antialiasing differences, sub-pixel rendering quirks, font rendering engine variance—is production noise you cannot eliminate. I have seen a product manager demand pixel-perfect alignment between Zeplin and Chrome on a Windows machine. That request alone cost two weeks of engineering slot. The button looked identical to users. The crew just couldn’t prove it in a screenshot.

Define your fidelity threshold before Monday’s standup. Write it down. Accept that Figma’s canvas applies 0.5px stroke rendering differently than Safari’s compositor. That variance is not a bug—it’s the cost of running two systems. The moment you stop fighting it, you free energy for the cracks that actually matter: missing states, broken interactions, and format corruption that silently rewrites your layout.

Pick your battles. Lose the shadow wars.

What You Can Try Tonight (and What to Measure)

Run a format conflict audit on one workflow

Pick the lone workflow that hurts most. The one where someone inevitably mutters “I’ll just rebuild it in a new file” every two weeks. That’s your candidate. Map every format handoff—from the primary input file to the final deliverable. List the aid, the export preset, the manual override, the copy-paste. One crew I worked with found seven hidden conversions between a designer’s Figma frame and the production PDF. Seven. They’d been blaming “bad software.” The real problem was a chain of undocumented defaults. The fix cost nothing—just a shared note saying “export with PNG, not JPG, then import as CMYK.” That one-off change cut rework by 40%.

The catch: you cannot audit everything at once. Most teams skip this step entirely—they buy a new instrument instead. That’s expensive hope, not diagnosis.

Map the transformation chain end to end

Draw the chain on a whiteboard. Every node where format A becomes format B. Every human decision point. Every “I just tweak it in Illustrator” exception. You are looking for seams that are invisible to the people who touch them daily. The odd part is—the same seam that works fine for one asset breaks catastrophically for another. A PDF/X-1a that sails through prepress might choke a web renderer. Same file, different rules.

What usually breaks first is the metadata. Headers that describe a 300 DPI image get dropped during a “quick” convert to PNG. Nobody notices until the print shop calls. Measure the number of re-export cycles per asset. If that count exceeds three, your chain is hiding a structural mismatch. Flag it.

“We spent three hours arguing about PDF versions. Then we looked at what actually happened to the file. It had been flattened and re-saved four times before we touched it.”

— Technical lead, brand production crew

Decide on a solo source of truth—or accept none

Here is the trade-off most articles skip: a one-off source of truth solves some problems and creates others. It forces everyone into one format, one tool, one timeline. That works when the group is small and the output is fixed. But in cross-format systems, a rigid source of truth often breaks the creative loop. I have seen teams adopt a “master PSD” rule—only to have illustrators rebel and export SVGs from their own tools anyway. The rule became a fiction. Maintenance rot followed.

The alternative is honest: declare that no single format can serve all downstream uses. Accept two sources. Or three. Then enforce translation boundaries—explicit gateways where format conversion happens, with validation rules at each step. Measure the phase between format conversions. If that time falls below one minute, you are hiding an automated but brittle handoff. If it exceeds a day, you are stockpiling stale artifacts. Both hurt.

Try this tonight: kill the file named final_final_v3.ai. Replace it with a short readme that says “source of truth is the .indd on the server; everything else is a derivative.” Watch what breaks. That breakage is your next improvement.