The Table and the Mountain: Why Formal Systems Change What They Claim to Represent

What does a spreadsheet have in common with a mountain village where cannabis has been grown for generations?

At first, almost nothing. One belongs to the world of Markdown files, databases, and digital workflows. The other belongs to the Rif mountains of Morocco, where cultivation is shaped by altitude, terrain, informal property arrangements, and relationships that may never appear in an official record.

Yet both raise the same deceptively difficult question: What happens when living, messy knowledge is forced into a formal system?

Embedding an Airtable into a Markdown file sounds like a technical convenience. Legalizing an informal agricultural economy sounds like a matter of law and public policy. But beneath both is a struggle over representation. A table wants rows and columns. A state wants licenses and land titles. Reality supplies neither. Reality is contextual, locally understood, and constantly changing.

The central lesson is this: formalization does not merely make an existing system visible. It changes what the system is.

The fantasy that visibility is neutral

Most tools for organizing knowledge begin with an appealing promise: make the information easier to see, search, share, and act upon. A Markdown document is attractive because it is portable and readable. A database is attractive because it is structured. Combining them seems to offer the best of both worlds: the narrative flexibility of a document and the precision of rows and columns.

But the moment information enters a table, it must answer questions that may not have existed before. What counts as a record? Which fields are required? Is a person identified by name, location, or role? Does a project have one status, or several competing statuses depending on who is looking at it?

The table does not simply display reality. It proposes a model of reality.

Consider a modest personal knowledge system. You may have notes about a book, a conversation, an experiment, and a half formed idea. In their original state, these notes are irregular but rich. They contain uncertainty, emotion, timing, association, and context. Converting them into a database can create powerful connections. It can also flatten distinctions that mattered.

A note may become an “idea.” A conversation may become a “source.” A question may become a “task.” Once categorized, each item becomes easier to retrieve, but perhaps harder to understand. The system gains legibility while losing texture.

The same transformation appears in the attempt to move cannabis cultivation in Morocco from an informal economy into a legal one. The existing industry is not merely a set of plants awaiting official recognition. It is an entire social and geographic arrangement. Farmers cultivate in a historically restive region, often on steep terrain, sometimes in wild areas or on land without formal title. Their position in the market depends partly on remoteness, local knowledge, and relationships outside official channels.

A legal framework must translate this arrangement into licenses, approved locations, registered producers, documented land, and regulated buyers. That translation may increase revenue for the industry as a whole. It may also make the people who sustained the industry least able to participate in its new form.

The first cost of formalization is often paid by whatever the formal system cannot easily describe.

The map is not just smaller than the territory

The familiar phrase “the map is not the territory” is often used to warn us that models are imperfect. But the deeper problem is that maps influence the territory. Once a map becomes authoritative, people alter their behavior to fit it.

A table of contents changes how a writer organizes a book. A project management board changes how a team defines progress. A legal category changes who can participate in an economy. Representation becomes infrastructure.

This suggests a useful distinction between two kinds of visibility:

1. Descriptive visibility, which helps us perceive what already exists.
2. Administrative visibility, which makes something eligible for coordination, ownership, payment, or enforcement.

These forms overlap, but they are not identical. A farmer may be visible to neighbors, traders, and local authorities while remaining invisible to a licensing system. A piece of knowledge may be perfectly visible in a handwritten notebook but invisible to a search engine. A person can be socially legible and institutionally unrecognized.

Administrative visibility has benefits. It can make neglected work count. It can enable investment, safety standards, taxation, public services, and legal protection. But it also establishes a gate. To become visible in the official system, a person or activity must often resemble the system’s preferred template.

This is why a legal market can produce an unexpected outcome: the people who have the most practical knowledge may not be the people best positioned to enter it. Those with land titles, capital, transport links, and administrative capacity can satisfy the new requirements. Those who know how to cultivate in difficult terrain may be displaced by better connected producers in more accessible plains.

The paradox is severe. Legalization can recognize an industry while excluding its original participants.

The same paradox appears in knowledge work. A person may have years of experience solving a recurring problem, but if that experience is not captured in a standardized field, it remains difficult to search or transfer. Someone else may possess less practical understanding but excel at documenting work in the system’s accepted format. The database rewards legibility, not necessarily competence.

Every schema is also a distribution of power

A schema is usually presented as a technical object. It defines columns, data types, relationships, and rules. Yet every schema also distributes power because it determines what can be counted, compared, approved, or ignored.

Imagine a table for tracking a creative project. Its columns might include title, deadline, owner, status, and priority. These fields are useful, but they encode a theory of work. They imply that ownership is singular, that status is discrete, that priority is stable, and that deadlines are meaningful indicators of progress.

What if the most important variable is not status but confidence? What if the project is jointly owned? What if the work advances through long periods of invisible incubation? The table can accommodate these realities only if someone deliberately designs fields for them. Otherwise, the system quietly treats them as noise.

The same is true of public regulation. A licensing regime may include fields for land ownership, production volume, location, and compliance. It may not include the value of inherited knowledge, informal risk sharing, or the social cost of moving cultivation away from the communities that depend on it. Those factors do not disappear. They become externalities, which is a polished way of saying that the system refuses to carry them in its accounting.

This leads to a practical mental model: every formal system has a center and a remainder.

The center consists of what the system handles well. In a spreadsheet, this may be clean numerical data. In a legal market, it may be documented transactions and compliant producers. The remainder consists of ambiguity, exceptions, oral knowledge, informal relationships, and conditions that do not fit the standard form.

Weak systems deny the remainder exists. Strong systems design explicit ways to preserve it.

A Markdown document that embeds a live table illustrates this principle. The table is excellent for structured facts. The surrounding document is better for explanation, interpretation, and unresolved questions. If the table replaces the prose, the system loses meaning. If the prose refuses structure, the system becomes difficult to operate. The real design challenge is not choosing between structure and context. It is creating a boundary where each can correct the other.

Build systems that preserve friction

Modern design often treats friction as an enemy. We want one click, instant synchronization, automatic categorization, and clean dashboards. Some friction is wasteful. But some friction is evidence that reality is resisting a simplistic model.

Suppose a knowledge system forces every note to have one category. The user may experience the uncertainty of choosing between “research,” “project,” and “personal.” A careless designer eliminates the difficulty by adding automation. A thoughtful designer asks whether the difficulty contains information. Perhaps the note is valuable precisely because it connects categories.

Likewise, if farmers struggle to meet formal requirements, the answer is not automatically to dismiss the requirements. Standards can protect workers, consumers, and communities. The question is whether the system treats difficulty as a compliance failure or as a signal that its categories are poorly fitted to local conditions.

A more humane architecture uses several layers:

1. The operational layer records what must be acted upon. These are the rows, licenses, tasks, quantities, and deadlines.
2. The contextual layer records why the facts look the way they do. This includes place, history, relationships, and constraints.
3. The uncertainty layer records what is disputed, incomplete, or changing.
4. The appeal layer records how people can challenge the system’s representation of them.

Most systems build only the first layer. That is why they appear efficient while producing confusion and resentment. They are optimized for transactions, not understanding.

For an individual, this might mean linking every structured record to a short narrative note. A project row should point to the decision that created it. A task should preserve the question it answers. A contact record should retain the context of the relationship rather than reducing a person to a role and an email address.

For institutions, it means involving affected communities before the schema is finalized. It means allowing provisional registration, collective representation, alternative evidence, and periodic revision. A land title may be one form of proof, but it should not automatically be the only form of proof when formal ownership has historically been unavailable.

The point is not to abolish structure. It is to make structure accountable to experience.

The real goal is translation, not capture

A common ambition in digital work is to “capture knowledge.” A common ambition in regulation is to “bring an informal sector into the formal economy.” Both phrases suggest that something already complete can be transferred intact into a new container.

That is rarely true. Translation always changes the thing translated. The goal, therefore, should not be perfect capture. It should be loss aware translation.

A loss aware system asks three questions:

• What does this format make easier to see?
• What does it make easier to coordinate?
• What does it cause us to forget?

The third question is the one most organizations neglect. They measure adoption, speed, compliance, and output. They rarely measure what has become unreportable.

This framework can be applied immediately to any system you are building. If you are embedding a table in a document, do not ask only whether the table renders correctly. Ask whether a reader can understand the assumptions behind its columns, identify missing information, and distinguish a confirmed fact from an interpretation.

If you are designing a policy, do not ask only whether the sector becomes more profitable. Ask who gains access to the new channels, who bears the documentation burden, and which forms of expertise lose value when the market moves toward the easiest places to monitor.

A system is mature when it can say not only “here is the data,” but also “here is how this data was produced, here is what it leaves out, and here is how to contest it.”

Key Takeaways

• Treat every schema as a theory. Before adding columns or legal categories, identify the assumptions they encode about ownership, progress, identity, and value.
• Separate visibility from eligibility. Ask who can be seen by a system and who can actually benefit from being seen by it.
• Preserve context beside structure. Pair tables, forms, and dashboards with narrative explanations, provenance, and unresolved questions.
• Make uncertainty explicit. Use fields for confidence, source, dispute, and last review rather than forcing ambiguous information into false precision.
• Create an appeal path. Anyone represented by a formal system should have a way to correct the record, offer alternative evidence, or explain what the categories miss.

The deepest mistake is to believe that formalization is a neutral upgrade from disorder to order. It is more like moving a landscape into a model. Some features become measurable and transferable. Others become invisible. The model may unlock new value, but it may also redirect that value toward the people and places most compatible with its design.

A Markdown file with an embedded database and a newly regulated agricultural economy therefore share a surprising moral: the interface is never just an interface. It is a decision about whose reality will count as real enough to organize around.

The best systems do not eliminate the messy world. They give its messiness a place to speak. And before we ask how to make information fit our tools, we should ask the more consequential question: what kind of world will our tools make easier to inhabit, and who will find themselves outside the frame?