Why structured data should return to files

I took several wrong turns while building Eidos.

At first, I tried to build an all-in-one workspace on top of SQLite—something closer to Notion, with documents, databases, views, automation, and collaboration in one product. The feature set kept growing, but a more basic question remained unanswered: what should Eidos continue solving over the long term?

That exploration was useful, but adding more features did not produce a clearer direction. The question was no longer how much Eidos could contain. It was what deserved to outlive any particular application and remain in the user’s hands.

Eventually, I returned to a file-based approach.

Text has Markdown. What does structured data have?

Files have a quality that online services struggle to replace: they can continue to exist independently of a product.

A file can be saved, copied, moved, backed up, and opened by different tools. Markdown has shown that an open format can support not only content, but an ecosystem of editors, renderers, plugins, and automation. Tools change; the file does not have to disappear with them.

Structured data rarely has the same freedom.

Projects, customers, tasks, research, and content plans often live inside an online product. People see tables, boards, calendars, and forms, while the underlying data depends on the platform’s private format, APIs, and business decisions. An export may preserve rows and columns, but rarely carries field types, relations, formulas, views, and operating rules intact.

This is the gap Eidos is trying to address:

Text             → Markdown                  → editors and tools
Structured data  → Eidos (a SQLite file)     → editors, automation, and agents

Markdown can be understood as a text file with a shared set of conventions. In the same way, an Eidos File is a SQLite file with shared structural conventions. It remains an ordinary file, while different tools can understand its tables, fields, relations, formulas, and views.

A multidimensional spreadsheet is not a database skin

A multidimensional spreadsheet is often described as a friendlier database interface. That is only partly true.

A database stores and queries data. A multidimensional spreadsheet translates database concepts into objects, fields, relations, states, and views that people can understand directly. Someone can create a lightweight data model without first learning SQL and joins.

The same data can appear as a grid, board, calendar, or another view. These are not separate copies. They are different ways to understand and operate on one model. Field types, linked records, formulas, and filters are not merely visual settings; together, they define what the data means and which changes make sense.

A multidimensional spreadsheet is not the UI of a database. It is the semantic and operational layer between a database and the working world.

That semantic layer is useful to more than people. An agent also needs to know what each table represents, how fields relate, which operations are allowed, and how a change can be checked or reversed.

Why SQLite—and why SQLite alone is not enough

SQLite is an excellent foundation for local structured data. It is mature, stable, portable, and able to store relations, indexes, and transactions in a single file without requiring a database server.

But a raw SQLite file does not automatically become a multidimensional spreadsheet.

It does not know that a column is a status, that another column links to a record, or how views, field properties, and safe mutations should work. Eidos adds an open specification above SQLite to define how these semantics are stored. The Runtime reads, validates, and changes them consistently. The shared UI presents the same semantics to people.

The interface is therefore not the owner of the data. It is one client among several. Eidos Lite, the Web Editor, the local editor, the CLI, and agents all work with the same .eidos file.

Changing the tool does not require moving the data first.

A file also needs history

Returning structured data to a file solves only part of the ownership and portability problem. Once the file changes over time, another set of questions appears:

• Which records did this change affect?
• What did a person change, and what did an agent change?
• Can an experiment happen on a branch?
• Can a bad change be restored?
• Can several devices stay in continuity without making the cloud the only source of truth?

Text files can use Git for history, but SQLite is not line-oriented text. Comparing database binaries does not explain how an individual record changed.

This is the problem Graft is designed to solve. It gives SQLite files understandable history, row-level diffs, branches, restore, and optional remote sync. The goal is not to store a database as an opaque blob, but to make structured changes visible, discussable, and reversible.

Eidos understands the data; Graft remembers the changes. Keeping these concerns separate means the file format does not depend on a sync service, and the local file remains independent.

Agents will change interfaces, not eliminate semantics

Agents can generate pages, write SQL, and even create a temporary application. That will compress the value of many traditional low-code interfaces, but it will not make structure and rules disappear.

When any interface can be generated quickly, the things that must endure become clearer:

• data the user actually owns;
• a stable, understandable data model;
• verifiable boundaries around mutations;
• traceable and recoverable history;
• shared rules for people and agents.

An agent may skip the spreadsheet UI, but it cannot skip these questions. Without them, automation becomes a direct database edit with too little context and too little room for review.

Eidos is not trying to prevent agents from bypassing the UI. It is trying to make people and agents follow the same structured semantics—even when they enter through different tools—and change the same user-controlled file.

What Eidos is no longer trying to be

This change in direction also changes the definition of Eidos.

It is no longer trying to be a workspace that contains everything, and it is not merely a local Airtable. Eidos is becoming an open set of tools built around structured data files:

• Eidos File defines how data and views are stored;
• the Runtime lets different applications use that data consistently;
• the UI lets people inspect and edit it;
• the CLI and Skills let automation and agents participate safely;
• Graft makes each change traceable and recoverable.

These parts can work together, or other tools can adopt them independently. The important part is that the data does not lose its home when one interface, application, or service stops evolving.

A beginning

Putting structured data in files does not automatically solve every problem. Complex merging, collaboration models, specification evolution, and ecosystem compatibility will require long-term work.

But compared with building an all-in-one workspace with an ever-growing feature list, this direction is closer to the value Eidos may be able to create:

Give structured data the openness of Markdown and the traceability of Git.

When data becomes a file again, users can choose their tools instead of being chosen by them. That is where Eidos wants to begin.