START WITH ONE WORKFLOW — GIVE AI THE CONTEXT IT IS MISSING
    Penumbra
    ← MethodPrinciple 01

    Expertise-Proximate Design.

    The system adapts to the expert — not the other way around.

    Active · Published 2026·05·06 · 7 min read

    "The cost of expertise in technology systems is not the expertise itself. It's the translation."

    01 — The translation tax

    In every organization, there is a gap between the person who knows and the person who can do.

    The domain expert says: "we need to track customers at risk of churning." The analyst translates: "flag customers with declining engagement." The engineer implements: WHERE login_count_30d < 5 AND support_tickets_90d > 3.

    Was that what the expert meant? Probably not. They meant something about the pattern of engagement change, specific support interactions, and the contract renewal context. Each translation layer discards information that doesn't fit the translator's mental model or the target system's expressiveness.

    Expert's understanding   (rich, contextual, nuanced)
        ↓ lossy translation
Analyst's interpretation (structured, simplified)
        ↓ lossy translation
Engineer's implementation (precise — about the wrong thing)

    The feedback loop compounds the problem. The expert sees the output, notices it's wrong, files a ticket, waits for a sprint. After a few rounds, they settle for "close enough" because the cost of precision exceeds their patience.

    02 — What "moving the expert closer" actually means

    The industry framing gets the direction of adaptation wrong.

    No-code tools simplify the technology and ask the expert to meet it halfway. The expert still learns a tool-specific paradigm — drag-and-drop, formula languages, pipeline builders — and gets 60% of the way before hitting a wall.

    Self-service BI gives the expert SQL-adjacent query builders. The expert learns to think in tables and joins. They've adapted to the data model instead of expressing their domain.

    Prompt engineering is the newest form of the translation tax. Every prompt is a one-time translation that doesn't persist, isn't governed, and isn't reusable.

    All three share the same assumption: the expert should learn the system's language. Penumbra inverts this — the system should learn to execute from the expert's domain expression.

    03 — Domain commitments

    The expert already knows their domain. It just isn't in a form a system can execute.

    A risk officer already knows what a Credit Exposure is, what properties matter, how exposures relate to counterparties. A shape captures that knowledge as domain commitments: explicit statements about what exists in a bounded domain and how things relate.

    Example commitments

    • "A Customer has a lifetime_value: 90-day rolling LTV, excluding churned accounts."
    • "Customers relate to Contracts through HAS_CONTRACT (one to many)."
    • "Segment must be one of: enterprise, mid-market, smb."
    • "The name field is the legal entity name, not the DBA."

    These are not technical specifications. The expert didn't write code, learn a tool, or adapt their thinking to a system's constraints. They described what exists and how things relate. The system formalizes the rest.

    Five properties of a commitment

    What separates a commitment from a requirements doc, prompt, or schema.

    1. 01

      Inspectable

      The expert can read it back and verify it. The feedback loop closes without a sprint.

    2. 02

      Versionable

      Changes are tracked through workspace governance. Who changed what, when, and why.

    3. 03

      Composable

      Commitments from different experts combine through shape relationships. Neither expert needs the other's full domain.

    4. 04

      Operational

      The system transforms commitments into working artifacts: extraction schemas, agent tools, query constraints, document templates.

    5. 05

      Durable

      They persist beyond the engagement, the sprint, the conversation. Governed organizational knowledge.

    04 — Compilation is invisible

    One commitment, many surfaces. The expert never picks which.

    The expert defines a Customer with properties and relationships. From that single commitment, the system produces:

    • An extraction schema that recognizes Customers in uploaded documents.
    • Agent tools that can create, read, and modify Customer entities.
    • Query constraints that enforce segment values.
    • An OWL ontology class for knowledge graph materialization.
    • A data binding that maps Customer.name to a database column.
    • A document section template for reports about Customers.

    The expert's only job is to make commitments about their domain that are true. The compilation is a system-level concern.

    05 — The direction of adaptation

    The system adapts to the expert. Not the other way around.

    Traditional

    Technology
   ↓ simplify
Expert adapts to tool

    Penumbra

    Expert
   ↓ domain commitments
System adapts to expression

    The technology is still visible — the expert sees entities, relationships, properties. But these are domain concepts, not system concepts. The data engineer's job shifts from interpreting intent to binding commitments to data sources. The shape is the shared artifact both can read.

    Application across Penumbra

    Seven interfaces, two ways of building them.

    Shape creation
    Traditional —Expert writes JSON Schema or fills a form
    Penumbra —Expert describes domain in natural language; system proposes the schema
    Extraction
    Traditional —Engineer builds an ETL pipeline per source
    Penumbra —Expert defines what entities matter; system extracts against those commitments
    Data binding
    Traditional —Engineer writes SQL views or dbt models
    Penumbra —Expert defines domain types; adapter maps properties to columns
    Agent tools
    Traditional —Engineer builds custom API endpoints
    Penumbra —Shape turns into type-bound tools automatically
    Deliverables
    Traditional —Consultant manually builds reports
    Penumbra —Shape properties drive document section structure via Forge
    Quality checks
    Traditional —Engineer writes validation rules
    Penumbra —Shape constraints enforce quality at extraction
    Cross-domain
    Traditional —Engineer builds join tables or ETL merges
    Penumbra —Shape relationships declare how domains connect; system resolves

    Design checklist

    Five questions to ask of any feature.

    1. 01

      Whose language does the interface speak?

      Domain terms, not system terms. The expert shouldn't need technical training to read the screen.

    2. 02

      Where is the translation layer?

      If a human translator sits between expert and system, can it be eliminated — or at least made inspectable?

    3. 03

      Can the expert verify the output?

      In domain terms, in minutes — not in system terms, over weeks.

    4. 04

      Does the commitment persist?

      Will the artifact still be useful next month, next quarter, at the next client?

    5. 05

      Does the compilation scale?

      One commitment should produce value across many surfaces — extraction, agents, documents, views.

    Anti-patterns

    Three failure modes — and the fix in each.

    01

    The prompt tax

    The expert explains the domain to an engineer. The engineer writes a system prompt. The agent misinterprets. Repeat. Prompts are ephemeral, ungoverned, and don't transfer across agents.

    Fix —Domain commitments are the agent's context. The prompt is generated from the shape — not hand-written.

    02

    The schema-as-ontology trap

    An engineer maps the database schema, calls it the ontology. The expert can't read it because it's about tables, not domain. The two talk past each other.

    Fix —Start from domain commitments — what exists. Then bind to data sources — where it's stored. Not the other way around.

    03

    The tool-learning tax

    We bought Collibra. Now experts learn Collibra. We set up dbt. Now analysts learn dbt. We deployed Genie. Now we annotate two thousand tables for it.

    Fix —The expert's interface is the shape. The shape turns into whatever tools the organization uses. The expert learns one thing.

    "The system adapts to the expert. Not the other way around."

    PUT THE METHOD TO WORK

    See what a domain-first firm looks like in practice.

    BOOK A WORKING SESSION →