How your job is split across Macs

The short version

You choose the task and permitted data; Lithi spreads eligible work across different owners. For a run with multiple atomic groups under spread placement, the Kit encrypts the pieces in your controlled environment. Lithi assigns them across independently owned Macs. An atomic group is information that must stay together for the task. Each assigned Mac can decrypt only the piece it has been granted.

A fixed owner cap limits the cumulative atomic-group exposure in that run for any one provider across all of the Macs, retries, checking, and combining steps they control. Providers cannot choose which pieces they receive. You do not choose the shards, provider Macs, cells, or physical piece size.

If your whole job is one indivisible atomic group, one Mac must read it. Splitting limits how much one provider can see; it does not anonymize the piece or turn an ordinary Mac into confidential computing.

How splitting works

Your controlled environment
prepares and seals permitted input
                 ↓
Lithi assigns bounded pieces
under the spread policy
                 ↓
Different owners process
only their granted pieces

Each assigned Mac reads only the piece it is granted.

Who does what

The kit and the service have separate responsibilities. Local sealing does not choose the execution plan, and an approval does not expose more than the selected profile allows.

Responsibility	Owner
Define the task, semantic groups, expected output and result checks	Your agent, using your approved context
Select permitted input and field policy	You or your integration
Prepare, measure, and seal supported input	Local kit helpers such as `prepareRecords`, `preparedBinding`, and `sealBlocks`
Protect alias keys and reverse maps	Your environment
Plan execution and enforce placement and owner-exposure policy	Lithi
Release scoped input keys under the selected custody model	The authorized release path
Read the granted piece while processing it	The assigned Mac
Retrieve, decrypt, and review results	Your authorized integration

The planner receives a content-free manifest for the sealed blocks. It does not need their readable contents to plan placement. The exact key-custody and envelope details follow the selected profile contract; this page does not prescribe a wire shape. Transfer permission and execution approval remain separate from local sealing.

Your environment performs the final join of accepted pieces. If the plan uses a network reducer, that reducer receives only its declared scoped inputs; every readable group counts toward its owner's exposure, and the reducer is not a path to the whole request.

The cap applies to the owner, not just one Mac. If one provider controls several Macs, enrollments, key rotations, retries, or checking attempts, all of that access counts together.

One atomic group and a multi-group job are different

A job containing one indivisible atomic group is necessarily read by one Mac; the result discloses that boundary. A job with two or more atomic groups follows the signed spread policy even if all its data would fit on one Mac. Fitting in memory does not waive the owner cap or independent-owner requirements.

If the required spread is infeasible, admission offers the options permitted by the selected policy, such as local processing or a different data profile. It does not silently widen access. Any permitted customer-set single-owner exception must be explicit and disclosed.

What limits one owner

Rule	What it means
No full job on a multi-piece run	When a run has two or more atomic groups, one owner cannot reach them all under the spread policy. All Macs, enrollments, and key rotations they control count as the same owner.
Fixed owner cap	Each run sets the maximum share one owner may reach. Pieces are sized to fit that cap; the cap is not increased to accommodate an oversized piece.
Enough independent owners	Lithi works out the minimum number of distinct owners from everyone who may read a piece through production, checking, retries, or combining. Counting Macs alone does not establish independent verification.
Independent checking	A piece is checked or combined by a different owner from the one that produced it.
Providers do not choose pieces	Placement follows an unpredictable, auditable assignment rule. A provider cannot request or predict a particular piece.

Example: 40 records, 8 pieces

Suppose a 40-record batch becomes 8 sealed blocks and the run has a 25% owner cap. This cap is illustrative of the calculation, not a universal default. For this example, each record is one atomic group and each block contains five atomic groups.

The cap is measured in atomic groups: floor(40 × 25%) = 10 groups. Because every block has the same five-group count, that equals at most 2 of the 8 blocks for one owner, including access through retries, checking, and combining. When blocks have different group counts, block count alone is not the cap calculation.

Checking mode	Minimum distinct owners
No checking	4
Check a 10% sample	5
Full verification	8

With full verification, every block is read twice: once to produce the result and once to check it. The checker belongs to a different owner.

A 1-record job can remain one piece. One Mac reads that piece, and the result states that.

Once access is granted, it still counts

Once an owner receives a grant that can expose part of a run, that access counts toward the owner's limit for the rest of the run. It still counts if the attempt loses, fails, or times out.

Lithi adds together every atomic group that owner can reach through production, verification, combining, retries, or hedging, across every Mac, enrollment, and key rotation they control.

Changing devices, rotating keys, or re-enrolling does not reset that exposure.

The allowance is cumulative for this run. A new attempt, verification read, reducer input, hedge, device, or key does not create a fresh exposure allowance. This cap alone does not limit exposure across runs; the selected profile and any separate collection budget still define what later runs may reach.

Repeated access to the same atomic group appears once in the union. A failed attempt does not erase the disclosure.

Who can release a decryption key?

By default, a run-scoped release authority holds a key that can technically unwrap the keys for individual blocks.

It re-wraps a block key only for the leased Mac assigned to that shard, and only after the lease, fence, purpose, and owner-exposure reservation checks pass. Every release is recorded, and the release authority does not use that key to read content.

Because the release authority technically holds the ability to unwrap block keys, this default profile does not support a claim that Lithi is unable to decrypt an input.

shared_customer_approved and restricted profiles can instead keep key release on your own machine, with the kit online for the run. Managed release is the default; both custody modes release keys automatically under the approved job or automation policy. A human is not asked to approve each grant, retry, redrive, or repair. A genuinely new destination, purpose, or wider scope still needs its own authority.

If you set a single-owner exception, the result discloses it. That exception does not increase the fixed owner cap for a multi-piece job.

What splitting protects — and what it does not

	Meaning
It does	Limit how much of a multi-piece job any single owner can reach.
It does not	Anonymize the content inside a piece or turn the Mac processing it into a confidential-computing environment.

A sufficiently privileged or compromised host operator may still be able to inspect ordinary memory while that Mac processes its assigned piece. Match your input's sensitivity to that boundary before you approve a job.

An XPC helper can narrow process communication and capability, but it does not make the Mac's ordinary plaintext memory confidential from its root owner. Treat the assigned Mac as able to read the plaintext required for its piece, regardless of the process boundary.

Read what leaves your machine to see how preparation reduces what a piece can contain, and encryption evidence for the full transfer-to-delivery picture.

For the helper-by-helper reading order, see Use the Kit with your agent and the Kit helper reference.