First, some context on the two pieces.

Papre is a platform I'm building that replaces static legal agreements with self-executing smart contracts. You describe a deal in plain English, the system assembles reusable clause modules (escrow, milestone payments, signatures, deadlines, arbitration), generates both the legal prose and the on-chain logic, and deploys an agreement that actually enforces itself. Funds go into escrow automatically. Milestone approvals trigger payments automatically. If someone doesn't respond within the review window, the contract enforces the deadline. No chasing invoices. No $10,000 legal bills to enforce a $5,000 contract.

Sentience is a personal AI platform currently in private beta, backed by a $6.5M seed round from Bain Capital Ventures and South Park Commons. The core idea is that it captures your entire digital life (emails, messages, meetings, conversations, notes, screenshots, calendar events) and builds a living, searchable memory of who you are. It's not a generic chatbot. It's a personal AI that learns your patterns, your voice, your preferences, and your decision-making style over time. Everything is encrypted and fully owned by the user. Nobody else, not even the Sentience team, can access your data. It runs as a desktop app that quietly observes your digital activity and builds an increasingly rich understanding of how you think and operate. I've been using it during the beta to do things like draft emails in my voice, search across months of conversations instantly, and even build tools that use its memory layer as context for automated workflows. The longer I use it, the more it acts like a genuine digital version of me.

Papre already has an AI layer. You can say "I'm hiring a developer to build my website for $3,000, half now, half on delivery" and the system translates that into a structured agreement with the right clauses configured and connected. That's useful. But it still starts from scratch every time. The AI knows what an escrow clause is. It doesn't know anything about you.

Now imagine plugging Sentience into that pipeline.

When Sentience sits behind Papre's agreement builder, the system doesn't just understand contract structure. It understands your contract structure. Your preferences. Your patterns. Your personality as a business operator.

Say you're a freelance designer who's created 30 agreements on Papre over the past year. Sentience has observed that you always structure milestone payments as 50/25/25. You consistently set 14-day deadlines. You never skip the arbitration clause. Your cancellation fees are always capped at 10%. You prefer USDC. You tend to be the one who marks work as delivered, meaning you're usually the service provider, not the client.

Next time you start a new agreement, you don't configure any of that. You say "new logo project with Sarah, $5,000." Papre's AI, powered by your Sentience memory, assembles the agreement pre-configured: 50/25/25 milestone split, 14-day deadlines, arbitration enabled, 10% kill fee, USDC escrow. It even knows Sarah's wallet address from your last three deals with her and pre-fills the counterparty.

You review, tweak if needed, and deploy. What used to be a 15-minute configuration is now 30 seconds.

But it goes deeper than just remembering your settings. Sentience understands context.

Let's say you just had a meeting where you told a colleague "I'm done doing net-30 on anything under $10K, it's not worth the cash flow risk." Sentience captured that conversation. Next time you create an agreement under $10K, the system defaults to payment-on-delivery instead of net-30. You didn't update a settings page. You didn't file a preference somewhere. You made a decision out loud in a meeting, and your AI heard it and acted on it.

Or say you're negotiating with a new client and you mentioned in a previous conversation that you want to start requiring deposits upfront for first-time clients. Sentience flags the counterparty as new (no prior agreements on Papre) and automatically adds a 50% upfront deposit clause. The system is reasoning from your stated preferences, not from a generic template.

From Papre's architecture perspective, this fits cleanly. Papre is built on a modular, composable clause system with AI-readable manifests. Every clause (escrow, signatures, milestones, arbitration) has a semantic description, use cases, and composition rules that an AI can reason over. Sentience would sit as an intelligence layer that reads those manifests plus your personal memory to make informed clause selections and configurations. The manifests tell the AI what's possible. Sentience tells it what you'd actually choose.

There are a few ways this could work architecturally.

First, Sentience as an optional module. Users who connect their Sentience account get personalized agreement suggestions. Users who don't still get the standard AI builder. This is the lightest integration -- basically Sentience as a preference engine that feeds into Papre's existing AI pipeline.

Second, Sentience as Papre's built-in AI. Instead of using a generic LLM for agreement building, Papre's AI layer is Sentience. Every user's agreement builder is personalized from day one because their digital context is already loaded. The AI improves as the user's Sentience memory grows.

Third, Sentience as a deal-intelligence layer. Beyond just configuration, Sentience could analyze the counterparty's reputation (if they're also on Papre), flag risk patterns based on your past disputes, suggest different clause configurations for different deal sizes, and even recommend when you should require more protective terms based on patterns it's observed in your business.

The privacy model works because Sentience is fully encrypted and user-owned. Papre never sees your Sentience data. Sentience processes locally and returns structured recommendations that Papre's clause system can act on. Your preferences, your conversations, your decisions stay yours. The platform just gets better outputs.

I don't know if any of this will actually ship. I'm sharing it because I think it points at something bigger than either product alone. The agreement system that wins long-term is the one that knows you well enough that the right deal structure assembles itself before you even ask. Papre provides the execution infrastructure. Sentience provides the personal intelligence. Together, agreements stop being something you configure and start being something that configures itself around who you are.

Written with Sentience.

I've spent my career at the intersection of law and technology. I started with a BA/BS in Mathematics and Computer Science, but never worked in related fields, instead choosing law school and then an LL.M. in International Taxation. I practiced as an attorney in tax, business, and estate planning, using my comfort with technology to build a practice that operated wherever in the world I found myself. I taught taxation at the post-JD level, writing and revising over 50 pieces on tax and business law with publishers like Wolters Kluwer, West, and Oxford University Press.

But don’t get the idea that I wrote that first paragraph out of pride, holding myself out as an expert to be taken seriously. No, I wrote it as a prelude to the rest of the story, the story moving through today and my role as Founder at Papre.

Despite the accomplishments I built on paper, I burned out in the practice of law; I couldn’t hack it anymore and retired my law license, never to practice again. After that dark night of the soul experience, I emerged wondering why I’d ever gone to law school, racking up student loan debt for a career I’d left behind. This was the amplified echo of my shift from tech into law, but this time there were real consequences.

It felt like there was a purpose to it all, at least I wanted to believe there was a purpose, but after closing my firm, I ended up working in sales for a legal services company and also moonlighting as a legal consultant to firms that didn’t have attorneys with my skillset.

One of those firms sent me a client who’d worked on a crypto project and needed advice. I won’t say much more than that for confidentiality reasons, but the computer scientist in me was intrigued when they talked to me about blockchain.

Crypto didn't so much strike my fancy, but the promises of blockchain did. The idea that you could encode not just a promise, but the consequence of a promise—that the enforcement could be built into the agreement itself—that stopped me cold. I'd spent years watching contracts do nothing. Signed, filed, forgotten. When things went wrong, enforcement was a threat that only worked if someone could afford to make it real. Below a certain dollar amount, everyone just ate the loss. The contract was theater. What blockchain promised wasn't better theater. It was something else entirely: An agreement that doesn't just describe what should happen; it makes it happen! That was worth paying attention to.

But I also knew enough law to know the word “contract” was doing too much work.

A smart contract can move value, update state, and enforce a rule. But code alone doesn't solve assent, notice, capacity, jurisdiction, ambiguity, public policy, evidence, privacy, or the messy human facts that real agreements depend on. The old legal system wasn't useless. It was carrying meaning that code did not know how to carry.

That tension became the thing I couldn't stop thinking about. Traditional contracts capture legal meaning, but they don't run. Smart contracts run, but too often they don't capture enough legal meaning. One side has prose without execution. The other has execution without enough legal context.

The opportunity wasn't to replace law with code. It was to make agreements that could be read by people, enforced by courts, and executed by software. It was to give the agreement a runtime.

That became the line back to all of it — the math and computer science degree, the legal practice, the tax teaching, the burnout, and the blockchain client.

And for the last stretch of my professional life, I've been building Papre — a platform where agreements don't just sit in a folder after signature. They run.

That shift — from contracts as documents to contracts as systems — is the core of what I'm calling Composable Law. And I think it's the most important infrastructure change coming to how businesses operate.

Let me explain why.

Contracts themselves are not broken. They've worked for thousands of years as tools for recording intent, allocating risk, and making commerce legible. What's broken is the gap between the agreement and the systems that are supposed to carry it out.

The Problem Is Simple (and Expensive)

Every business runs on contracts. Every dollar of revenue, every vendor relationship, every hire, every partnership — there's an agreement underneath it. And yet, the moment that agreement is signed, it becomes operationally dead weight. A PDF in a repository. Maybe someone sets a calendar reminder for a renewal date. Maybe not.

Meanwhile, the actual work happens in software. Billing systems. CRMs. Payment rails. ERPs. Logistics APIs. The agreement says what should happen. The software does what actually happens. And the gap between those two things is where businesses hemorrhage value.

World Commerce and Contracting puts the number at roughly 9% of annual value lost to poor contract management. Best-in-class companies lose around 3%. Worst performers lose 15% or more. https://www.agiloft.com/blog/9-risks-of-bad-contract-management-that-you-cant-afford/

That figure isn’t speculative. It shows up consistently across research and related industry studies, which describe “value leakage” as the gap between what a contract says should happen and what actually happens in practice.

The losses don’t come from one catastrophic failure. They come from accumulation: missed price adjustments, unclaimed discounts, delayed billing, unmanaged obligations, disputes, and breakdowns between legal, procurement, and operations.

In other words, the deal gets signed, but the business never fully performs the deal as written.

That’s not a rounding error. That’s a structural failure.

The contract said "pay on delivery." The delivery happened. Nobody triggered the payment. Now there's a dispute. Multiply that by every obligation in every agreement across an entire organization, and you start to see the scale of the problem.

What Composable Law Actually Is

Composable Law is a method for building agreements out of reusable, typed, executable modules — while keeping them enforceable under ordinary legal principles.

Think of it like this. Software engineering went through a similar evolution. We used to write monolithic applications. Then we learned to compose systems from reusable components — libraries, packages, APIs, microservices. Each piece does one thing well. You snap them together. The system works.

The infrastructure around contracts hasn't had that evolution. We still draft them like it's 1995. Copy-paste from the last deal. Redline. Negotiate. Sign. File. Forget.

Composable Law says: what if each clause in an agreement was a module? What if that module carried both the legal language and the logic for how that part of the deal actually executes? What if you could compose an agreement the way you compose software—from tested, versioned, reusable building blocks?

That's the idea. And it's not science fiction. The legal and technical foundations already exist.

A Composable Law agreement has four layers that work together. First, a meaning layer: the natural-language legal prose that anchors interpretation. Second, a semantic layer: a typed data model that defines the parties, roles, variables, rights, obligations, states, and events. Third, an execution layer: the code and integrations that operationalize automatable parts like payments, notices, provisioning, and credits. Fourth, an evidence layer: audit logs, signatures, attestations, and packaging designed for disputes, compliance, and litigation.

None of these layers replaces the others. The prose governs meaning. The code executes performance. The evidence layer makes everything legible to a court if it ever gets there.

What This Is Not

I want to be clear about what Composable Law is not claiming.

It's not claiming courts are obsolete. Courts matter. Meaning matters. Equity matters. Composable Law doesn't replace judges. It gives them better evidence when they're needed.

It's not claiming every obligation can be reduced to deterministic code. Some obligations are inherently subjective. Indemnities. Good faith obligations. Reasonableness standards. These can't self-execute, and pretending they can is irresponsible.

It's not a blockchain maximalist argument. Public chains are useful for some things. They're terrible for others. Composable Law is substrate-agnostic. Use the right tool for the job.

And it's not claiming automated enforcement eliminates consumer protection or jurisdiction. Skeptics are right to flag that smart contracts can create an illusion of enforcement. That's exactly why Composable Law takes the position it does: automate what you can, design the rest. Don't pretend the edge cases don't exist. Build escape hatches.

Why Now

This isn't a new idea born from crypto hype. It's the natural next step in a progression that's been happening for decades.

Contracts have changed media before. Paper standardization gave us boilerplate — reusable clause language that enabled commercial scale. Clickwrap and browsewrap moved formation onto screens. E-SIGN made electronic signatures legally equivalent to ink. eIDAS ensured electronic signatures are legally recognized across the EU, with qualified signatures treated as equivalent to ink. UNCITRAL’s Model Law on Electronic Transferable Records enables the digital use of foundational trade instruments across borders.

Each of these shifts followed the same pattern: a new medium, legal recognition of that medium, then widespread adoption. Composable Law is next in line. Once formation, records, and signatures are accepted in digital form, the natural next step is execution and governance in digital form.

The legal scaffolding is already in place. The UK Jurisdiction Taskforce concluded that smart contracts are capable of satisfying the requirements of a binding contract and can be interpreted and enforced using ordinary legal principles. The UK Law Commission reached similar conclusions about smart legal contracts fitting within existing doctrine. E-SIGN explicitly contemplates contracts formed by electronic agents. The foundations are solid.

What's missing is the implementation layer. A standardized way to compose legal meaning the way software composes code. Reusable modules. Typed parameters. Event-driven execution. Auditability. Governance for upgrades and amendments.

That's what we're building at Papre.

How It Works in Practice

A Composable Law agreement is a package. It contains the canonical legal text, typed parameters, a registry of which clause modules are used and their versions, execution logic, signature and consent artifacts, and evidence metadata.

At runtime, the agreement operates as a state machine over events. Events can come from the outside world — delivery confirmed, uptime breached, payment received — or from inside the system — notice served, cure period expired. State transitions trigger actions. Release funds. Issue a credit. Escalate a dispute. Serve a notice.

The composability comes from the module system. Each clause module — escrow, milestone acceptance, late fees, termination, SLA credits, arbitration, confidentiality, IP assignment — is a reusable building block. It includes both the legal text and the semantics. It declares what inputs it needs, what actions it produces, and what events it emits for downstream systems.

A rule engine prevents invalid compositions. You can't have a termination clause without a breach definition. Cure periods have to be consistent with governing-law constraints. Modules are versioned because law changes, policies change, and risk evolves.

This is how you maximize predictability without pretending you can anticipate everything. Enumerate the nodes you can. Constrain compositions to those you can defend. Build explicit escape hatches for the rest.

The Truth Problem

Most commercial agreements depend on facts that exist outside any system. Did the shipment arrive? Is the service up? Did the inspection pass? What's the usage count?

Smart contracts can't access external data without oracles — interfaces that bring real-world information into the system. This is non-trivial. Centralized data feeds create single points of failure. The Chainlink white paper proposed decentralized oracle networks for exactly this reason.

Composable Law treats oracles as first-class modules. Every assertion has provenance — who said what. Cryptographic signatures. Redundancy across sources. Dispute windows before finalization. And escalation paths that route to human review or invoke an arbitration clause when the data is contested.

Automation first. Dispute resolution when automation fails. That's the design principle.

Evidence as a Default Output

Here's something most CLM platforms get wrong. They treat the contract as a document plus metadata. The execution is indirect. The evidence is an afterthought — assembled after a dispute, from scattered emails and ambiguous records.

Composable Law flips that. Evidence is a default output of every agreement. Every state transition, every event, every action is logged with integrity proofs, timestamps, and schemas. The evidence bundle is designed to be admissible.

Under FRE 902(13), a record generated by an electronic process can be self-authenticated via certification. Under FRE 803(6), business records kept in the course of regularly conducted activity have a hearsay exception. Under FRCP 34 and 37(e), electronically stored information is subject to specific production requirements and preservation obligations.

Composable Law evidence bundles are built with all of this in mind. Standardized logs. Immutable integrity proofs. Clear schemas. Exportable records. When disputes happen — and they will — you're not reconstructing reality from a mess. You're handing over a clean, verifiable record.

Where Papre Fits

The market has adjacent solutions that each solve part of the problem.

CLM platforms — DocuSign CLM, Icertis, Ironclad, Agiloft — do workflow, repositories, approvals, and analytics well. But the contract is still fundamentally a document. Enforcement is indirect.

Smart contract platforms like Ethereum proved that deterministic logic can execute on shared state. But they're weak on legal prose, assent UX, compliance, and privacy.

Smart legal contract toolkits like the Accord Project bind prose to data models and connect to chain execution. But integration is heavy and adoption is fragmented.

Composable Law is the missing layer that unifies these. Legal meaning becomes modular and interoperable. Execution becomes verifiable. Evidence becomes a default output.

Papre's differentiating position is not "better CLM." It's CLM plus a runtime. The runtime unlocks predictable automation and evidence-grade logs. CLM remains useful as UI and workflow, but it becomes a consumer of the runtime.

Our product already points directly at this category. Agreements that enforce themselves. Escrowed payments released on completion. Clause selection and pricing guided by the system. The strategic move is evolving from "self-executing agreements" into a full agreement runtime — a platform where legal modules compile into verifiable workflows integrated with real software systems and backed by evidence, identity, privacy, and compliance controls.

Real Use Cases, Conservative Numbers

I'm not interested in selling ideology. I'm interested in workflows and measurable outcomes.

In finance and capital markets, the industry is actively converging on standardized lifecycle event models through ISDA’s Common Domain Model. Composable Law modules for margin, collateral, termination, and notice — driven by events, backed by oracle feeds and evidence bundles — can measurably reduce reconciliation overhead, exception handling, and operational risk.

In supply chain and trade, milestone-based payment modules with carrier API oracles, escrow release, and dispute windows directly reduce payment delays and dispute cycle time. Better working capital through faster condition verification.

In HR and workforce agreements, privacy constraints are high, but the workflow is clear — offer, IP assignment, policy acknowledgment, termination triggers, identity integration, evidence bundles for audits. Less admin time. Fewer compliance misses. Better audit readiness.

In real estate, deposit escrow with claim windows, inspection attestations, and automatic release after the window closes eliminates most deposit disputes. Faster turnover. Less manual mediation. And the consent UX matters here — Nguyen v. Barnes and Noble taught us that assent with consumers has to be engineered, not assumed.

In IP licensing, oracle-driven usage inputs, royalty calculation modules, audit rights triggers, and late fee enforcement reduce leakage from under-reporting and cut audit friction.

In B2B SaaS, SLA credit modules triggered by uptime events, renewal notices, usage commitments, and provisioning gates reduce churn from SLA disputes, fewer escalations, fewer renewal errors.

The umbrella number: if the average business loses 9% annually through poor contract management, recovering even a fraction of that justifies the infrastructure spend.

The Risks Are Real

I'm not going to pretend this is easy.

Security risk is well-documented. Smart contract vulnerabilities have led to real losses. The mitigation is to minimize the on-chain surface, treat core modules as a standard library with audits, use formal methods where justified, and build monitoring and incident processes.

Oracle risk is the truth problem. External data is messy. Multi-source attestations, signed provenance, dispute windows, fallback to human review, and explicit arbitration modules are how you handle it.

Upgrade governance risk is real because upgradeable contracts introduce powerful change mechanisms with new attack surfaces. Explicit upgrade policies, multi-sig governance, time locks, and version pinning in agreement packages.

Formation and UX risk is something product teams need to take seriously. Specht v. Netscape and Nguyen showed that even sophisticated businesses can blow enforceability if notice and assent are weak. Standardize consent UX patterns. Ship evidence proofs of what was presented and how assent was captured. Never default to browsewrap.

Regulatory risk around payments and AML is real if the platform includes escrow or automated payouts. AML and KYC need to be modular compliance layers — policy engines, integrations with regulated providers, jurisdiction gating.

Privacy risk under GDPR means you can't put personal data on immutable storage where erasure is required. Off-chain encrypted storage for sensitive content. On-chain commitments only. Retention controls.

Every one of these risks is manageable. But you have to design for them from day one, not bolt them on later.

What We're Building Toward

The sequencing matters. Runtime first. Then modules. Then integrations. Then evidence infrastructure. Then ecosystem.

We start with the agreement package and event bus — the typed model, state machine, adapters, and audit log. Evidence bundles aligned to E-SIGN and eIDAS validity principles from the jump.

Then composability — the module spec, standard library, validator, semantic types, and versioning. Curated core modules with legal review.

Then integrations — identity, payments, notifications. SDK, webhook subscriptions, failover. AML and KYC plugin surface for value transfer scenarios.

Then verifiability — signed attestations, provenance, challenge windows. Oracle design patterns and escalation logic.

Then litigation readiness — export formats, certifications, retention. Evidence bundles that hold up under FRE 902(13) and business records analysis.

Then ecosystem — marketplace, certification toolchain, security baseline.

Our twelve-month goals are concrete. 100-plus production agreements. 10,000-plus events processed. Sub-1% critical incident rate. 12 reusable modules with a reuse rate above 50%. Evidence bundles generated for 100% of agreements. Three oracle patterns shipped. AML/KYC plugin architecture and policy engine MVP. Three design partners across SaaS, supply chain, and fintech. Ten paid pilots.

The Big Picture

Composable Law is ultimately an interface shift.

In the future, agreements are not signed and forgotten but deployed and observed. Rights and obligations are not text-only but typed state machines over events. Performance evidence is not assembled after disputes but produced continuously. Integration is not bespoke but modular — payment rail, identity rail, oracle rail. Amendments are not chaotic redlines but versioned upgrades with governance.

Courts still matter. Meaning and equity still matter. Composable Law simply ensures that when courts are needed, reality is not reconstructed from scattered emails and ambiguous PDFs. It's reconstructed from a verifiable, signed, well-structured record of intent, events, and outcomes.

That's the real promise. Not law without courts. Law with predictable execution and evidence.

That's what we're building at Papre. And I think it changes everything.

Consciousness is the medium.

Every atom of this body. Every attention unit. Existence itself. The inherent bliss of pure awareness.

The sculptor's tool, shifting, spreading—deployed for one purpose: creating art. Consciousness painted.

Sure, we start with business contracts, software development milestone agreements, NDAs, and consulting accords. But that's a remnant of my attorney past.

Easy entrée into a world of overlapping Agreement.

It's deeper than that.

Papre isn't about Agreement for the sake of business efficiency.

A software developer agrees with her client. Easy.

You agree to follow the laws of your country. Yes, you agree. You're free to violate the law, although under duress.

Bodies agree to fall at 9.8m/s². Planets orbit stars. E=mc².

Papre is about Agreement as the connective tissue of the Human organism, of material reality itself.

It's axiomatic in this system.

It isn't Truth.

It's a way of ordering the world.

And when we order the world coherently in this way, as a system of Agreements, we can create an API for the world.

APIs are usually seen as a way for the world to interface with software.

Papre is different. Papre is the world's API.

By ordering the world in this way, software becomes the world's graph, a system of edges connecting previously disparate components of material reality into explicit systems that can be observed and shifted like a painter moving paint with her brush, eventually manipulating the very structure of reality.

Crazy? Yes.

But you already live inside this web of Agreements. Weave it yourself.

What's Been Shipping

A month of quiet violence against the blank canvas:

• Mobile QR signing — you scan a code, you sign from your pocket. Agreements escaped the desktop

• Facilitated agreements — a third party can now weave an agreement between two others, like a matchmaker who steps aside once the vows are spoken

• The document editor became an instrument — bubble menus, slash commands, drag sections like rearranging verses, AI that reads your document and fills the blanks

• Chain-agnostic architecture — Papre no longer cares which blockchain you're on. Switch chains with an environment variable. The protocol is indifferent to the substrate

• API v1 — the first public interface. Other software can now create and query agreements programmatically. The world's API gets its own API

• Embed profiles — agreement flows that live inside other websites, like a clause that nests inside a stranger's sentence

• A design system that breathes — warm grays, glass navigation, teal gradients. The interface started looking like something you'd want to touch

• The repo split in half — web and API separated into independent deployments. Faster. Cleaner. Two lungs instead of one

• Demo mode — a sandboxed reality for showing the product without disturbing the living system

Today was E2E test infrastructure day. We went from scattered lifecycle tests with Firefox failures to a consolidated overnight suite passing 240 tests across Chromium, Firefox, WebKit, Mobile Chrome, and Mobile Safari.

• Consolidated the overnight E2E suite — moved safety-net and NDA lifecycle tests into e2e/overnight/, where they belong alongside freelance and retainer lifecycles. The default CI suite stays fast (400 tests, Chromium-only); the overnight suite runs everything (640 tests, 5 browsers)

• Created 8 retainer lifecycle tests covering the full state machine: unsigned, signed-unfunded, fund-period visibility, claim-when-streamed, all-claimed, cancelled, completed, and party display with role labels

• Filled NDA and safety-net test gaps — one-way NDA variant rendering, terminate action for disclosing party, expired review deadline enforcement, and dispute evidence submission UI

• Fixed cross-browser Firefox failures by introducing gotoAgreementPage — a navigation helper using domcontentloaded instead of commit for tests that rely on addInitScript localStorage seeding. Firefox was racing past init scripts before the page could read E2E data

• Added overnight config hardening — 60s timeout (up from 30s) and 1 retry for cross-browser resilience

• Set up GitHub Actions overnight workflow with dependency deduplication checks and full lint/type/test/build/E2E pipeline

• Fixed 3 app-level bugs discovered during E2E: auth bypass in wallet mode, NDA key casing mismatch, and milestone state display

Why It Matters

Every agreement type now has lifecycle tests covering its full state machine across all browsers. When we add new features or refactor, these tests catch regressions before they reach users. The overnight suite is our safety net for the safety nets.

Up Next

• Close PAP-104, PAP-112, PAP-120, PAP-128 in Linear

• Begin retainer streaming payment UI work

From the Builder's Desk

The work I'm doing is piecemeal. It is far more focused than ever, by a large margin, but there's a shift that needs to happen.

I've been thinking about the work I do as pieces instead of a whole.

Yes, I'm director of Veda, founder of Papre, developing the Recovery software, and I'm a father and husband — but there do not need to be different me's doing that work. I am one. Not only within myself, but with everything around me.

Every moment integrated into the Pregnant Now.

That's frightening in a specific way because there's no room for bullshit. I kind of like the bullshit. I like the fragmentation because it feels like moments where there's no responsibility.

But there is no responsibility.

Responsibility is a product of fragmentation. Responsibility assumes a responsible self and an irresponsible self. I can feel how that split creates internal pressure: a manager self policing a managed self, a "good" me trying to control a "bad" me, a me that's on track bracing against a me that might fall behind.

I'm on the verge of recognizing the unified self.

There's no surrender necessary in the present moment. It's all the ever-present, pregnant now. No today or tomorrow. No goal. No past. No "present" defined as opposed to any other time. No one to become.

Fragmentation is a survival mechanism of ego. And fragmentation has a cost. It results in anxiety and worry. It makes it harder to shift gears.

Wholeness is ease. Fragmentation is anxiety.

When it's all one, there's no stress. Whether debugging a new flow, leading yoga, or holding my wife, there's no distinction. Just the ever-present, whole moment reacting to itself in bliss.

In the last three months I've noticed how radically unfazed I am by shifting gears. At one time in my life, I couldn't get anything done in the morning if I had a client meeting at 1pm. Now I ease into a flow that can shift from caring for the homeless guy I'm guardian for, to coding, to hiring and firing, to holding my wife.

No friction needed.

The flow happens without a "me."

Pause. Listen. Breathe. Relax for a moment and observe.

Onward.

What We Shipped

• Replaced all hardcoded legal templates with TemplateMark native rendering — legal prose now renders from typed Concerto models through Accord's template engine, not string interpolation. Every clause is a reusable package with its own data model, prose template, and test data. The assembler stitches clauses into contracts from a manifest. 12 clause packages compose into the first contract type, and new agreement types are now a manifest + strategy registration, not a copy-paste operation

• Built a generic Accord evaluation pipeline — all 9 agreement types now use the same evaluate-then-execute path. Seeding runs from seed-accord.mjs into Redis KV. The client sends form data to /api/accord/evaluate, which runs Accord's TypeScript logic in a VM sandbox and returns ALLOW/DENY/NEEDS_INPUT decisions. On ALLOW, the intent-executor calls writeContract() with ABI-encoded parameters. Milestone actions go through the same pipeline before hitting the chain. We removed the hardcoded template registry entirely in favor of adapter-driven metadata — each agreement type self-registers via a Map-based strategy registry

• Shipped API v1 with public signing — external users can now sign agreements without a Papre account. This was one of the last blockers for real-world use. Privy auth, CORS headers, and rate limiting on all routes. Extended ESLint to cover API .js files and eliminated 104 warnings across the codebase

• Migrated Terms of Service to papre-accord — the ToS is now a first-class Accord template, rendered through the same pipeline as every other agreement. No more special-case rendering for legal documents

• Added Ctrl+Shift+D test data for equipment-rental, papreboat-rental, and liability-waiver templates. Switched all test emails from Gmail to Mailinator (Gmail was bouncing test verification emails). Fixed field mapping issues in equipment-rental test data

• Hardened resilience across the stack — Lit Protocol encryption now gracefully degrades instead of crashing the app when the network is unavailable. Added embedded wallet fallback when smart wallet is unavailable on Fuji testnet. Fixed E2E testing issues with KV mode detection, auth ordering, and party email handling. Fixed CI smoke test failures and improved dev cold-start performance

• Codebase hygiene — eliminated all 104 ESLint warnings, deduplicated hooks and shared patterns across the codebase, extended lint coverage to API routes, and resolved CI E2E smoke test failures

• Wrote 16 architecture documents in one session — 7 new documents covering the Accord app integration pipeline, accept strategy pattern (self-registering strategies for all 9 agreement types), document encryption architecture (Lit Protocol + IPFS split architecture), SimpleDocumentAgreement spec, test data system, and 2 API specs. Migrated 6 ad-hoc docs that had been written directly to docs/ (bypassing the Obsidian vault workflow) back into the vault where they belong. Updated 3 existing architecture docs with cross-references. Caught up the CHANGELOG with 12 missing entries spanning two weeks of features. Deduplicated entries that had been copy-pasted up to 7 times. Restored the documentation workflow instructions to CLAUDE.md so the AI agent won't skip docs again

Why It Matters

The hardcoded-to-TemplateMark migration is the difference between a platform with 9 agreement types and a platform that can scale to 100. Every new agreement type is now a manifest pointing at reusable clauses. The on-chain and prose layers mirror each other — both are compositions of atomic primitives. This is the architecture that makes composable law possible.

The documentation overhaul matters just as much. Architecture docs that fall behind the code aren't just missing information — they're missing institutional memory. We closed a two-week gap today and restored the workflow that prevents it from happening again.

Up Next

• Retainer agreement adapter implementation

• Expand E2E test coverage across all 9 agreement types

• Begin integrating Accord evaluation results deeper into the on-chain execution pipeline

• Start building toward the 50-clause library

From the Builder's Desk

Blockchain development, running group therapy, managing staff and clients, and personal meditation and yoga practice create an ever-changing, ever-shifting flow. All I can do is relax into it and let it pass through me. If I clench, the current catches me and throws me around. If I stay present but relaxed, the flow leaves nothing behind except the invigoration of energy in motion and the bliss of exploration.

Stress and anxiety in me are reactions, not to external circumstances, but to my own clenching against those circumstances. In private work with others, I often hear a familiar fear: if they meditate too much, they'll lose their edge. They'll lose their drive to succeed.

Maybe. And if you do, it's only because you've shifted out of the energy flow your biology, your family, your society, your experience have imposed upon you. By relaxing, you stop doing their bidding. You enter a more natural flow, where life is, frankly, easier. But releasing the NEED to achieve isn't universal in those who meditate, or in those who go deep within themselves to discover.

Others—like me—dig deep and find that the natural course is to attempt to make big changes in reality, to bring lots of energy to bear on the material world.

That's the thing about deep internal work: you don't get to choose where it heads ahead of time. I should say, your ego doesn't get to choose ahead of time. In my life, I've come to feel like there's a kind of higher-self calling the shots. I've come to experience this higher-order autonomy, not as an idea, but as something alive in me.

When I let go of the need to control, what I thought I wanted and needed usually falls away, and something far better manifests itself. This has happened over and over and over. My wife is 10x the woman I was seeking. My project is 1000x as incredible as I envisioned. My life is indescribably better than anything I imagined, even at my most optimistic. And it sure as hell is an improvement over the version of me that would have been satisfied with not dying totally broken and alone.

Sometimes it feels like I've died, and that God—if there is one—is so merciful that it shifted me to heaven. And in order to keep me from freaking out, that heaven looks a lot like the world I left at death.

Tomorrow we keep building the infrastructure for trustless coordination — one clause, one agreement, one document at a time.

I run a men's sober living facility by day. I fire employees, reprimand clients, teach yoga to 26 guys who've spent decades numbing themselves. Then I come home and dream about where Agreement technology can take humanity over the next 250 years, and reverse-engineer that future into today's code.

What We Shipped

Nothing public today. The Accord evaluator integration from yesterday is sitting in the branch, tested and compiling. 56 tests passing. But the real work today was internal.

Why It Matters

Papre needs speed, clarity, and a center of gravity. As we scale from solo builder to team, the leadership patterns I'm building now will determine everything. Consensus is comfortable but slow. What I'm learning managing sober living — where consensus doesn't work, where stakes are high and decisions have to land — is directly applicable.

From the Builder's Desk

I've always tried to manage by consensus. I like alignment. I like people feeling heard. I like building something that feels like ours, not mine. When the team is mature, motivated, and competent, consensus can work well.

But consensus has a cost. It slows decisions. It blurs accountability. It quietly teaches people that no one owns the outcome, because the outcome belongs to "everyone." And when stakes rise, consensus can turn into a veto system.

I don't think that approach will work at Papre. Papre needs a strong vision, clear roles, and decisions that actually land. People can challenge ideas, debate them hard, and contribute honestly, but once we decide, we move. I want collaboration without drift, input without paralysis, and culture without confusion.

So I'm learning to hold the line. Listen deeply, decide cleanly, and make it obvious who owns what. Not because I want control, but because I want results — and because I want the work to ship.

Tomorrow, more code. But today's lesson will outlast any commit.

Turns out I had a throughput problem.

From the Builder's Desk

I've struggled with executive function all my life. This apparent dysfunction didn't fade with time or effort. Then along came AI, and my apparent executive dysfunction disappeared. My superpowers emerged.

Now I stay focused, hyperfocused even, 12-14 hours a day. I produce at a rate beyond my wildest daydreams.

It turns out my problem was not doing enough.

Before modern AI, I was at my best when I was working on five unrelated projects. I got more done that way. Sure, I was spreading myself thin, but I was also doing good work in five different areas.

With AI, I can devote all my time to one project. Instead of trying to type 1,000 words a minute to keep up with my thoughts, I break the work into pieces, well-defined pieces, and delegate.

Call it "vibe coding," call it what you will. Without me, without my human brain, without my creativity, AI certainly won't produce the work. And no one else will either.

I'm a unique combination of transactional lawyer, computer science grad, mathematics grad, and meditation teacher. It's not that I'm smarter. It's that I'm uniquely me, and Papre could only be created by me.

What This Means for Papre

Papre is composable agreement infrastructure — trustless coordination through atomic clauses. The kind of thing that requires deep knowledge of both contract law and smart contract architecture. The kind of thing that wouldn't exist if I was still context-switching across five projects.

AI didn't replace my thinking. It removed the friction between thinking and building.

Up Next

• Continuing the TemplateMark native integration for legal document rendering

• First full end-to-end digest publish across 8 platforms

The throughput is the therapy.