Arukh HaShulchan, Orach Chaim 310:13-311:2

Hook

You are running out of runway. The market has shifted, your primary product is flatlining, and your Series B lead investor just backed out. In the corner of your balance sheet sits a highly restricted asset: a massive, proprietary dataset of user-permissioned medical records. You promised your users, your compliance team, and your regulators that this data would only be used for diagnostic training. But a pharmaceutical giant just offered you a $2.5 million licensing fee to use that same data for targeted marketing.

Alternatively, you have a failed product line—a "dead" project that cost you $4 million to build. It is sitting on your public GitHub, rotting, showing the world your technical missteps, and actively damaging your reputation as you try to recruit top-tier talent.

Do you repurpose the restricted data "just this once" to save the company? Do you leave the dead project to rot in the sun, hoping no one notices, or do you quietly manipulate your metrics to bury it?

This is the founder’s crucible. In the blinding heat of survival, the boundaries of what is "untouchable" begin to blur. Today is Rosh Chodesh Tamuz—the start of the summer season, historically associated with intense heat, the vulnerability of the eyes, and the catastrophic breakdown of boundaries (the shattering of the Tablets and the breach of Jerusalem's walls). In the startup ecosystem, "heat" translates to runway pressure, and "blinding" translates to the rationalizations we make when we look at restricted assets with desperation.

To navigate this, we turn to the laws of Muktzeh (objects set aside and forbidden to be moved on Shabbat) and the handling of a deceased body (Met) in the Talmudic tradition, codified by Rabbi Yechiel Michel Epstein in the Arukh HaShulchan. The text details how we treat assets that are strictly set aside due to financial risk (Muktzeh Machmat Chisaron Kis) and how we manage "dead" entities under extreme crisis.

This is not abstract theology. This is a masterclass in operational boundaries, ethical workarounds, and the high-ROI discipline of keeping your hands off what does not belong to you, even when the house is on fire.

---

Text Snapshot

ערוך השולחן, אורח חיים ש"י:י"ג "כל דבר שקפיד עליו שלא להשתמש בו תשמיש אחר אלא המיוחד לו, מפני שעל ידי תשמיש אחר יפחת דמיו... הוי מוקצה מחמת חסרון כיס..."

ערוך השולחן, אורח חיים שי"א:א'-ב' "מת המוטל בחמה... מניח עליו ככר או תינוק ומטלטלו... ואם אין לו ככר או תינוק... מטלטלו מן הצד... מפני כבוד הבריות שלא יתבזה המת..."

Translation

Arukh HaShulchan, Orach Chaim 310:13 "Any item that one is particular about, not to use it for any other purpose except its designated one, because by using it for another purpose its value will decrease... is Muktzeh due to monetary loss..."

Arukh HaShulchan, Orach Chaim 311:1-2 "A corpse lying in the sun... one places a loaf of bread or a child upon it and moves it... and if he does not have a loaf or a child... he moves it indirectly (tiltul min hazad)... out of respect for human dignity, so that the deceased does not become disgraced..."

---

Analysis

Insight 1: The Integrity of "Muktzeh" Assets (Fairness & Operational Boundaries)

In Arukh HaShulchan, Orach Chaim 310:13, Rabbi Epstein defines a category of property known as Muktzeh Machmat Chisaron Kis—items set aside strictly because of potential monetary loss. The mechanical definition is precise: "Any item that one is particular about, not to use it for any other purpose except its designated one, because by using it for another purpose its value will decrease."

┌────────────────────────────────────────────────────────┐
│               THE BOUNDARY OF RESTRICTED ASSETS        │
├────────────────────────────────────────────────────────┤
│  [High-Value / Single-Use Asset]                       │
│  e.g., Secure User Data, Escrowed Cash, Regulatory IP  │
├───────────────────────────┬────────────────────────────┤
│  Operational Temptation   │  Halakhic Ruling           │
│  "Repurpose to survive"   │  "Muktzeh" (Do Not Touch)   │
└───────────────────────────┴────────────────────────────┘

In the ancient economy, this referred to a professional scribe’s quill, a surgeon’s scalpel, or a merchant’s pristine stock. These items were never repurposed for mundane tasks. You did not use a scribe's knife to slice bread, because doing so would dull the blade and ruin its primary financial utility. Because of this absolute psychological and operational separation, the Sages ruled that these items are Muktzeh—they cannot be moved or touched on the Sabbath, even if you need their physical space.

Translate this directly to your startup's balance sheet and operational architecture. Your company possesses "Muktzeh" assets. These are not merely expensive assets; they are assets whose value, integrity, and legal standing depend entirely on their exclusivity of purpose.

Examples include:

1. User Data and Privacy Permissions: Customer data collected under a strict, limited-use privacy policy.
2. Earmarked Capital: Grant money, R&D tax credits, or customer deposits held in escrow that are legally restricted to specific operations.
3. Core Intellectual Property: Cryptographic keys, proprietary algorithms, or security environments that must remain isolated to preserve their integrity.

When runway gets short, the founder's temptation is to break these boundaries. You look at your earmarked R&D grant and think, "We will just use this to cover general payroll this month, and we'll replenish it when our sales cycle closes." You look at your restricted user data and think, "We'll run a quick, lookalike audience campaign for a partner company; no one will ever know, and it secures us a $50k pilot."

The Arukh HaShulchan provides a clear decision rule: The moment you repurpose an asset whose value is predicated on its restricted nature, you permanently degrade its systemic value.

If you use a scribe's knife to cut bread, it is no longer fit to write a Torah scroll. If you use restricted user data for an unauthorized commercial pivot, you do not just risk a regulatory fine; you destroy the trust-premium of your brand. Once an asset is designated as "restricted," it must remain operationally untouchable, regardless of the immediate utility of touching it. True operational excellence means building a firewall around your high-risk, single-use assets so they are never swept into the chaotic flow of day-to-day survival.

Insight 2: Ethical Decommissioning of "Dead" Assets (Truth & Reputation Management)

In Arukh HaShulchan, Orach Chaim 311:1, we encounter a highly sensitive crisis scenario: "A corpse lying in the sun." On the Sabbath, a deceased human body is Muktzeh—it cannot be moved. However, leaving a body in the heat of the sun leads to rapid decomposition, which severely compromises Kevod HaMet (the dignity of the deceased) and Kevod HaBriot (human dignity in general). The text observes that leaving the body to rot in public is an intolerable disgrace: "so that the deceased does not become disgraced."

In business, we constantly generate "corpses." These are failed product lines, abandoned pivots, deprecated software architectures, laid-off departments, or terminated joint ventures.

┌────────────────────────────────────────────────────────┐
│             DEALING WITH THE "DEAD" ASSET              │
├────────────────────────────────────────────────────────┤
│  [The "Corpse" in the Sun]                             │
│  Failed product, deprecated code, terminated partnership│
├───────────────────────────┬────────────────────────────┤
│  The Danger of Neglect    │  The Halakhic Imperial     │
│  Reputational rot,        │  "Do not leave it to rot"  │
│  security vulnerabilities  │  Decommission with dignity │
└───────────────────────────┴────────────────────────────┘

Many founders handle these failures with one of two toxic extremes:

1. Denial and Abandonment (Leaving it in the sun): They abandon the code, ignore the legacy servers, or leave the deprecated product online without support. This creates catastrophic security vulnerabilities, customer frustration, and brand rot.
2. Revisionist History (Burying it dishonestly): They manipulate historical performance metrics to hide the failure from board members and future investors, treating the dead project as if it never existed or pretending it was a planned success.

The Halakha does not allow us to leave a corpse to rot in the sun, nor does it allow us to violate the laws of Shabbat directly to move it. Instead, it demands that we address the reality of the situation with high-level problem-solving.

When a project dies, you cannot simply walk away and leave the mess for your customers or the community to stumble over. Leaving an unmaintained, open-source repository or an unsupported API active without a clear deprecation notice is the modern equivalent of leaving a corpse to rot in the sun. It degrades your engineering reputation, frustrates developers who rely on your ecosystem, and creates a security liability.

You must decommission your failures with the same operational rigor and dignity with which you launched them. This means:

• Writing clean, honest post-mortems for your team and investors.
• Gracefully sunsetting products with clear timelines, data-export tools, and migration paths for legacy users.
• Properly offboarding laid-off employees, ensuring their dignity is preserved through fair severance and job-placement support, rather than cutting off their Slack access instantly like thieves in the night.

Honoring your failures is not just a moral duty; it is a high-yield reputation play. The tech ecosystem has a long memory. How you wind down a failed product or handle a layoff defines your brand far more than your hyper-growth announcements.

Insight 3: The "Shim" and Indirect Movement (Competition & Ethical Workarounds)

What do you do when you are caught between two absolute constraints? On one hand, you have the prohibition of moving Muktzeh (the dead body). On the other hand, you have the absolute moral imperative of preserving human dignity (Kevod HaBriot).

The Sages of the Talmud, codified in Arukh HaShulchan, Orach Chaim 311:1-2, developed a brilliant legal workaround: "one places a loaf of bread or a child upon it and moves it." By placing a non-Muktzeh item (like bread or a child, which may be moved on Shabbat) on top of the corpse, the corpse becomes secondary (tafel) to the permitted item. You are technically moving the bread or the child, and the corpse is moved along with them. If no bread or child is available, the Halakha allows "indirect movement" (tiltul min hazad): moving the body by pushing it with an object that is not your hand (e.g., using a broom or a board).

┌────────────────────────────────────────────────────────┐
│             THE STRUCTURE OF AN ETHICAL "SHIM"         │
├────────────────────────────────────────────────────────┤
│  [The Challenge]                                       │
│  Solve a high-stakes crisis without crossing           │
│  regulatory or ethical red lines.                      │
├────────────────────────────────────────────────────────┤
│  [The Solution: "Kikar o Tinok" (Bread or Child)]       │
│  Use a legal, structured, transparent intermediary      │
│  mechanism to achieve the goal safely.                 │
└────────────────────────────────────────────────────────┘

This is the origin of the "ethical shim." In engineering and business, a "shim" is a small library or process that transparently intercepts API calls or operations to resolve compatibility issues. In business ethics, an ethical shim is a structured, legal, and transparent workaround that allows you to solve a high-stakes crisis without crossing your core regulatory or moral red lines.

Let’s look at a concrete example. You are a fintech startup. You need to verify user identities (KYC) to prevent fraud, but your automated verification engine just went down. If you stop onboarding, your daily active user metric crashes, and your bridge round collapses. If you onboard users without verification, you violate federal anti-money laundering (AML) laws.

An unethical founder simply bypasses the KYC check, falsifies the compliance logs, and tells themselves they will backfill the verifications once the system is back online. This is a direct violation of the law—the equivalent of directly carrying a corpse on Shabbat.

An ethical founder uses the "Kikar o Tinok" (the bread or child) protocol. They implement a structured workaround:

1. They route all sign-ups to a manual pending queue.
2. They hire a temporary agency to manually verify identities via a secure, third-party portal.
3. They transparently inform users of a "security-first manual onboarding delay."

This manual queue is slower and costs more, but it is a legal and compliant intermediary mechanism. You are still moving the onboarding process forward, but you are doing so through a permitted, compliant path.

The distinction between a corrupt hack and an ethical shim lies in transparency, legality, and systemic integrity. A corrupt hack relies on deception, hides the reality from stakeholders, and leaves the system vulnerable. An ethical shim is structured, respects the spirit of the law, and uses legitimate, alternative pathways to achieve the mission-critical objective without compromising your integrity.

---

Policy Move

The Restricted Resource & Deprecated Initiative Protocol (RRDIP)

To implement these insights, your company must adopt a formalized Restricted Resource & Deprecated Initiative Protocol (RRDIP). This policy codifies the boundaries of your "Muktzeh" assets and outlines the exact procedures for decommissioning "dead" projects.

┌─────────────────────────────────────────────────────────────────┐
│              RRDIP: TWO-WAY OPERATIONAL PROTOCOL                │
├────────────────────────────────┬────────────────────────────────┤
│  1. THE "MUKTZEH" SHIELD       │  2. THE GRAVEYARD PROTOCOL     │
│  • Tag all restricted assets.  │  • Audit dead projects.        │
│  • Multi-sig authorization.    │  • Secure sunset timelines.    │
│  • Zero-repurposing policy.    │  • Human-dignity offboarding.  │
└────────────────────────────────┴────────────────────────────────┘

Section 1: The "Muktzeh" Asset Shield (Asset Protection)

1. Asset Classification & Tagging: Every data asset, capital reserve, and software key must be audited and classified. Any asset that carries strict regulatory, privacy, or contractual constraints must be tagged as a Level-3 Restricted Asset (L3-RA).
2. Multi-Signature Access Controls: L3-RAs must be architecturally isolated. Accessing or moving these assets for any purpose other than their primary, designated function requires multi-signature authorization from the CEO, CTO, and an external compliance officer or legal counsel.
3. The Zero-Repurposing Mandate: Under no circumstances may L3-RAs be leveraged, licensed, or repurposed to meet short-term cash flow needs, valuation targets, or operational emergencies, unless explicit, informed consent is re-obtained from the original asset owners (e.g., your users or partners).

Section 2: The Graveyard Protocol (Decommissioning Failures)

1. Quarterly Rot Audits: The engineering and product teams will conduct a quarterly audit of all deprecated, inactive, or failing projects (codebases, APIs, legacy servers, and product features).
2. Sunset Timelines and Notices: Any project slated for deprecation must be decommissioned according to a public sunset timeline. Users must receive at least 60 days' notice, complete with data-export tools and clear migration paths.
3. The Dignity Offboarding Standard: If a department or product line is shut down, leading to layoffs, the company will apply the "Kevod HaBriot" standard:
   • No Instant Lockouts: Unless there is a documented, high-risk security threat, departing employees will not be immediately locked out of all communication channels. They will be given a structured, respectful exit window to say goodbye to colleagues and hand over their work.
   • Transition Support: The company will provide professional transition services, resume workshops, and active introductions to peer startups in our VC portfolio.

Metric Proxy: The Legacy Decay Index (LDI)

To track the health and security of your company's legacy footprint, monitor the Legacy Decay Index (LDI):

$$\text{LDI} = \frac{\text{Unmaintained Active Assets} + \text{Unresolved Legacy API Endpoints}}{\text{Total Active Supported Assets}}$$

• Target KPI: Maintain an LDI of < 0.05. Any score higher than 0.05 indicates that your company is leaving too many "corpses in the sun," creating massive reputational, operational, and security risks.

---

Board-Level Question

"What are our 'dead' assets, how are we paying to maintain them, and are we using any 'restricted' assets to artificially prop up our operational metrics?"

┌────────────────────────────────────────────────────────┐
│            BOARD-LEVEL AUDIT CHECKLIST                 │
├────────────────────────────────────────────────────────┤
│  [ ] Identify all Level-3 Restricted Assets (L3-RAs).  │
│  [ ] Review data access logs for boundary violations.  │
│  [ ] Map all legacy, deprecated, or "dead" projects.   │
│  [ ] Evaluate offboarding dignity standards.           │
└────────────────────────────────────────────────────────┘

As a board member or founder, this question cut through the noise of high-level financial reporting to expose hidden operational liabilities. It forces the executive team to confront two critical truths:

1. The Risk of Asset Contamination: It ensures the startup is not quietly violating its privacy policies or regulatory constraints to boost short-term numbers. If the company is leveraging restricted data to train models for unauthorized use cases, or using earmarked capital to cover operational burn, the board must intervene immediately before a regulatory audit destroys the company's valuation.
2. The Cost of Unburied Failures: It forces the leadership team to account for the drag of failed initiatives. Unfinished, abandoned projects drain engineering hours, create security vulnerabilities, and clutter your product roadmap. A healthy company does not hide its failures; it accounts for them, decommissions them cleanly, and reinvests those resources into core growth areas.

By demanding an explicit audit of both Restricted Assets and Deprecated Initiatives, the board establishes a culture of high operational integrity. This protects the company from catastrophic compliance failures and ensures that runway calculations are based on real, uncompromised metrics.

---

Takeaway

In the intense heat of Rosh Chodesh Tamuz, when the pressure to survive makes everything look like a resource waiting to be used, you must remember the wisdom of the Arukh HaShulchan:

1. Respect your boundaries. What is set aside as restricted (Muktzeh Machmat Chisaron Kis) must remain untouched. Do not sacrifice your long-term trust-premium for short-term operational survival.
2. Bury your failures with dignity. Do not leave your failed projects or laid-off teams to rot in the sun. Sunsetting your initiatives with transparency and respect protects your brand and preserves your team's integrity.
3. Use the ethical shim. When a crisis hits, do not resort to deceptive hacks. Build legal, transparent, and structured workarounds (Kikar o Tinok) to navigate regulatory challenges safely.

The ultimate ROI of a startup is built on trust. By maintaining pristine operational boundaries and treating your failures with dignity, you build an enterprise designed to survive the heat of the summer and thrive in the seasons to come.