Skip to content
Work

Three systems, three domains.

Three systems built in-house, chosen because they sit in three different parts of the stack: a multi-tenant content platform, a natural-language analytics system, a privilege-separated display manager. A product surface, a data system, an operating system. The same hand across all three, which is the range a complete product build actually needs.

01: Builds

What has been built.

Read each as an answer to one question: what does this prove we can be handed? A product surface, a data and inference system, and an operating system are three different kinds of hard, and the range across them is the point.

  • / 01
    Product surface

    Tessera

    A multi-tenant content platform

    An authoring surface sits on top of a document model, and what an editor manipulates is not what a browser is eventually served. Once that platform is multi-tenant the same gap opens again in permissions, in domains and in billing, and every one of them has to close in the schema rather than in a query somebody remembered to write.

    Read the reasoning: Tessera

    What it demanded

    • A block model the editor and the renderer cannot drift apart on
    • Every save recoverable, not just the last one
    • Permissions decided in one place rather than checked at each call site
    • Tenant isolation that a forgotten WHERE clause cannot defeat
    TypeScriptNext.jsReactPostgreSQLDrizzle ORMTurborepo
  • / 02
    Data and inference

    QueryFlow

    A natural-language analytics system

    A question in English becomes SQL against a real schema, runs, and draws a chart. The generation is the least of it: the system has to be safe to point at a production database, and an answer nobody can trace back to a query is not an answer.

    Read the reasoning: QueryFlow

    What it demanded

    • Generated SQL checked before it reaches the database, not after
    • Read-only execution with a bound on what one query may cost
    • The query shown to the reader, not hidden behind the chart
    • A model provider that can be replaced without touching the callers
    TypeScriptNext.jsPythonFastAPIPostgreSQLsqlglot
  • / 03
    Operating system

    tda-dm

    A privilege-separated display manager

    The graphical login is the one program that authenticates a user, holds root while it does, and hands control to a session that must never inherit that authority. It also owns the screen: when it fails, there is frequently nothing left to report the failure on.

    Read the reasoning: tda-dm

    What it demanded

    • A privilege boundary that a session bug cannot reach back through
    • Credentials that do not outlive the moment they are used
    • No path where a compromised interface can start a session
    • Recovery from a crash that does not depend on the screen still working
    RustPAMX11runitelogindD-Bus
02: How to read this

What three domains prove.

Read across the three, not down any one. The range is the point.

  • No handoff between layers

    One of these runs underneath everything else, one turns raw data into an answer, one is a surface people touch directly. None of the three was handed between specialists, so there is no seam where infrastructure hands off to product.

  • The scope was defined, not received

    Each system's requirements were worked out here, not handed over. Deciding what each one had to do, and what it did not have to do, was part of the engineering in all three cases.

  • Depth from kernel to interface

    An operating system reaches the lowest level a build can go; a product surface reaches the highest. Covering both, plus the data and inference layer between them, is the range a general systems practice has to be able to work across.

03: Next step

Ask about any of these.

The specifics are not on this page. Ask for them directly, or send the problem you actually need solved.

Book a callSend a brief