Chullin 70

Hook

Every founder lives in the high-stakes purgatory of the "almost."

You have a signed term sheet, but the wire hasn’t cleared. Is that capital yours, or are you still bootstrapped? You have a verbal "yes" from an enterprise client on the last day of Q3, and your sales rep is demanding their commission. Do you recognize that revenue now, or do you wait for the ink to dry? Your lead engineer has built 90% of a critical feature, but the last 10%—the buggy integration—is dragging on. Is the milestone met, or is it still a work in progress?

These are not merely operational headaches; they are profound ethical and financial boundary disputes. When we operate in the grey zones of transition, we tempt systemic failure. We play games with our balance sheets, our cap tables, and our reputations.

In Chullin 70a, the Talmud wrestles with the exact anatomy of a transition. It asks a deceptively simple question: At what precise millimeter, and under what conditions, does a transition become absolute?

Through a series of hyper-detailed, physical dilemmas regarding the birth and consecration of a firstborn animal, the Sages of the Talmud map out the exact mechanics of thresholds, retroactivity, and interposition. They dissect the difference between incremental progress and absolute delivery. They ask whether a boundary crossed via a proxy still counts as a boundary crossed.

As a founder, if you do not master these boundaries, your cap table will dissolve into lawsuits, your revenue recognition will trigger audits, and your channel partners will eat your margin. Let’s apply the razor-sharp logic of the Talmud to your scaling startup.

---

Text Snapshot

"Rava raises a dilemma: Does one follow the majority with regard to limbs or does one not follow the majority with regard to limbs?... Rather, the dilemma is referring to a case where half of the fetus emerged, but that half includes the majority of a certain limb, and Rava raises the following dilemma: With regard to this minority part of a limb that is inside the womb, what is the halakha as to whether one casts it and counts it together with the majority of that limb and considers it as if that entire limb has emerged?" — Chullin 70a:11

---

Analysis

Insight 1: Fairness – The Toxic Illusion of Retroactive Valuation (Rav Huna vs. Rabba)

The Gemara opens with a fundamental dispute between Rabba and Rav Huna regarding when a firstborn fetus becomes consecrated Chullin 70a:1. Rabba holds that the animal is consecrated "from that point forward" (מכאן ולהבא קדוש), meaning its status changes only when it actually crosses the physical threshold of birth. Rav Huna, conversely, argues that the consecration is "retroactive" (למפרע קדוש), meaning that once the birth is complete, the holiness retroactively applies to the moments before the final threshold was crossed.

To understand the operational danger of Rav Huna’s retroactive model, we must look at Rashi’s commentary on this passage. Rashi notes:

"דאי אמרת למפרע קולא הוא דלא קדיש" — Rashi on Rashi on Chullin 70a:1:1

(Translation: "For if you say it is retroactive, it results in a leniency where it is not consecrated.")

Rabbeinu Gershom echoes this structural tension, stating:

"דכשם שאמרו לחומרא כך אמרו לקולא" — Rabbeinu Gershom on Rabbeinu Gershom on Chullin 70a:1

(Translation: "Just as they said to be stringent, so they said to be lenient.")

When you base your business operations on retroactive calculations, you introduce a structural instability that can be exploited. In startup terms, this is the classic trap of the retroactive adjustment clause.

Consider a common founder scenario: You issue equity to an early employee with a retroactive vesting clause tied to a performance milestone, or you sign a vendor agreement with a retroactive pricing tier based on annual volume. If the milestone is met, the valuation or pricing applies retroactively to day one.

The Talmud warns us that while retroactivity seems like a convenient tool to manage risk (a "stringency" to protect your downside), it inevitably introduces a "leniency"—a loophole that destroys fairness.

If an employee's equity vests retroactively upon a successful product launch, you create an ethical hazard. The employee has every incentive to rush a buggy product to market to trigger the retroactive payout, even if it harms the company's long-term health.

Conversely, if you retroactively claw back commissions from sales reps because a client churned in month eleven, you destroy morale and trust.

The Decision Rule

Reject retroactive contract mechanics.

Adopt Rabba’s rule of mikan u'lehabah—from this point forward Chullin 70a:1. All valuations, vesting, and pricing tiers must be triggered by discrete, forward-looking events. If a volume target is hit, the discount applies to the next dollar spent, not the last. If a milestone is met, the equity begins vesting from that day forward. This eliminates the temptation to manipulate past data to achieve a retroactive windfall.

---

Insight 2: Truth – The "Majority of a Limb" Fallacy and ASC 606 Compliance

Rava raises a brilliant architectural dilemma:

"Does one follow the majority with regard to limbs or does one not follow the majority with regard to limbs?" — Chullin 70a:10

The Gemara clarifies the scenario: Half of the fetus has emerged, but that half includes the majority of a specific limb that is still partially inside the womb Chullin 70a:11. Do we aggregate the minority of the limb inside the womb with the majority of the limb outside, thereby claiming the entire limb—and by extension, the majority of the fetus—has emerged?

Steinsaltz explains the mechanics of this dilemma:

"שמיעוט האבר שבפנים מצטרף לרוב האבר שבחוץ" — Steinsaltz on Steinsaltz on Chullin 70a:11

(Translation: "The minority of the limb inside joins with the majority of the limb outside.")

This is the exact operational problem of fractional milestone aggregation. In software development and enterprise sales, founders constantly try to "join the minority inside with the majority outside."

For example, your engineering team reports that a critical platform migration is "90% done." The database is migrated (the majority of the limb is outside), but the security protocols are still being written (the minority is inside). Because the database is the most visible part of the work, you aggregate the two and report to your board that the milestone is fully achieved. You have allowed the "majority of the limb" to distort the truth of the whole.

In accounting, this is a violation of ASC 606 (Revenue from Contracts with Customers). Under ASC 606, you cannot recognize revenue on a performance obligation unless control of the distinct good or service has transferred to the customer. If you recognize revenue on a software delivery because the "majority of the features" are live, while the core integration is still "inside the womb," you are committing accounting fraud.

The commentary of the Dor Revi'i on this passage analyzes how we view incremental delivery:

"נעשה כאלו יצא רובו" — Dor Revi'i on Dor Revi'i on Chullin 70a:2:1

(Translation: "It is treated as though the majority has emerged.")

He discusses the tension between viewing a delivery as a series of cut-up pieces (mchatach u'maniach) versus a single, holistic event. If you deliver a product piece-by-piece, you cannot claim the holistic value of the product until the final, connecting piece crosses the threshold.

The Decision Rule

Define milestones with absolute, non-aggregating granularity.

A feature is not "shipped" if it is waiting on a code review. A contract is not "closed" if it is waiting on a security questionnaire. You must ban the phrase "90% done" from your company’s vocabulary.

Milestones must be binary: 0 or 1. You cannot use the progress of one "limb" (e.g., frontend design completed) to claim that the "body" (the functional software) has crossed the delivery threshold.

---

Insight 3: Competition – The Interposition of Proxies and Channel Partner Leakage

Rava introduces a series of increasingly radical boundary challenges that should keep any platform founder awake at night. He asks:

"If one wrapped the fetus in the bast of a palm tree... and it therefore did not come in contact with the opening of the womb directly when it emerged, what is the halakha?" — Chullin 70a:15

He goes on to ask about a fetus swallowed by a weasel inside the womb, carried out, and then vomited back in Chullin 70a:18. Finally, he asks about pressing the openings of two wombs together, where a fetus exits one womb and directly enters another Chullin 70a:21.

These are not bizarre agricultural hypotheticals. They are highly sophisticated models of interposition and channel routing.

In the modern digital economy, the "womb" is your proprietary platform, your intellectual property, or your primary customer relationship. The "fetus" is the transaction value or data generated. The "bast of a palm tree" or the "weasel" represents third-party intermediaries, APIs, white-label wrappers, and channel partners.

When a customer uses your software, but they access it through a white-labeled integration built by a channel partner (the "bast of a palm tree" wrapping the fetus), who owns the customer relationship? If a transaction is routed through a partner's payment gateway (the "weasel" swallowing the fetus) before being settled on your ledger, did that transaction "open your womb"—meaning, are you entitled to the full transaction fee, or has the partner intercepted the value?

The Gemara’s analysis of the two-womb scenario is particularly striking:

"Is the womb considered to have opened only when its own fetus emerges from inside, but a fetus that is not its own is not halakhically considered to have opened the womb?" — Chullin 70a:21

The Gemara leaves this unresolved: "The dilemma shall stand" (teiku).

In business, when you allow your product to be routed through a competitor's or partner's infrastructure so closely that the boundaries blur (pressing two wombs together), you enter a legal and strategic danger zone where attribution is impossible to prove. If a user starts on your platform, clicks an integrated partner link, completes the transaction on their site, and then returns to yours, who owns the conversion? Who pays the affiliate fee?

The Decision Rule

Protect your platform boundaries from proxy degradation.

If you white-label your technology or distribute it through channel partners, your contracts must explicitly state that the "interposition" of a partner's wrapper does not negate your IP rights, your data ownership, or your direct platform attribution.

Never allow a partner to "wrap" your product so deeply that your brand and data collection mechanisms are completely insulated from the end-user. If you do, you are giving away your core asset—the direct relationship with the customer.

---

Policy Move: The "Threshold Integrity and Binary Milestone" Protocol

To translate these talmudic insights into a concrete operational system, your company must implement the Threshold Integrity and Binary Milestone (TIBM) Protocol. This policy completely eliminates the grey zones of "almost" and "retroactive" calculations across your engineering, sales, and finance departments.

                  THE TIBM PROTOCOL: MILESTONE FLOW
                  
   [   INCOMPLETE   ] ──( The "Limb" Fallacy )──► [ 0% RECOGNITION ]
         │
         ▼ (Must cross 100% of defined threshold)
         
   [   COMPLETED    ] ──( Mikan U'lehabah )─────► [ 100% RECOGNITION ]

Policy Specifications

1. The Binary Engineering Definition of "Done" (The Rava Rule)

• No project, feature, or sprint task may be reported as a percentage of completion to leadership or the board.
• All tasks must be tracked as either 0 (Incomplete) or 1 (Complete).
• A task is only marked "1" when it meets the "Definition of Done" (DoD), which must include:
  • Code written and peer-reviewed.
  • Unit and integration tests passed.
  • Deployed to a staging environment.
  • Signed off by the Product Owner.
• If a feature is 99% coded but lacks the final API handshake, its reported status is 0. We do not "cast the minority inside the womb with the majority outside" Chullin 70a:11.

2. Forward-Only Financial Adjustments (The Rabba Rule)

• All enterprise contracts, vendor agreements, and commission structures must be drafted using the Mikan U'lehabah (from this point forward) framework Chullin 70a:1.
• No retroactive clawbacks or rebates. If a customer signs an annual contract with volume-based pricing tiers, the discounted pricing applies only to transaction volume processed after the tier threshold is crossed. It does not apply retroactively to volume processed at the higher rate.
• Sales Commissions: Sales commissions are earned and paid only when cash is received from the client. If a client churns, future unpaid commissions are cancelled, but past paid commissions are never retroactively clawed back. This maintains fairness and contract integrity.

3. Strict Channel Attribution and Wrapper Auditing (The Wrapper Rule)

• Every API integration, white-label agreement, or distribution partnership must include an "Attribution and Direct Contact Clause" (addressing the "bast of a palm tree" dilemma Chullin 70a:15).
• The clause must state: "Regardless of the software wrapper, user interface, or intermediary routing platform utilized by the Partner, the underlying transaction and user data remain the sole property of the Company. The use of an intermediary wrapper shall not diminish, alter, or delay the Company’s rights to IP protection, transaction-level auditing, and direct brand attribution."

KPI Proxy: The Milestone Integrity Ratio (MIR)

To measure the effectiveness of this policy, your finance and operations teams will track the Milestone Integrity Ratio (MIR) monthly.

$$\text{MIR} = \frac{\text{Projected Milestone Revenue Recognized on Time}}{\text{Actual Milestone Revenue Verified by External Audit}}$$

• Numerator: The revenue recognized or milestones marked "complete" by internal team leads during the quarter.
• Denominator: The revenue or milestones validated as 100% complete by an independent external auditor or a cross-functional internal QA team at quarter-end, applying strict binary criteria.
• Target: 1.0. Any deviation below 0.95 indicates that your team is aggregating "fractional limbs" and recognizing progress prematurely, exposing the company to regulatory and financial risk.

---

Board-Level Question

Context for the Founder

As a founder, you must defend the integrity of your platform and your cap table against the pressure to inflate short-term metrics. When your VCs push you to show "progress" to secure the next round of funding, they may encourage you to play in the grey zones—recognizing revenue early, counting soft commits as closed sales, or ignoring IP leakage through your channel partners.

You must walk into your next board meeting and ask a question that signals you are an ethical, long-term builder who understands the structural mechanics of risk.

The Strategic Question to Ask Your Board

"Are we pricing and vesting on the basis of retroactive progression or point-forward certainty, and do our current channel partner contracts protect our platform from attribution leakage when our technology is wrapped by third-party APIs?"

Deep Dive into the Board Discussion

If you ask this question, here is how you lead the conversation based on Chullin 70:

1. Address the Vesting and Pricing Mechanics (Rabba vs. Rav Huna)

Explain to your board that retroactive contract triggers (Rav Huna’s model Chullin 70a:1) create misaligned incentives. If we offer key hires retroactive vesting upon a liquidity event, we encourage short-sighted decision-making designed to force a transaction, rather than building long-term value.

Insist that all cap table allocations and pricing structures operate on a point-forward basis (mikan u'lehabah). This protects the cap table from predatory retroactive claims by departed founders or early advisors.

2. Address the Attribution Leakage (The "Two Womb" and "Weasel" Dilemmas)

Show your board the risk of our API-first distribution strategy. If our product is swallowed by a partner's platform (the "weasel" Chullin 70a:18) and delivered to the end-user without our direct tracking and branding, we are losing our moat. We are becoming a low-margin utility.

We must audit our partner agreements to ensure that even when our software is "wrapped in palm bast" Chullin 70a:15, our system remains the sole "consecrating" entity—meaning, we own the data, the transaction ledger, and the primary brand equity.

3. Address Milestone Integrity (The Limb Fallacy)

Make it clear to the board that we do not aggregate partial completions Chullin 70a:11. If a joint venture or a key customer deployment is "almost done," we treat it as not done. This protects the company from premature revenue recognition scandals that could destroy our valuation during a future due diligence process.

---

Takeaway

In the relentless pursuit of scale, it is tempting to view boundaries as fluid, milestones as negotiable, and retroactivity as a harmless financial lubricant.

The ancient wisdom of Chullin 70a warns us that this is a dangerous illusion. Whether you are dealing with the birth of a firstborn animal or the delivery of an enterprise software platform, the rules of integrity are identical:

1. Transitions must be binary. You cannot claim a milestone is met by aggregating the "majority of a limb" while the rest remains hidden.
2. Valuations must look forward. Retroactivity introduces loopholes and moral hazards; build your contracts on point-forward certainty.
3. Boundaries must be absolute. Do not allow channel partners, wrappers, or intermediaries to obscure your platform’s direct relationship with the value it creates.

Do not build your startup on the shifting sands of the "almost." Define your boundaries with the precision of a Talmudic sage, and build an enterprise that stands on the rock-solid foundation of truth and operational integrity.