DEV Community: Chad Augur

Let's Define Undefined

Chad Augur — Tue, 22 Sep 2026 07:00:00 +0000

Falsifiable Defaults and the Semantics of Undefined

Artikulates Resilient GitHub repository
Artikulates Resilient npm package

There is a small habit in JavaScript that carries a surprisingly large amount of meaning: reaching for undefined whenever a value is absent, empty, failed, or not yet understood.

The habit is understandable. undefined is available everywhere, falsy, and often harmless until a later operation needs a string, an array, a number, or a function. But using one representation for all of those states asks it to say more than it can.

Resilient treats absence more narrowly. When a contract has an executable empty form, that form should remain inside the contract. undefined is reserved for a different fact: no contractual value has been supplied or produced.

That distinction does not make a program more certain than it is. It gives uncertainty, absence, and falsification separate places to live.

A default says something

In The Code Is the Contract, defaults carry executable meaning. They describe what a boundary does with absence, and that meaning has to agree with the operations that follow.

const readTitle = ({ title = '' } = {}) => title.trim();

The default does not validate arbitrary input. 42 is still not a string. It does establish what this function will receive when title is omitted or undefined: an empty string, on which trim() remains an ordinary operation.

That is more than a defensive convenience. The boundary has made an agreement visible. It says that absence of text is expressed here as text with no characters.

The default carries the agreement

Where a falsifiable default is feasible, it is not merely one signal among many. It is the primary carrier of the agreement. In Resilient's grammatical convention of the destructured signature, the signature declares the shape a function receives and its defaults declare the usable values that stand for absence within that shape.

const renderArticle = ({
    title = '',
    tags = [],
    metadata = {}
} = {}) => ({
    title: title.trim(),
    tags: tags.map(tag => tag.trim()),
    metadata
});

This is not a prose description placed beside the boundary. It is executable evidence. title begins as a string agreement, tags as an array agreement, and metadata as an object agreement whenever the corresponding property is absent or undefined. The operations and return path can be checked against those same agreements without first widening each one into a nullish alternative.

For the analyzer, this is the beginning and end of the local path: read the destructured signature, follow the agreements through their operations and guards, and require every reachable normal return to preserve the promised families. The default is therefore a compact, executable statement of both absence behavior and continuation behavior. It does not validate an arbitrary incoming value, but it gives the analyzer—and the next participant—a known agreement when absence is the case the boundary has chosen to handle.

The same pattern is available across familiar value families:

const count = 0;
const enabled = false;
const title = '';
const items = [];
const record = {};

Each value remains usable according to its family:

count + 1;
enabled === false;
title.trim();
items.map(item => item);
Object.keys(record);

Each can also participate in a falsifiable observation:

!count;             // true
!enabled;           // true
!title;             // true
!items.length;      // true
!hasContent({});    // true

The array and the object are themselves truthy. Their emptiness needs a more specific observation: an array's length, and an object-content guard such as hasContent. That small difference is important: a test should say what it is actually testing.

Falsifiable does not mean invalid

A falsifiable value is still a valid member of its contract.

0 does not stop being a number because !0 is true. false does not stop being a boolean. An empty string remains a string, an empty array remains an array, and {} remains an object. The value family and its available operations survive the negative observation.

What that observation means belongs to the participant consuming the value.

if (!count) return;

const next = count + 1;

In the first scope, zero stops the operation. In the second, it is a useful operand. Neither reading changes the producer's numeric agreement.

This is the grammar of falsifiable defaults in Resilient. Success and a falsifiable condition do not require different value families:

string  → string
array   → array
object  → object
number  → number
boolean → boolean

The consumer may decide to stop, continue, render, calculate, filter, or assign the value. The producer has not abandoned its agreement merely because the consumer can make a negative observation about its contents.

That matters to static analysis as well as runtime behavior. A producer that returns an empty array can still promise an array. Its consumer can ask the question that belongs to array content:

if (!items.length) return;

It does not first need to resolve whether the producer returned an array or withdrew from the array contract. Preserving the value family preserves the operations the next participant is entitled to use.

Empty needs the right test

An empty default does not make every family falsifiable through bare truthiness. JavaScript makes both [] and {} truthy. A contract that requires collection members or record fields needs a content test that establishes that condition directly.

const hasArrayContent = (value = []) => (
    Array.isArray(value) && !!value.length
);

const hasContent = (value = {}) => (
    Object.prototype.toString.call(value) === '[object Object]' &&
    !!Object.keys(value).length
);

These synthetic tests construct the observation that truthiness alone cannot provide. More importantly, they let the consuming scope ask whether the agreement it needs has been established. An empty array or object retains its family; a failed content test falsifies the content agreement where that scope requires content.

if (!hasContent(record)) return;

const { title = '' } = record;

The first line asks whether this scope has the record content it needs. The second still receives an object-shaped value and can use the object agreement. The guard owns the consequence of the failed content test; the empty default does not itself force control flow.

Falsification is therefore about agreement, not a universal verdict on a value. An object-content test does not declare every empty object invalid, and an array-length test does not validate every member. Each test establishes only the condition the present agreement asks it to establish.

What is left for `undefined`?

Once established contracts can express their own falsifiable states, undefined no longer has to serve as the universal negative member of every contract.

It can say something narrower and more useful: no contractual value has been supplied or produced.

const count = 0;       // a Number has been established
const enabled = false; // a Boolean has been established
const title = '';      // a String has been established
const items = [];      // an Array has been established
const record = {};     // an Object has been established
let func;              // no Function has been established

This is not a claim that 0, false, '', [], and {} share one universal meaning. They do not. It is a claim that each already gives the receiver a value in the promised family, while func has not yet established a callable value at all.

The distinction keeps several states from collapsing into one another:

falsifiable value ≠ undefined
undefined         ≠ contradiction
unknown           ≠ undefined
unknown           ≠ contradiction

A known zero is not unknown. A known false is not absent. An empty string has not failed its string contract. An unknown external payload should not become undefined merely because the application has not yet established its contract. Each state carries different evidence, and collapsing them creates more ambiguity for both the developer and the analyzer.

The edge exposed by functions

Functions make the distinction difficult to ignore. There is no falsy callable function in JavaScript.

const defined = {
    func: () => {}
};

This function does nothing, but it still exists. It is callable and truthy:

typeof defined.func === 'function'; // true
!!defined.func;                     // true

Supplying an empty callback therefore makes a real claim on behalf of the participants: an implementation is present. It may be a no-op implementation, but it is not the absence of one.

let func;

const unresolved = { func };

Here the property is present, but no callable value has been supplied. The receiver still has a decision to make. Not knowing whether an implementation exists is the condition being represented.

That is the edge of falsifiable defaults. An empty string can preserve a string agreement; an empty array can preserve an array agreement. A no-op callback cannot preserve the agreement that no callback has been established.

The receiver owns the decision

A function boundary may require a callable value. It may also allow its absence, provided it guards the call in its own scope.

const notify = (func) => {
    if (!isFunction(func)) return; // return here acts as a break on the side-effect

    func(); // this is a side-effect nothing is returned from notify directly. 
};
// Isolation of side-effects will be a later blog

The guard makes the decision visible. If the value is callable, execution proceeds. Otherwise, the function ends without producing a return value.

The scope of that conclusion matters. notify() also returns no value after a valid callback runs, so its result does not prove whether the callback ran. Boolean conversion alone also does not distinguish undefined from every other falsy value. Test callability when the operation needs a function; test a result only when the next operation depends on that result.

This is the producer-and-consumer division described throughout Resilient: the producer owns the agreement it offers, and the consumer owns the interpretation needed in its own scope. A guard knows enough to stop. It does not need to invent an implementation for one that was never supplied.

The language meaning of `undefined`

The ECMAScript specification defines the undefined value as the primitive value used when a variable has not been assigned a value. It defines the Undefined type as the type whose sole value is that value. Section 8.1 reiterates the relationship: the type contains one value, and an unassigned variable has that value.

That is not a side note to this argument. It is the ground on which the contractual reading stands. ECMAScript establishes the language mechanics: undefined is the primitive value of an unassigned variable. Resilient does not attempt to redefine that fact. It asks what that available language expression should mean when participants use it to make agreements in an application.

JavaScript permits explicit assignment of undefined. A dialect still has to decide which permitted expressions belong in its grammar. For Resilient, the meaning begins with the state named by the specification: a value has not been assigned. The runtime represents that state with undefined; within the dialect, it communicates something left undefined.

The same restraint applies to a bare return. No return value is supplied, and the caller receives undefined as the outcome. The language supplies the value; the program has still said that its path did not produce one.

An outcome, not a catch-all assignment

Consider the difference in authored intent:

let func;

No implementation has been supplied.

func = undefined;

An assignment has been made. If a function existed before, a known value has been cleared, invalidated, or withdrawn. Those are actions with meanings of their own, and the resulting value does not reveal which action occurred.

Resilient therefore treats undefined most clearly when it arises from what was not supplied or what was not produced: an uninitialized binding, an omitted result, or a guarded path that deliberately does not continue. When an action has a known domain meaning, its contract should express that meaning rather than hiding it behind a catch-all assignment.

JavaScript cannot reconstruct this history from the resulting value. The distinction belongs to the authored code and to the discipline used to read it. That is part of what makes Resilient a dialect: participants agree on how the language's available expressions will be used.

Let's define `undefined`

The point is not to ban undefined, or to make every absence look like an empty collection. It is to stop asking one value to carry incompatible facts.

An empty default is not a placeholder. It is a falsifiable expression of an established agreement: [] says an array is here, even when it has no members; {} says an object is here, even when it has no own content; '', 0, and false remain values in their respective families. Their consumers decide what follows when the agreement's content test fails.

undefined says something prior to that agreement. No contractual value was supplied or produced. It is not the empty array, the empty object, a failed string, an unknown external payload, or a known contradiction. It is the remaining language value for something genuinely left undefined.

That is the discipline Resilient needs from its defaults and its analysis. Let a destructured signature establish the agreement it can honestly carry. Let a falsifiable default preserve that agreement through its empty form. Let a guard decide whether the present scope can continue. And when no value has been established, let undefined say exactly that.

Let falsifiable defaults carry agreement. Let the unknown remain unknown. Let undefined mean something was actually left undefined.

The Fallacy of the “Unknown Cliff” in Modern Web Applications

Chad Augur — Wed, 16 Sep 2026 00:11:43 +0000

Artikulates Resilient GitHub repository
Artikulates Resilient npm package

What dynamic data does—and does not—take away

Modern web applications are built at the meeting point of two kinds of knowledge.

Inside the application, the source can tell us a great deal. A function tells us what it accepts and what it returns. Defaults describe what absence means. Operations reveal what a value is expected to do. Those agreements can be followed through functions, modules, components, and transformations.

Then the application meets something it does not own.

An API returns a payload. A user submits a form. A database provides a record written by an earlier version of the application. A browser API, cache, feature flag, or third-party service introduces a value whose runtime contents are not established by the local source.

Something important has changed.

It is tempting to imagine this transition as an unknown cliff. On one side, the program is understandable. On the other, the evidence disappears, and with it our ability to say anything useful. The external value is unknown, therefore everything that depends on it becomes unknowable.

That conclusion asks uncertainty to do far more work than it deserves.

Unknown data marks the point where one source of evidence ends. It does not erase the contracts surrounding that value, the operations performed upon it, or the agreements established after it enters application ownership.

Unknown is a boundary marker, not a collapse of meaning.

That distinction matters because modern applications live at boundaries. The interesting question is not whether those boundaries can be made statically certain.

They cannot.

The question is what we can still know when certainty ends.

The cliff is an attractive story

Consider a fairly ordinary API path:

const response = await fetch('/api/profile');

if (!response.ok) {
    return { name: '' }; // creates disagreement
}

const profile = await response.json();

return profile.name.trim();

// even profile?.name?.trim() produces an unreliable contract while avoiding a null check.

There is nothing especially reckless here.

response.ok establishes that the request succeeded. json() establishes that the response body could be decoded into a JavaScript value.

Neither establishes that the value is a profile.

The agreement may be real. The API is expected to return a profile. The application was written against that expectation. Tests, documentation, schemas, and the implementation on the other side may all reinforce it.

The local source cannot establish whether that agreement is being fulfilled now.

That is where the cliff becomes attractive.

One response is to call the payload unknowable and stop reasoning at the network boundary. Another is to let a local description stand in for the external agreement and continue as though the value has been proven.

Both claim too much.

The first throws away evidence the application still has. The second invents evidence it does not.

The boundary is smaller than either suggests:

external system → unknown value → owned boundary → application value

The unknown belongs exactly where the evidence ends.

The application can then take responsibility for the value and establish the agreement its own code needs.

But calling something a parser does not make it a boundary:

const parseProfile = ({ name = '' } = {}) => ({ name });

That establishes what absence means. It does not establish that name is usable as the application expects. 42 still becomes { name: 42 }.

Ownership requires more than moving the value through a conveniently named function. The boundary has to produce the contract it claims to establish.

const normalizeProfile = ({ name = '' } = {}) => ({
    ...(!!name && !!(name.trim) && {
        name: name.trim()
    })
});

const response = await fetch('/api/profile');

if (!response.ok) {
    return renderProfile({});
}

const data = await response.json();

const { name = '' } = normalizeProfile(data);

return renderProfile({ heading: name.toUpperCase() });

Nothing here proves more about the API. A successful response means the request succeeded. Decoding JSON means the body became a JavaScript value. Neither tells us that data is a profile.

normalizeProfile is where this application makes its own, narrower decision. For this path, a profile is something from which the application can produce a usable name, or an absent name. That is the handoff.

After that handoff, name.toUpperCase() is ordinary code. It is not checking the API again. It is using the limited string agreement that the boundary has already established.

The remote system remains responsible for what it sends. The local boundary is responsible for the promise it makes to the rest of this application. That is where uncertainty stops being an excuse to stop reasoning and becomes a specific responsibility in the code.

Unknown is not contradiction

Unknown means that the available evidence has not answered a question. It does not mean that the value has failed. It means the program has reached the limit of what this source can honestly say.

Contradiction is different. It is the moment the available evidence reveals that two claims cannot both hold. A contradiction gives us a path to graceful degradation; the expected shape is not available and will not continue through the stack. An unknown gives us a question that remains open.

That distinction keeps uncertainty in proportion. An unresolved value does not spread outward and erase the contracts, operations, and consequences the rest of the application still exposes. It remains at the point where the evidence ran out.

And because it remains contained, it has an owner. The boundary that receives it can reject it, interpret it, normalize it, or deliberately carry it forward. The unknown is not a cliff beyond which reasoning stops. It is a responsibility with a location.

The agreement keeps moving

The important consequence of a local boundary is not that it has made the outside world predictable. It is that the rest of the application no longer has to act as though the outside world is the only fact that matters.

The profile has crossed a line. On one side is a value whose contents the application cannot establish from its own source. On the other is a small, ordinary agreement that local code can use. That agreement can be passed to a component, returned from a function, stored in state, or transformed again. Each new use has its own responsibility, but it does not begin at unpredictable shapes each time.

This is what lets an application grow without making every function an integration layer. The boundary contains the question that belongs to the external system. The rest of the program can remain about the work it was written to do.

The integration boundary

The boundary has another side. The normalizer can make an honest promise to the application, but it cannot establish that the remote service is continuing to keep its promise. That agreement has to be exercised where it exists: between the application and the service.

This is what an integration check is for. Send the request. Inspect the status and the response. Confirm that the service still produces the behavior the application depends on. A tool such as Postman is useful here not because it makes the response statically knowable, but because it crosses the boundary and asks the system itself.

That evidence belongs beside the executable agreement, not in competition with it. The local code tells us what the application will do. An integration check tells us whether the profile service is still supplying the kind of response that made that choice sensible. One follows the agreement inside the program. The other tests the agreement between programs.

Together, they give a web application a more realistic kind of confidence. The code remains legible when the network is not present. The integration boundary remains testable when the network is. Neither has to pretend to do
the other's work.

There is no cliff

The web is full of values that arrive from somewhere else. That fact does not divide an application into a small island of reason and an ocean of mystery. It gives the application edges.

At an edge, source evidence ends and runtime observation begins. The boundary inside the application answers for the agreement it makes next. The integration boundary answers for whether two independently running systems are still meeting each other where they actually meet.

That is not a retreat from certainty. It is a refusal to counterfeit it. The application can know what its code says, can make disagreement visible when the source reveals it, can establish a usable local agreement when an external value arrives, and can test the external promise against the system making it.

That is the work. Not to eliminate the unknown, but to keep it from becoming an excuse for either fantasy or paralysis.

Preserve the known. Name the boundary. Test agreement.

A path to more resilient software: Agree wherever possible. Disagree gracefully. Allow the unknown to remain unknown.

Chad Augur — Thu, 10 Sep 2026 23:03:23 +0000

Chad Augur

Sep 8

Software as an "Agreement Engine"

#architecture #javascript #programming #software

5 min read

Software as an "Agreement Engine"

Chad Augur — Tue, 08 Sep 2026 16:30:00 +0000

Innovation & Lineage in the Resilient JavaScript Dialect

Artikulates Resilient GitHub repository
Artikulates Resilient npm package

Agree wherever possible.
Disagree gracefully.
Allow the unknown to remain unknown.

That is the discipline at the center of Resilient JavaScript.

It is also a way to think about reliable software more generally: keep what works, make disagreement visible, and do not manufacture certainty.

Resilient enters an old argument about correctness, contracts, invariants, specifications, and boundaries. It is not claiming that dynamic languages are unknowable or that static types are useless. It asks three simple questions: where does knowledge come from, how far can it travel, and what should a tool do when the evidence runs out?

Innovation

The move Resilient makes is simple: it changes where authority lives.

Resilient is a dialect of standard JavaScript, not a new language. The grammar stays put. The discipline comes from the choices the code makes and the tooling that checks whether those choices remain coherent.

For application-owned executable contracts, “the code that runs is the primary source of truth.”

— The Code Is the Contract

The source is not merely an implementation of a design described somewhere else. It is the record of the agreements the program is actually making. The tool reads those agreements, follows them where the evidence holds, and leaves uncertainty alone where it does not.

This does not make explicit models obsolete. A model earns its keep when it crosses ownership, time, or a runtime boundary: an external payload, a public package, a persisted record, or a compatibility promise. The unnecessary model is the one that repeats an executable fact and then has to stay in sync with it by hand.

Model the things that cross meaningful boundaries. Infer the things that happen inside them.

— The Code Is the Contract

That is the move: ask standard JavaScript to carry more of its own meaning, and ask tooling to listen before the code is made to speak twice.

The Agreement Engine paradigm

An agreement is not a type or a promise written beside the code. It is a relationship that has to survive contact with execution.

Programs are conversations between parts. One part offers something; another receives it, changes it, or passes it on. Every exchange carries an expectation. A program stays coherent when those expectations hold, when disagreement becomes visible, and when nobody pretends to know what has not been established.

The Agreement Engine does not eliminate uncertainty. It gives us a way to see how a program stays trustworthy while uncertainty moves through it.

agreement    → cooperation
disagreement → information
unknown      → room for evidence

Every application or function has two broad outcomes: the result satisfies the agreement, or it does not. The goal is to define valid clearly, preserve it through the program, and manage invalidity without making it catastrophic.

unknown is not a third outcome. It is the condition to respect until the available evidence is sufficient to establish what is true.

Code is where these relationships become real. It is where the program's assumptions meet the world and either hold together or change.

Predicates

An Agreement Engine rests on five axioms. Each acts as a predicate over an agreement: it asks what is true, what is promised, where does responsibility rest, what behavior matters, and where uncertainty belongs.

Correctness: An agreement has to survive execution. The question is not whether the code looks plausible, but what execution establishes and which claims remain valid afterward. Floyd, Hoare, and Dijkstra provide the formal lineage for reasoning about program meaning, assertions, and justified results:

Robert W. Floyd — “Assigning Meanings to Programs”
C. A. R. Hoare — “An Axiomatic Basis for Computer Programming”
E. W. Dijkstra — “Letter to Dr. H. Bekic, 8 October 1974”

Contract: A component makes an offer to its caller, then has to deliver on it. The contract gives the agreement a shape. The contract tradition runs through:

Bertrand Meyer — “Design by Contract and Assertions”

Blame: When an agreement breaks, locate the break. Responsibility should not be smeared across every component that happened to carry the value. Findler and Felleisen give this problem a name and a strategy:

Robert Bruce Findler and Matthias Felleisen — “Contracts for Higher-Order Functions”

Behavior: An agreement is about what a value is allowed to do, not only what representation it has. If a property matters, specify the behavior that depends on it. A behavior-first account of specifications begins with:

Rich Hickey — “clojure.spec — Rationale and Overview”

Boundaries: Every agreement has an edge where local evidence ends. Uncertainty belongs there, where it can be isolated, interpreted, and turned into something the rest of the system can trust. Two useful treatments of where uncertainty should be handled are:

Gary Bernhardt — “Boundaries”
Alexis King — “Parse, don’t validate”

Taken together, these predicates make an agreement actionable. They tell us what the program claims, what execution supports, where a contradiction belongs, what behavior must be preserved, and what remains unresolved. Resilient brings those questions to standard JavaScript, where the language leaves clues rather than settling every question for us. The work is to make those clues legible: to see where an agreement holds, where it breaks, and what still needs to be learned.

Principle

Those questions do not stop at the analyzer. They describe a broader discipline for any system that has to remain trustworthy under change. These are not instructions to be agreeable at any cost. They are a way to stay compatible where we can, be precise when something breaks, and remain humble about what we have not established.

Agree wherever possible

In software, agreement is interoperability. A boundary accommodates ordinary variation and preserves the invariant the next part of the system relies on, without pretending an invalid value is valid.

In life, agreement is common ground. It is not people-pleasing or surrender; it is recognizing another person's reality where recognition is possible before asserting a different view. Connection and collaboration begin with that small act of validation.

Disagree gracefully

In software, a known contradiction needs an owner and a useful way out. A system can degrade, return an explicit error, or provide a fallback without silently corrupting everything around it.

In life, graceful disagreement protects both truth and relationship. It separates a person from an idea, makes a boundary firm without making it hostile, and leaves a bridge for whatever comes next.

Allow the unknown to remain unknown

In software, not every component needs to know how every other component works. Encapsulation and abstraction leave some implementation detail unresolved until it matters. Resilient applies the same restraint to analysis: uncertainty stays open until validation or new evidence establishes more.

In life, this is humility without paralysis. We do not need a definitive answer for every mystery, future outcome, or person's motive before we move forward. Ambiguity can be bounded without being filled with a confident story.

That parallel is more than a metaphor. Software and human systems become more resilient when they preserve what works, make disagreement visible without making it catastrophic, and respect uncertainty without rushing to fill it. The interesting question is what becomes possible when code is built with the same discipline: not a new language, and not a promise of certainty, but a clearer record of what the system has agreed to—and what it has not yet learned.

Stop making your code explain itself twice—the code itself should be the authority—better tools can catch disagreements before they become bugs. #AST #eslint #EMCAnative #StaticAnalysis

Chad Augur — Sun, 06 Sep 2026 15:09:20 +0000

Chad Augur

Sep 3

The Code Is the Contract

#javascript #eslint #softwareengineering #devtools

9 min read

The Code Is the Contract

Chad Augur — Thu, 03 Sep 2026 04:39:21 +0000

Native ECMA, Static Analysis

Artikulates Resilient is an open-source static-analysis method and disciplined dialect of standard JavaScript. It reads executable boundaries—destructured defaults, return paths, operations, callbacks, and local module relationships—as evidence, then reports contradictions in the source it can resolve. The current package exposes that analysis through ESLint as an integration surface; the contract model stands on its own. The project analyzes its own source, so it is both the method and a working example of the discipline.

GitHub repository

npm package

There is a particular kind of software maintenance that feels like inventory. Every function gets a description. Every object gets a shape. Every value gets a label. Then the descriptions multiply, drift, and become important enough that nobody wants to touch them.

The code keeps moving underneath.

Resilient starts somewhere else. For application-owned executable contracts, the code that runs is the primary source of truth. Its signatures, defaults, operations, control flow, callbacks, and return paths already contain the contract. That evidence belongs in a model any tool can query, not only in the diagnostics of whichever linter happens to be running. The job is to read that evidence, carry it to the places where it matters, and report contradictions before they become runtime surprises.

This is not a claim that dynamic JavaScript is completely knowable. It is a decision about what to do with the part that is knowable, and about where the responsibility for handling it should sit.

Report contradictions. Preserve unknowns. Keep runtime safety visible. That responsibility belongs to the tooling, not to a second syntax layered on top of the language. For Resilient, annotations that merely restate executable boundaries are an anti-pattern: they create a second description of the same fact that must remain in agreement by hand. Resilient asks the language to keep saying what it already says, and asks the tooling to get better at listening.

A boundary is already a declaration

A boundary is where code hands a value to another responsibility: a function parameter, a return path, an object property, or a callback argument. Consider this:

const render = ({ title = '' } = {}) => title.trim();

render({ title: 42 });

The function tells us that it accepts an object-shaped boundary. The default tells us what absence means for title. The operation tells us that the value must be string-like. The call supplies a known number-like value.

There is no missing information that needs to be restated before the error can be understood. For this input boundary, the signature is not documentation about the contract. It is the contract.

The same is true for a return:

const loadItems = () => [];

loadItems().toUpperCase();

The return path produces an array-like value. The later operation is string-like. The contradiction belongs at the use of the returned value. A separate return declaration would repeat the evidence; it would not create it.

Where the contract becomes visible

A contract becomes visible wherever responsibility changes hands. A function receives something. A call makes a demand. A return carries a result forward. An object exposes some things and keeps other things private. An operation reveals what a value is expected to be. A callback, a module, or a branch makes the same kind of promise in a different form.

These are not annotations added beside the program. They are the places where the program declares an expectation in executable form. The full implementation inventory belongs in the contract documentation; the principle is simpler: where code changes hands, its expectations become visible.

Defaults defend execution

Defensive defaults are sometimes accused of hiding broken data. That criticism confuses two different jobs.

const getItems = ({
    data: {
        items = []
    } = {}
} = {}) => items;

The default is an operational fail-safe for a missing or undefined value. It keeps that absence from needlessly destroying the consuming path. It does not validate an arbitrary API payload. It does not make null array-like. It does not make a known number acceptable as items.

With resilient.configs.contracts enabled, when the source provides enough evidence, the development pipeline still flags the contradiction at the boundary. The application gets its intended absence behavior. The developer gets a diagnostic.

Those are not competing goals. A user should not have to experience every upstream failure for a developer to learn that the contract was wrong.

A default tells the analyzer a property is not required. If absence already has a defined meaning, flagging that absence would be a false error. A function parameter without a default carries no such absence policy, so a known local call that omits it can still be reported for arity. The default does not just protect execution; it is what marks a boundary as open to absence in the first place.

The evidence has to travel

Once a contract is visible, it must remain available as the value moves. That is a different problem from identifying the boundary. Resilient propagates known contracts through aliases, returns, object properties, callbacks, local imports, re-export barrels, and known higher-order calls.

const makeReader = () => (title = '') => title.trim();
const api = { read: makeReader() };

api.read(42);

The value is still a function after it is returned and stored on an object. The call still crosses a boundary. The source did not stop being understandable because the value took a short trip through the program.

The same evidence can survive a resolved local module boundary and a destructure, even when no native operation follows immediately:

// article.js
export const getArticle = () => ({
    title: '',
    summary: ''
});

// view.js
import { getArticle } from './article.js';

const { title, summery } = getArticle(); // known returned shape: `summery` is absent

The typo is visible because the imported return shape remains part of the consumer’s evidence. The contract did not disappear just because the value crossed a file boundary and changed shape through destructuring.

The project graph has two useful views:

Passive Tree: indexed source and contracts
        |
        +-- Active Tree: selected root and closure
                |
                +-- consumer diagnostics

The Passive Tree indexes available project definitions, signatures, capabilities, and relationships. The Active Tree follows the statically resolvable path from a selected root through local module edges. The analyzer reasons from the source present in that tree and records external, dynamic, unresolved, and unsupported edges as unknown.

When a provider changes, an ESLint run that includes an affected consumer rebuilds the relevant graph and analyzes the consumer again. Change the provider; the consumer call site receives the updated contract evidence.

Unused files remain indexed but inactive. External and unsupported edges remain unknown. Nothing gets pulled into the active analysis because the engine felt optimistic that it probably knew what was there.

Unknown is not failure

Some values cannot be known statically. API responses, database records, configuration files, dynamic properties, and third-party implementations are real boundaries. A tool that assigns certainty to them is not being helpful. It is fabricating inventory.

Resilient keeps those values unknown until runtime validation, falsification, normalization, or an explicit guard establishes more evidence. Unknown is a boundary marker, not a final endorsement. When a value enters authored code, that marker tells us where a guard or normalizer may be needed. Unknown does not mean that every surrounding safety rule turns off. A dynamic value can still be subject to callback guards, failure ownership, mutation policy, and native runtime behavior.

The distinction is simple:

known         → check it
contradictory → report it
unknown       → preserve it, avoid fabricated certainty, and keep safety obligations visible

That is a better result than turning uncertainty into a confident lie.

The value and the operation must agree

A contract is not just a bag of allowed property names. The receiver, the operation, the callback, and the result belong to the same story. The same agreement that governs a return path also governs any native method called on that value:

Object.entries({ title: 'ready' }).map(entry => entry);
Object.entries({ title: 'ready' }).trim();

The first operation agrees with the array-like result of Object.entries. The second does not. Likewise, [].map(...) makes sense while [].trim() does not.

Native prototype methods provide evidence about the value being used. Resilient protects that agreement. A familiar method name is not automatically valid on every receiver.

Safety is larger than value compatibility

The most expensive failures are not always about a number reaching a string operation. They are often failures of ownership and control:

an optional callback is invoked without a function guard;
a promise rejection is dropped;
an object owned by another boundary is mutated;
a value-producing path returns an incompatible fallback;
a silent catch discards the failure;
collection work is hidden inside loop state that obscures what is happening.

These are dialect policies. They are not pretend types.

Inference explains what the source proves. Policy decides what the project permits. An analyzer can understand a rejected mutation so later reads remain accurate while the dialect still rejects the mutation as unsafe.

That separation is important. The machinery needs to understand what happened even when the code is not allowed to keep doing it.

Model the boundary, not every brick

Not every external model is redundant. A runtime schema or validator for an API payload, persisted record, versioned event, or public package surface has an independent job. It may validate data, define a compatibility boundary, generate documentation, or serve consumers who cannot inspect the implementation.

Those models cross ownership, time, or a runtime boundary. They have a life outside the function that happens to consume them. That is different from placing a granular description on every local value whose behavior is already visible in the source.

Model the things that cross meaningful boundaries. Infer the things that happen inside them. The model earns its keep when it has an independent job to do.

The code should not have to carry a second structure just to prove that it has one.

Tooling should read the code

The editor should be able to ask the code what it means. That is the model promised from the start: evidence that lives independently of any single consumer.

Resilient’s contract core exposes signatures, value families, object shapes, return contracts, source stacks, module agreements, and diagnostics independently of ESLint. ESLint is one consumer of that model, not its owner.

The implementation is open for inspection in the contract source, and the public API is documented in the contract documentation.

Human documentation still matters. It should explain purpose, context, examples, caveats, and external semantics. It should not become an alternate authority that disagrees with the executable boundary.

The best documentation is not always more text. Sometimes it is a default in the right place, an explicit rest element, a guard before a callback, a return path that agrees with itself, or a native method that says exactly what the code is doing.

The code is the contract

I am not trying to invent a better language. I want standard JavaScript to be largely true to itself: readable by people, inspectable by tools, and disciplined at the places where values and responsibilities change hands.

The code defines the boundary. Defaults define absence and express property intent (for example, a default should assign a testable, type-appropriate empty value where no other value is appropriate—'', [], {}, false, or 0—not null or undefined). Rest elements define intentional, contextual passthrough where the boundary allows it; they are not relevant to every transformation. Operations test whether the value and its behavior agree. Guards define safe optional behavior. Return paths define the result. Policies define ownership and failure handling.

The code is the thing that has to survive. It is the load-bearing structure. Make it legible. Make its boundaries carry their own weight. Make the tools inspect what is actually there.

Do not build a second structure to explain the first.

References: conceptual and theoretical

This position did not arrive from nothing. These works either support it directly or shaped the instincts behind it:

Douglas Crockford, JavaScript: The Good Parts. The case for treating a language as a chosen, disciplined subset rather than everything it permits is the direct ancestor of calling Resilient’s rules a dialect, not a type system.
Elijah Manor, “Eliminate JavaScript Code Smells”. A JavaScript-native vocabulary for recognizing runtime and control-flow hazards—dropped rejections, unguarded callbacks, silent catches—as smells worth catching, rather than treating them as a matter of taste.
Martin Fowler and Kent Beck, Refactoring. The book that popularized and developed “code smell” as a practical vocabulary for structural problems: a smell is evidence of a deeper issue, not a cosmetic complaint, which is why these policies are enforced rather than merely suggested.
Kyle Simpson, You Don’t Know JS: Types & Grammar. A narrative, JS-native case for respecting the value and operation behavior that JavaScript actually provides—the same instinct behind treating a default as absence-handling rather than payload validation.
Peter Naur, “Programming as Theory Building”. Support for the claim that a signature is not documentation about the contract—it is the contract, because the executable structure carries the real theory of what a program does.
Findler and Felleisen, “Contracts for Higher-Order Functions” (ICFP 2002). A formal foundation for higher-order contracts and blame as boundary obligations between a provider and a consumer—close to the academic ancestor of what this piece calls a boundary.
Siek and Taha, “Gradual Typing for Functional Languages” (2006). The formal case for letting typed and dynamic regions coexist at an explicit boundary, closest in spirit to preserving unknown values rather than forcing them into a type. Resilient does not implement gradual typing; the kinship is in the boundary, not the mechanism.

DEV Community: Chad Augur

Let's Define Undefined

Falsifiable Defaults and the Semantics of Undefined

A default says something

The default carries the agreement

Falsifiable does not mean invalid

Empty needs the right test

What is left for undefined?

The edge exposed by functions

The receiver owns the decision

The language meaning of undefined

An outcome, not a catch-all assignment

Let's define undefined

The Fallacy of the “Unknown Cliff” in Modern Web Applications

What dynamic data does—and does not—take away

The cliff is an attractive story

Unknown is not contradiction

The agreement keeps moving

The integration boundary

There is no cliff

A path to more resilient software: Agree wherever possible. Disagree gracefully. Allow the unknown to remain unknown.

Software as an "Agreement Engine"

Software as an "Agreement Engine"

Innovation & Lineage in the Resilient JavaScript Dialect

Innovation

The Agreement Engine paradigm

Predicates

Principle

Agree wherever possible

Disagree gracefully

Allow the unknown to remain unknown

Stop making your code explain itself twice—the code itself should be the authority—better tools can catch disagreements before they become bugs. #AST #eslint #EMCAnative #StaticAnalysis

The Code Is the Contract

The Code Is the Contract

Native ECMA, Static Analysis

A boundary is already a declaration

Where the contract becomes visible

Defaults defend execution

The evidence has to travel

Unknown is not failure

The value and the operation must agree

Safety is larger than value compatibility

Model the boundary, not every brick

Tooling should read the code

The code is the contract

References: conceptual and theoretical

What is left for `undefined`?

The language meaning of `undefined`

Let's define `undefined`