Tehom Customer-Zero Engineering Case Study

• Date prepared: 2026-06-25
• Scope: Cycle 115, Cycle 117, and Cycle 119
• Audience: seed investors evaluating Tehom
• Purpose: engineering Proof behind the investor deck and proof graph white paper
• Evidence posture: source-backed internal operating Proof, not external commercial ROI

Case Thesis

Tehom's seed case depends on one concrete question: can one accountable human govern machine-speed work without losing purpose, authority, evidence, review, repair, or memory?

Cycles 115, 117, and 119 are Tehom's first engineering answer to that question. Across ten calendar days, Tehom operated as its own customer zero. One human owner directed overlapping agent sessions through planning, implementation, review, runtime recovery, PR promotion, closeout, publication, and evidence synthesis. The work was not a demo. It produced canonical cycle records, bet files, verification sections, retrospectives, ADRs, PR references, run-check evidence, and a mined session footprint.

The supported claim is:

Tehom logged 715+ hours of governed agent work across 24 overlapping sessions over the 10-calendar-day Cycle 115/117/119 window, managed by one human owner with explicit governance, evidence, review, and repair boundaries.

That is not a claim of 715 human labor-hours saved. It is stronger as an engineering claim: Tehom demonstrated a governed work field where agent execution could run in parallel while human purpose, review, evidence, and repair remained visible.

Customer zero for this proof is Tehom itself. H&J and PetroSuites are not the current outcome claim. They are the first business-workflow proof lanes the round should instrument next.

Tehom Language Decoder

The case uses Tehom language where it makes the operating model easier to see:

Operating Context

Tehom is building Amar, a governed operating surface for human-machine work, and Or, the relationship-memory substrate underneath it. The investor deck argues that organizations are entering a human-agent era where work accelerates faster than accountability, memory, and review can keep up. That claim is easy to state in a deck. It is harder to prove.

Cycles 115, 117, and 119 mattered because they forced the thesis through Tehom's own operating reality. The system had to preserve why-context, keep source authority current, route review, recover runtime state, manage Forgejo promotion evidence, close out planning records, and remember what failed. When automation became opaque, the human owner intervened. When the workflow broke, the failure became a repair bet or ADR instead of disappearing into chat.

This is the correct shape of early proof for Tehom. Before Tehom claims external ROI, it must show that its own work can be governed.

Engineering Challenge

The challenge was not "can an AI agent write code?" That question is too small. The challenge was whether a human-agent organization could keep control while the amount of machine work expanded.

The stress test had three parts:

Together, the cycles tested Tehom's thesis in the only environment fully available at this stage: Tehom's own engineering and operating system.

Method

The system under test had four layers.

The work proceeded through normal engineering artifacts rather than a special demonstration path: cycle READMEs, Move files (BET-####), Changesets, Judgments (ADRs), Forgejo PR references, review/security references, run-check IDs, and closeout records.

Measured Outcomes

The measurements below are the case-study dashboard. They combine delivery volume, governance coverage, architecture learning, and session-footprint evidence.

The first-order result is not merely activity. The result is governed activity. Every bet file carried verification and retrospective structure. Failures created ADRs and repair records. The work left a source trail that can be reviewed after the fact.

Findings

Finding 1: The Control Loop Ran Under Pressure

The deck names a control loop: Ask, Prove, Review, Resolve, Remember. In these cycles, that Amar Way loop was exercised as engineering practice. Human Marks became cycle scopes and Move acceptance criteria. Proof moved through run checks, PR evidence, runtime records, review records, and session logs. Work was resolved through merge, closeout, supersession, deferral, or reopening. Learning was preserved in retrospectives, Judgments (ADRs), and future-cycle inputs.

This matters because an investor cannot underwrite philosophy alone. The important fact is that Tehom's operating loop generated durable records while the work was underway.

Finding 2: Leviathan Became Diagnosable

The deck's Leviathan is the condition where work accelerates while accountability erodes. Cycle 117 made that condition concrete. The system surfaced stale Source, lifecycle ambiguity, missing status, runtime Trace gaps, non-current review, cleanup disagreement, and dependency misclassification.

Those failures were not buried. They were converted into repair Moves, recurrence rules, guarded promotion behavior, and governing Judgments. That is the strongest category Proof in the case: Tehom encountered the problem it claims the market will face, then made the problem inspectable.

Finding 3: Memory Started Compounding

Tehom's moat is not model access. The moat is Or memory: accepted Proof, recurring failure patterns, governance Judgments, review history, Source-authority rules, and repair outcomes. These cycles created the first meaningful customer-zero memory set.

The evidence is practical. Bet files preserved verification and retrospective structure. ADRs captured architecture consequences. Session metrics showed how much work happened under sparse steering. Forgejo references tied planning records to promotion and review evidence. The organization could ask what happened, what failed, what repaired it, and what should change next.

Finding 4: Speed Stayed Subordinate To Governance

Cycle 119 is important because it did not respond to throughput pressure by removing gates. It shaped execution lanes, stacked PRs, tiered checks, and audited cleanup while preserving Forgejo promotion gates and default-mode restraint.

For an investor, that is a governance signal. Tehom is not building a faster path around review. It is building the operating layer that lets machine work become faster while review remains visible.

Evidence-To-Conclusion Matrix

Each conclusion below is tied to exact evidence. This is the engineering case inside the investor story.

The 715+ Hour Claim

The claim should be stated as:

715+ hours of governed agent work across 10 calendar days, managed by one human owner.

Use it carefully:

• It measures logged wall-clock agent-session footprint, not audited human labor-hours saved.
• Sessions overlap, so the number describes a governed work field rather than a single linear stopwatch.
• The business value is the governance pattern: one human directed parallel machine work while evidence, review, repair, and memory stayed visible.

This framing is more credible than inflated productivity math. It says what Tehom must prove first: agent work can be made governable.

Investment Implication

The deck can now make a stronger claim:

The internal operating proof exists. The seed round funds productization and external proof.

The case supports a $2-3M round because the next work is specific:

The case does not ask you to believe Tehom has already won. It asks you to believe Tehom has found the right operating problem, proved the first internal loop under pressure, and now needs capital to turn the loop into product and external proof.

Limitations

This case should not claim:

• external customer traction;
• audited ROI;
• precise human-hours saved;
• general repeatability across customers;
• that every Codex-authored commit was autonomous;
• that Tehom already owns a finished Codex replacement.

The supported claim is narrower and stronger:

Tehom has source-backed evidence of a working recursive improvement loop for governed machine work. The internal proof exists; the raise funds productization and external customer proof.

Forgejo Source Evidence

Investor-facing source evidence should point to Forgejo-hosted records rather than workstation-local paths. Session-log metrics are summarized in the Forgejo-hosted source appendix; raw workstation logs remain internal audit material and should be provided separately only when diligence requires it.

Canonical cycle records:

• Cycle 115 README
• Cycle 117 README
• Cycle 119 README

Canonical changesets:

• Cycle 115 changeset
• Cycle 117 changeset
• Cycle 119 changeset

Governing ADRs:

• ADR-091 MCP autocycle architecture
• ADR-092 MCP execution lanes
• ADR-093 MCP API boundary authority
• ADR-094 AGE graph topology
• ADR-095 Postgres-native Or graph substrate
• ADR-096 Tehom, Amar, Or canonical naming

Investor packet evidence:

• Source evidence appendix
• Deck proof appendix