Daily Rambam Accelerated · Startup Mensch · Standard
Mishneh Torah, Tithes 10-12
Hook
Every early-stage startup begins in a state of high-trust paradise. You, your co-founders, and your first three engineers are a tight-knit cohort. You do not need written policies, time-trackers, or cryptographic access controls. You operate in what the Talmudic sages would call a state of chavairut—a closed circle of trusted peers who share the same values, the same risk profile, and the same absolute commitment to the mission.
But then, you raise your Series A.
Suddenly, your head count doubles, then triples. You must integrate third-party APIs, hire outsourced contractors in Eastern Europe, and buy raw materials from vendors whose corporate governance consists of a handshake and a prayer. In the rush to scale, you transition from a high-trust insular group to a wide market of external actors—the modern business equivalent of the am ha'aretz (the common person whose compliance with ethical and regulatory standards is unverified).
This is where the wheels fall off.
Founders mistakenly believe that they can scale their internal culture of trust outward by simply "expecting" vendors, partners, and new hires to operate with the same integrity. They do not realize that trust is not a vibe; it is a structural architecture. When you fail to draw hard boundaries between your verified internal processes and your unverified external counterparties, you do not elevate the market—you dilute your own brand. You inherit their liability, their dirty data, their regulatory non-compliance, and their ethical debt.
As we enter Rosh Chodesh Tamuz, this dilemma becomes acute. Tamuz is historically the month of sight, of exposure, and of intense heat Mishnah Taanit 4:6. It is the season when the cracks in your operational foundation, previously hidden by the cool shade of early-stage obscurity, are baked under the harsh sun of market scrutiny. It is the time of year when Moses sent spies to inspect the Land of Israel—a classic case of agency failure, distorted reporting, and unverified inputs Numbers 13:1.
If you do not build a systematic, graduated framework for trust, verification, and liability delegation, the heat of this growth season will incinerate your enterprise. Applying the meticulous laws of demai (doubtfully tithed produce) from Maimonides’ Mishneh Torah, Hilchot Ma'aser (Chapters 10-12), we will construct an ironclad, ROI-minded framework for managing counterparty risk, platform liability, and compliance delegation.
Full Experience in the App
Listen. Chat. Go deeper.
Audio playback, interactive chevruta, Hebrew tools, and every daily learning track — only in Derekh Learning.
Text Snapshot
"When a person makes a commitment to be considered trustworthy with regard to the tithes... he must tithe [the produce] he eats, that which he sells, and that which he purchases, and he must not accept the hospitality of a common person. He must make these commitments in public... Every Torah scholar is always considered trustworthy. There is no necessity to investigate his [conduct]... [We operate] under the presumption that a person will not sin without receiving any benefit." — Mishneh Torah, Tithes 10:1, Mishneh Torah, Tithes 10:2, and Mishneh Torah, Tithes 12:14
Analysis
To build a highly scalable, ethically bulletproof enterprise, you must abandon the naive assumption that trust is binary. It is not. According to the Rambam, trust is a dynamic state of custody, agency, and transaction volume. We extract three critical business decision rules from Chapters 10, 11, and 12 of Hilchot Ma'aser.
Insight 1: The Trust Premium and the Cost of Public Compliance (Fairness)
The Rambam begins by defining the entry requirements for the chavair—the trustworthy cohort:
"When a person makes a commitment to be considered trustworthy... he must tithe [the produce] he eats, that which he sells, and that which he purchases..." Mishneh Torah, Tithes 10:1.
Rabbi Adin Steinsaltz, in his commentary on this passage, notes the expansive nature of this commitment. In Steinsaltz on Mishneh Torah, Tithes 10:1:1, he writes that "what he eats" applies "whether his own or that of a common person" (בין משלו ובין משל עם הארץ). Furthermore, in Tithes 10:1:3, "that which he purchases" is defined as "buying from a common person in order to sell" (קונה מעם הארץ על מנת למכור).
The ethical lesson for a founder is stark: You cannot claim a high-integrity brand while using low-integrity inputs.
If you sell a product, you are ethically and operationally responsible for the entire supply chain. You cannot say, "Our internal code is secure, but the open-source library we imported from an unverified developer had a backdoor." If you buy from an unverified counterparty to sell to your clients, you must run the full suite of security audits yourself.
The Rambam notes that this commitment must be made "in public" (בָּרַבִּים), which the commentary defines as "in the presence of three people" who are already verified Mishneh Torah, Tithes 10:1:5.
In modern terms, this is your SOC2 Type II certification, your ISO 27001 audit, or your public smart contract audit. It is a costly, public-facing friction point. Why do you pay this upfront compliance tax? Because it unlocks the Trust Premium:
"Every Torah scholar is always considered trustworthy. There is no necessity to investigate his [conduct]." Mishneh Torah, Tithes 10:2.
In business, trust is velocity. If your firm has established a public, verifiable standard of compliance, your enterprise clients will not subject you to months of security questionnaires and vendor audits. They will bypass the gate because your brand carries the "scholar" status of automatic trust.
However, if you mix your operations with unverified actors without strict separation, you lose this premium instantly. The Rambam warns:
"It is more likely that a person with proper habits will become lax due to the bad habits of a friend than a person with improper habits will change..." Mishneh Torah, Tithes 10:3, note 12.
If your high-compliance engineering team frequently interfaces with a low-compliance outsourced agency without a rigorous API gateway or code-review firewall, your internal code quality will inevitably decay to the level of the outsourced agency. The laxity of the unverified counterparty is contagious.
[Unverified Market (Am Ha'aretz)]
│ (High Friction / Low Velocity)
▼
┌────────────────────────────────────────┐
│ Public Compliance Gate (SOC2/Audit) │ ◄── "Must make commitments in public"
└────────────────────────────────────────┘
│ (Unlocks Trust Premium)
▼
[Verified Cohort (Chavair)]
│ (Zero-Friction / High Velocity)
▼
[Enterprise Scale]
Insight 2: Asymmetric Agency and the "Meah" Rule (Truth)
One of the most profound insights in Hilchot Ma'aser concerns the boundaries of agency and custody. The Rambam writes:
"When a common person gives a meah to a chavair and tells him: 'Buy me a bunch of vegetables...' he may purchase it for him without any qualification and is not obligated to tithe it." Mishneh Torah, Tithes 10:8.
Why is the chavair exempt from tithing here, despite the rule that he must tithe everything he purchases? Because he is acting strictly as a non-custodial agent. He did not mix his own capital with the transaction; he did not buy it for himself and flip it to the client. He was merely an API router.
However:
"If [the agent] exchanged the meah, he is obligated to tithe..." Mishneh Torah, Tithes 10:8.
If the agent swaps the client's specific coin for his own money, he has stepped out of a pure non-custodial routing role and into a custodial/clearing role. The moment you touch the money, pool the assets, or exchange the currency, you assume full liability for the compliance of the underlying asset.
This is a massive warning for Fintech and Web3 founders. If you build a non-custodial wallet or a routing protocol, your regulatory and ethical liability is minimal. But the moment you implement a "liquidity pool," a "gas-less relayer," or a clearing mechanism where you exchange the user's specific assets for your own inventory, you have "exchanged the meah." You are now fully liable for tithing (KYC, AML, and asset verification) the entire transaction flow.
This concept of volume and custody is further illuminated by the Ohr Sameach in his commentary on Tithes 10:10:1. He analyzes a scenario where a common person tells a chavair: "Collect figs for me from my fig tree."
The Ohr Sameach explains that if the chavair is given a specific, limited container—a mela kalkala (a full basket)—it is a transaction of a "known measure" (מדה ידועה). In this case, the expectations are clear, the boundaries of the asset are fixed, and the agent must operate with high-precision compliance.
In contrast, if it is an open-ended, loose arrangement, the compliance burden shifts. When you deal in precise, metered API calls or fixed-contract deliverables, your compliance must be absolute. When you deal in loose, unmetered consulting retainers, the lack of defined boundaries creates ethical gray zones where liabilities bleed across entities.
Insight 3: The "Mouth vs. Hand" Principle of Platform Liability (Competition)
How do you build a platform that hosts unverified users without becoming criminally liable for their actions? The Rambam provides an extraordinary blueprint in Chapter 11:
"When a doctor who is a chavair is feeding a common person... from the produce of a common person, he should place [the food] in his hand, but not in his mouth." Mishneh Torah, Tithes 11:1.
This is the ultimate distinction between infrastructure provision and direct execution.
The doctor knows the food is likely uncompliant (demai). Because the patient is sick, there is a necessity to facilitate the transaction. But how does the doctor protect his own ethical integrity?
- He places it in the patient's hand: He provides the platform, the physical access, and the enablement layer. The patient retains ultimate agency and liability.
- He does not place it in his mouth: He does not execute the final action. He does not act as the direct instrument of non-compliance.
If you run a B2B SaaS platform, a marketplace, or a developer platform (like GitHub or AWS), you are the doctor. Your users will occasionally upload copyrighted material, run unauthorized scrapers, or store uncompliant data.
If you design your software to automatically parse, clean, and execute actions on that uncompliant data for them, you are "placing it in their mouth." You have crossed the line from a neutral infrastructure provider to an active accomplice.
You must design your systems with "hand-delivery" boundaries. Provide the storage, provide the API endpoint, but force the user to pull the trigger, sign the transaction, and validate the input.
Furthermore, the Rambam introduces a brilliant volume-based liability rule:
"All of those who add to the measure when they sell in large quantities... are permitted to sell and send demai... Since they add to the measure, our Sages ordained that the purchaser... be the one who separates the tithes..." Mishneh Torah, Tithes 11:2.
If you sell in bulk (wholesale B2B), the unit economics are thin, but the transactional velocity is high. The Sages recognized that forcing a wholesaler to verify every single unit of data or inventory would paralyze the market. Therefore, for "large measures" (defined in Tithes 11:3 as half a se'ah or more), the compliance burden shifts entirely to the buyer.
But if you sell in "small measures" (retail B2C), where you are extracting high margins and pocketing the retail markup, you must bear the compliance cost:
"...since the seller is the one who profits, he should make the separations." Mishneh Torah, Tithes 11:2.
If your startup is a high-margin premium B2C app, you cannot hide behind a "user-generated content" disclaimer. You are pocketing the retail premium; therefore, you must curate, moderate, and verify the inputs. If you are a low-margin, infrastructure-level B2B pipe, you can legally and ethically shift that burden to your enterprise buyers, provided you sell in "large measures" of volume.
Policy Move
To operationalize these insights, you must implement a Graduated Counterparty Verification Protocol (GCVP). This policy eliminates the binary "trust/no-trust" bottleneck and replaces it with a dynamic, three-tiered system modeled directly on the Rambam’s treatment of the chavair, the am ha'aretz, and the shifting of liability based on transaction volume.
[Counterparty Onboarding]
│
┌──────────────────────┴──────────────────────┐
▼ ▼
[B2B / Large Volume] [B2C / Small Volume]
(Half a Se'ah +) (Retail / High Margin)
│ │
▼ ▼
┌──────────────────────────────┐ ┌──────────────────────────────┐
│ Shift Compliance to Buyer │ │ Platform Must Self-Audit │
│ "Large Measure" Exemption │ │ "Small Measure" Obligation │
└──────────────────────────────┘ └──────────────────────────────┘
│ │
▼ ▼
[Escrow / Indemnity] [Strict API Gateways]
"Stipulation in Heart" Clause "Hand, Not Mouth" Execution
Phase 1: Establish the "Large Measure" Volume Gate
Do not waste your engineering team's cycles running deep security audits on low-value, high-volume B2B integrations.
- The Policy: Any vendor integration or data pipeline processing under 10,000 requests per month (the modern "small measure") must be fully sandboxed, and its outputs must be run through automated validation scripts (our modern demai separation).
- The Exemption: For high-volume enterprise integrations processing over 100,000 requests per month (the modern "large measure"), the master service agreement (MSA) must include an Asymmetric Compliance Clause. This clause legally shifts the liability of data hygiene, licensing, and security verification to the counterparty, utilizing the Rambam's rule that "the purchaser or the recipient be the one who separates" Mishneh Torah, Tithes 11:2.
Phase 2: Implement the "Hand, Not Mouth" API Architecture
If your platform allows third-party developers or users to run custom integrations, you must refactor your execution layer.
- The Policy: No automated system may execute a high-risk action (e.g., executing a financial transaction, deploying code to production, or sharing private user data) based on unverified third-party inputs.
- The Implementation: You must build an explicit, asynchronous "User Confirmation Gate." Your platform may parse the third-party data and present the option to the user (placing it "in his hand"), but the user must manually click "Approve" or sign the cryptographic payload (preventing you from placing it "in his mouth" Mishneh Torah, Tithes 11:1).
Phase 3: The "Stipulation in the Heart" Escrow Policy
When your executives must interact with unverified counterparties under high-velocity situations (e.g., closing a partnership at a conference, or acquiring distressed assets), implement an escrow-based safeguard modeled on the chavair's silent stipulations:
"Perhaps the chavair is relying on the stipulations made in his heart." Mishneh Torah, Tithes 10:6.
- The Policy: Every rapid-execution partnership or vendor onboarding that bypasses standard compliance cycles must be executed through a Conditional Escrow Agreement.
- The Mechanism: 20% of the contract value is held in escrow for 90 days. During this window, the counterparty's outputs (code, data, or physical inventory) are subjected to retrospective audits. If a compliance failure is detected, the escrow is forfeited to cover the cost of internal remediation. This is the operational equivalent of reserving the right to make retroactive separations on doubtfully acquired goods.
Metric to Track: The Trust Friction Ratio (TFR)
To measure the financial and operational ROI of this policy, track your Trust Friction Ratio (TFR):
$$\text{TFR} = \frac{\text{Vendor Onboarding Time (Days)} \times \text{Legal/Security Hours Billed}}{\text{Total Contract Value (TCV)}}$$
By establishing the "Large Measure" exemption and the "Hand, Not Mouth" architecture, you should aim to reduce your TFR by 35% year-over-year for high-volume enterprise contracts, shifting the expensive compliance overhead to the counterparties who are best equipped to bear it.
Board-Level Question
Context
In Hilchot Ma'aser, the Rambam details the complex dynamics of inheritance and mergers between high-compliance and low-compliance entities:
"When a chavair and a common person inherit [the estate] of their father who was a common person... [the chavair] may say: 'Take the wheat in this-and-this place and I will take the wheat in this-and-that place...' He should not say: 'Take wheat and I will take the barley...'" Mishneh Torah, Tithes 11:5.
The Sages allowed the chavair to split identical assets (wheat for wheat) because we apply the principle of bereirah (retroactive clarification)—assuming that the inheritance was split from the very beginning. But if he swaps different types of assets (wheat for barley), it is considered a sale of uncompliant goods (demai), which is strictly forbidden.
Furthermore:
"When the daughter of a common person... marries a chavair... they must accept the requirements as at the outset." Mishneh Torah, Tithes 10:3.
This is the exact operational challenge of Corporate Mergers, Acquisitions, and joint ventures.
When your high-compliance, enterprise-grade startup acquires a smaller, scrappier competitor (the "daughter of a common person"), or when you enter a joint venture with a legacy corporate partner, you cannot assume their historical data, codebases, or customer lists are compliant. If you simply merge their database into yours, you "mix the wheat with the barley" and poison your entire corporate estate.
The Question for the Board
"When we execute an acquisition, joint venture, or major third-party integration, what is our technical and legal protocol for isolating their legacy 'ethical and technical debt' (unverified data, uncompliant code, unvetted customer consent) before it integrates with our core systems?"
Discussion Guide for the CEO & Board
To guide this discussion, evaluate your pipeline against the following three risk profiles:
The "Wheat-for-Wheat" Isolation Rule: Are we separating acquired assets cleanly? If we acquire a company, we must run their legacy data in a completely segregated database instance. We cannot merge their user profiles with our core database until we have run a retrospective "tithing" audit (verifying GDPR/CCPA compliance, opt-in consent, and data encryption standards).
The "Marriage Onboarding" Period: Just as the daughter of an unverified person must "accept the requirements as at the outset" Mishneh Torah, Tithes 10:3, the engineering and sales teams of an acquired company must undergo mandatory, immediate training on our compliance standards. Their legacy workflows must be suspended on Day 1, and they must not be granted write-access to our main codebase until they are verified as chavairim.
The "Dung Heap" Assessment:
"Those on a dung heap - wherever it is found - are permitted." Mishneh Torah, Tithes 11:14.
Are we wasting money trying to audit and clean low-value legacy assets from our acquisitions? If an acquired codebase or customer list is outdated and messy, do not spend engineering hours trying to "tithe" it. Declare it "ownerless on a dung heap." Deprecate it immediately. The cost of cleaning bad legacy code is almost always higher than the cost of rebuilding it from scratch.
Takeaway
In the relentless pursuit of scale, founders often treat trust as a soft skill or a marketing slogan. The Torah, through the precise mechanics of demai and chavairut, reveals that trust is a highly engineered, cryptographic, and legal architecture.
You cannot scale a high-velocity enterprise on unverified inputs. You cannot build a premium brand while routing dirty data, using unvetted vendors, or allowing uncompliant actors to pull the trigger on your platform.
By applying the Rambam’s insights, you protect your enterprise from systemic rot:
- Pay the public compliance tax to unlock the high-velocity "Trust Premium."
- Enforce the "Hand, Not Mouth" boundary to keep your platform clean of user liability.
- Shift the compliance burden to your high-volume partners, and ruthlessly isolate the technical debt of your acquisitions.
As we navigate the heat of Tamuz, let your operational visibility be absolute. Do not rely on "stipulations in the heart" where hard code and ironclad contracts are required. Build your startup as a chavair—a beacon of systemic integrity that the market can trust without investigation.
derekhlearning.com