Frame Analysis of PatLang: Four Concepts, Four Real Episodes

FrameFrame Analysis for Software sets out Goffman's four concepts in the abstract: primary framework, keying, fabrication, and frame break. This page does the opposite — it starts from four real, already-documented moments in PatLang's own development history and asks which of the four each one actually is. The point of doing this concretely, rather than staying at the level of software engineering in general, is that PatLang's development history is unusually well-documented at exactly the grain frame analysis needs: not just what happened, but what someone believed was going on at the time, and how that belief was revised.

Primary framework: what "done" is even allowed to mean

AA primary framework is the background scheme that makes an entire domain of activity intelligible in the first place — it's rarely stated, because everything built on top of it treats it as simply how things are. PatLang has one, stated as an explicit standing rule rather than left implicit: no feature counts as finished until it produces byte-identical output across three separate ways of running a program — interpreted, natively compiled, and compiled by PatLang's own self-hosted compiler.

This is a primary framework rather than just a policy because of what it does silently, in the background, to everything downstream of it: it redefines what a bug even is. Under a weaker framework — "does it run correctly once?" — a large fraction of PatLang's most instructive documented bugs would never have been bugs at all; they'd have been invisible agreements between two things that were both quietly wrong in the same way, never exposed because nothing forced a third, independent perspective into the comparison. The frame doesn't just set a bar for quality; it determines which category "correct" and "incorrect" even sort into.

Keying: an activity patterned on the real one, understood as something safer

AA keying transforms an already-meaningful activity into something that looks patterned on it but is understood, by whoever's performing it, as a different kind of activity — a rehearsal is a keying of a performance. PatLang's development history has a clean, documented instance of this happening by accident rather than by design, which is arguably more useful pedagogically than a deliberate one: a GUI demo intended to show off file-writing produced its output using print(page) rather than the real write_file(...) call the feature was actually about. The demo looked like — and was built to look like — a demonstration of the write-file feature. It was actually a keying of that activity into something safer: printing text to a console, which sidestepped a real, unfixed bug in the WASI compatibility shim that write_file depended on.

The interesting failure here isn't that the bug existed — it's that nobody involved in building the demo was consciously aware a keying had taken place. The demo's author believed they were demonstrating the real activity, not a transformation of it that happened to avoid its broken part. This is exactly the risk Goffman's concept flags: a keying only stays honest as long as everyone involved knows it's a keying. The moment that awareness lapses — even innocently, even without anyone deciding to cut a corner — a demonstration of X quietly becomes a demonstration of "something that resembles X, minus whichever part happened to be broken," and nothing about watching it succeed tells you which one you actually saw.

Fabrication: when the frame itself becomes the thing that's wrong

FabricationFabrication is Goffman's term for a one-sided keying — one party manages what another believes is going on, without the second party's awareness that any transformation has occurred. PatLang's own development history contains a structural version of this that's worth taking seriously precisely because it wasn't the result of anyone intending to deceive: a results registry for the language's inductive synthesis engine held both genuine search results — code the engine had actually found through search — and hand-written fallbacks a developer had written directly, distinguished from one another only by an optional metadata field nobody was required to check.

Anyone reading a result out of that registry and reporting "the synthesis engine found this" was operating under a frame — this is a genuine discovery — that, for some entries, simply wasn't true. That's fabrication in Goffman's precise sense, regardless of the complete absence of any intent to mislead: what makes something a fabrication isn't motive, it's the gap between what a reader is led to believe is going on and what's actually going on. It was caught the same way most fabrications of this kind get caught — not by a test failing, but by someone's plain suspicion ("I'm rather nervous these are hand-authored") turning out, on inspection, to be exactly right. The fix is worth noting as a design principle in its own right: the correction wasn't "remember to check the flag more carefully" — it was removing the shared frame entirely, by giving the two kinds of result physically separate directories and separate writer functions with no code path capable of blurring them. A fabrication risk that depends on a person remembering to check a marker will eventually recur; one that's been made structurally impossible won't.

Frame break: when the evidence was never actually wrong

AA frame break is the specific, disorienting experience of a frame simply stopping fitting the evidence, forcing a shift to a different one before anything makes sense again. PatLang's history has a textbook example: a compiler error reported a specific line number in what appeared to be an unambiguous way, and two separate investigation cycles were spent scrutinising that exact file at that exact line, on the operating assumption that the report was straightforwardly about the file currently being edited. It wasn't. A hidden preprocessing step meant the line number was accurate — but about an entirely different file, one nobody had thought to check because the frame in place made checking it seem unnecessary.

Notice what the diagram makes visible that a purely verbal account can slide past: the evidence at every stage was accurate. The line number was correct. The file compiled the way the error said it would. Nothing was lying. The frame — "this report describes the file I currently have open" — was simply the wrong lens, and no amount of re-examining the same evidence more carefully from inside that lens was ever going to surface the problem, because the problem wasn't in the evidence. It was in the assumption that made the evidence legible in the first place. The fix, once the frame broke, took moments; the two cycles that preceded it were spent doing careful, competent work inside a frame that had already stopped being true.

Why this is worth doing as a set, not one at a time

ReadingReading these four side by side rather than in isolation makes a point none of them makes alone: three of the four (keying, fabrication, frame break) describe failure modes — moments where a frame slipped, was misapplied, or turned out to be false. The fourth, primary framework, is the thing that has to exist and be sound before any of the other three can even be evaluated as failures rather than as simply "what happened." PatLang's three-path parity rule doesn't prevent keyings, fabrications, or frame breaks from occurring — all three of the examples above happened despite it. What it does is guarantee that they eventually surface, because a keying, a fabrication, and a frame break all share one property: they produce an answer that's wrong in a way a second, independently-arrived-at answer won't quietly agree with. A primary framework built around forcing that second, independent answer to exist is, in effect, a standing commitment to eventually catching the other three — not preventing them, but refusing to let them stay hidden indefinitely.