I’m reviving Munchausen, a C# NuGet package I started 9 years ago. This is part 5 of an 8-part series documenting both the development process and the engineering decisions behind bringing the project back to life.
This is the Dev Log: the practical work, cleanup, implementation steps, and day-to-day progress behind this part of the project.
M4 is the milestone with opinions. It's the catalog that decides FirstName
should be a name, Email an email, Price some money, the part that makes Munchausen feel smart instead of just random. And it's the milestone where, for the first time, I stopped building and revisited an assumption because my design genuinely disagreed with itself.
The setup
The matching rules are mostly mechanical: normalize the member name (so FirstName, first_name, and FIRST-NAME all collapse to firstname), check the value type matches, score the candidate's confidence, and let the selected mode filter it. Forty-four rows of curated candidates, captured in the design document. Straightforward.
Except that the catalog had a knot in it. The general rule says: if a candidate is gated by a model hint (like "this only applies to car-ish models") and the hint doesn't match, drop the confidence one level. But the Vehicle rows had hand-written notes saying make/model should drop to Low (two levels), and year should switch to an entirely different generator. I had written a general rule and exceptions that disagreed. Since the choice affects seeded output, every future golden would preserve whichever interpretation I picked.
Instead of choosing the easier implementation, I returned to the user experience I wanted the catalog to create.
The argument that settled it
Think about a non-vehicle model with a Make property, a Printer, a Shirt.
Under the lenient reading, Make confidently generates "Toyota." Under the strict
reading (the row notes), it drops to Low, gets rejected by the default mode, and
falls back to obvious lorem filler. Which behavior would I rather debug?
The lorem is better. A car brand sitting in a printer's Make field is the
worst kind of bug for a fake-data library: it looks completely plausible, so it
sails through review and into your test fixtures, quietly wrong. Generic filler,
on the other hand, screams "I didn't recognize this", you see it, you add a rule,
done. A false negative you can spot beats a false positive you can't. So the row
notes won, and the candidate model grew a couple of optional override fields to
encode that decision.
I love that this was a taste decision hiding inside a matching rule. Resolving it taught me something important about the library: protecting users from confidently wrong data matters more than maximizing how often inference succeeds.
Making the catalog defend itself
The other thing I'm proud of here is the conformance test. The catalog is 44 rows of data, and the data rots. A future edit could quietly shift a confidence or alias.
So I wrote the intended catalog a second time, independently, in the test and asserted the two match row-for-row. Now changing the design requires an explicit change to both the implementation and its expectation. I'll reuse the same idea for diagnostic codes next milestone.
It passed on the first run, which means my two independent transcriptions agreed, a small but real confidence boost that I didn't fat-finger the table.
A sneaky edge case
There's one candidate (category) that's hinted but has a Medium base, where a hint match produces a slightly surprising promotion to High. I kept the general behavior and left a comment because category has no explicit exception. The surprise is now visible and easy to reconsider later.
Where it leaves things
The engine can now look at any member and decide: scalar or nested or collection or
unsupported; if scalar, which semantic generator (by name) and at what confidence,
or else a type default. It doesn't run any generators yet; it just produces
decisions and the plan-model types to hold them. The taste is in; the execution is
next.
What's next
M5: the compiler. Time to take all these inference decisions plus the user's rules and assemble them into one frozen, immutable plan, detecting conflicts, choosing constructors, walking the recursive type graph, with every possible failure carrying a stable diagnostic code. It's the milestone where Build() finally
works.
Top comments (0)