The contract that changes everything is almost signed.
Every department says yes. Every department means no.

The CEO stands in the conference room holding a folder.

"If we land this account," he says,
"we run at 80% capacity for three years.
Stable revenue. Everyone keeps their job."

The room nods.

Oran counts the nods.
Twelve people. Twelve nods.

He writes in his notebook: zero commitments.

The customer is large. The kind of large that has its own supplier requirements document — forty-seven pages, updated quarterly, with a compliance checklist at the end that takes two people a week to fill out.

Page 31, Section 4.2:
All production data must be stored in a centralized, auditable system. Traceability from raw material intake to finished goods shipment is required. Excel-based record-keeping is not acceptable for Tier 1 suppliers.

The CEO reads this paragraph out loud.
Then he closes the document.

"All data goes into a shared system," he says. "Oran will build it."

The room nods again.

The meeting ends at 11am.

By noon:

• QA has locked their defect log in the filing cabinet.
• Engineering has added a password to their process parameters folder. The password is the VP's dog's name. Nobody else knows this yet.
• Manufacturing's shift supervisor has started CC'ing nobody on the daily output report.

By 3pm, Oran sends an email to all three departments:
Please share your current data files so I can assess the migration scope.

By 5pm, he has received:

• One reply from QA: "I already sent it to you last week."
• No reply from Engineering.
• One reply from Manufacturing: "Which data do you mean specifically?"

Oran checks his inbox. Nothing from QA last week.
He checks his spam. Nothing.
He replies to Manufacturing with a list of seven specific data types.
Manufacturing replies: "Let me check with my team."

That was Tuesday.
It is now Friday.

Here is what Oran understands, sitting at his desk at 6pm with an empty inbox:

Data hoarding is not laziness.
It's not incompetence.
It's rational.

Think about it from the VP of Manufacturing's perspective:

If Manufacturing's output numbers are the only output numbers, then when something goes wrong on the line, Manufacturing gets to define what went wrong. They control the investigation. They control the conclusion.

If the numbers go into a shared system, QA can query them. Engineering can query them. The CEO can query them. Manufacturing becomes readable instead of narrated.

That's terrifying if your department has anything to hide.
Even more terrifying if it doesn't — because then everyone else can see that too,
and use it to argue their own case.

Information asymmetry is job security.

Every Excel file in every drawer is a locked door.
Oran is being asked to remove all the doors.
Nobody wants that. Not really.

That weekend, Oran writes the first real schema draft.

Not the final one. Not even close.
But the first honest attempt to answer the question:
What data do we actually need, and who owns each piece of it?

CREATE TABLE production_batches (
  batch_id        VARCHAR(50) PRIMARY KEY,
  product_code    VARCHAR(50),
  start_time      DATETIME,
  end_time        DATETIME,
  shift           VARCHAR(20),
  line_id         VARCHAR(20)
);

CREATE TABLE inspection_results (
  result_id       BIGINT PRIMARY KEY,
  batch_id        VARCHAR(50) REFERENCES production_batches(batch_id),
  inspected_at    DATETIME,
  inspector_id    VARCHAR(50),
  defect_type     VARCHAR(100),  -- whose definition?
  defect_count    INT,
  outcome         VARCHAR(20)    -- pass / fail / conditional
);

He looks at defect_type VARCHAR(100) for a long time.

Then he adds a comment:

-- TODO: who decides what goes in this field?
-- QA: scratches are defects
-- Engineering: scratches are cosmetic unless functional
-- Manufacturing: scratches don't exist unless the customer notices them
-- Need one definition. Agreed in writing. Before we build anything.

He doesn't know it yet,
but that comment will take six weeks and three meetings to resolve.

Monday morning.

Oran arrives early. He prints two copies of the schema draft.
He puts one on the VP of QA's desk.
He puts one on the VP of Engineering's desk.

He slides a third copy under the VP of Manufacturing's door,
because the VP of Manufacturing is already in a meeting
that started at 7am
and will apparently last until noon.

Then he goes back to his desk and writes an email to the CEO:

The technical build is straightforward. The prerequisite is data governance — a written agreement on definitions, ownership, and submission timelines, signed by each department head. Without this, I can build the database, but I cannot guarantee the data inside it will be correct.

I'd like thirty minutes on the agenda for next week's leadership meeting.

He sends it before he can change his mind.

The company was about to get its biggest customer.
The data was in twelve drawers,
four password-protected folders,
and one Excel file that only opened on Linda's laptop.
Linda was on maternity leave.

The database didn't care.
It was waiting.

Next: Ep3 — The Auditor Arrives
She doesn't look at the machines.
She looks at the filing cabinets.

← Ep1: The Excel Republic

Coding Cat Oran is a serialized fiction about building real systems inside real companies.
The politics are real. The cat is fictional. The filing cabinets are very, very real.

By SysLayer · dev.to/syslayer