tuckerl.ee

Building thoughtful software with AI.Notes from the systems behind the work.

White papers

Engineering decisions, examined in depth.

Focused papers on the problems behind the products: the design, the alternatives, and the evidence needed to decide.

01

tuckerl.ee / Technical white paper

Publishing the Version That Was Reviewed

A publication approval can become stale between review and release. Editing an article, replacing an image, or changing a chart may alter what readers receive while leaving the approval attached to the same post. This paper examines the exact-payload release model in tuckerl.ee: a public release manifest identifies the bodies, metadata, and resource digests under review, and publication checks approval against that manifest. It traces a synthetic revision race, separates content safety from editorial accuracy, and compares the model with status flags and revision-only approvals. The evidence is a source inspection of the publishing implementation; no production reliability or privacy effectiveness measurements are reported.

Read paper 7 min
02

EntryPin / Architecture white paper

One Access Decision From Identity, Membership, and Entitlement

Successful authentication does not establish whether a person may perform a particular action for a particular tenant. Licensing introduces another independent condition: a feature may be unavailable even to an otherwise authorized member. This paper proposes a composed decision model for EntryPin that evaluates identity, session validity, tenant membership, resource scope, and entitlement at the action boundary. A synthetic revocation race shows why a valid session and a cached feature flag are insufficient. The analysis compares centralized decisions with embedded claims, identifies availability tradeoffs, and describes tests for cross-tenant access and delayed revocation. It presents a reference design rather than a verified account of the product's current implementation.

Read paper 6 min
03

RED: The Order Engine / Architecture white paper

From Inventory Evidence to an Order You Can Explain

Ordering systems must reconcile records that disagree about identity, quantity, and time. Collapsing those records into a single inventory value hides uncertainty at the moment a buyer commits money. This paper develops an architecture for RED that separates source observations, accepted facts, planning proposals, and supplier outcomes. A worked example follows an ambiguous pack quantity through reconciliation and approval. The analysis explains why immutable planning inputs and durable submission receipts address different failure modes, compares alternatives, and specifies tests for replay, concurrency, and partial fulfillment. It is a proposed operating model informed by existing engineering notes; it reports no production benchmark or regulatory assessment.

Read paper 8 min
04

LunchLineup / Architecture white paper

A Schedule Is a Versioned Commitment

Workforce scheduling joins two different problems: finding a feasible assignment and communicating a dependable commitment. An optimizer can produce a valid draft while the published schedule becomes inconsistent through concurrent edits, unconfirmed swaps, or ambiguous local times. This paper proposes a LunchLineup scheduling model that separates feasibility, preference optimization, publication, and acknowledgment. A synthetic swap illustrates why two individually plausible changes can jointly remove required coverage. The design compares manual editing, full recomputation, and bounded repair, then specifies evaluation cases for constraints and revision handling. It is a reference architecture, with no measured scheduling improvement or assessment of employment-law compliance.

Read paper 6 min
05

StaffingQuest / Architecture white paper

From Workload to Staffing Scenarios Without False Precision

A workload forecast cannot be converted into a staffing decision without assumptions about handling time, productive capacity, skill coverage, and service objectives. This paper proposes an explicit scenario model for StaffingQuest that preserves those assumptions and separates calculated capacity from a feasible roster. A fully synthetic example derives staffing requirements and shows how a handling-time change alters the result. The analysis distinguishes sensitivity ranges from statistical prediction intervals, compares aggregate and interval-based planning, and sets out a validation method. It supplies a reproducible decision framework rather than a validated demand forecast or a recommendation about individual workers.

Read paper 6 min
06

CodeHermit / Architecture white paper

Local AI Coding With Explicit Execution Authority

Running a coding model near a developer's source changes where computation happens, but does not determine which actions the assistant may take. This paper proposes a CodeHermit runtime in which model suggestions, context selection, tool authorization, and workspace mutation have separate contracts. A worked edit scenario shows how a valid proposal becomes stale when its target changes, and how a revision check can prevent an unintended overwrite. The design also addresses remote context disclosure and adapter-aware cache identity. Alternatives and a fault-oriented evaluation plan are presented. This is a reference architecture for the product direction, not a report of verified CodeHermit implementation or measured model performance.

Read paper 7 min
07

Stackedus.IO / Architecture white paper

When a Healthy Signal Becomes Unknown

A status page can continue displaying health after its evidence has stopped arriving. This paper proposes a Stackedus.IO status model that separates observations, freshness, assessed service impact, and public incident communication. A synthetic probe failure demonstrates why missing evidence must not be interpreted as continued success. The design defines distinct handling for recovery, delayed observations, and publication, compares simple thresholding with a stateful evaluator, and outlines tests for monitoring and notification failures. It is a reference architecture for status communication; it reports no observed availability, incident-response improvement, or verified deployment behavior.

Read paper 6 min
08

theFeed / Architecture white paper

A Chronological Feed That Preserves Reading State

A chronological reader needs a stable account of article identity even when publishers revise content, change timestamps, or temporarily stop serving feeds. This paper proposes an ingestion and reading-state model for theFeed that separates source entries, content revisions, ordering keys, and user actions. A synthetic article update shows how deduplicating by title or sorting by fetch time can reset read state and distort chronology. The design draws on Atom identity semantics and HTTP cache behavior, compares storage alternatives, and defines a test corpus for repeated and malformed input. It is a reference architecture rather than a verified description of the reader implementation.

Read paper 6 min
09

Slot3 / Architecture white paper

Home Automation That Distinguishes Commands From Reality

Home automation often treats a delivered command as evidence that a device reached the requested state. That assumption breaks when messages are delayed, acknowledgments are ambiguous, or a resident uses a physical control. This paper proposes a Slot3 control model with separate desired state, observed state, command identity, and override policy. A synthetic lighting sequence illustrates how an older command can conflict with a newer human action. The analysis distinguishes message-delivery guarantees from physical outcomes, compares toggles with explicit state commands, and defines tests for reconnects and stale observations. It is a reference architecture for household control, not a validated safety case or an account of a deployed installation.

Read paper 6 min