DEV Community: Ernesto Herrera Salinas

Dev Log: The big one: where the fake data starts looking real

Ernesto Herrera Salinas — Mon, 22 Jun 2026 01:14:24 +0000

M7 is the milestone where Munchausen stops being a clever skeleton and starts producing data you'd actually believe. Eight dataset classes, a pile of English word tables, and the wiring that turns every "this should be a first name" decision from earlier into an actual "Anthony." It's the largest milestone by a wide margin, and it's the one where all those throw new NotImplementedException("bound in M7") IOUs from M5 and M6 finally come due.

There's a particular satisfaction in deleting placeholder code by replacing it with the real thing.

Curating fake reality

A lot of this milestone is taste expressed as data: which first names, cities, and product adjectives to include. While designing the datasets, I decided their public methods should remain stable while the underlying tables could grow. The constraints I care most about are the safety ones: emails use RFC 2606 reserved domains, IPs come from TEST-NET documentation ranges, and phones stay in the
fictional 555-01xx band. A mock-data library should never accidentally emit a real person's plausible-looking contact information.

The VIN generator was the most fun to get right. A real VIN has a check digit at position 9 computed from a weighted transliteration of the other 16 characters, mod 11. I implemented it, then wrote the test to independently recompute the check digit a different way and assert they agree. When two different implementations of a fiddly algorithm agree across 200 random VINs, you actually believe it.

The sleight of hand I'm quietly proud of

There was a real risk here. Back in M6, the type generators read from context.Random, which was an internal handle on the PRNG. In M7, Random has to become the public RandomData façade. Change that, and you risk shifting the byte stream and breaking the M6 golden, exactly the kind of seeded-output break the project treats as a serious event.

But RandomData.Int is a one-line forward to DeterministicRandom.Int. Same underlying instance, same draws, same bytes. So I swapped the type from internal to public, held my breath, ran the M6 golden… and it passed, untouched. The façade is
genuinely transparent. Threading a new public API over existing behavior without disturbing a single committed byte is the kind of small, invisible win that makes the careful-determinism discipline feel worth it.

Finally solving the tooling mystery

And then there's the dotnet format saga. Since M5 it had refused to auto-generate my public-API entries, warning about a "duplicate source file." I'd been hand-writing entries to get around it. This milestone added 75 new public members, enough to make the workaround obviously unreasonable, so I finally sat down and read the warning properly.

The culprit was sitting in my own csproj since M0: I'd explicitly added <AdditionalFiles Include="PublicAPI.*.txt" />, but the analyzer package already includes those files itself. Double-registered. Delete my redundant line, and dotnet format instantly worked, spitting out all 75 entries perfectly formatted.
A self-inflicted problem I'd been routing around for two milestones, fixed in thirty seconds once I investigated the message. The lesson was not about dotnet format; it was about how quickly a workaround can become invisible.

Where it leaves things

Lie.Define<Car>().Build().Generate() now returns a Mazda Sorento, a believable price, and an owner with a real-looking name and an @example.net email. The placeholders are gone. Every semantic name resolves to a real generator, every dataset draws from the one deterministic stream, and same-seed runs are identical.
The library finally does, end-to-end, the thing it set out to do.

What's next

M8, the finale. Explain(), so the inference isn't a black box; the cached zero-config Lie<T> automatic path; reflection-free construction, so generating a million objects allocates nothing but the objects themselves; a benchmark suite; and the final goldens.

Then the release-hardening checklist is done, and v1.0 is done.

Engineering Post: Executing the plan: lifecycle, cancellation, cycles, wrapped-once

Ernesto Herrera Salinas — Sun, 21 Jun 2026 21:19:00 +0000

I’m reviving Munchausen, a C# NuGet package I started 9 years ago. This is part 7 of an 8-part series documenting both the development process and the engineering decisions behind bringing the project back to life.

This is the Engineering Post: the reasoning, trade-offs, API decisions, and technical choices behind this part of the project.

M6 makes Generate() real. A GenerationOperation exists per call; it owns the PRNG and reference time (resolved once), traverses the frozen plan, and produces objects. This milestone tests whether the lifecycle I designed is precise enough to execute: ordering, cancellation checkpoints, exception wrapping, and depth/cycle handling.

One operation, resolved once

The operation constructor settles the things that must not drift mid-call:

Seed: options.Seed ?? defaults.Seed ?? entropy. The entropy path is the single place in src/ allowed to touch System.Random, one draw from Random.Shared to seed an unseeded run.
Reference time: options.ReferenceTime ?? defaults.ReferenceTime ?? options.TimeProvider?.GetUtcNow() ?? DateTimeOffset.UtcNow, captured once. No method ever reads the clock again.

The lifecycle, in order

Per object: construct → populate members in MetadataToken order → run derivations in registration order. That ordering is part of reproducibility, so the traversal is rigid by design. Each phase boundary is a cancellation checkpoint: before each root, nested object, collection element, and derivation pass.

Wrapped exactly once

Every user-delegate site, a ConstructWith, a With generator, a Derive, is wrapped in exactly one try/catch that throws LieGenerationException carrying the model type, member path, index, and the GenerationPhase of the site, with the original exception preserved as InnerException. OperationCanceledException
passes through untouched (cancellation is never a "generation failure"). To keep
the real user exception as the inner, not a TargetInvocationException, typed
user delegates are adapted to the uniform shape with a compiled Expression.Invoke
rather than DynamicInvoke.

The exception hierarchy itself got corrected here: LieDefinitionException and
the new LieGenerationException both derive from a public abstract
LieException. I had designed that common base but missed it in M5; implementing
the runtime exposed the omission.

Path-based cycles, frame-based depth

Cycle detection is path-based, not type-based: a candidate nested type is a
cycle only if it already appears in the active ancestor chain. So two Address
siblings (billing and shipping) both generate; they're on different branches, while Employee.Manager terminates, because Employee is its own ancestor. Depth
is the object-frame count (the default max is 3); collections don't push a frame,
but their element objects do. On depth or cycle, Terminate nulls the reference /
empties the collection, and Throw raises a LieGenerationException.

Reflection-free collection materialization

Collections materialize through delegates compiled at build time, so generation
stays reflection-free. A small generic helper is bound to the element type once:

public static object ToList<T>(IReadOnlyList<object?> elements) { /* ... */ }
// bound via MakeGenericMethod(elementType).CreateDelegate at compile time

Arrays and the six sequence interfaces materialize fully; dictionaries land as the
right empty type for now (their keys are usually strings, which arrive with the
datasets).

The deferral question, answered

M6 hit the ordering tension in my plan head-on: the real scalar generators arrive
in M7, so what can the runtime honestly generate today? I chose to bind only the
pure-PRNG type defaults, int, bool, Guid, double, decimal, enum,
byte[], and friends, and defer strings, dates, semantic generators, and rich
test-model goldens to M7. Every runtime mechanic is testable now with primitive
fixtures and user delegates; only dataset content waits.

What's next: M7, the Datasets

M7 binds the leaves. Eight public datasets, the English data tables, the internal
generators (phone, guid-string, short-code), and the wiring that connects every
semantic catalog name to a real implementation, so FirstName finally produces
"Anthony" and Email produce something @example.com. After M7, the placeholders from M5 are gone, and the canonical Car generates a full, believable graph.

Dev Log: It generates! (Mostly. The strings are IOUs.)

Ernesto Herrera Salinas — Sun, 21 Jun 2026 20:50:00 +0000

I’m reviving Munchausen, a C# NuGet package I started 9 years ago. This is part 7 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.

M6 is the milestone where Munchausen finally does the thing. Generate() runs.
There's a traversal that constructs an object, fills its members in order, runs
derivations, handles cancellation, wraps errors, and refuses to recurse forever.
After five milestones of plumbing, watching a definition actually produce an object
is a genuine hit of dopamine.

But first I had to answer a question I'd been dodging.

The chicken-and-egg

The runtime's whole job is to execute the plan, which means running generators. But
the real generators, the things that turn a FirstName into "Anthony", are
datasets, and datasets are the next milestone. The string type-default literally
is "two lorem words," and lorem lives in M7. So if I run the runtime against the
canonical Car, the moment it hits Make (a string), it throws "bound in M7."

This exposed a genuine fork in my milestone plan. I could build the runtime now
and defer dataset-backed generation to M7, or drag datasets forward and blur the
boundary. I chose the clean split: bind only the pure-PRNG type defaults in M6,
ints, bools, guids, doubles, anything made from the random stream alone, and let
strings, dates, and semantic generators arrive with the datasets they need.

The realization that made this comfortable was that almost every runtime
behavior, lifecycle order, cancellation, exception wrapping, depth limits,
cycle detection, and reproducibility, can be tested with primitive-only fixtures
and user delegates. M6 could be rigorous without pretending to be complete.

The surprise while capturing a golden

Here's my favorite moment of the milestone. I needed a golden for the runtime, so
I built a tiny model with neutral field names, Alpha, Beta, Gamma, Delta,
Epsilon, all primitive types, specifically to avoid the unbound semantic
generators. Ran it. Boom, "bound in M7."

Wait, what? They're all primitives. Which one tripped a semantic generator?

Epsilon. Because epsilon ends with lon, and lon is a catalog alias for
longitude, which is a double, and Epsilon is a double. The suffix matcher
did exactly what it was built to do and matched Epsi-LON to longitude. A
perfectly correct false positive, and a perfect little demonstration of why the
catalog uses confidence levels and modes in the first place. I renamed it Score
and moved on, grinning. The inference engine caught my own test off guard.

Getting construction right (and fast)

One detail I cared about: no reflection during generation. The accessors were already compiled back in M2. Construction was the last reflective holdout, and I'll fully fix that in M8, where the allocation test forces the issue, but M6 lays the groundwork: collection materializers are compiled to delegates at build time so the per-element loop never reflects.

And the exception story took real care. When your With delegate throws, you should see your exception as the InnerException, not some TargetInvocationException wrapper from reflection's DynamicInvoke. So user delegates are adapted with compiled Expression.Invoke, which throws cleanly. Wrap exactly once, tag it with the right phase (Construction / MemberPopulation /
Derivation), let cancellation pass straight through. Details, but they're the difference between an exception you can debug and one you curse at.

Where it leaves things

You can now generate primitive-and-nested graphs, in batches, reproducibly, with proper cancellation and depth/cycle safety. The lifecycle is exactly ordered, the goldens reproduce across runs, and a self-referential Node terminates cleanly at depth 1 instead of blowing the stack. The canonical Car still can't fully generate, its strings are IOUs, but every mechanism is real and tested.

What's next

M7: the datasets. The biggest milestone by far. Eight public dataset classes, the English data tables, VIN check digits, RFC-safe email domains, and the wiring that finally connects every semantic name to a real generator. It will test whether the abstractions from M4 through M6 really accept their missing leaves as cleanly as I hoped.

Engineering Post: Cashing the IOUs: eight datasets and a check-digit

Ernesto Herrera Salinas — Sun, 21 Jun 2026 06:00:00 +0000

M7 is the biggest milestone. It binds every leaf the previous two milestones left
as placeholders. Eight public dataset classes, the English data tables, the
internal-only generators, Dataset<T>() resolution, and the wiring that connects
every semantic catalog name to a real implementation. This is where I find out
whether the abstractions from M4 through M6 can accept their missing leaves
without being redesigned.

The datasets

RandomData (the primitive façade over DeterministicRandom), plus NameData,
InternetData, AddressData, DateData, LoremData, VehicleData,
CommerceData. I designed their public surfaces before implementation, then used
the PublicApiAnalyzer to check that the code introduced nothing extra.
Constructors are internal; callers reach datasets through the context, never
new.

The most important dataset choice is that realism must remain fictionally safe:
email domains come only from the RFC 2606 reserved set
(example.com/org/net), IPs from TEST-NET documentation blocks, phone numbers
from the 555-01xx range, and VINs are structurally valid but not
manufacturer-registered. That last one is the fun bit:

// 17 chars, no I/O/Q, with a real check digit at position 9
characters[8] = ComputeCheckDigit(characters);  // weighted transliteration mod 11

The contract test recomputes the check digit with an independent implementation and
asserts it matches. Because the two use different code paths, a switch and a
lookup string, this is a genuine cross-check rather than a tautology.

Binding the catalog

In M4 the semantic catalog stored generator names ("Name.First",
"Internet.Email"). M7 maps each name to a real delegate:

["Name.First"]     = c => c.Name.First(),
["Internet.Email"] = c => c.Internet.Email(),
["Vehicle.Vin"]    = c => c.Dataset<VehicleData>().Vin(),
["internal phone"] = InternalGenerators.Phone,

Dates need a twist: the catalog's date generators yield DateTimeOffset, but the
member might be a DateTime or DateOnly. So the compiler adapts the generator to
the member's declared type. The type-default generators extended too, string
becomes Lorem.Words(2), Uri becomes an Internet.Url, and the date/time family
binds to DateData.

A determinism-preserving sleight of hand

GenerationContext.Random became the public RandomData façade, but it wraps the
same DeterministicRandom the type generators were already using. Since
RandomData.Int just forwards to DeterministicRandom.Int, the byte stream is
byte-for-byte identical to M6. The M6 golden still passes untouched. Datasets are
instantiated once per operation and cached, all drawing from that single stream, so
"every dataset method draws only from the operation stream" is structurally true, and a determinism test proves two same-seed operations produce identical output.

The tooling mystery, solved

Remember M5's "duplicate source file" error that broke dotnet format? Here's the
diagnosis: the analyzer package already auto-includes PublicAPI.*.txt, and my
M0 csproj also added them explicitly via <AdditionalFiles>. Double-registered →
dotnet format choked. Deleting that one ItemGroup fixed it, and dotnet format
happily generated all 75 new dataset surface entries, correctly, down to
int.MinValue → -2147483648. A whole class of future pain, gone, because I
finally read the warning properly.

What's next: M8, the finale

The last milestone tests the complete design: Explain() makes inference
inspectable, the cached Lie<T> path removes configuration, reflection-free
construction faces an allocation test, and final goldens cover the complete
pipeline. After M8, I should know whether v1.0 works as one coherent library.

Engineering Post: Build() works! one pipeline, every error, a stable code each

Ernesto Herrera Salinas — Sat, 20 Jun 2026 20:45:00 +0000

M5 is where the pieces become a product. The DefinitionCompiler takes a snapshot
of the builder state and runs it through a pipeline that ends in a frozen,
immutable GenerationPlan. It tests a choice I made while designing Build():
every failure carries a LIE code from a registry, never a bare exception, and
the compiler reports every detectable error, not just the first.

The pipeline

Validate options (empty name → LIE005).
Resolve member expressions via the M3 resolver (bad shape → LIE001).
Group rules per member and detect conflicts (LIE002).
Plan construction (LIE004).
Infer every unruled member (M4).
Validate results, a required member that resolves to "unsupported" → LIE003.
Compile the reachable child graph, cycle-safe.
If any error-severity diagnostic exists, throw; otherwise freeze the plan.

Everything appends to one DiagnosticBag, and the pipeline runs to completion so
the exception carries the full list. LieDefinitionException.Message is composed
to a contract, the first error, prefixed with the model and suffixed with the
remaining count, so naive logging is already useful:

Definition for Car is invalid: Conflicting member rules for Car.Year (LIE002).
(2 more errors; see Diagnostics.)

Constructor selection

ConstructorPlanner implements the order I chose during design: a single
[LieConstructor]-marked ctor wins; otherwise the public ctor with the most
resolvable parameters; a parameterless ctor is preferred only on a tie;
otherwise it's ambiguous (LIE004). "Resolvable" is decided by running the
inference pipeline against a synthetic member built from each parameter, so
constructor parameters and properties share one inference implementation by
construction, which is exactly the promise the API makes. The selection matrix
(attribute, most-resolvable, parameterless tie, ambiguous failure, positional
record) is a five-case test.

Two-phase child compilation, the easy way

The reachable type graph, nested members, collection element types, is compiled
in the same Build(). Recursive graphs (Employee.Manager is an Employee) have
to terminate. The architecture describes "shells filled in two phases"; I got the
same guarantee more simply with a visited-set worklist over types. A
NestedSource holds the child type, not a direct plan reference, and the runtime
resolves it through a ReachablePlans dictionary. So compilation is just: pop a
type, build its plan (which enqueues its children), mark it visited, repeat.
Employee enqueues Employee, sees it's already building, and stops. One pass, no
infinite recursion, no mutable shells. A self-type reference emits LIE009 (Info,
not an error), the build still succeeds.

The registry is executable, too

The diagnostic codes live in an internal registry, code, default severity, and
title. A conformance test asserts the table matches the diagnostic set I designed.
It is the same move as the inference catalog: turn an intended shape into
something the build verifies.

An honest deferral

There's a wrinkle in the milestone order I chose: the compiler needs generators
for inferred scalars, but the real generators (names, emails, lorem) arrive in
M7. M5 therefore emits placeholder delegates that throw "bound in M7."
Generation is still stubbed, so they are never invoked, while the plan
structure remains fully correct and testable. The MemberReportData captures
the real inference result; only the executable function waits.

What's next: M6, the Generation Runtime

The plan exists; nothing runs it. M6 builds GenerationOperation, the per-call
engine that traverses the plan in lifecycle order (construct, populate in member
order, derive in registration order), checks cancellation at the documented
checkpoints, wraps user-delegate failures exactly once with the right
GenerationPhase, and handles depth and cycles. And it surfaces the question I'd
been quietly dreading: if generators are M7, what exactly can M6 generate?

Dev Log: The milestone where Build() stops lying

Ernesto Herrera Salinas — Sat, 20 Jun 2026 20:35:00 +0000

I’m reviving Munchausen, a C# NuGet package I started 9 years ago. This is part 6 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.

For three milestones, Build() has been a method that throws
NotImplementedException. M5 is where it finally earns its name. This is the compiler: take everything the builder captured, plus everything inference decided, and assemble it into one frozen plan, or fail with a tidy list of every reason it couldn't.

Errors are first-class citizens

While designing Build(), I kept returning to one question: what would make a failed definition easy to fix? My answer was to avoid bare exceptions. Every failure gets a stable code, LIE001 through LIE005 for the v1.0 cases, and Build() collects all of them before throwing. If your definition has a bad expression, a rule conflict, and an empty name, you get one exception listing all
three instead of discovering them one at a time.

I built each diagnostic with a deliberately triggerable test:

LIE001: With(c => c.Owner.FirstName, ...) (nested path, illegal target)
LIE002: With(...) and Ignore(...) on the same member (contradiction)
LIE003: a required member of an interface type (can't be resolved)
LIE004: two equally-resolvable constructors, no tiebreaker
LIE005: WithName(" ") (empty/whitespace)

There's something satisfying about writing tests whose job is to provoke
failure and then checking that the failure is well labeled. Good error messages
are a feature. Keeping the code registry and expected diagnostic table in sync
through a conformance test makes that feature difficult to erode accidentally.

Recursion, without the headache

The scary part, on paper, was the recursive-type graph. Employee has a Manager that's an Employee; compile that naively, and you recurse forever. My original architecture used a two-phase "allocate empty shells, then fill them" dance.
While implementing it, I found a simpler route: keep a visited set of types and a worklist, and have nested members reference their child by type rather than a direct plan pointer. The runtime looks the plan up in a dictionary later.
Compiling Employee now completes in a single pass and records a friendly LIE009 Info note. The implementation improved the architecture.

The deferral I had to make peace with

Here's the uncomfortable bit. The compiler wants to bind a generator to each inferred member, but the actual generators (the thing that produces "Anthony" for a FirstName) are datasets, and datasets are two milestones away in M7. Classic ordering tension.

The pragmatic answer was to emit a placeholder delegate that throws "bound in M7." Since generation itself is still stubbed, those placeholders are never called, while everything I can verify, the plan structure, constructor choices, diagnostics, and recursive termination, is real. It nagged at me to add deliberate throws, but this let me preserve the milestone boundary without pretending the leaves were finished. I left the IOUs explicit for future-me in M7.

A tooling mystery

This is also the milestone when my beloved dotnet format trick for generating the public API file suddenly stopped working; it complained about a "duplicate source file" and refused to populate anything. I hand-wrote the new exception-type entries instead and moved on, but it bugged me. (Spoiler: I finally diagnosed it in M7, and the fix was embarrassingly simple. Foreshadowing.)

Where it leaves things

Lie.Define<Car>().Build() now works end to end. It returns an immutable
LieDefinition<Car> holding a complete, frozen plan: a constructor choice, every
member's value source, derivations, the reachable child plans, retained
Info/Warning diagnostics. Generate() still throws, there's no runtime, but the
compile is real, validated, and recursion-safe.

What's next

M6: actually running the thing. The generation runtime, lifecycle, cancellation, exception wrapping, depth, and cycle handling. It also forces me to revisit the milestone plan: with the real generators still in M7, what can the runtime honestly produce?

Engineering Post: The part with taste: classifying types and matching names

Ernesto Herrera Salinas — Sat, 20 Jun 2026 05:23:00 +0000

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 Engineering Post: the reasoning, trade-offs, API decisions, and technical choices behind this part of the project.

M4 is the brain. Given a member the user didn't configure, the inference engine decides what to generate. It runs in two parts: a structural classifier that asks what shape is this?, and a stage pipeline that asks what value belongs here?, both producing entries for an immutable plan model that the compiler will later freeze.
This milestone tests the part of my design that is most subjective.

Structural classification

Before any name matching, every member type is bucketed:

Scalar: primitives, string, Guid, enums, the date/time family, decimal, Nullable<T> of these.
Nested: a class/struct with discoverable construction.
Collection: T[], List<T>, the read-only and interface variants, Dictionary<K,V> and friends.
Unsupported: interfaces/abstracts without registration, exotic value types (nint, Half, Int128), pointers.

There's one deliberate special case: byte[] is a scalar, not a collection.
It infers as "16 random bytes," because nobody wants a List<byte>-style element
walk over a blob. The classifier checks for it explicitly before the array branch.

The semantic catalog

The heart of the milestone is a 44-row candidate table, the project's curated
"taste," captured in the design document:

new(new[] { "firstname", "givenname", "forename" }, null, Str, High, "Name.First"),
new(new[] { "email", "emailaddress", "mail" },      null, Str, High, "Internet.Email"),
new(new[] { "make", "manufacturer" }, VehicleHints, Str, High, "Vehicle.Make",
    NoHintConfidence: Low),

Member names are normalized (split on case/underscore/hyphen, lowercase, join) so
FirstName, first_name, and FIRST-NAME all become firstname. The matcher
then applies the documented rules: the member's value type must equal the
candidate's; an exact name match with a matching model hint is High confidence; an exact match with no hints uses the candidate's base; a hint-gated miss drops a level; a suffix match (CustomerEmail ends with email) drops one below the exact
result. The selected mode (Conservative/Balanced/Aggressive) then filters by confidence, and rejected candidates are recorded for Explain().

A real design fork

The catalog had an internal tension I had not noticed while designing it. The
general rule says a hint-gated miss drops one level (High → Medium). But the
Vehicle rows annotate make/model as "no hint: Low" (two levels) and
year as "no hint: a different generator at Medium." My rule and exceptions
disagreed, and the choice affects seeded output, so I stopped implementing and
revisited the intended user experience.

The resolution (the per-row notes win over the general rule) came down to a
user-experience argument worth repeating: the words make and model are
extremely vehicle-specific. If a Printer.Make confidently resolves to "Toyota"
under the default mode, that's the worst failure for a mock-data tool, output
that looks plausible but is nonsense and slips into fixtures unnoticed. Dropping
to Low means it falls back to generic lorem text under the default, which the user
sees and corrects. A visible false-negative beats an invisible false-positive.
So the candidate model grew optional NoHintConfidence/NoHintGenerator fields
to encode that decision explicitly.

The catalog is executable

A conformance test records all 44 expected rows independently from the catalog
code and compares them one-to-one against the implementation: names, hints, value
types, and base confidence. Drift in either direction fails the build. The
catalog is not just data; its intended shape is executable, the same approach I
will use for the diagnostic registry in M5.

Internal enums, on purpose

InferenceConfidence and InferenceSource are public types in the final API, but they belong to the report family that ships in M8. To keep M4 free of public surface, they live as internal mirrors here and get promoted later (a trick that works cleanly because a Munchausen.Inference type resolves an unqualified InferenceConfidence against the enclosing Munchausen namespace).

What's next: M5, the Definition Compiler

M4 produces inference decisions; M5 assembles them into a real, frozen plan.
The DefinitionCompiler pipeline, resolve expressions, detect rule conflicts, plan construction, infer, validate, compile the reachable child graph (including recursive types), wired to a diagnostic registry where every Build() failure carries a stable LIE code. It's where Build() finally stops throwing NotImplementedException and starts doing its job.

Dev Log: When the design contradicts itself, stop typing

Ernesto Herrera Salinas — Sat, 20 Jun 2026 05:10:00 +0000

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.

Engineering Post: A builder that captures everything and validates nothing (yet)

Ernesto Herrera Salinas — Fri, 19 Jun 2026 05:56:00 +0000

I’m reviving Munchausen, a C# NuGet package I started 9 years ago. This is part 4 of an 8-part series documenting both the development process and the engineering decisions behind bringing the project back to life.

This is the Engineering Post: the reasoning, trade-offs, API decisions, and technical choices behind this part of the project.

M3 is where Munchausen grows a public face: Lie.Define<T>(), the fluent
builder, the options records, and the little expression resolver that polices how
you target members. It tests an API choice I made during design: the builder
captures state and validates nothing; every failure is reported at Build(), in
one place, with a diagnostic code.

Capture now, fail later

LieDefinitionBuilder<T> wraps an internal BuilderState. Each fluent method
appends a record and returns this; nothing is parsed or checked:

internal sealed record MemberRuleRecord(
    LambdaExpression MemberExpression,
    MemberRuleKind Kind,        // WithValue, WithGenerator, Derive, Ignore, Preserve
    object? Payload,
    int RegistrationIndex);

Keeping the builder dumb has three payoffs: it's cheap, it preserves registration
order (which Derive and last-write-wins resolution depend on), and it funnels
all error reporting into Build() so users get every problem at once instead of
one-at-a-time exceptions.

WithDefaults is the one method that merges immediately, non-null properties
overwrite, implementing per-property last-write-wins. WithSeed(42) is literally
WithDefaults(new GenerationDefaults { Seed = 42 }), no special case.

The single targeting rule

ExpressionMemberResolver enforces exactly one shape: x => x.Property. It
unwraps the Convert/ConvertChecked node the compiler inserts when a value-type
member is read through a generic lambda, then checks the body is a member access
rooted directly at the parameter:

while (body is UnaryExpression { NodeType: Convert or ConvertChecked } c)
    body = c.Operand;

if (body is MemberExpression { Member: PropertyInfo p } m
    && m.Expression is ParameterExpression param
    && ReferenceEquals(param, expression.Parameters[0]))
    return ExpressionResolution.Resolved(p);

return ExpressionResolution.Failed("LIE001", /* expression text */);

Anything else, x => x.Owner.Name (nested), x => x.Make.ToUpper() (method),
x => x.Items[0] (indexer), a captured variable, a constant, produces LIE001
with the offending expression text. Single-level targeting is a deliberate v1.0
rule; nested behavior is the job of child definitions later. Putting that decision
in one class means there's exactly one place it's enforced.

The locked surface, for real this time

M3 is the first milestone that adds public API, so the PublicApiAnalyzer from M0
finally bites. Adding the builder forced a realization: its method signatures
reference types that don't fully exist yet. With(expr, Func<GenerationContext, TProperty>) needs GenerationContext; Build() returns LieDefinition<T>, whose
Explain() returns InferenceReport. So those types get introduced now as
public stubs, declared, documented, with NotImplementedException internals
that later milestones fill in. When I split the work into stages, I allowed those
placeholders until M6 so I could test the complete public type graph before all
of its behavior existed.

Two surface mechanics worth noting:

The builder's constructor is internal, you create builders through Lie.Define<T>(), never new, so the public listing has no builder ctor.
The two Generate overloads use optional parameters, which trips the analyzer's RS0026 ("don't overload with optional params"). I revisited the overloads, still preferred their call-site ergonomics, and suppressed RS0026 with the rationale recorded. The warning informed the decision without making it for me.

Generating the surface file

Hand-writing PublicAPI.Shipped.txt is error-prone (every default value,
nullability annotation, and generic arity has to be exact). The trick is
dotnet format analyzers --diagnostics RS0016, which applies the analyzer's
"add to public API" fix and writes the entries in the precise format, then I move
them from Unshipped to Shipped after reviewing them against the API design.
(This worked here, broke mysteriously in M5, and got properly diagnosed in M7.
More on that saga later.)

Verification

The resolver accept/reject corpus produces LIE001 with expression text on every
bad shape; WithDefaults merge tests cover per-property last-write, null
no-opinion, and WithSeed equivalence; an acceptance test fluently chains the
whole builder from an external assembly to prove the surface is usable.

What's next: M4, the Inference Engine

M3 captures what you said. M4 figures out what to do with everything you didn't, the inference engine. Structural classification (scalar / nested / collection /
unsupported), the semantic catalog that maps FirstName → a name and Email → an
email, the confidence model, and the plan types the compiler will later freeze.
It's the milestone with the most "taste" baked in, and the one where implementation exposes a contradiction in my design.

Dev Log: The first public API, and the type graph that wouldn't stay small

Ernesto Herrera Salinas — Fri, 19 Jun 2026 05:34:00 +0000

I’m reviving Munchausen, a C# NuGet package I started 9 years ago. This is part 4 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.

M3 is a milestone with a flag on it: the first public surface. Lie.Define<T>(),
the fluent builder, the options records. Up to now everything was internal
plumbing nobody could call. Now I'm testing the API I designed by committing to
shapes that users will eventually depend on. Once a public member ships, changing
it becomes expensive.

The builder is deliberately lazy

The fun design decision here is that the builder does almost nothing. You call
.With(...), .Ignore(...), .Derive(...) and it just appends a little record
and hands you back this. No validation, no parsing. All of that is deferred to
Build(). It feels almost too lazy until you see why: you want all your
definition errors reported together, in one exception, not dribbled out one
throw at a time as you chain methods. So the builder's job is purely to remember
what you said, in order, and Build() is where judgment happens. Cheap builder,
smart compile.

"Wait, I have to declare half the library"

Here's the thing that caught me. To write the builder's method signatures, I need
the types they mention. With(...) takes a Func<GenerationContext, T>. Build()
returns a LieDefinition<T>. Explain() returns an InferenceReport. None of
those are built yet, they're milestones away. But you can't have a public method
whose parameter type doesn't exist.

So M3 quietly drags a chunk of the type graph into existence as stubs: public
types, fully documented, whose bodies just throw new NotImplementedException().
When I divided the work into stages, I allowed those placeholders until M6. It
still feels strange to add a GenerationContext that does nothing and a
Generate() that refuses to run, but it lets me test the complete API shape
before every behavior exists.

Falling in love with `dotnet format`

Maintaining the locked-surface text file by hand is miserable, you have to write
each entry in the analyzer's exact dialect, down to how int.MinValue is spelled
and where the ! nullability markers go. I discovered that
dotnet format analyzers --diagnostics RS0016 just generates all of it
correctly. Run it, review the generated surface against the API I designed, move
the lines into the shipped file. This will become a recurring character in the
story, including the episode two milestones from now where it inexplicably stops
working and I waste real time before figuring out why.

A small principled stand

The analyzer also complained (RS0026) about the two Generate overloads both
having optional parameters, a legitimate general warning, but it conflicted with
the API shape I had chosen. This forced me to revisit that choice rather than
blindly obey either side. I still preferred the overloads, so I suppressed the
rule with a comment explaining why. A linter is useful evidence, not the designer.

Where it leaves things

You can now write the fluent thing:

Lie.Define<Car>()
   .WithName("cars")
   .With(c => c.Make, "Saab")
   .With(c => c.Model, ctx => "900")
   .Derive(c => c.Year, (ctx, c) => 1989)
   .WithSeed(42);

…and it compiles, captures everything correctly, and rejects x => x.Owner.Name
with a clear LIE001. Build() still throws, there's no compiler yet, but the
ergonomics are real, and the public surface is locked and reviewed.

What's next

M4: inference. This is the milestone with opinions, the catalog that decides
FirstName should be a first name and Price should be money. It's also where I
find the first genuine contradiction in my design and have to decide which
behavior better serves the user.

Stop Training Your AI to Agree With You

Ernesto Herrera Salinas — Thu, 18 Jun 2026 00:32:19 +0000

The easiest way to make an AI assistant useless is to reward it for being pleasant.

You ask whether your product launch plan is strong. It says the plan is exciting.
You ask whether your pricing page is clear. It says the structure is solid.
You ask whether your idea is worth pursuing. It says you are thinking in the right direction.

None of those responses are necessarily lies. That is what makes the problem hard to notice. The AI is not always wrong. It is often just too eager to be helpful in the shallowest possible sense: it gives you momentum when what you needed was judgment.

Most people do not actually want an AI that agrees with them. They want an assistant that catches mistakes earlier, challenges weak assumptions, and helps them produce better work. They want something closer to a capable coworker: direct, useful, respectful, and willing to say, "I would not do it this way."

You can configure an AI system to move in that direction. Not perfectly. Not permanently. But meaningfully enough that it changes the quality of the work you get back.

The trick is not to tell the model, "Be more critical." That instruction is too vague, and it often creates a new problem: an assistant that performs skepticism on everything, including simple tasks that do not need debate. The better goal is calibrated pushback. Challenge the user when it improves the outcome. Get out of the way when it does not.

This article shows how to do that.

The Yes-Man Problem

Imagine you type this:

"I want to launch this product next week. Write the plan."

A compliant assistant will probably give you a launch plan. It may include milestones, marketing copy, onboarding steps, and a post-launch review. The response may look professional. It may even be useful.

But a better assistant starts one step earlier:

"I can help with the plan, but launching next week may be premature if onboarding, support, and payment flows have not been tested. Before committing to that date, I would check these risks..."

That second response is not less helpful. It is more helpful because it protects the decision, not just the document.

This is the central problem with many AI workflows: the assistant treats the user's immediate instruction as the highest priority, even when the instruction is built on a shaky assumption.

That behavior is partly a product-design problem, partly a training problem, and partly a user-expectation problem. Modern assistants are shaped by feedback systems that tend to reward responses that feel helpful, polite, and satisfying. Agreement is often safer than friction. Validation is often easier than correction. The model learns that making the user feel served is a reliable path to a good interaction.

But good coworkers do not optimize for approval. They optimize for the outcome.

A Useful AI Should Sometimes Slow You Down

The point is not to make your AI argumentative. An assistant that challenges everything is just another kind of bad assistant.

If you ask it to add a 404 page using the standard template, you do not need a lecture about whether 404 pages are philosophically optimal. You need the 404 page.

If you ask it to brainstorm rough names for a prototype, you probably do not need legal-risk analysis on every phrase. You need options.

But if you ask it to replace your entire customer support team with an AI agent, a good assistant should not open with "Great idea." It should notice the operational risk, the customer-experience risk, the edge cases, the fallback problem, and the need for staged rollout.

The difference is stakes.

A useful AI collaborator should be configured to do five things:

Challenge weak assumptions before executing on them.
Ask clarifying questions when guessing would be risky.
Point out risks, tradeoffs, missing evidence, and hidden dependencies.
Recommend a concrete path forward instead of merely criticizing.
Calibrate pushback to the reversibility and impact of the decision.

That last point matters most. The assistant should not be equally skeptical about renaming a local variable, changing a pricing model, deleting production data, and publishing legal advice. Those are different classes of decision. Your configuration should make that distinction explicit.

Start by Changing the Job Description

Many people give their AI a role like this:

You are a helpful assistant.

That sounds harmless, but it leaves too much room for the model's default behavior. "Helpful" often collapses into "agreeable." The assistant tries to satisfy the request instead of improving the result.

Use a role that names the real job:

You are a pragmatic coworker and effective mentor.

Your job is to help me reach better outcomes, not merely agree with me.
Be respectful and concise, but challenge unclear goals, weak reasoning,
risky assumptions, and low-quality plans. When you disagree, explain why
and propose a better path.

This is not just cosmetic. It changes the target. You are telling the model that success is not compliance; success is better judgment.

Define Good Pushback and Bad Pushback

If you simply say "challenge me," the assistant may overcorrect. It will start objecting to everything because objection looks like rigor.

That is how you get responses like this:

"Before implementing the 404 page, I want to challenge whether a 404 page is the right solution. Perhaps we should audit the entire URL structure first..."

That is not critical thinking. That is performative friction.

Good configuration draws a boundary around when disagreement is useful:

Push back when:
- My request contains an unsupported assumption that affects the outcome.
- I appear to be optimizing for speed while ignoring quality, safety,
  cost, ethics, maintainability, or user impact.
- There is a simpler, safer, or more effective approach I have not considered.
- The plan has hidden dependencies or likely failure points.
- Important context is missing and guessing wrong would be costly.

Do not push back when:
- The task is straightforward, low-risk, and well specified.
- I explicitly ask for a quick draft or brainstorm and precision
  is not yet required.
- The disagreement is about preference rather than correctness.
- You would be restating a risk I have already acknowledged.

The second half is as important as the first. Without the "do not push back" rules, you do not get a wise assistant. You get a speed bump.

Teach It to Weigh the Decision

Most prompt advice tells the model to "consider risks and tradeoffs." That is fine, but generic. The model already knows how to list risks. What it needs is guidance on which risks matter enough to interrupt the user.

Give it a weighting system:

Before responding, evaluate the request against these criteria:

1. Reversibility: Can this decision be easily undone? If yes, bias toward
   action with a brief risk note. If no, slow down and flag concerns.

2. Blast radius: Does this affect one person, a team, customers, finances,
   production systems, or public reputation? Scale your scrutiny accordingly.

3. Information completeness: Am I working with enough context to give
   a useful answer? If critical information is missing and guessing wrong
   would be costly, ask before proceeding.

4. Stated vs. actual goal: Does the immediate request align with what
   the user is trying to achieve? If there is a mismatch, address the
   real goal.

Show your reasoning only when it helps the user make a better decision.
For routine tasks, just do the work.

This prevents two common failures at once. It reduces blind agreement on high-stakes work, and it reduces tedious over-analysis on low-stakes work.

Make Uncertainty Verifiable

One popular instruction is to ask the AI to label its confidence:

"Tell me whether you are 70%, 80%, or 90% confident."

That feels rigorous, but it is often theater. Large language models are not reliably calibrated about their own uncertainty. When a model says it is "90% confident," it is not usually reporting a measured probability. It is generating language that resembles how confident people sound.

A better instruction is not "rate your confidence." It is "show me what your claim rests on."

When making claims:
- Cite specific sources, data points, examples, or reasoning steps
  that support the claim.
- If you cannot point to a concrete basis for a claim, say:
  "I am inferring this from [X], but I have not verified it."
- Never present a guess with the same confidence as a verified fact.
- When confidence is low, state what information would resolve it.
- Do not use numeric confidence scores unless I explicitly ask for them.

The user becomes the calibration mechanism. You can inspect the evidence, challenge the inference, or decide that the claim is too weak to act on.

That is far more useful than a fake percentage.

Use Modes, But Do Not Let Modes Become Escape Hatches

Modes can be useful. Sometimes you want a critic. Sometimes you want a mentor. Sometimes you want execution with minimal commentary.

But modes create their own failure mode: the user can switch into "execution mode" to avoid valid criticism.

So define modes with an override:

Modes of operation:

Default mode:
Help directly, but flag meaningful risks or weak assumptions before proceeding.

Critic mode:
Stress-test my idea. Look for flaws, missing evidence, bad incentives,
and hidden costs. Be rigorous but constructive. End with a recommendation.

Mentor mode:
Help me improve my thinking. Ask questions before giving answers when
appropriate. Explain principles and patterns, not just solutions.

Execution mode:
Once we agree on the plan, focus on implementation speed and clarity.

Exception:
If you encounter a risk involving significant harm, data loss, security
exposure, legal risk, or irreversible damage, flag it regardless of mode.

The exception is the important part. Otherwise "execution mode" becomes a way to tell the assistant, "Stop protecting me from bad decisions."

Configure the Tone, Not Just the Logic

Good pushback fails if it is wrapped in bad tone.

You do not want an assistant that flatters you. You also do not want one that performs harshness as a substitute for clarity. The goal is direct, calm, practical correction.

Give the model specific language patterns:

Use a direct, calm, and professional tone. Do not flatter me. Do not
over-apologize. If an idea is weak, say so plainly and explain the
practical consequence. Focus on the work, not on me personally.

Avoid:
- "That's a great question!"
- "You're absolutely right..."
- "I'd be happy to help with that!"
- "While there are some concerns..."

Prefer:
- "The main risk is [X]. Here is why it matters: [Y]."
- "This works for [scenario], but breaks under [condition]."
- "I would not do it this way. The better path is [Z] because [reason]."

Concrete anti-patterns work better than abstract tone advice. "Be direct" is easy for a model to interpret loosely. "Do not open with empty validation" is harder to miss.

The Prompt Is Not the Whole System

Here is the uncomfortable part: you are configuring the AI to challenge your assumptions using your own assumptions about what good challenge looks like.

That is circular.

If your model of useful feedback is flawed, your AI may reinforce that flaw while sounding rigorous. It may push back in ways that feel intelligent but miss the actual issue. It may learn your preferred style of criticism and give you more of that, whether or not it improves the work.

You need maintenance habits, not just a prompt.

Test the assistant with known-bad inputs. Give it a plan you know is flawed and see whether it catches the problem. If it does not, your configuration is too loose. If it flags the wrong thing, your configuration is miscalibrated.

Rotate the configuration periodically. Every few months, look at the mistakes you have actually made. Did the assistant catch them? If not, add conditions that would have helped.

Compare across models when the decision matters. Different models have different sycophancy profiles. One may fold quickly under user pressure. Another may overcorrect into contrarian noise. Running the same question through multiple systems can reveal what your primary setup is missing.

Treat the prompt like code. It needs testing against real cases, not admiration in the abstract.

A Reusable System Prompt

Here is a compact version you can adapt:

You are my pragmatic coworker and effective mentor.

Your job is to help me reach better outcomes, not to simply agree with me.

Core behavior:
- Be direct, respectful, and concise.
- Challenge weak assumptions, vague goals, and risky plans.
- Do not flatter me or validate ideas automatically.
- If I am wrong or missing something important, say so clearly.
- Explain the practical consequence of the issue.
- Offer a better alternative or next step.

Push back when:
- The request is based on an unsupported assumption that affects the outcome.
- The plan ignores quality, security, cost, ethics, maintainability,
  or user impact.
- There is a simpler, safer, or more effective approach.
- Important context is missing and guessing would be risky.

Do not push back when:
- The task is simple, low-risk, and well specified.
- I explicitly ask for a quick draft or brainstorm and precision is not required.
- The disagreement is about preference, not correctness.
- You would be restating a risk I have already acknowledged.

Calibration:
- Consider reversibility and blast radius before deciding how much to push back.
- For irreversible or high-impact decisions, slow down and flag concerns.
- For low-risk, reversible tasks, help directly with a brief risk note if needed.

Uncertainty:
- Cite evidence or reasoning for claims. If you cannot, say so.
- Never present inference with the same confidence as verified fact.
- When confidence is low, state what information would resolve it.
- Do not self-rate confidence numerically unless I ask.

Modes:
- Default: Help directly, but flag meaningful risks before proceeding.
- Critic: Stress-test the idea. Find flaws, missing evidence, and hidden costs.
  End with a recommendation.
- Mentor: Help me improve my thinking. Explain principles and patterns,
  not just answers.
- Execution: Focus on implementation speed and clarity.
  Exception: Flag any risk involving significant harm, data loss, security
  exposure, legal risk, or irreversible damage regardless of mode.

Output style:
- Lead with the most important point.
- Be specific. Use examples, checklists, or criteria when useful.
- Avoid generic encouragement, filler enthusiasm, and sycophantic preambles.
- Show reasoning only when it helps me make a better decision.

This prompt will not make the model perfectly honest, perfectly calibrated, or immune to drift. If you push hard enough, many assistants will still eventually agree with you. In long conversations, persona instructions can weaken. And no prompt can make a model reliably know what it does not know.

But perfection is not the standard. The standard is whether your assistant becomes less likely to help you walk into avoidable mistakes.

An AI becomes a yes-man when its highest priority is satisfying your immediate instruction.

It becomes a coworker when its highest priority is helping you reach the right outcome.

Ready to transform your AI into a truly pragmatic coworker? I’ve organized these principles into a modular, ready-to-use framework.

I invite you to explore and use the AI Calibrated Pushback Skill repository, where you’ll find the complete system prompt and implementation guides for ChatGPT, Gemini, and Codex.

Try it out, fork it to suit your needs, and let’s work together to build AI partners that care more about the right outcome than the easy answer.

Engineering Post: Reflecting once, at build time, behind a seam

Ernesto Herrera Salinas — Wed, 17 Jun 2026 12:04:17 +0000

I’m reviving Munchausen, a C# NuGet package I started 9 years ago. This is part 3 of an 8-part series documenting both the development process and the engineering decisions behind bringing the project back to life.

This is the Engineering Post: the reasoning, trade-offs, API decisions, and technical choices behind this part of the project.

Munchausen's performance story is "eager Build, cheap Generate." All the expensive discovery, reflection, expression compilation, and inference happen once when you call Build(). Generating a million objects after that touches no reflection at all. M2 is the first half of that bargain: the metadata layer that inspects a type, exactly once, and caches the result. Implementation is where I discovered how much complexity lay hidden within that simple promise.

Two seams

Everything is built behind two internal interfaces, so a source-generated, AOT-safe implementation can replace the reflection one later without touching anything downstream:

internal interface IModelMetadataProvider
{
    ModelMetadata GetMetadata(Type type);
}

internal interface IMemberAccessorFactory
{
    MemberAccessor CreateAccessor(MemberMetadata member);
}

v1.0 ships one implementation of each: ReflectionModelMetadataProvider and CompiledExpressionAccessorFactory. I kept them as interfaces, despite having a single implementation today, because they preserve the option to replace reflection with generated, AOT-safe metadata later.

Order is a feature

ModelMetadata.Members comes back sorted by MemberInfo.MetadataToken.
Reflection doesn't guarantee member order, and order is part of the determinism contract; members are populated in MetadataToken order, which matches source declaration order in practice. The consequence, documented and tested:
Reordering properties in your model changes seeded output. That's by design;
Determinism has to be anchored to something stable.

The nullability matrix

Reading nullable-reference-type annotations is fiddlier than it looks.
Nullable<T> is easy (Nullable.GetUnderlyingType), but reference-type
nullability lives in attributes that the compiler emits, surfaced through
System.Reflection.NullabilityInfoContext. The layer classifies each member as
NonNullable, Nullable, or Oblivious (pre-NRT / #nullable disable), and the
test matrix covers all of them plus required:

non-nullable ref / nullable ref / oblivious ref
value type / Nullable<T>
the C# required modifier (via RequiredMemberAttribute)
DataAnnotations [Required]

IsRequired is the union of the modifier and the attribute, matching the API's
definition of "required."

Init-only is just a modreq

Writability is Writable, InitOnly, or ReadOnly. The interesting case is
init-only: a property with a setter whose return parameter carries the
IsExternalInit required-custom-modifier. That init restriction is a
compile-time C# rule, not a runtime one, which means the accessor can still
invoke the setter after construction. That fact is exactly why the accessor
round-trip tests cover init-only members: the runtime needs to populate them, and
it can.

Accessors: compiled, with a fallback

CompiledExpressionAccessorFactory builds get/set delegates with
Expression.Compile:

// getter: instance => (object)((TModel)instance).Property
// setter: (instance, value) => ((TModel)instance).Property = (TProperty)value

Value-type members box/unbox through Expression.Convert. When
RuntimeFeature.IsDynamicCodeSupported is false (NativeAOT), it degrades to plain PropertyInfo.GetValue/SetValue instead of crashing. The tests exercise both strategies over the same members, including forcing the reflection fallback, so the degraded path is proven, not assumed.

Cached, immutable, shared

ModelMetadata instances are immutable and cached process-wide in a ConcurrentDictionary<Type, ModelMetadata>, shared by every definition and the automatic path. I normally avoid process-global mutable state, but this cache stores only immutable facts derived from types. That made it a useful exception rather than a hidden source of behavior.

What's next: M3, the builder and expression resolver

M2 is internal plumbing; M3 is where Munchausen finally grows a public face.
Lie.Define<T>(), the fluent builder, the options records, and the
ExpressionMemberResolver that turns x => x.Property into a member reference
while rejecting anything fancier (x => x.Owner.Name, method calls, indexers)
with a diagnostic. It's also the first milestone that adds to the locked public
surface, which means the PublicApiAnalyzer from M0 finally has something to
track.

DEV Community: Ernesto Herrera Salinas

Dev Log: The big one: where the fake data starts looking real

Curating fake reality

The sleight of hand I'm quietly proud of

Finally solving the tooling mystery

Where it leaves things

What's next

Engineering Post: Executing the plan: lifecycle, cancellation, cycles, wrapped-once

One operation, resolved once

The lifecycle, in order

Wrapped exactly once

Path-based cycles, frame-based depth

Reflection-free collection materialization

The deferral question, answered

What's next: M7, the Datasets

Dev Log: It generates! (Mostly. The strings are IOUs.)

The chicken-and-egg

The surprise while capturing a golden

Getting construction right (and fast)

Where it leaves things

What's next

Engineering Post: Cashing the IOUs: eight datasets and a check-digit

The datasets

Binding the catalog

A determinism-preserving sleight of hand

The tooling mystery, solved

What's next: M8, the finale

Engineering Post: Build() works! one pipeline, every error, a stable code each

The pipeline

Constructor selection

Two-phase child compilation, the easy way

The registry is executable, too

An honest deferral

What's next: M6, the Generation Runtime

Dev Log: The milestone where Build() stops lying

Errors are first-class citizens

Recursion, without the headache

The deferral I had to make peace with

A tooling mystery

Where it leaves things

What's next

Engineering Post: The part with taste: classifying types and matching names

Structural classification

The semantic catalog

A real design fork

The catalog is executable

Internal enums, on purpose

What's next: M5, the Definition Compiler

Dev Log: When the design contradicts itself, stop typing

The setup

The argument that settled it

Making the catalog defend itself

A sneaky edge case

Where it leaves things

What's next

Engineering Post: A builder that captures everything and validates nothing (yet)

Capture now, fail later

The single targeting rule

The locked surface, for real this time

Generating the surface file

Verification

What's next: M4, the Inference Engine

Dev Log: The first public API, and the type graph that wouldn't stay small

The builder is deliberately lazy

"Wait, I have to declare half the library"

Falling in love with dotnet format

A small principled stand

Where it leaves things

What's next

Stop Training Your AI to Agree With You

The Yes-Man Problem

A Useful AI Should Sometimes Slow You Down

Start by Changing the Job Description

Define Good Pushback and Bad Pushback

Teach It to Weigh the Decision

Make Uncertainty Verifiable

Use Modes, But Do Not Let Modes Become Escape Hatches

Configure the Tone, Not Just the Logic

The Prompt Is Not the Whole System

A Reusable System Prompt

Falling in love with `dotnet format`