Three Modes, One Table: How TAFNE's P2P Architecture Works

Most table editors work against you when your task gets complicated.

You start in a spreadsheet. You need to clean the data, so you write a script. Then you need to join it with another source, so you open a second tool. Then you need to format it for output, so you go back to the first tool and redo work you already did. Every context switch is a chance to introduce an error or lose state.

The problem isn't that any one of these tools is bad. It's that they were designed to work in isolation, and data work rarely happens in isolation.

TAFNE takes a different approach. Three specialized modes, one shared sheet store, one continuous flow.

The Three Modes

Table Mode is the canvas. Everything in TAFNE starts or ends here. You load data by pasting any format, CSV, HTML, Markdown, JSON, ASCII art tables, raw text with delimiters, and the parser figures out the structure. From there you edit cells directly, drag and drop columns, merge cells, transpose the whole thing with one click, apply CSS classes for styling, and export in six formats: HTML, Markdown, JSON, CSV, SQL, ASCII.

It's built for the work that requires human judgment. The cell you have to fix by hand because you know the context. The merge across a header row that makes the table readable. The column ordering that only makes sense if you understand the audience.

Node Mode (the Node Editor) is the logic engine. It's a canvas where you wire together a directed graph of operations. Sheet nodes pull in any existing TAFNE sheet. API nodes fetch live JSON from a URL you provide. Filter, Formula, and Join nodes operate on the data. When you click Run, the executor walks the graph in topological order and builds a result.

It's for the work that would otherwise be a manual copy-paste job or a fragile VLOOKUP chain. Multi-sheet joins. API enrichment. Computed columns. Repeatable pipelines that run the same way every time.

Lab Mode is the QC layer. Between loading raw data and doing anything meaningful with it, there's almost always a cleaning step: flag the blank fields, filter the rows that don't make sense, rename headers that came in wrong, split a column that should have been two. Lab Mode makes that step explicit and composable.

It runs a pipeline of 26 pre-defined functions across three phases: Validate (flag problems without changing anything), Transform (reshape the data), and Analyze (produce summaries and pivot tables). Every function is pure, no DOM access, no globals, no side effects. The pipeline is serializable JSON, which means it's repeatable and shareable.

The P2P Loop

The three modes share a sheet store. Any sheet produced by any mode is available as a source in any other mode. That's the core of what TAFNE calls Pipeline-to-Pipeline, or P2P.

The flow is not rigid. Different tasks use different paths. But here are some common ones:

Light cleaning: Load raw data in Table Mode, fix a few cells by hand, switch to Lab Mode, flag empties and filter bad rows, submit the cleaned result back as a new sheet. Done.

API enrichment: Add an API node and a local sheet in the Node Editor, join them on a key, build the result as a new sheet, apply styling in Table Mode, export as HTML.

Multi-source report: Receive data via the bridge from the Schema Editor (a separate TAFNE tool). Open it in Lab Mode. Run a mergeBy to consolidate duplicate components in a bill of materials. Submit. Diff view shows what changed before anything gets sent back.

Full pipeline: Paste raw text into Table Mode, use Text Split to parse it into structured rows, hand it to Lab Mode for validation, hand the validated output to the Node Editor for a formula computation, back to Table Mode for a final export.

The output of each step is a clean TAFNE sheet. No state leaks between modes. No data loss on context switch.

Why Separate Modes Instead of One Interface

The natural question is: why not build this as one unified interface?

The short answer is that the three modes have genuinely different interaction models. Table Mode needs direct cell manipulation, clicking, double-clicking, drag and drop, keyboard navigation. A visual node canvas in the same viewport would compete with that. Lab Mode's step-builder and result pane need vertical space and a clear separation between the pipeline definition and the data preview. The Node Editor needs an open canvas for drawing connections between nodes.

Putting all of this in one interface would mean building a UI that does all three things adequately and none of them well.

Separate modes with a shared sheet store gives each interface the space to be good at what it does, while keeping the data accessible everywhere.

What's Actually Shared

The sheet store is the connective tissue. When Lab Mode submits a cleaned dataset, it calls addSheet(name, htmlString). When the Node Editor builds a table, it calls the same function. When Table Mode loads a sheet, it reads from the same store.

The store is a flat map, sheet ID to sheet state. Every mode gets read/write access. The sheet manager at the bottom of the screen shows all sheets from all modes. Any sheet, any source, any mode.

This is also how the bridge integration works. TAFNE can receive data from the Schema Editor via an IPC message, a bill of materials from a wiring diagram, a schedule from a floorplan, a component table from a UML diagram. When that data arrives, it lands in the sheet store like any other sheet. Lab Mode can open it, process it, and send it back with a diff view before anything is committed.

The three modes aren't just UI tabs. They're three different cognitive stances on the same data: hands-on editing, automated logic, and structured QC. The architecture is what makes it possible to move between them without losing work.

TAFNE is free and open source: github.com/carnworkstudios/TAFNE