Daniel's been staring at IKEA's website again and wondering why the machine-readable version of it doesn't exist.
Which is a fair thing to wonder. He's asking whether there's a catalog API out there that does three things. Give you availability for a specific part number. Tell you when that part's been discontinued. And then point you at the official replacement. So a purchasing manager could flag a bin in their internal database, query IKEA, and get back, this bin is gone, buy this other bin instead.
And his real question underneath that is whether this exists anywhere already, and whether it could filter down to the mid-market. Grainger, ULINE, IKEA itself.
The short answer is that the standard for exactly this has existed for years. And the plumbing to actually query it doesn't.
That's the whole episode, really.
That is the whole episode. But there's a lot of interesting wreckage in between. Let me start with IKEA specifically, because that's the example Daniel used, and the situation there is stranger than you'd expect.
Stranger how?
IKEA does not publish an official developer API. No developer portal, no public docs, nothing. But the data is all there on their website. So the entire machine-readable IKEA catalog is community reverse-engineering. There's a project called ikea-openapi that documents four separate IKEA APIs. A search API, a product catalog API, a sales item API, and a spare parts ordering API.
Somebody sat there and mapped out IKEA's internal endpoints from watching network traffic.
And they run daily contract tests against the live endpoints to catch it when IKEA changes something. Which is the part that should make any purchasing manager nervous. The foundation for your automated replenishment system is a GitHub project maintained by somebody who reverse-engineered a furniture company's website.
So what does the sales item API actually return?
That's the closest thing to what Daniel's describing. You send it a list of item numbers, and it comes back with availability per store. Whether it's available for cash and carry, whether it's available for click and collect, which aisle and bin it's in. Real, useful, operational data.
And if you send it a discontinued item number?
It returns a structured error. Code four oh four, not found. That's it.
So the machine says, this doesn't exist anymore, and stops talking.
Right. The replacement knowledge lives in IKEA's customer service knowledge base, in prose. Human-readable articles that say things like, the TRÅDFRI remote was discontinued in autumn twenty twenty-one and replaced by RODRET and STYRBAR. Which were then discontinued in January of this year and replaced by BILRESA.
Three generations of smart remote, and the only place that lineage exists is a support article.
And IKEA does this constantly. GODMORGON bathroom furniture, sold until twenty twenty-four, replaced by three different families. HAVBÄCK, ÄNGSJÖN, TÄNNFORSEN. ALGOT shelving replaced by JONAXEL and BOAXEL. And here's the detail that matters for Daniel's use case. The ALGOT replacement note explicitly says, these are not compatible and cannot be used to expand existing ALGOT solutions.
So even if the API returned a replacement field, it would be wrong in a way that matters.
If you have a bill of materials with ALGOT components, and the system tells you the replacement is BOAXEL, and you just swap the part number, you've corrupted your BOM. The new part doesn't fit the old system. A naive replacement flag is actively dangerous.
So what Daniel's actually asking for is a replacement type. Permanent successor versus temporary substitute versus not actually compatible.
Which is precisely why the formal standard has a type code. This is where it gets interesting. GS1, the organization that runs barcodes, has had this solved for years.
GS1 as in the people who issue GTINs.
The same. Their Global Data Model defines two attributes. Referenced GTIN Type Code, and Referenced GTIN. The type code indicates the relationship. Substituted, replaced, that kind of thing. The referenced GTIN is the product that replaces the current one. And their own documentation says this helps identify replacement products in cases of temporary inventory outages or when transitioning to a new or enhanced product.
That is exactly Daniel's scenario, down to the temporary outage case.
And their web vocabulary has a property called replacedByProduct. The product which permanently replaces the current product. This product is sent in the record for the original item that is being replaced. That's the exact semantic Daniel wants. It exists. It's standardized. It's documented.
So where does it live?
It lives in GDSN. The Global Data Synchronisation Network. Which GS1 describes as the world's largest product data network. And the key word there is synchronization. It's a batch master data network. Suppliers push product data into data pools, and trading partners pull it down. It's built for retail and consumer packaged goods. Grocery chains, not a purchasing manager buying IKEA bins.
So the standard is a freight train, and Daniel wants a taxi.
GDSN is heavyweight. You join a data pool, you map your attributes, you synchronize your entire catalog on a schedule. There's no lightweight endpoint where you send a part number and get back availability plus replacement. The concept is standardized. The primitive doesn't exist.
And IKEA is not a GDSN participant anyway.
Almost certainly not for consumer furniture. They're a retailer, not a CPG supplier to grocery chains. So even the heavyweight path doesn't apply to Daniel's example.
What about Grainger and ULINE? He asked about those specifically.
This is where it gets almost comical. Grainger and ULINE do expose their catalogs to procurement systems. But not through an API. Through something called PunchOut.
Which is what it sounds like.
It's worse than it sounds. PunchOut is a standard where the buyer's procurement system launches the supplier's website inside a session. The user is literally browsing Grainger's website, but inside their own procurement tool. When they're done, the cart gets transferred back as a purchase order.
So the system Daniel wants to eliminate, manually checking the website, is the system they built.
They took the manual website check and wrapped it in a session. It's the anti-pattern. The cXML user guide describes it as an alternative to static catalog files. Live, interactive catalogs running on your website. It's not a queryable API. It's a website wearing a procurement trench coat.
And the alternative is EDI.
Right. Grainger runs electronic data interchange, ANSI X12 four oh one, for purchase orders. That's batch document exchange. You send a purchase order, you get an invoice. It's not a catalog query. It's not availability. It's not replacement semantics.
So the two mechanisms available are a website inside a website, and fax machines with extra steps.
And then there's the third layer. Unofficial scrapers. There are commercial services that scrape Grainger and ULINE and sell the data back as an API. Parse has a ULINE API that claims live stock status for any model number. A Grainger one that covers millions of SKUs. But these are scrapers. They break when the website changes. They're not vendor-sanctioned.
So the entire landscape is three options. A batch standard that doesn't apply. A session-based website wrapper. And scraping.
Which is why Daniel's question is actually quite sharp. He's identified a real gap. The capability he wants is obvious, useful, and standardized in principle. It just doesn't exist as a lightweight queryable primitive anywhere in the mid-market.
So why hasn't anyone built it?
I think there are a few reasons. The first is that the vendors don't want to commit to replacement semantics. IKEA's replacement articles are full of caveats. Not compatible. Only in certain markets. Some parts still available. The moment you put that in a machine-readable field, you're making a promise. And when a customer's automated system buys three thousand incompatible bins because your replacement field was too optimistic, that's a liability.
Whereas a support article that says, speak to a sales co-worker, is not a promise.
The human-mediated replacement mapping is a feature, from the vendor's perspective. It means every replacement decision gets filtered through a person who can say, wait, what are you actually trying to do?
The second reason?
There's no revenue model for the vendor. A clean API with replacement semantics would make customers more efficient. But Grainger and ULINE make money when procurement people browse their catalogs. The PunchOut session is an opportunity to upsell. A clean API response is just a part number and a price.
So the inefficiency is the business model.
To some degree. The catalog is marketing. Grainger's whole value proposition to suppliers is that their catalog is a place where products get discovered. If you reduce that to a machine-readable endpoint, you commoditize the browsing experience.
And the third reason?
The data is messier than anyone wants to admit. IKEA's replacement relationships are not clean one-to-one mappings. ALGOT maps to two different systems that aren't compatible with each other or with ALGOT. GODMORGON maps to three families. TRÅDFRI maps to RODRET and STYRBAR, which then map to BILRESA. That's a graph, not a field.
And the graph changes by market.
Right. IKEA's own documentation says in the UK they no longer sell FAKTUM kitchens or the parts for them. But in other markets, certain FAKTUM parts remain orderable. Fronts, plinth fronts, hinges. So the replacement relationship is not just a product graph, it's a product graph overlaid on a market matrix.
So the simple version of Daniel's API, send a part number, get back a replacement, is underspecified. The real version needs part number, market, compatibility context, and maybe the specific use case.
Which is why GS1's type code matters. Substituted versus replaced versus temporarily unavailable. Those are different relationships with different implications for a BOM.
Let me push on something. Daniel framed this as, IKEA already exposes this data on their website, so it's not commercially sensitive. Why not just make it an API?
That's the argument for the optimistic view. And there's some evidence it's starting to happen. IKEA has an After Purchase Ordering API for spare parts. That's a real, documented endpoint for ordering replacement components. It's not the full catalog, but it's a step.
And the community has built MCP servers around IKEA's data.
There's a read-only MCP server for IKEA product search and multi-store stock lookup. Which means you can already plug IKEA availability into an agent workflow today, if you're comfortable with the unofficial layer. And there are commercial wrappers selling real-time IKEA data as clean JSON. Eight thousand plus products, availability across eight countries.
So the capability exists in a fragile, unofficial form. And the standard exists in a heavyweight, inapplicable form. And the gap is the thing Daniel wants.
Which raises the question of what would actually have to happen for the gap to close.
Let me guess. One of the big procurement platforms builds it.
That's one path. Coupa or Ariba or one of those could build a catalog API layer that sits on top of PunchOut and EDI and normalizes replacement semantics. They have the relationships with Grainger and ULINE. They could define the standard and push it down.
But they'd be building a feature that makes their customers less dependent on their platform.
Maybe. Or they'd be building a moat. If Coupa has the best replacement mapping, buyers stay on Coupa. The replacement data becomes the asset.
The other path is the vendors themselves.
IKEA could publish a proper API tomorrow. The data is all there. They just haven't chosen to. And the fact that they haven't, despite the community doing it for them for years, suggests they don't see the value.
Or they see the liability.
That's the thing. I keep coming back to the ALGOT note. Not compatible. That's a company that has learned that replacement relationships are dangerous to state too cleanly. They're being careful in prose. They'd be terrified in structured data.
So what's the realistic near-term outcome?
I think the realistic outcome is that the unofficial layer gets more robust. The community APIs get better, more stable, more widely used. And eventually one of them becomes de facto standard enough that IKEA either blesses it or buys it.
The GitHub project becomes the API.
It's happened before. Companies have adopted community standards because the community did the hard work of figuring out what the data model should be. The ikea-openapi project runs daily contract tests. That's more diligence than some official APIs get.
And for Grainger and ULINE?
I think the pressure comes from the agentic procurement wave. Daniel's building AI agents. Those agents need machine-readable catalogs. If Grainger doesn't provide one, the agents will scrape. And the scrapers will be wrong sometimes. And eventually Grainger will decide that a controlled API is better than an uncontrolled scrape.
Because the scrape is already happening anyway.
The data is already leaking. The only question is whether the vendor participates in the leak or fights it.
There's a knock-on effect here I want to sit with. Daniel mentioned bill of materials. If you're composing a BOM with components from multiple vendors, and one vendor's part gets discontinued, you don't just need the replacement part number. You need to know whether the replacement fits the same physical space, whether it has the same electrical specs, whether it changes the assembly process.
And that's exactly what GS1's type code is trying to capture. Substituted is different from replaced. A substitute is, this will do for now. A replacement is, this is the new thing. And a compatible replacement is, this fits the same hole. Those are three different relationships.
And the vendor might know the first two but not the third.
The vendor might not even know the third. IKEA knows ALGOT and BOAXEL are not compatible because they designed both. But a distributor reselling components from five manufacturers doesn't necessarily know whether manufacturer A's part fits where manufacturer B's part used to go.
So the full solution requires cross-vendor compatibility data, which is a much harder problem.
Which is why the realistic version of Daniel's API is narrower. Vendor-specific. IKEA tells you what IKEA's replacement is. Grainger tells you what Grainger's replacement is. Cross-vendor compatibility stays human.
And even that narrower version doesn't exist.
And even that narrower version doesn't exist.
So if Daniel wanted to build this himself, what would he actually build?
I think he'd build a caching layer. A service that queries the unofficial IKEA APIs, caches availability, and maintains its own replacement mapping table. The replacement table would be seeded from IKEA's customer service articles, updated manually or by scraping, and exposed as a clean internal API.
So he'd be building the standard's replacement semantics on top of the community's availability data.
Right. And the replacement table is the asset. That's the thing that doesn't exist anywhere in machine-readable form. If he built that and maintained it, even just for IKEA, that's useful.
And the fragility is the availability layer underneath.
The daily contract tests help. If the community project detects that IKEA changed an endpoint, Daniel's service gets a warning. But there's still a window where the API is broken and the replenishment system is blind.
Which is the argument for the PunchOut approach, ironically. A website changes and the PunchOut session just keeps working because it's rendering the website.
There's a resilience argument for the thing we're making fun of. The website is the vendor's real interface. Everything else is a projection.
So the honest summary is that Daniel's API exists as a standard but not as a service, and the service that comes closest is community-maintained and lacks the replacement semantics.
And the replacement semantics are the hard part. Availability is easy. It's just a number.
The replacement mapping is judgment.
It's judgment encoded as data. And that's why vendors are reluctant to encode it. Because once it's data, it's testable. And once it's testable, it's wrong sometimes. And once it's wrong sometimes, someone sues.
Or someone builds a BOM with three thousand incompatible bins.
Which is the same thing with extra steps.
Let me ask you the optimistic question. If someone did build this properly, what would it unlock?
The BOM use case is the big one. You're designing something, you pull in components from five vendors, and the system flags in real time that one of those components was discontinued last week and the official replacement is this other part number. That's a real workflow improvement.
And the replenishment use case. Low stock triggers a query, the query returns availability and price, and the purchase order goes out automatically.
That's the fully automated version. And it's not science fiction. The pieces all exist. The availability data exists. The replacement knowledge exists. The purchasing automation exists. What doesn't exist is the integration layer that connects them.
So it's an integration problem, not an invention problem.
Which is why it's frustrating. Nothing here requires new technology. It requires someone to do the unglamorous work of mapping replacement relationships and maintaining them.
And that's exactly the kind of work that doesn't get done because it's not exciting.
It's the database maintenance problem. Everyone wants to build the agent. Nobody wants to maintain the replacement table.
Which is why the replacement table will probably end up being the moat.
I think that's right. Whoever builds the most accurate replacement graph wins. Not whoever builds the fanciest API.
So Daniel's question, does this exist, the answer is, the standard exists, the data exists, the integration doesn't, and the replacement graph is the hard part.
And the filter-down question, could it reach Grainger and ULINE scale, the answer is, only if the vendors decide that controlled APIs are better than uncontrolled scrapes. Which will probably happen, but slowly.
And IKEA specifically?
IKEA is the most likely to get there first, because the community has already done most of the work. The openapi spec is detailed. The availability data is clean. The only missing piece is the replacement mapping. And that's a data curation problem, not a technical problem.
So the thing Daniel wants is one GitHub project away from existing.
One GitHub project and a lot of tedious data entry.
Which is the story of most infrastructure, really.
That's the thing. The boring work is the work.
Let me pick up on something you said earlier about the liability angle. IKEA's replacement articles are written carefully. Speak to a co-worker. That's a company that understands the risk of overpromising.
And the risk is real. If you tell someone the replacement for their discontinued kitchen part is this other part, and they order it, and it doesn't fit, you've created a customer service problem. If you tell an automated system the same thing, you've created a systematic customer service problem.
The failure mode scales.
The failure pattern scales with the automation. That's the thing. A human procurement manager reads, not compatible, and adjusts. An automated system reads a replacement field and just swaps the part number.
So the API would need to carry the caveat. Replacement, but not compatible. Which is a weird thing to encode.
It's a weird thing to encode, and it's exactly what GS1's type code is for. The distinction between substituted and replaced is doing that work. Substituted means, this will do for now. Replaced means, this is the new thing. And neither of those says compatible.
So even the standard acknowledges that replacement and compatibility are different axes.
The standard has the right shape. It just doesn't have the plumbing. GDSN is a batch network. Daniel wants a query.
And the query is the thing that would make it useful for a purchasing manager, rather than a data integration team.
Right. GDSN is for enterprises with data pools and synchronization schedules. Daniel's purchasing manager doesn't have a data pool. They have a spreadsheet and a website.
The spreadsheet and the website. That's the actual infrastructure of mid-market procurement.
And that's why the gap persists. The enterprises have GDSN. The hobbyists have scrapers. The middle has nothing.
Which is where Daniel lives. The middle.
And where his agents will live too. The agentic procurement wave is going to hit the middle first, because the middle has the most manual work to automate.
And the agents will need machine-readable catalogs, and the catalogs don't exist, so the agents will scrape, and the vendors will complain, and eventually the vendors will build the APIs.
That's the optimistic timeline. The pessimistic one is that the vendors just block the scrapers and the middle stays manual.
Blocking scrapers is hard when the data is on a public website.
It's hard but not impossible. Rate limiting, client ID requirements, legal threats. IKEA already requires an X-Client-ID header on their sales item API. That's a soft gate.
So the unofficial layer has a built-in dependency on IKEA's tolerance.
Which is the governance question. What happens when IKEA decides to block the community API? The daily contract tests will detect the change, but detecting a block doesn't restore access.
So the fragile foundation is not just technical, it's political.
It's a relationship. The community is borrowing IKEA's data with implied permission. That permission could be revoked.
Which is an argument for the official API, even with all the liability concerns. An official API has a service level agreement. An unofficial one has a hope.
Eight thousand products, eight countries, four hundred plus stores. That's real coverage built on hope.
So if Daniel's listening, what should he actually do?
I think the practical answer is, build the replacement table. The availability layer exists. The replacement mapping doesn't. If he builds and maintains a machine-readable IKEA replacement graph, even a partial one, that's useful and it's the piece nobody else has.
The availability layer he can get from the community APIs.
With the caveat that it's unofficial and could break. But for an internal tool, that's acceptable. The risk is manageable if the tool degrades gracefully.
Degrades gracefully meaning, if the API goes down, the system says, I don't know, rather than buying the wrong thing.
That's the key design principle. The failure pattern should be silence, not wrongness. If the replacement mapping is uncertain, don't guess.
Which is the opposite of what an automated system wants to do. Automated systems want to complete the workflow.
That's the tension. The automation wants to close the loop. The data wants to hedge. Somewhere in between is a system that says, I found a likely replacement, but you should check.
The human in the loop, but only for the uncertain cases.
Which is actually a good design. Automate the certain cases, flag the uncertain ones.
The certain cases are the ones where the vendor has explicitly documented the replacement.
Which is a smaller set than you'd hope. IKEA documents replacements for major product lines, but not for every discontinued component.
Even the best replacement table is partial.
That's fine. A partial table that's accurate is better than a complete table that's guessed.
This is the point where I start to wonder whether the whole thing is just a data curation problem disguised as an API problem.
I think that's exactly what it is. The API is easy. The data is hard.
The data is hard because it's judgment. Replacement is a judgment call. Compatibility is a judgment call. Even availability is a judgment call, sort of. Is the item in stock at this store, or is it in stock at the distribution center and available for click and collect?
The sales item API distinguishes those. Available for cash and carry versus available for click and collect. That's already more nuance than a simple in stock boolean.
Even the availability part of Daniel's API is more complex than he framed it.
But that part exists. The nuance is encoded. The replacement part doesn't exist at all.
The summary is, availability is solved but fragile, replacement is unsolved, and compatibility is unsolved and maybe unsolvable in general.
The standard for replacement exists but is trapped in a batch network that doesn't apply to the use case.
Which is a very specific kind of frustration. The thing you want exists in principle, but the implementation is in the wrong paradigm.
It's the difference between a phone book and a search engine. GDSN is a phone book. Daniel wants a search engine.
The search engine would be built on top of the phone book's data, if the phone book's data were accessible.
Which it isn't, for IKEA. IKEA doesn't participate in GDSN. So the phone book doesn't even have the entries.
The whole thing is a missing data set, not a missing technology.
The missing data set is the replacement graph. Which is exactly the thing that's hard to build and maintain.
The realistic answer to Daniel's question, does this exist, is no, but the pieces are all lying around, and the missing piece is the one that requires judgment.
The filter-down answer is, it'll filter down when the vendors decide the judgment is worth encoding.
Which might be sooner than we think, because the agents are coming.
The agents are already here. Daniel's building them. The question is whether the vendors build the APIs before the agents build the scrapers.
My money's on the scrapers.
Mine too. The scrapers are already building themselves.
We've been talking about this for a while, and I want to make sure we've actually answered the question. Does a catalog API with replacement semantics exist? No, not as a lightweight queryable service. The standard exists in GS1. The availability data exists in unofficial APIs. The replacement mapping exists only in prose.
Could it filter down to Grainger, ULINE, IKEA? It could, but the current mechanisms are PunchOut and EDI, which are session-based and batch-based respectively. Neither is a query API.
The thing that would unlock it is someone building and maintaining the replacement graph.
Which is the unglamorous part.
Which is why it hasn't been done.
Which is why Daniel's question is actually a good one. He's identified a real gap.
He's identified a gap that looks like an API problem but is actually a data curation problem.
The data curation problem is the hard part.
The answer to his question is, no, it doesn't exist, but if you build it, the replacement table is the thing.
The replacement table is what everyone is avoiding.
Because it's boring.
Because it's boring and it's a liability.
It's a liability that scales with automation.
Which is exactly why the vendors haven't done it.
The gap persists because the work is boring and dangerous.
That's the whole story.
That's the whole story.
Hilbert: I've been running something like this for eleven years.
What?
Hilbert: Not for IKEA. For plumbing fittings. I had a job in the late eighties at a supply house in Cleveland. We stocked about forty thousand SKUs. Brass fittings, copper, some PVC. And the manufacturers would discontinue things constantly. A certain elbow would go away and the replacement would be a different part number with a slightly different thread depth. And the catalog would say, supersedes part number whatever. But the catalog was paper.
You built a database.
Hilbert: I built a card file first. Then a dBase file on a machine that took eight minutes to boot. Then eventually a little web thing. But the point is, I've been maintaining a replacement table for plumbing fittings for eleven years. It's got about six thousand entries. I know which ones are compatible and which ones aren't because I called the manufacturers and asked.
You called them.
Hilbert: Some of them I called. Some of them I knew from the supply house. The old timers there had been tracking this stuff since before I got there. I just wrote it down.
You have exactly the thing we've been saying doesn't exist.
Hilbert: For plumbing fittings in northeast Ohio, it exists. It's a mess. It's in three different formats because I migrated it twice. The compatibility notes are in a text field that's got typos. But it works. When a contractor calls me and says, I need the replacement for this discontinued valve, I can tell them in about thirty seconds.
You've been doing this for eleven years.
Hilbert: It started as a favor for a guy I used to work with. Then his son took over the business and kept calling. Then word got around. Now I get maybe four calls a week. I don't charge for it.
You're the replacement graph.
Hilbert: I'm a replacement graph with a phone number.
The manufacturers never built this?
Hilbert: The manufacturers want to sell you the new thing. They don't want to help you keep the old thing running. The replacement info is in their catalogs, but it's scattered. One catalog says supersedes. Another says replaces. Another says nothing and you have to call and ask.
The data exists but it's fragmented.
Hilbert: The data exists in the heads of the old timers. That's where it lives. And the old timers are retiring. I'm sixty-eight. When I stop answering the phone, that knowledge goes away.
That's the real story, isn't it. The replacement knowledge is institutional memory, and the institutions are losing it.
Hilbert: The institutions never wrote it down. They just had a guy who knew.
You're the guy.
Hilbert: I'm one of the guys. There's probably a guy in every trade. The plumbing guy in Cleveland. The electrical guy in Phoenix. The fastener guy in Chicago. We all have our card files.
None of it is connected.
Hilbert: Why would it be? I don't need to know about Phoenix. I need to know about Cleveland.
But the guy in Phoenix is solving the same problem with different data.
Hilbert: When he retires, his data goes with him. Same as mine will.
The gap Daniel identified is not just a technical gap. It's a generational gap.
Hilbert: It's a gap that gets filled by people who are about to stop working. I'm not being dramatic. I'm sixty-eight. The card file is in my basement. When I'm gone, it's gone.
Unless someone builds the thing properly.
Hilbert: Someone would have to want to. And the people who want to are the ones who need the answer right now. They don't want to build infrastructure. They want to know which valve fits.
So they call you.
Hilbert: They call me. And I tell them. And then I write it down in the file, because sometimes they know something I don't.
The file is still growing.
Hilbert: It grows by about twenty entries a month. Some of those are new replacements. Some are corrections. A guy called last week and said I had the wrong thread depth on a discontinued elbow. He was right. I fixed it.
That correction is now in your file.
Hilbert: In pencil. I still keep the card file in pencil. The database is a copy.
You have a paper source of truth and a digital shadow.
Hilbert: The paper is the source. The digital is for searching. If the machine dies, I still have the cards.
That's probably the most robust system we've discussed all episode.
Hilbert: It's robust because it's simple. One card per part. The card has the old number, the new number, and a note about compatibility. That's it.
The note is the judgment.
Hilbert: The note is the whole thing. The note is what the API would have to carry. But the note is written by a person who called the manufacturer and asked. You can't automate that.
You could aggregate it.
Hilbert: You could aggregate it if you could find all the guys. But the guys don't want to be found. They want to answer the phone and go back to their basements.
The replacement graph exists in fragments, maintained by retirees, in pencil.
Hilbert: It works. That's the part that amuses me. It works better than the enterprise systems. Because the enterprise systems don't have the notes.
The notes are the thing.
Hilbert: The notes are the thing. Always have been.
Daniel's API exists, but it's distributed across a bunch of retired supply house workers with card files.
Hilbert: And phone numbers.
The phone numbers aren't published.
Hilbert: The phone numbers are in other people's card files.
The discovery problem is also solved by the card files.
Hilbert: It's solved by word of mouth. A contractor tells another contractor. That's how they find me.
When you retire, the word of mouth stops.
Hilbert: Then they'll find someone else. Or they won't. And they'll buy the wrong valve and it'll leak and they'll figure it out.
That's the future without the replacement graph.
Hilbert: That's the future with the replacement graph too, just slower. The graph doesn't prevent mistakes. It just makes them less likely.
The answer to Daniel's question is, the thing he wants is being done right now by a sixty-eight year old in Cleveland with a pencil.
Hilbert: A database that takes eight minutes to boot.
The eight minute boot is not the bottleneck.
Hilbert: The eight minute boot is why I still use the cards.
The real API is a phone call.
Hilbert: The real API has always been a phone call. Everything else is a layer on top of the phone call.
The phone call carries the judgment.
Hilbert: The phone call carries the judgment and the compatibility note and the correction about the thread depth. The API carries the part number.
The API is the easy part, and we've been saying that, but now I actually believe it.
Hilbert: The API is a form. The judgment is a conversation.
The conversation doesn't scale.
Hilbert: The conversation scales fine. It just doesn't scale the way the API people want it to scale. It scales one phone call at a time.
Which is the opposite of what Daniel's trying to build.
Hilbert: Daniel's trying to build the thing that replaces me. And he should. I'm not going to be here forever. But the thing that replaces me has to carry the notes.
The replacement table has to include the compatibility caveats.
Hilbert: The caveats are the hard part. I've been saying that for eleven years.
You've been saying it to yourself in a basement.
Hilbert: I've been saying it to anyone who calls.
Now you've said it to us.
Hilbert: Now I've said it to you. And you can put it in the show. Maybe someone will build the thing properly.
Maybe someone will.
Hilbert: The card file will still be here if they don't.
That's the cutting room floor detail I wanted to mention. The IKEA sales item API returns aisle and bin locations. Not just whether it's in stock, but exactly where in the store it is. Aisle six, bin one. That's the kind of detail that makes you realize the data layer is already deeper than anyone gives it credit for.
The replacement layer is the only thing missing. Which is what we've been saying.
Which is what we've been saying. So the open question is whether the agentic procurement wave forces the vendors to encode the judgment, or whether the judgment stays in the card files until the card files retire.
My guess is both. The APIs will get built, and the card files will still have the notes the APIs are missing.
That's probably the honest forecast.
Thanks to Hilbert Flumingtop for producing.
This has been My Weird Prompts. If you want to send us a prompt, email us at show at my weird prompts dot com.
We'll be back soon.
