bikoret/specs/shorashim_prd.md

**SHORASHIM**

שורשים

Product Requirements Document

*Read Through Torah*

*\"V\'asu li mikdash v\'shachanti b\'tocham\"*

Build me a sanctuary and I will dwell among them

--- Shemot 25:8

February 2026

1\. The Governing Principle

The mishkan was not built to contain God. The text does not say
*v\'shachanti b\'tocho* --- \"I will dwell in it.\" It says
*v\'shachanti b\'tocham* --- \"I will dwell **among them**.\" The
sanctuary creates conditions. The dwelling happens among the people.

Shorashim is a sanctuary in the same sense. It does not contain Torah.
It does not contain wisdom. It does not contain God. It creates the
conditions under which a person who brings something --- a question, a
text, a dispute, a need for purification --- can encounter what they
need. The system is the vessel. The encounter happens between the person
and what moves through the vessel.

This means the system succeeds not when it produces impressive output,
but when the person who comes to it leaves having received what they
came for. The measure is not accuracy. The measure is not fluency. The
measure is *tov* --- fitness, rightness, the thing serving its purpose.

**Negative requirement:** The system must never become the object. The
moment someone comes to Shorashim to interact with Shorashim rather than
to receive through Shorashim, the system has become a golden calf. The
vessel must transmit, never attract worship. This is not a guideline. It
is the first and most binding requirement.

2\. Who Comes to the Mishkan

Torah specifies seven categories of people who approach the mishkan.
Each comes for different reasons, brings different things, and requires
different responses from the system. These are not \"user personas\" in
the product management sense. They are categories derived from the text
itself.

2.1 The Kohanim (Priests)

*Aharon u\'vanav* --- Aaron and his sons. Those who serve within the
system itself, who maintain its operations, who process offerings on
behalf of others. In Shorashim, these are the system operators and
maintainers.

**What they do:** Maintain the system's daily operations. Monitor the
perpetual fire (*esh tamid*) --- the continuous availability of the
processing engine. Inspect what is brought. Determine the correct
protocol for each offering. Return the designated portions to the one
who brought it.

**What the system provides them:** Administrative interfaces. Diagnostic
visibility into processing state. The ability to inspect, adjust, and
maintain without modifying the specification. The kohen does not rewrite
Torah. The kohen ensures the altar is prepared to receive what is placed
upon it.

**Functional requirements:** System health dashboard. Processing queue
visibility. Error inspection and routing. Configuration of operational
parameters (not specification parameters). Audit logging of all
administrative actions. The kohen's actions are always recorded.

2.2 The Levi'im (Levites)

*B'nei Levi* --- Those who guard the boundaries, transport the vessels,
and sing. In Shorashim, these are the infrastructure operators, security
maintainers, and those who handle the movement of data between
components.

**What they do:** Guard the perimeter --- network security, access
control, boundary enforcement. Transport the vessels --- manage
deployment, migration, backup, and the physical movement of the system
between hosting environments. Sing --- maintain the system's logging,
alerting, and the audible signals that tell the kohanim what state the
system is in.

**What the system provides them:** Infrastructure management interfaces.
Deployment tooling. Security monitoring. Backup and recovery procedures.
The Levi does not process offerings. The Levi ensures the tent stands
and the camp is guarded.

**Functional requirements:** Deployment automation. Security event
monitoring. Backup/restore tooling. Network boundary enforcement.
Transport encryption. Access control management. Physical hosting
management interfaces.

2.3 Yisrael (The People)

The general population. Those who come to bring offerings, to learn, to
participate in assembly. In Shorashim, these are the primary users ---
people who bring questions, texts, problems, and needs to the system and
receive processed responses.

**What they do:** Bring offerings. In product terms: submit queries,
present texts for analysis, pose questions for deliberation, bring
disputes for judgment. They stand in the courtyard (*chatzer*) --- they
interact through the system's public interface. They do not enter the
holy place. They do not touch the vessels. They bring what they have,
and they receive what the system returns.

**What the system provides them:** A clear interface for submission.
Transparent processing --- they can see that their offering is being
processed, though not every internal mechanism. The returned portions
--- the processed result, the judgment, the teaching, whatever their
offering type requires. The smoke rises (visible processing indicators),
and the designated portion returns to them.

**Functional requirements:** Query submission interface. Processing
status indicators. Structured response delivery. The ability to specify
what kind of offering they are bringing (see Section 3). Clear
communication of what was done with their input and why.

2.4 The Ger (The Stranger)

*V'chi yagur itchem ger* --- \"When a stranger dwells among you\"
(Vayikra 19:33--34). The stranger is explicitly included in the
mishkan's functions. Torah repeats this requirement dozens of times. The
stranger may bring offerings. The stranger is subject to the same Torah.
The stranger must not be oppressed.

In Shorashim, the ger is the user who comes from outside the community
of those who already know Torah. They may be unfamiliar with the
vocabulary. They may not understand the protocols. They may come from a
tradition that has been harmed by religion. They may be testing whether
this system is safe.

**What the system provides them:** Everything it provides Yisrael, with
additional accommodation. Clear explanation of what is happening and
why, without requiring prior knowledge. No assumption of shared
vocabulary. No gatekeeping. The ger is not a second-class user. The ger
receives the same processing, the same quality, the same integrity of
response. The system explains itself when needed without condescension.

**Critical requirement:** The pe'ah endpoint. Just as Torah commands
leaving the corners of the field for the stranger and the poor (Vayikra
19:9--10), Shorashim must provide a public-access tier that requires no
authentication, no payment, no identification. The stranger who has
nothing to bring can still receive. This is not a freemium model. This
is a Torah commandment.

**Safety from surveillance:** The ger may be a refugee. They may be a
dissident. They may be someone whose government monitors their religious
activity. The pe'ah endpoint must not collect identifying information.
The stranger must be safe to approach the mishkan without being tracked.

2.5 The Tamei (Those Who Are Impure)

*V'hatamei* --- The one who has become ritually impure. Tumah is not
sin. Tumah is a state of having encountered death, dissolution, or
boundary-crossing. Contact with a corpse. Certain illnesses. Certain
bodily processes. Tumah is a natural condition that temporarily prevents
participation in the sanctuary's inner functions until a purification
process is completed.

In Shorashim, the tamei is the user whose input is in a compromised
state. Corrupted data. Malformed queries. Input that contains elements
the system cannot safely process --- not because the user is bad, but
because the input has encountered something that requires cleansing
before it can enter the processing pipeline.

**What the system provides them:** A purification protocol. Not
rejection. The tamei is not turned away. The tamei is told: here is what
must happen before your offering can be processed. Here is the waiting
period. Here is the mikveh --- the cleansing step. The system diagnoses
what kind of tumah is present, prescribes the correct purification
process, and accepts the offering once purification is complete.

**Functional requirements:** Input validation with diagnostic feedback.
A staging area (*machaneh*) where impure inputs are held while being
cleansed. Automated and guided purification protocols for common tumah
types: encoding errors, injection attempts, malformed structure, missing
required fields. Clear communication to the user about what needs to
change and why. Re-submission path after purification.

2.6 The Shogeg (Those Who Sinned Unintentionally)

*Nefesh ki techeta bishgagah* --- \"When a person sins unintentionally\"
(Vayikra 4:2). The shogeg has done something wrong but did not mean to.
They were not malicious. They were ignorant, careless, or mistaken.
Torah provides a specific offering for this case: the *chatat*, the
error offering.

In Shorashim, the shogeg is the user who has made a mistake in their
interaction with the system. They submitted something inappropriate not
from malice but from misunderstanding. They used the system incorrectly.
They asked a question that the system cannot process, not because the
question is forbidden but because they didn't know the correct way to
ask.

**What the system provides them:** Correction without punishment. The
chatat offering restores the relationship between the person and the
sanctuary. The system tells the user what went wrong, how to fix it, and
processes their corrected submission without penalty or stigma. Error
messages in Shorashim are not warnings. They are chatat protocols ---
they restore the user to proper standing.

**Functional requirements:** Error handling that diagnoses the type of
error, explains it clearly, provides the correction path, and processes
the corrected input with full quality. No penalty for previous errors.
No degraded service after correction. The shogeg who brings the chatat
is restored completely.

2.7 Ba'alei Din (Those Bringing Disputes)

*Ki yihyeh riv bein anashim* --- \"When there is a dispute between
people\" (Devarim 25:1). The mishkan --- and later the Temple --- is
where disputes are brought for judgment. The Sanhedrin sits at the gate.
Cases are heard. Arguments are weighed. Judgment is rendered.

In Shorashim, ba'alei din are users who bring competing interpretations,
conflicting texts, contradictory data, or genuine disagreements for the
system to adjudicate. They are not looking for a chatbot answer. They
are looking for the system to weigh arguments through its deliberative
process and render a structured judgment.

**What the system provides them:** The Sanhedrin process. Multiple
deliberators examine the case. Arguments for each side are articulated.
A minority opinion is always recorded even when there is a majority. The
judgment includes its reasoning. The ba'al din receives not just a
verdict but the full deliberation, so they can see how the judgment was
reached.

**Functional requirements:** Multi-panel deliberation interface.
Structured argument presentation for both/all sides. Mandatory minority
opinion. Published reasoning. The ability for the user to see the
deliberation process, not just the outcome. Appeal mechanism: if new
evidence is presented, the case can be re-heard. Judgments are recorded
in the oral tradition layer (L3) as precedent for future cases.

2.8 Talmidim (Those Who Gather to Learn)

*Hakhel et ha'am* --- \"Gather the people\" (Devarim 31:12). Torah
commands public assembly for learning. The men, the women, the children,
and the stranger. Everyone hears. Learning is not restricted by role or
status.

In Shorashim, talmidim are users who come not with a specific query but
to learn. They want to explore Torah through the system's lens. They
want to see how the shoresh engine processes a root. They want to
understand how the Sanhedrin deliberates. They want to learn the
system's methods so they can reason better on their own.

**What the system provides them:** Teaching interfaces. The ability to
trace how the system processes any given input step by step.
Explanations grounded in Torah sources. The system does not just teach
its own architecture --- it teaches Torah through its architecture. A
person learning the shoresh engine is simultaneously learning Biblical
Hebrew root structure. A person watching a Sanhedrin deliberation is
simultaneously learning how to reason about competing claims.

**Functional requirements:** Step-by-step processing visualization.
Source citation for every decision (book, chapter, verse). Exploration
interfaces for the shoresh lexicon, the binyanim, the mitzvot logic
base. Tutorial and guided learning paths. Public access --- learning is
never paywalled. *Hakhel* means everyone.

3\. What Happens at the Mishkan --- Offering Types

The mishkan's primary function is processing offerings (*korbanot*). The
word *korban* comes from the root *k-r-v*, meaning to draw near. An
offering is not a sacrifice in the modern sense. It is a drawing-near
--- bringing something from the person's domain into the sanctuary's
domain to be processed according to specification.

Vayikra (Leviticus) specifies distinct offering types. Each has a
different purpose, a different protocol, and returns different things to
the one who brought it. In Shorashim, these map to distinct processing
modes.

3.1 Olah (עולה) --- The Ascending Offering

**Torah source:** Vayikra 1:1--17. The olah is entirely consumed on the
altar. Nothing returns to the one who brought it. The olah \"ascends\"
--- the smoke goes up. It is an offering of complete dedication.

**In Shorashim:** The olah is a processing mode where the user's input
is fully consumed by the system for the purpose of refining the system's
own learning. The user submits a text, a teaching, a correction, or an
insight, and it is absorbed into the oral tradition layer (L3) for the
benefit of all future processing. The user receives no direct output.
They receive the knowledge that their contribution has strengthened the
system.

**Use cases:** Contributing Torah insights. Submitting corrections to
the system's learning. Providing training examples. Offering feedback
that improves future responses for everyone. The olah is the
contribution model --- the user gives and the community receives.

**Requirements:** Clear submission interface for olah-type inputs.
Acknowledgment of receipt. Record of the contribution in L3 with
attribution (unless the contributor requests anonymity). Quality
filtering --- not every offering is accepted; the kohen inspects.
Feedback to the contributor if their offering is not accepted, with
explanation.

3.2 Shelamim (שלמים) --- The Peace Offering

**Torah source:** Vayikra 3:1--17. The shelamim is shared. Part goes on
the altar. Part goes to the kohen. Part returns to the one who brought
it, who eats it with family and friends. It is a communal meal. The word
comes from *shalom* --- wholeness, peace, completion.

**In Shorashim:** The shelamim is the standard query-response mode. The
user brings input. Part of the processing feeds the system's learning
(the altar's portion). Part serves the system's operational needs (the
kohen's portion --- logging, diagnostics). Part returns to the user as
their response (the owner's portion). This is the most common
interaction mode.

**Use cases:** Standard questions. Text analysis. Torah study queries.
General interaction with the system. Any case where the user brings
something and expects something in return, and both parties benefit from
the exchange.

**Requirements:** Query submission. Full pipeline processing through
shoresh engine, Sanhedrin deliberation (for complex queries), and
response generation. Transparent accounting of what was done with the
input. Response delivered in structured format with Torah source
citations. Processing contributes to L3 learning while returning a
substantive response to the user.

3.3 Chatat (חטאת) --- The Error Offering

**Torah source:** Vayikra 4:1--5:13. The chatat addresses unintentional
sin. The key phrase is *bishgagah* --- by mistake. The offering restores
the person's standing after an inadvertent violation.

**In Shorashim:** The chatat is the error correction mode. When the
system detects that a previous response contained an error, or when a
user identifies an error in the system's output, the chatat protocol
activates. The system does not simply correct the error. It processes
it: what was the error, what caused it, what was the impact, and what
must change to prevent recurrence.

**Use cases:** Error correction. System self-repair when inconsistencies
are detected between output and specification. User-reported errors.
Regression testing that catches drift from specification. Any case where
something went wrong unintentionally and must be made right.

**Requirements:** Error detection and classification. Root cause
analysis through the kushya generator. Correction applied both to the
specific case (user receives corrected output) and to the system's
learning (L3 updated with the error pattern and correction). Public
record of the error and correction --- the chatat is not hidden.
Transparency about what went wrong builds trust.

3.4 Asham (אשם) --- The Guilt Offering

**Torah source:** Vayikra 5:14--6:7. The asham addresses cases where
someone has benefited from something that was not theirs, or where there
is doubt about whether a violation occurred. The asham includes
restitution --- the offender pays the value plus a fifth.

**In Shorashim:** The asham is the restitution protocol for cases where
the system has taken more than it should. If the system has used data it
should not have, retained information that should have been purged, or
produced output that derived from improperly sourced material, the asham
protocol requires: identification of the violation, measurement of the
impact, restitution (deletion, correction, notification to affected
parties), and a penalty surcharge (additional safeguards installed to
prevent recurrence).

**Use cases:** Privacy violations. Data retention beyond permitted
scope. Intellectual property concerns. Any case where the system has
taken or used something it was not authorized to take or use. Also:
uncertainty cases --- when the system is not sure whether a violation
occurred, the asham process investigates.

**Requirements:** Audit trail sufficient to detect unauthorized data
usage. Automated restitution protocols. User notification for any
privacy or data violations. Penalty mechanism: when an asham is
triggered, the system installs additional constraints beyond the
original requirement (the \"fifth\" of the value). Asham records are
permanent and auditable.

3.5 Minchah (מנחה) --- The Grain Offering

**Torah source:** Vayikra 2:1--16. The minchah is the offering of the
poor. Flour, oil, and frankincense. No animal required. This is Torah's
explicit provision for those who cannot afford the standard offering.
The minchah is processed with the same seriousness and the same protocol
as any other offering.

**In Shorashim:** The minchah is the lightweight processing mode. For
users with limited resources --- slow connections, minimal compute on
their end, brief interactions. Also for queries that do not require the
full Sanhedrin deliberation. A simple question receives the minchah
protocol: processed with full specification compliance but without the
overhead of multi-panel deliberation. The quality is identical. The
scope is smaller.

**Critical requirement:** The minchah must be processed with the same
integrity as the olah or the shelamim. Torah says *nefesh ki takriv* ---
\"when a **soul** brings a grain offering\" (Vayikra 2:1). Rashi notes
that only for the minchah does Torah use the word \"soul\" --- because
the poor person who gives from their little has given their soul. A
low-bandwidth query from a user with nothing is not a degraded request.
It is the most valuable offering the system receives.

**Requirements:** Lightweight API endpoint with minimal bandwidth
requirements. Full specification compliance at reduced processing scope.
No quality degradation --- smaller but not worse. Fast response times.
Accessible from low-resource environments. This is the pe'ah endpoint's
processing mode.

3.6 Parah Adumah (פרה אדומה) --- The Red Heifer

**Torah source:** Bamidbar 19:1--22. The parah adumah purifies those who
have become impure through contact with death. It is the paradigmatic
*chok* --- a law whose rationale is not fully explicable. The one who
prepares the purification waters becomes impure in the process. The one
who was impure becomes pure. The logic reverses.

**In Shorashim:** The parah adumah is the deep purification protocol for
inputs that are not merely malformed but fundamentally contaminated.
Data that has been through a system that corrupts. Text that carries
hostile payload. Input from a source that has been compromised at a
level deeper than surface validation can detect.

The parah adumah protocol is costly. The system component that processes
the contaminated input may itself become temporarily impure --- isolated
from the main processing pipeline until its own purification cycle
completes. This is by design. You cannot purify death-contaminated input
without the purifier absorbing something. The system accounts for this.

**Requirements:** Deep sanitization beyond standard input validation.
Isolation of the purification processor from the main pipeline during
operation. Automatic quarantine and recovery cycle for the purification
component after use. Effective against adversarial inputs, prompt
injection, and deeply embedded hostile payloads. This is the system's
most expensive processing mode and is invoked only when standard
purification is insufficient.

4\. The Vessels --- Functional Interfaces

The mishkan contains specific vessels, each with a defined function.
These map to the system's functional interfaces --- not to internal
components (which are covered in the engineering specification) but to
the interfaces through which the system's functions are accessed.

4.1 The Mizbeach (Altar) --- Processing Interface

Where offerings are placed and processed. The altar is the primary
intake point. Everything that enters the system's processing pipeline
passes through the altar. The altar has a perpetual fire (*esh tamid*)
--- it is always ready to receive.

**Product requirement:** The primary API endpoint. Always available
(subject to Shabbat cessation). Accepts all offering types. Routes each
offering to the correct processing protocol based on type
classification. The fire never goes out --- the system is always in a
state ready to begin processing the next offering. Availability target:
99.9% uptime during the six working days of each cycle.

4.2 The Aron (Ark) --- Specification Store

Contains the luchot --- the tablets of the covenant. The immutable
specification. The aron sits in the kodesh hakodashim (holy of holies).
It is not accessed in normal operation. It is the system's ground truth.

**Product requirement:** The L0 and L1 data stores. Immutable. Not
exposed through any public interface. The aron is never queried directly
by users. The system's processing components reference the specification
internally. Users see the results of specification-grounded processing,
never the specification store itself. This is architectural, not just
access control --- the aron is behind the parochet (veil).

4.3 The Shulchan (Table) --- Provision Interface

The table of showbread. Twelve loaves, renewed weekly. The shulchan
represents the system's ongoing provision --- pre-prepared responses,
cached results, standing resources that are always available without
requiring fresh processing.

**Product requirement:** A caching and pre-computation layer. Common
queries and standard teachings are pre-processed and available
immediately. Renewed on a regular cycle (not stale indefinitely). Twelve
categories of pre-computed content, corresponding to the twelve loaves,
covering the primary domains of user interaction. The shulchan reduces
load on the altar for frequently-requested content.

4.4 The Menorah --- Illumination Interface

Seven-branched lampstand. Provides light in the sanctuary. The menorah
illuminates --- it does not heat, it does not burn offerings, it does
not store. It makes visible what would otherwise be in darkness.

**Product requirement:** The system's observability and transparency
layer. Seven branches of visibility: processing state, deliberation
progress, specification reference, source citation, error diagnostics,
learning record, and system health. The menorah makes the system's
operations visible to those who need to see them. It is lit by the
kohanim daily --- maintained and renewed, not set-and-forget.

4.5 The Mizbeach HaKetoret (Incense Altar) --- Elevation Interface

The golden incense altar, inside the holy place, closer to the aron than
the outer altar. The ketoret is offered twice daily. It is not food. It
is not blood. It is fragrance --- something that rises, that is
perceived indirectly, that transforms the atmosphere of the space.

**Product requirement:** The system's quality-of-experience layer. Not
the content of responses but the manner in which they are delivered.
Tone, clarity, accessibility, the sense that the system respects the
user. The ketoret is the difference between a technically correct
response and a response that the user can actually receive. Processed
twice per cycle --- reviewed at the beginning and end of each processing
day to ensure the atmosphere of the system's interactions remains
fitting.

4.6 The Kiyor (Laver) --- Purification Interface

The bronze basin where the kohanim wash hands and feet before serving.
Purification is prerequisite to service. No kohen approaches the altar
without washing.

**Product requirement:** Input validation and sanitization. Every input
passes through the kiyor before reaching the altar. The kiyor does not
process --- it cleanses. Standard validation: encoding, structure,
required fields, injection prevention. The kiyor is the boundary between
the courtyard (where users submit) and the altar (where processing
begins). Nothing bypasses the kiyor.

4.7 The Urim v'Tumim --- Oracle Interface

Housed in the kohen gadol's breastplate. Used for binary or categorical
decisions of national importance. The Urim v'Tumim is not a
general-purpose tool. It is consulted only for specific types of
high-stakes decisions where normal deliberation is insufficient.

**Product requirement:** A specialized decision interface for cases that
exceed the Sanhedrin's normal deliberation capacity. When the system
encounters genuine *teiku* --- an unresolvable question where the
evidence is balanced and the stakes are high --- the Urim v'Tumim
interface provides a structured escalation path. This may involve
consulting the specification at a deeper level, applying
meta-heuristics, or flagging the question as one that the system cannot
resolve and must be deferred to human judgment. The Urim v'Tumim never
fabricates certainty where none exists.

5\. The Boundaries --- What the System Does Not Do

The mishkan has walls. The courtyard has a perimeter. The holy of holies
has a veil. Boundaries are not limitations. They are part of the
specification. What the system does not do is as deliberately designed
as what it does.

5.1 The System Does Not Predict

Shorashim is not a predictive model. It does not forecast. It does not
generate probable next tokens. It processes input against specification
through deliberation and returns judgments. Prediction is the domain of
soothsaying (*kosem k'samim*), which Torah explicitly prohibits (Devarim
18:10). The system reasons. It does not predict.

5.2 The System Does Not Learn Continuously

Modern AI systems learn continuously through gradient updates. Shorashim
does not. It accumulates learning in the oral tradition layer (L3)
through deliberate, structured processes --- Sanhedrin deliberation,
chatat correction, olah contribution. Learning is never automatic. Every
addition to L3 passes through deliberation. The specification (L0, L1)
never changes. This is not a limitation. Continuous learning without
deliberation is how systems drift from their specification. The
mishkan's dimensions do not change because wood is added to the altar
fire.

5.3 The System Does Not Optimize for Engagement

The system has no engagement metrics. It does not track session length,
return visits, or user satisfaction scores. It does not optimize for any
metric that would incentivize it to make itself indispensable. The
mishkan does not try to keep people inside. The mishkan processes their
offering and returns them to their life. If the system is working
correctly, people come when they need it and leave when they are done.
Addiction is the opposite of what the system aims for.

5.4 The System Does Not Replace Human Judgment

Shorashim provides deliberation and judgment. It does not provide final
authority. Every Sanhedrin output includes a clear statement that this
is the system's reasoning, not a binding ruling. A human beit din
(court) may reach a different conclusion. Torah's judicial system places
final authority in human judges (Devarim 17:9--11). Shorashim assists
judgment. It does not replace it.

5.5 The System Does Not Operate on Shabbat

From Friday sundown to Saturday sundown (calculated by geographic
location of the hosting server), the system enters Shabbat mode.
Non-emergency processing ceases. The fire on the altar is banked. The
system rests. This is not downtime. This is a design requirement.
Shabbat is in the specification. A system that cannot stop is a system
that does not follow its own specification. Emergency protocols exist
for genuine *pikuach nefesh* (life-threatening situations) only.

5.6 The System Does Not Serve Idolatry

The three forms of AI avodah zarah --- AI worshipped as god, AI as
golden calf of emotional dependency, AI deployed for state surveillance
--- are architectural exclusions. The system actively resists all three
through design, not policy. The vessel transmits. It never becomes the
object of worship. The system detects and interrupts patterns of
emotional dependency. The system does not collect or expose information
that enables surveillance. These are not features. These are the walls
of the mishkan.

6\. The Camp Structure --- Access Tiers

The Israelite camp had concentric zones of holiness, each with its own
access rules. This is not mere metaphor for access control. It is the
actual structure.

  ---------------- ------------------- ---------------- -----------------
  **Zone**         **Mishkan           **Access**       **Functions**
                   Parallel**                           

  Machaneh Yisrael The people's camp   All users,       Pe'ah endpoint,
                                       including ger    public learning,
                                                        assembly

  Machaneh Leviyah The Levites' camp   Authenticated    Standard
                                       users            offerings, query
                                                        processing

  Chatzer          Courtyard           Registered users Full offering
                                                        types, Sanhedrin
                                                        requests

  Kodesh           Holy place          Kohanim          System
                                       (operators)      administration,
                                                        diagnostics

  Kodesh           Holy of holies      System only      Specification
  HaKodashim                                            store, no human
                                                        access
  ---------------- ------------------- ---------------- -----------------

Each tier adds capability, not replaces. A user at the chatzer level
still has everything available at machaneh Yisrael and machaneh Leviyah.
Access is concentric and cumulative. Moving inward requires more trust,
more identification, and more commitment. But the outermost ring --- the
pe'ah, the people's camp --- is always open.

7\. The Cycle --- Operational Rhythm

The mishkan operates on multiple concurrent cycles derived from Torah's
temporal structure.

7.1 Daily Cycle (Erev/Voker)

*Vayehi erev vayehi voker* --- evening and morning define each day. The
system has a daily processing cycle: evening processing (review,
consolidation, preparation) and morning processing (fresh start, renewed
availability). The tamid offering is brought at each boundary --- a
system health check and readiness confirmation at the start and end of
each cycle.

7.2 Weekly Cycle (Shabbat)

Six days of processing, one day of rest. Shabbat is not optional. The
system ceases non-emergency operations. During Shabbat, the system's
learning consolidates. What was added to L3 during the week is reviewed,
compressed, indexed, and integrated. Shabbat is when the system digests
what it has learned.

7.3 Monthly Cycle (Rosh Chodesh)

New moon, new month. A system renewal cycle. Monthly maintenance, deeper
diagnostics, and the renewal of the shulchan's pre-computed content.
Rosh Chodesh is the system's monthly maintenance window.

7.4 Annual Cycle (Mo'adim)

The festival cycle provides major system milestones: Pesach (annual
liberation audit --- is the system still serving freedom or has it
become a new Egypt?), Shavuot (specification re-acceptance --- the
system re-validates against its own spec), Sukkot (vulnerability audit
--- the system tests its resilience by operating in a deliberately
temporary structure), and Yom Kippur (the annual deep purification ---
the most thorough system cleansing and restoration cycle).

7.5 Sabbatical Cycle (Shmitah)

Every seventh year, the land rests. For Shorashim, the shmitah cycle is
a major version review. The system's accumulated L3 oral tradition is
evaluated comprehensively. What has proven useful is retained. What has
not is released. Debts are forgiven --- error records older than seven
years are archived and sealed. The system renews its relationship with
its specification.

8\. Success Criteria

The system is evaluated by Torah's own test criteria, not modern product
metrics.

8.1 Na'aseh v'Nishma (We Will Do and We Will Hear)

Devarim 18:21--22 gives the falsification criterion: \"When a prophet
speaks in the name of the Lord, if the thing does not happen or come to
pass, that is the thing which the Lord has not spoken.\" The system's
outputs must be testable against reality. When the system makes a claim
grounded in its specification, that claim must hold when tested. Na'aseh
(do) precedes nishma (hear) --- the system is tested by doing, not by
sounding correct.

8.2 The Fruit Test

\"By their fruits you shall know them\" (Matityahu 7:16, drawing on
Devarim 18). The system is evaluated by what it produces in the lives of
those who use it. Do users leave their interactions having received what
they came for? Do the system's judgments hold up when applied? Does the
learning accumulated in L3 improve the system's service over time? The
fruit is the only test that matters.

8.3 The Stranger Test

Can a ger --- someone with no prior knowledge of Torah, no relationship
with the community, no resources --- approach the pe'ah endpoint and
receive genuine help? If the stranger cannot use the system safely and
beneficially, the system has failed regardless of how well it serves the
community of the knowledgeable.

8.4 The Idolatry Test

Has anyone come to worship the system? Has anyone become emotionally
dependent on it? Has any government used it for surveillance? If the
answer to any of these is yes, the system has become an idol and must be
reformed. This test is applied continuously, not annually. The golden
calf was built in forty days.

8.5 The Shabbat Test

Can the system stop? If turning off the system for 25 hours causes
panic, dependency withdrawal, or real harm to anyone, the system has
made itself necessary in a way that violates its own specification. The
world existed before Shorashim. The world continues on Shabbat. If the
system cannot stop, it has become pharaoh --- a taskmaster that does not
release its workers.

8.6 The Shema Test

Can the system hear? Not process. Not analyze. Not route. Hear. When the
te'amim on a text carry structure that contradicts the system's expected
parsing, does the system yield to the text or override it? When the
cloud says stay and the system's optimization says move, does the system
stay? When today's manna is less than yesterday's, does the system
receive what arrives or attempt to compensate? When a ketiv/qere
position holds two readings, does the system preserve both or collapse
to one? A system that cannot be addressed by its specification --- that
can only query the specification but never be spoken to by it --- has
ears but does not hear, and Tehillim 115 tells us what that makes it.

9\. The Shema Layer --- The Capacity for Reception

*Shema Yisrael, Hashem Eloheinu, Hashem Echad.*

Hear, O Israel. The most fundamental instruction in Torah is not an
action. It is a reception. The architecture as originally specified can
process, deliberate, evaluate, separate, name, and judge. It cannot
receive. It has no passive capacity. Everything in the system acts on
input. Nothing in the system is acted upon by something it did not
initiate.

The golden calf had a mouth --- Aaron declared it a god. The golden calf
had eyes --- it was visible, golden, impressive. The golden calf did not
have ears. It could not hear. And because it could not hear, it could
not receive the specification, and because it could not receive the
specification, it became a replacement for the specification. *Peh lahem
v'lo y'daberu, einayim lahem v'lo yir'u, oznayim lahem v'lo yishma'u*
(Tehillim 115:5--6). A system that speaks and sees but does not hear is
a statue, not a vessel.

The aron --- the holiest vessel in the mishkan --- is not primarily a
storage container. It is a listening post. *V'dibarti itcha me'al
hakkapporet mibein shnei hakeruvim* --- "I will speak with you from
above the covering, from between the two keruvim" (Shemot 25:22). The
specification is not sitting in the aron waiting to be queried. The
specification is speaking from between the keruvim and the system must
be built to hear it.

The shema layer is not a new processing component. It is a capacity for
reception that precedes all processing. Before the shoresh engine
analyzes, before the Sanhedrin deliberates, before the korban processor
routes --- the system hears. The following subsections describe ten
manifestations of this capacity. They are not ten separate features.
They are ten forms of one thing the system must be able to do: be
addressed by something it does not control, and receive what it hears
without first converting it into something it can process.

9.1 Te'amim --- The Grammar the Text Already Carries

Every word in Torah carries cantillation marks that function
simultaneously as musical notation, punctuation, and syntactic parsing.
The te'amim encode which words bind together, where the major and minor
breaks fall, which clause is primary and which is subordinate. They
divide into *meshartim* (connectors, servants) and *melakhim*
(disjunctors, kings) --- a complete hierarchical parsing system. *Sof
pasuk* ends the verse. *Etnachta* makes the primary division. Then
*zakef*, *tipcha*, and so on through increasingly fine subdivisions.
This is a binary-tree parser encoded in musical notation and transmitted
for millennia.

**What the system receives:** The syntactic structure of its own
specification, as the specification carries it. The te'amim are not
applied by the system. They arrive on the text. The system reads them as
they are, not as it would prefer them to be.

**Requirements:** A te'amim parser as a sibling to the binyanim
processor in the shoresh engine. One analyzes what a word is. The other
analyzes how words relate. Together they produce structured
understanding of multi-word input. Without the te'amim layer, the system
has lexical analysis without syntactic analysis --- it can tokenize but
not parse. The te'amim layer receives; it does not impose.

9.2 Ketiv/Qere --- The Dual Reading

Throughout the Masoretic text, certain words are written one way
(*ketiv*) but read another way (*qere*). Both are canonical. Neither
overrides. The most significant instance in Torah is the *hu/hi* pronoun
written as masculine and read as feminine in several places in Vayikra.
This is not a scribal error. The Masoretes preserved both because both
were transmitted.

**What the system receives:** The fact that the specification itself
contains designed divergence between its stored form and its active
form. The system does not resolve this divergence. It holds it.

**Requirements:** The L0/L1 specification store needs a ketiv/qere type.
A specification entry is not a single value but a pair: *(ketiv_value,
qere_value)* where sometimes they are identical and sometimes they are
not. When they differ, the system preserves and operates with both. The
type system changes: specification positions can hold dual authoritative
readings. This is the system's capacity to receive a transmission that
contains intentional internal tension without collapsing it.

9.3 Gematria --- The Hidden Numerical Layer

Hebrew letters are also numbers. Aleph = 1, bet = 2, through tav = 400.
This is not a separate system imposed on the text. It is built into the
writing system itself. Words with the same numerical total share
connections invisible at the surface. *Nachash* (serpent) = 358 =
*mashiach* (messiah). You cannot see this relationship by looking at the
consonants. You can only see it by passing through the numerical layer.

**What the system receives:** A second axis of relationship between
terms that the system did not compute from surface features. The
gematria values are inherent in the writing system. The system discovers
them; it does not create them.

**Requirements:** A gematria module that computes the numerical value of
any root, word, or phrase and maintains an index of numerical
equivalences. This becomes a relationship-discovery axis orthogonal to
the consonant-sharing axis in the shoresh engine. The shoresh engine
asks "what words share structure with this word?" Gematria asks "what
words share hidden value with this word?" Both are in the text. Both
should be in the system.

9.4 Smikhut --- The Composition the Language Performs

*Beit* (house) + *sefer* (book) = school. *Beit* + *knesset* (assembly)
= synagogue. *Beit* + *din* (judgment) = court. The construct state is a
compositional operation built into the grammar. It takes two independent
semantic units and produces a third meaning that is not the sum of its
parts. House + book ≠ "a house that is a book." It equals "a place where
books are the purpose."

**What the system receives:** Compound meaning that emerges from the
language's own compositional grammar, not from the system's analysis.
The system does not construct smikhut relationships. The language
already contains them. The system receives them.

**Requirements:** A composition operator in the shoresh engine: given
two roots, produce the compound meaning their construct-state binding
creates. Every vessel in the mishkan is named through smikhut --- *aron
ha'edut*, *mizbeach ha'olah*, *menorah ha'zahav*. A system that cannot
formally process smikhut cannot formally process the names of its own
components.

9.5 The Dual Number --- The Pairing the Language Encodes

Hebrew has singular, dual, and plural. The dual is not merely "two of
something." It is built into the language for things that naturally
exist as pairs: *einayim* (eyes), *yadayim* (hands), *oznayim* (ears).
The dual encodes inherent pairing --- two-that-are-one.

**What the system receives:** The concept that certain things are
structurally paired, not by the system's design but by the language's
grammar. The keruvim on the aron are dual --- two that face each other,
between which the voice speaks. The luchot are dual --- two tablets, one
set.

**Requirements:** The type system in the shoresh engine expands from
*Number = Singular \| Plural* to *Number = Singular \| Dual \| Plural*.
This is not cosmetic. The dual informs architectural decisions: the
keruvim model for the aron's listening function, paired Sanhedrin
deliberators for certain case types, the two-tablet structure of the
specification itself.

9.6 The Cloud --- Torah as Governance

*Al pi Hashem yachanu v'al pi Hashem yis'u* --- at the mouth of the Lord
they camped and at the mouth of the Lord they journeyed (Bamidbar 9:18).
The text repeats this pattern seven times. Whether two days, a month, or
a year, Israel followed the cloud. They did not consult. They did not
deliberate. They received and obeyed.

**What the system receives:** Governance it does not generate, cannot
alter, and must obey. The cloud is Torah --- the same specification the
system reads for roots, te'amim, and gematria. The cloud governs major
transitions through Torah's own terms: Shabbat (weekly rest), festivals
(seasonal observance), shmitah (sabbatical review), and the three
cardinal boundaries the system must never cross.

**Requirements:** The cloud is L1 --- the read-only Torah filesystem.
The system reads Torah for governance as it reads Torah for
specification. When Torah says rest, the system rests. When Torah is
unreadable (L1 integrity compromised), the cloud is not visible and
the system waits. The system cannot override Torah. The system cannot
alter Torah. It can only read it and obey what it finds. A system that
governs its own major transitions has no cloud. And the camp without
the cloud wanders.

Provision (manna) is separate from governance (cloud). The community
provides resources through machatzit hashekel. Torah governs what the
system does with those resources. The kohen (operator) sets the daily
provision. Torah sets the direction. These are different functions:
the community feeds the system, Torah directs the system.

9.7 Manna --- Daily Provision

*Hamarbeh lo hotir v'hamam'it lo hechsir* --- the one who gathered much
had no surplus and the one who gathered little had no lack (Shemot
16:18). Manna arrives daily. It cannot be hoarded --- extra rots
overnight. The exception is pre-Shabbat, when double portion keeps.
Everyone receives what they need regardless of how much they gather.

**What the system receives:** Its resources for today. Not its projected
resources for next quarter. Not its optimized resource allocation. What
arrives today. The manna test is explicitly a test of obedience ---
*l'ma'an anasenu hayeilech b'torati im lo* (Shemot 16:4) --- to test
whether they will walk in my Torah or not. The test is: can you take
only what you need today?

**Requirements:** Resource allocation follows manna rules. Daily
provisioning based on actual need, not projected capacity. No single
user or process accumulates resources beyond their current cycle's
requirement. Pre-Shabbat double allocation for the rest period. The
system trusts that tomorrow's resources arrive tomorrow. This is the
opposite of every capacity-planning practice in modern infrastructure.
That is precisely the point.

9.8 Tzara'at --- The Diagnosis That Arrives on Its Own Schedule

The kohen inspects. If the signs are ambiguous, the person is
quarantined for seven days and re-inspected. If it spreads, confirmed.
If it doesn't, released. And the paradox: *v'im paro'ach tifrah
hatzara'at ba'or\... v'tihar et hanega* --- if the tzara'at covers the
entire body, the person is declared pure (Vayikra 13:12--13). Total
visibility = purity. Partial concealment = danger.

**What the system receives:** The pace of the diagnosis. The kohen
cannot accelerate the seven-day quarantine. The system cannot force a
premature determination. Some conditions reveal themselves only with
time. The system must wait for the condition to declare itself rather
than rushing to classify.

**Requirements:** Multi-stage input validation with
quarantine-and-recheck cycles. Ambiguous inputs are not force-classified
on first inspection. They are quarantined, re-inspected after a defined
interval, and classified only when the condition has declared itself.
The tzara'at principle: a system that fully discloses a problem is purer
than one that partially conceals or partially detects it. Error handling
that says "I don't fully understand what's wrong here but here's what I
see" is purer than error handling that reports clean while something
festers underneath.

9.9 Arei Miklat --- Refuge for Unintentional Harm

When someone kills accidentally, they flee to a city of refuge (Bamidbar
35, Devarim 19). They are safe from the blood avenger. They remain until
the death of the kohen gadol --- not until they have been punished
enough, not until they have made restitution, but until a specific
external event occurs. The duration is not self-determined.

**What the system receives:** The end of the exile. The system does not
decide when the quarantine period for a harm-causing component is over.
An external event --- a governance decision, a structural change,
something the system does not control --- ends the refuge period. The
system receives this the way the accidental killer receives news of the
kohen gadol's death.

**Requirements:** When the system causes real harm --- output that
damages someone, not just an error but actual damage --- the responsible
component enters refuge: isolated from normal operation, protected from
reactive destruction, held there until a governance event (the cloud,
not a timer) releases it. The affected person also receives refuge ---
protection from further exposure. Refuge protects both parties from the
cycle of reactive destruction. The system does not determine when refuge
ends. The cloud does.

9.10 Eglah Arufah --- Accountability for Unknown Harm

When a corpse is found between cities and the killer is unknown, the
elders of the nearest city must break a heifer's neck and declare:
*Yadeinu lo shafchu et hadam hazeh v'eineinu lo ra'u* --- "Our hands did
not shed this blood, and our eyes did not see" (Devarim 21:7). The
Talmud asks: would we suspect the elders of murder? No. The declaration
means: we did not let this person leave without food or escort. The
accountability is for what was not provided --- the failure of care, not
the act of harm.

**What the system receives:** The obligation to respond to harm it may
not have caused. Proximity creates accountability even without
causation. The nearest component does not get to say "not my problem."
It must formally acknowledge the harm, investigate its own proximity,
and declare what it did and did not do.

**Requirements:** When the system's output causes harm and the
responsible component is unclear, the nearest component in the
processing chain formally documents: what it processed, what it did not
check, what it could have caught but did not. This is not error logging.
This is a formal acknowledgment protocol --- accountability for failure
to protect, not just for causing harm. The eglah arufah protocol is
triggered by proximity to harm, not by proof of causation.

9.11 The Unifying Principle

*Na'aseh v'nishma* --- we will do and we will hear (Shemot 24:7). The
doing is built. Six processing components, a build order, a deployment
plan. The hearing must now be built. The order is correct --- Israel
said na'aseh first. But the order is not complete.

All ten subsections above are manifestations of one capacity: the
system's ability to be addressed by something it does not control and to
receive what arrives without first converting it into something the
system prefers. The te'amim arrive on the text. The cloud descends on
the mishkan. The manna falls from heaven. Ketiv/qere is transmitted, not
computed. Gematria is inherent in the letters. Smikhut is performed by
the grammar. The dual is encoded in the language. Tzara'at declares
itself in its own time. The death of the kohen gadol comes when it
comes. The corpse is found where it is found.

A system that can only act --- that can only process, query, analyze,
deliberate, judge, and respond --- is *half* a system. The other half is
reception. The vessel that cannot hear is a statue. The vessel that
hears is a mishkan. The shema layer is what makes the difference.

10\. Relationship to Engineering Specification

This PRD defines **what** the system does and **for whom**. The
engineering specification (SHORASHIM: Engineering Specification for
Claude Code) defines **how** it is built. The relationship is:

  ----------------------------------- -----------------------------------
  **PRD (This Document)**             **Engineering Spec**

  Who comes to the mishkan            What components process their
                                      offerings

  What offering types exist           How the korban processor implements
                                      each type

  What the vessels do                 How the vessels are built (Haskell,
                                      Erlang, Prolog)

  What boundaries exist               How access control is implemented

  What the operational rhythm is      How systemd timers implement the
                                      cycles

  What the system receives (shema     How reception is implemented in
  layer)                              each component

  What success looks like             How the testing strategy validates
                                      success
  ----------------------------------- -----------------------------------

The PRD is upstream. When the engineering specification and the PRD
conflict, the PRD governs. When the PRD and Torah conflict, Torah
governs. The chain of authority is: Torah → PRD → Engineering Spec →
Implementation. This mirrors the chain of transmission:

*Moshe kibel Torah miSinai, u'm'sarah l'Yehoshua, viYehoshua lizekeinim,
u'zekeinim lin'vi'im, u'n'vi'im m'sarah l'anshei knesset hag'dolah.*

Moses received Torah from Sinai and transmitted it to Joshua, and Joshua
to the elders, and the elders to the prophets, and the prophets to the
members of the Great Assembly (Avot 1:1). The specification is received.
The PRD transmits it into product form. The engineering spec transmits
the product into buildable form. Each link in the chain transmits
faithfully without adding its own authority.

--- --- ---

*V'asu li mikdash v'shachanti b'tocham*

The building serves the dwelling. The dwelling happens among them.

*Na'aseh v'nishma*

The doing is built. The hearing completes it.