Full Interview Transcript

Let me tell you a story to illustrate why you should care about this whole "syntax-free" and "BRCC-compliance" thing — even if you already have a great management team and practice agile development.

Imagine you’re running a shipyard, building massive ships for global shipping companies. You’ve got a fantastic crew, top-notch managers, and you’ve adopted agile principles. You’re running like clockwork — daily standups, retrospectives, and sprints to build parts of the ship. Everything seems great.

But here’s the catch.

Every single instruction for how to build the ship is written on whiteboards in three different languages: English, Portuguese, and Mandarin. Not only that, but different teams are using different dialects of those languages. One group of engineers is using old maritime English with terms like "forecastle" and "bulkhead," while another is using more modern "project management speak" like "sub-assembly" and "task components." Meanwhile, the offshore teams in Portugal and China are translating it into their own local dialects — but since language doesn’t always map perfectly, they each have to add their own annotations and footnotes.

Your team is amazing, so they manage to keep things on track — but it’s a constant struggle. Meetings are spent arguing over translations, reworking misunderstandings, and ensuring everyone’s on the same page. Half the time, people are re-writing the instructions after the ship parts are built because someone "misunderstood the requirements" due to language differences. Everyone thinks this is just part of "doing business." Meetings and miscommunication seem inevitable. You tell yourself, “That’s just life.”

But one day, something weird happens.

One of your engineers, call him Eric, walks up to you and says, "What if we just made a 3D model of the ship and stopped writing all these instructions in words?" Everyone looks at him like he’s lost it.

"But we already have diagrams!" someone says, pointing at the wall where there’s a technical blueprint.

Eric shakes his head. "That’s not what I mean. The blueprint is just a flat 2D representation of the ship. What I’m talking about is a 3D model of the actual ship itself — something we can rotate, inspect, and interrogate. We could click on a part of the ship and see its properties, like its weight, material, and supplier. We could track changes directly in the model. No more translating descriptions into different languages — the model is the ship.”

At first, everyone dismisses him. But then one day, they try it. They bring in a CAD (computer-aided design) system that allows engineers to work directly with a digital twin of the ship.

Suddenly, everything changes.

No more translating instructions. Instead of "draw a bulkhead with 14 rivets spaced 6 inches apart," you just click the bulkhead in the 3D model. Everyone around the world can see it. No Portuguese. No Mandarin. No English. Just reality.

No more rework. If someone in Portugal changes a part of the ship, everyone sees it in real time. It’s no longer possible to accidentally build the "old version" of the part because there is no old version. There’s just the one true model.

No more constant meetings. Changes are tracked automatically. If a supplier says, "We’re switching to a stronger steel," you just update it in the 3D model, and every team sees it instantly — no meeting required.

And here’s the kicker: Every change is precise, mathematically verifiable, and perfectly portable. You could move that 3D model to another shipyard in a different country, and they could pick up exactly where you left off — because the 3D model isn’t "written in English" or "written in Portuguese." It’s a direct mirror of reality, not a description of reality.

Now let me connect this story back to your question.

Right now, your agile development process is syntax-locked. Your "3D ship model" is really just a whole bunch of words — in user stories, JIRA tickets, comments, Slack messages, and diagrams drawn on whiteboards. Every time you write "As a user, I want to..." you’re translating conceptual reality into the syntax of human language (English, in this case) or maybe into SQL, C# , or Python when you finally write the implementation. This is the same problem the shipyard had when it tried to write assembly instructions in three languages.

The result? Unnecessary complexity and entropy.

You have meetings to "make sure everyone is on the same page."

You have rework when "what they built" isn’t what "the story said."

You have semantic drift — what the user meant vs. what the developer thought they meant vs. what the QA team tested for.

You have multiple "sources of truth" — the JIRA story, the Figma design, the engineering spec, and the final implementation — but they all get out of sync.

If you recognize any of these symptoms, then you’re stuck in the same syntax prison that the shipyard was in before Eric showed them the 3D model.

So, what’s the alternative?

Here’s where Business Rule Completeness Conjecture (BRCC) comes in. BRCC says you can capture the full logic of any system with just five primitives:

A normalized schema (like a knowledge graph or conceptual model)

Constants and facts (domain rules like "a user must be over 18 to register")

Lookups to parents (referencing related objects, like "this invoice belongs to this customer")

Aggregations from children (like summing all the line items in an order)

Calculated fields (deriving new facts from old ones, like "total price = unit price x quantity")

These primitives aren’t just abstract theory — they’re proven in Airtable, Baserow, SQL, and knowledge graphs. They work. When you model your system this way, you’re building a "3D model of the ship," not just instructions for how to build it. This is why, in an Airtable-like system, you can move a project from Airtable to Baserow to SQL Server without losing any fidelity. The model is reality, not a description of reality.

So, why should you care?

Because you already care about agile development.

Because you already care about reducing rework.

Because you already care about team alignment.

You’re already in the shipyard. But right now, you’re relying on syntax (words) to coordinate the build. If you move to a BRCC-compliant approach — where you model concepts directly, instead of locking them in syntax — you get the same benefits as the shipyard that switched from "written instructions" to "3D models."

No more 'misinterpretation of requirements' errors.

No more painful handoffs from design to development to QA.

No more chasing "old versions" of requirements.

Agile is great, but agile with BRCC compliance is like going from "good teamwork" to "no need for constant teamwork at all." Because when your conceptual model is clear, everyone can just see it, understand it, and interact with it — like that 3D model of the ship.

So next time someone says, "Why do we need all this syntax-free, BRCC, pre-syntax talk?", tell them the story of the shipyard. Tell them about the agony of language-bound instructions. Tell them how it all changed when they moved to the 3D mirror model of reality. Tell them how their meetings disappeared, rework vanished, and everything just "clicked."

Then look them in the eye and say, "Do you want to keep working in syntax, or do you want to work in reality?"