Trust and infrastructure

LotBeacon never sends a text, email or message. The rep copies the draft and sends it from their own phone or CRM.

Every release runs a static scan that fails the build if a network call shows up in the page code outside a short allowlist, plus a runtime check that the demo makes no outbound requests.

Each invite code carries one rooftop and one role. The server reads both from the invite ledger on every request, never from the page or the cookie.

Offline tests on every release check that one store's board shows only that store, that a rep code cannot open the owner view, and that owner views need a session and refuse cross-site requests.

Invite codes are stored as salted PBKDF2 hashes (100,000 rounds). New codes are 20 random characters. Sessions use a host-only, secure cookie that lasts 7 days.

Covered by the same offline desk tests.

20 requests a minute per rep, 60 a minute per network address, a daily cap per desk, and a 15-minute lockout after 5 failed sign-ins.

Counted in a shared store when one is attached, otherwise per server instance. In our Oct 17 load test, limits did not hold exactly under burst; exact counters are on the roadmap (ASAP).

Nothing ships unless build, type check, offline tests, banned-claim and secret scans, link check, accessibility smoke test, performance budget and a headless walkthrough all pass.

The gate report is kept for every release.

Every production release is an immutable deployment. The one before it stays available, and we write down its id at each release so we can switch back in minutes.

Hosting is Cloudflare Pages. Switching back is one step to the recorded deployment. We have not needed it at group scale.

Before a draft goes to the AI, the desk masks phone numbers, emails, Social Security numbers, labeled dates of birth, labeled account, loan and policy numbers, and street addresses.

The server runs this mask on the message before it asks the AI for a draft. Names stay as written.

On the LotBeacon desk, an activity log of drafted, flagged, copied and marked-sent, kept in the browser. Sent means the rep marked it sent. Message text stays out of the log.

The log lives in the rep's browser, capped at 400 rows. The server keeps usage counts only. A long-term, tamper-evident archive is not built.

Shown in the demo with scoped views for a fictional group.

The live desk supports one rooftop per code today. Multi-rooftop roles on the server are not built yet.

The desk holds drafts from 9 PM to 8 AM and on opt-out replies.

That uses the rep's device clock. Per-rooftop zones are a demo only.

Drafts quote only the store's inventory list and flag sold or stale units.

Inventory is loaded by hand today (file or sample). No DMS or vendor feed is connected.

We do not have a SOC 2 report and have not started an audit.

We will say so here when that changes.

Partly done. On Oct 17, 2026 we load tested a separate test copy of LotBeacon, never the live site. Public pages served 500 visitors at once with zero errors (95% of requests in under 50 ms). The rep desk handled 760 simulated reps drafting at once with zero server errors while the AI model was simulated. None of this was real store traffic. With the real AI model, 20 reps drafting at once got all 300 drafts back with no errors, median 8 seconds.

The test also found limits we are fixing now: sign-in, bulk invites, exact rate limits and per-store daily caps do not yet scale to a large group. Those are on the roadmap marked ASAP. Not yet tested: real-model traffic above 20 at once, multi-day runs, and traffic from many networks.

Internal security assessment completed October 2026. It covered dependency and secret scans of the full code history, static analysis, a header and CSP review, automated web scans against a test copy, and tests for sign-in, sessions, store-to-store isolation and payment webhooks.

Most findings are fixed. Two are open: rate limits need a stronger counter, and sign-in needs a ledger built for group scale. Both are on the roadmap. Report a security issue to nathan@holdthesend.com (also listed in /.well-known/security.txt).

No outside penetration test yet. Not yet scheduled.

The scope document is ready for vendors.

Not built. Reps sign in with invite codes.

Bulk invites and offboarding are shown in the group demo.

Not published yet.

Ask us and we will tell you what is kept and for how long today.