What Daedalus actually does

One record per customer with every vehicle they own, joined by VIN. When a truck gets sold, the next owner inherits the repair history you built — they see the cat replacement you did three years ago, the timing-belt service from last winter, the brake job last month. History travels with the vehicle, not the customer.

• Customer types: individual or commercial; corporate fleet accounts track an account contact + billing contact separately
• Multi-phone, primary + alt; email; physical address; tax-exempt flag with certificate ID
• VIN-keyed vehicle records: make / model / year / engine / trim / colour / license plate / odometer
• "Custom Vehicle" path for kit cars, antiques, non-US-market imports — flagged so analytics can exclude them
• CSV import from whatever software you're leaving — customers + vehicles in one pass
• Demo-data button loads 5 customers / 7 vehicles / 3 ROs so you can poke around before committing real data

Every RO moves through four primary stages — Draft → Estimate → RO → Invoice — with Paid as the closure and Voided as the audit-preserving cancellation. RO numbers are per-shop: your sequence starts at RO-1001 regardless of what other shops on the platform are doing.

• Per-RO notes (pinned + chronological), work assignments, diagnostic report attachments
• Photos: before / after attachments per line item
• Supplemental estimates: customer can approve a new amount mid-job; original kept for audit

Build an estimate with line items — parts, labor, sublet, fees. Send it for the customer's approval (email or SMS with a magic-link page; no account required). Approved estimates turn into ROs in one click. Invoices carry time, parts, labor, tax — all carried through automatically.

• Line items track cost + markup-percentage separately from the price the customer sees — you see your real margin without re-doing the math
• Parts price from the cost you enter, or from a supplier quote you paste — markup comes from your cost-band matrix, see Chapter 7. There is no live supplier feed and none is scheduled: Daedalus will not show you a part price it did not get from you.
• Per-line tax categories + a customer-supplied-parts waiver flag for the lines a customer brings their own part for
• Tax + labor rates per shop, multiple jurisdictions supported
• Templates: save a common job (e.g. "front brake service") with pre-filled line items, pull it into any future estimate
• Magic-link approval URLs are single-use, time-boxed, and tied to a specific RO — they don't expose anything else

Record payments against an invoice — cash, check, card, ACH. Partial payments supported. When a payment closes out the balance, the RO state advances to Paid automatically. Each payment is timestamped, attributed to who took it, and tied to the invoice + RO for audit.

Schedule customers for a specific bay on a specific day. Mobile shops skip the bay assignment and use a location text + GPS coordinates instead. Each appointment links to the customer + vehicle; reminders go out via the communications channel the customer prefers.

• Bay-aware — define your bays, get a visual schedule (see §8.5)
• Mobile-shop mode — location text + lat/lon, no bay column; the route optimizer (§4.2) sequences the day
• SMS / email reminders, configurable lead time

Multi-point inspection sheets attached to an RO. Pre-built templates for common safety / brake / suspension sweeps; you can also define your own. Each item gets pass / advisory / fail with optional photos and tech notes. Failed items can feed back into a follow-up estimate with one click; declined items can feed the win-back engine (§5.3).

• Sheets are sealed on completion so the record of what was inspected, and when, can't be quietly edited after the fact
• QC checklist — a final quality-control pass before the car goes back to the customer, recorded on the RO's workflow section
• Comeback tracking — when a car comes back for the same concern, it's linked to the original RO so your comeback rate shows up honestly in the KPIs (§6.3)

Every text, email, voicemail transcript, and in-person conversation gets logged on the customer or RO timeline. SMS goes through Twilio; email through Postmark or SMTP. Inbound replies route back to the same thread automatically (so a customer texting "yes" to an approval lands on the right RO).

• Per-shop sender identity: emails go from [email protected], not from us
• Bounce-suppression: a hard-bounced address is flagged so you don't keep emailing into the void
• Twilio inbound SMS is signature-verified — won't accept a spoofed approval
• Consent + opt-out are enforced on every send — see §12.3 for the communications-law rules Daedalus applies automatically

Your customers sign in at daedalusautomotive.app and see your shop's face, not ours. Their dashboard shows the Logbook for every vehicle they've ever brought you, current and historical ROs, estimates awaiting approval, and outstanding invoices. A Powered by Daedalus byline lives in the footer — understated, where it belongs.

• Per-shop accent colour: brand the portal in your shop's identity
• Logbook view per vehicle (history travels with VIN)
• Approve estimates inline, pay a deposit at approval, pay the invoice online, request appointments
• Magic-link sign-in (no password required for low-touch customers); password optional for repeat users

A diagnostic Q&A surface available from any page — the always-on assistant orb, plus a Chat tab for free-form questions. Ask about a DTC, a symptom, a procedure, a part — answers come back grounded in a curated knowledge base (P-code symptom guides, FaultID registry, OEM module catalog, actuator presets) and NHTSA recall/TSB data for the specific vehicle you're working on.

It also answers questions about this program — where a screen is, what a setting does, how to void an invoice. That runs off a second, separate search over this manual. The two corpora are kept apart deliberately: a product answer citing a technical bulletin, or a repair answer citing the manual, is worse than no answer, because you cannot tell which kind of claim you are reading. Sections covering features your shop has switched off are skipped, so it will not explain a screen you cannot open.

The assistant can also act on your data when you ask — pulling live KPIs, looking up ROs and customers, and drafting create-customer / open-RO actions (it confirms before making more than one change at once). Paste raw intake notes into Chat and it will parse the customer, vehicle, and three C's into a new RO.

Refuses to help with emissions defeat, safety-interlock bypass, and odometer rollback. Answers questions about aftermarket modifications and high-voltage work (with safety procedure prepended).

Sparkle buttons next to the Complaint / Cause / Correction / Note fields on every RO. Type rough notes the way a tech scribbles them; click Summarize; get a shop-voice rewrite ready to paste into the field. Designed to be terse — 1-2 sentences for complaint and note, 1-2 for cause, 2-3 for correction.

Receives the RO context (vehicle, current field values, active DTCs) so it doesn't strip useful detail just to be short. Never adds diagnosis or speculation to the complaint — it only rewrites what the customer actually said.

The customer-facing counterpart to Summarize. Summarize (§2.2) lives on the working RO fields and polishes tech-to-tech writing. Explain lives on customer-facing surfaces and rewrites tech-language into plain English the customer will understand — without losing the technical truth.

Where it appears:

• Notify-customer-ready modal — when you tap "Notify ready" the message composer includes an Explain button. Paste any tech- language cause / correction text in, click Explain, and the message is rewritten for the customer.
• Future customer-comm composers (estimate-approval email, invoice cover note, SMS templates) will attach the same button.

Looking at a fault code, Daedalus can show you what other shops actually resolved it with — anonymised aggregate data for a matching year, make, model and engine.

It ranks by what worked, not what was popular. Each repair category carries how many times it was confirmed fixed, how many times it was tried and did not resolve the code, and how many nobody verified either way. A rate is withheld until enough outcomes are known to mean anything, so a common repair that usually fails cannot out-rank a rarer one that holds. The failures are shown too: knowing three things that did not fix it narrows a diagnosis faster than one more thing that did.

Helpful / Not helpful buttons sit under every AI response. Thumbs-down opens a small dialog: too long, missing info, wrong, unclear, etc., plus a free-form note. Feedback lands in the operator review queue. When the operator approves a piece of feedback as a behaviour rule — say "always cite OEM part numbers when the question is about parts" — that rule gets injected into every Ask Daedalus call from then on. No model fine-tuning required; the system gets smarter organically based on what working shops actually want.

Rules can be scoped: global (every Daedalus user), per shop (only your shop), or per user (just this technician). Each rule has a 1–5 weight that controls how strongly it's rendered in the prompt (must / should / when practical).

When you add a vehicle, Daedalus fires a background fetch against NHTSA's public APIs for that exact make/model/year and pulls every active recall and technical service bulletin into the knowledge base — tagged so Ask Daedalus can cite them when you ask about that vehicle. Idempotent (re-runs don't duplicate), best-effort (NHTSA's API has intermittent outages; failures degrade quietly). The same federal data also powers the vehicle-intel chip strip (§3.6).

Each vehicle has a Health Score (0–100) computed from service history, manufacturer-recommended interval gaps, outstanding recalls, and historic alert signals. Shows up on the customer portal as a coloured tile ("Your truck: 82 / 100 — service for transmission fluid is overdue by 4,000 mi") and on the shop's vehicle detail as a diagnostic summary. Brake-pad / battery / fluid components are calibrated against published OEM intervals; the underlying model is documented and tunable.

On an RO, Daedalus can suggest add-on line items that fit the vehicle and the work already on the ticket — the services a thorough advisor would offer but might forget on a busy day (a cabin filter due by mileage, a fluid flush that lines up with the interval, the wiper blades the inspection already flagged).

• Suggestions are proposals, not auto-adds — the advisor accepts the ones that make sense and the line drops onto the estimate
• Grounded in the vehicle's service history and the current RO, so it doesn't pitch a service you just did
• Optional per shop (feature flag show_ai_upsell) — off for shops that don't want suggestive selling

Step-by-step guided procedures for common jobs — the wizard walks a tech through the sequence, the specs, and the gotchas so a less-experienced hand can do the job right and a veteran doesn't miss a step. Pairs with the RO so the work gets documented as it's done.

A reference for live data parameters (SAE J1979 PIDs — what each parameter means, the normal range, and what an out-of-range value points to) and an emissions-readiness view that explains the OBD-II monitor set: which monitors must be "ready" to pass a state inspection, and the drive-cycle conditions that set each one.

A capability catalog of bidirectional / actuator tests by system — what can be commanded on a given module (cycle the EVAP purge, command the cooling fan, bleed ABS, relearn a throttle body) and the safety preconditions for each. Grounded in the same ISO 14229 (UDS) service catalog the AI assistant uses.

Calibration covers ADAS work — the cameras and radar that drive lane-keep, adaptive cruise, and automatic braking — including which systems need a static vs. dynamic calibration after common repairs (windshield, alignment, bumper) and the conditions the bay needs to meet. Module replacement covers the program/clone/relearn steps a control module needs when it's swapped, so the new part actually works in the car.

An electric-vehicle high-voltage battery analysis view — state-of-health estimation and pack diagnostics for EV/hybrid work, with the high-voltage safety guidance prepended. A growing area as more EVs come through the bay.

Per-vehicle data pulled from federal public-domain sources, surfaced as a chip strip on the RO and vehicle detail: NHTSA recalls (and a rollup count for complaints / investigations / TSBs) and EPA fuel-economy data. A cheap one-call summary endpoint backs the chip strip; deeper lists are a click away.

A board of open ROs grouped by their primary technician — the most recent still-active work assignment — with an unassigned lane for jobs that need a hand. Each lane shows open ROs (anything not paid / cancelled / archived); each card carries time-on-job, customer name, vehicle label, the state badge, and the tail of the last note.

• Reassign or first-assign a job to a tech from the card
• One primary tech per RO keeps the board readable; the full work-assignment history stays on the RO
• Optional per shop (show_dispatch_board)

A scheduling queue (most-urgent first) for shops — and especially mobile operations — that need to plan a day of stops. The optimizer builds a proposed schedule that honours each job's SLA window, your working hours and days, customer availability, and daily caps, sequencing stops by distance.

A shift-clock chip sits in the header — a tech clocks in and out for payroll without leaving what they're doing. Labor time is also tracked against each job, so the hours actually spent on an RO are captured for both payroll and the efficiency report (§6.4).

• Per-shift clock in/out (payroll)
• Per-RO labor time (job costing + effective labor rate)
• Feeds the tech-time and productivity reports in §6.3

One switch, every clock. "Track time on jobs" (show_time_tracking) governs all of it — the header chip, the Timesheets page, the on-the-clock figures on your dashboard, and the timers on the repair order. A solo mobile tech who has no payroll to run turns it off and the whole surface goes with it, rather than leaving a clock in the corner of every screen.

Per-line labor clock & live timer. On the RO, every labor line carries its own ▶ start / ■ stop button and a live counter that starts at zero and ticks up while a tech is clocked onto that line. Starting a line timer stops whatever else that tech had running — one active job per tech — so the recorded time lands on the right line without double-counting.

Bill estimated or actual time — your call, per line. Each labor line shows a two-way Bill: Est / Actual switch:

• Est — bill the hours you quoted (the line's quantity). This is the classic behavior and the default.
• Actual — bill the recorded clock time instead. The line re-prices to the clocked hours automatically, and the invoice totals follow.
• The switch is non-destructive: your estimated hours and the recorded time are both kept, so you can flip back and forth freely — nothing is overwritten.
• Set the shop-wide starting point under Settings → Pricing & Tax → Labor billing basis; new labor lines inherit it, and any line can still be switched on the RO.
• The per-line clock, live counter, and Est/Actual switch appear only when time tracking is on (show_time_tracking).

Define shop-wide reminder rules ("oil service every 5,000 mi or 6 months") and Daedalus generates per-customer reminders as vehicles come due. Each reminder can be sent by email or SMS on demand, then marked sent — or dismissed / completed as the customer responds.

• Rules are shop-wide; reminders are per customer/vehicle
• Filter the queue by status or "due within N days"
• Schedule a follow-up reminder straight from an RO when you defer work
• Optional per shop (show_maintenance_reminders)

After pickup, send the customer a one-tap link to leave a review on Google or Yelp. Configure the links once in settings; the request goes out on the channel the customer prefers. Optional per shop (show_review_requests).

A campaign engine for win-back and follow-up. The headline use-case is declined services: when a customer turns down a recommended line, it lands in a follow-up queue, and a campaign can reach back out a set time later ("you held off on the rear brakes in March — still want to get those done?").

• Create, enable / disable, and force-run campaigns; a cron-style runner walks every enabled campaign
• Message templates substitute {customer_name}, {service}, and {shop_name}
• Declined lines are logged automatically from the approval flow
• Optional per shop (show_marketing_campaigns)

Build and sell recurring service plans — a catalogue of membership plans, customer enrollment, and cancellation. Sell the "3 oil changes + a free inspection a year" plan and track who's enrolled.

Promo-code administration with apply-at-estimate. Codes can be a percent off, a flat amount, or a free service, optionally scoped to a kind of line. The advisor applies the code on the estimate and the discount carries through to the invoice. Optional per shop (show_coupons).

For shops that carry receivables — fleet accounts especially — an accounts-receivable view with a bucketed aging report (0–30 / 31–60 / 61–90 / 90+ days) per customer, plus per-customer statements (opening balance, line activity, ending balance, aging) you can pull as JSON or download as CSV to send.

• Aging is computed as of any date you pick
• Statements scope to a customer and a date range
• Optional per shop (show_billing)

Create and track purchase orders to your suppliers. Draft a PO, add lines, then receive lines as the parts arrive — receiving bumps the on-hand count automatically. A reorder-point suggestion flags what's getting low so you can build the next PO from it.

• PO lifecycle: draft → add lines → receive (updates inventory)
• Track status, notes, shipping, tax per PO
• Reorder-point auto-suggest

A dashboard KPI strip plus a tabbed reports page. All reports are read-only and shop-scoped, and every one can be exported to CSV.

The KPI dashboard grades headline numbers (revenue, ARO, car count, effective labor rate) against benchmarks — or just ask the assistant "how's business this week?" It lives in the Profit tab of Reports and is always on; the separate KPI page and its show_kpi_dashboard switch were retired when the two were merged.

An efficiency report comparing flat-rate hours billed against actual clock hours per tech — the productivity number a shop owner lives by. Flat-rate hours come from each labor line; actual hours come from the time clock (§4.3). Commission rules let you turn those hours and sales into tech pay.

Hand clean data to your books. Map your chart of accounts once, then export a journal for a date range in the format your accountant wants — generic CSV, a QuickBooks journal CSV, or a QuickBooks IIF file — including or excluding payments, and optionally only the unexported rows. Exported invoices get stamped so you don't double-count.

• Formats: generic CSV · QuickBooks journal CSV · QuickBooks IIF
• Filter by date range, include/exclude payments, unexported-only
• Mark-exported stamp prevents double entry
• Optional per shop (show_accounting_export) — live API sync is on the roadmap (§15.2)

One rule governs every route below: you tell Daedalus what the part cost you, and Daedalus works out what the customer pays. Sell price = cost × (1 + your markup), with the markup coming from your parts matrix (§7.3). If you type a sell price yourself, that wins — Daedalus never second-guesses a number you entered, and it never invents one it wasn't given.

There are three ways to get the cost in. No setup, no vendor account, no API key — use whichever your supplier allows:

• Type it. On the repair order, + Add part, then fill in Cost. The Sell price and Markup % fields fill themselves in as you type, and you can override either one before you hit Add.
• Paste a quote or cart. Select the quote table on the supplier's site, copy it, and paste into the assistant box on the repair order. Daedalus reads the rows and stages them for you to review.
• Screenshot it. Can't select the text? Take a screenshot (Win + Shift + S on Windows, ⌘ + Shift + 4 on a Mac) and paste the image into that same box.

Every route lands the same way: lines staged on the repair order for you to approve. Nothing reaches the estimate until you say so. Staged parts show the vendor's cost with the sell price your matrix produces beside it, so you can see the margin before you accept the line.

If the supplier already charged you sales tax — retail orders usually do, wholesale counters on a resale certificate don't — those lines import marked not taxed, so your customer isn't taxed a second time on the same part. Tick the line taxable on the RO if your state requires you to collect again.

The parts you buy often are worth saving once. Parts → Import price book takes a CSV from your supplier — the price sheet your rep emails, or an export from the vendor portal — and turns it into a searchable list of your own costs.

After that, typing a part description on a repair order offers what you already have, with the cost prefilled. A part on the RO that matches a part number in your price book links back to it automatically.

Re-importing an updated sheet is safe. Matching rows update their description, brand, cost and list price; everything else is left alone. In particular a re-import never touches your on-hand counts, reorder points or bin locations — a supplier's price sheet knows what they have on the shelf, not what you do.

A flat markup over-prices the expensive parts and leaves money on the cheap ones. Settings → Pricing & Tax lets you set cost bands instead: a part's cost picks the first band it falls under, and if you set no bands the flat default applies to everything.

Worked example. With two bands — up to $50 → 45% and above → 30%:

• A $20 cabin filter sells at $29.00 (45%).
• A $180 alternator sells at $234.00 (30%).
• A part costing exactly $50 is in the first band — up to $50 means fifty and under.

The bands apply everywhere a cost becomes a price: the Add-line modal, an imported quote, and a part pulled from your price book. Outside work (sublet) can carry its own rate, also in Settings → Pricing & Tax. Labor is priced from your labor rate rather than a cost, and fees, discounts and mileage are already the customer-facing number, so none of them are marked up.

For mobile operations, track the stock that rides in the van — adjust counts as parts get used, check parts out to a job. Van inventory turns on automatically in mobile shop mode (it's the one inventory model that makes sense without a stockroom).

Manage a fleet of loaner cars: add loaners, mark one out of service, check a loaner out to an RO when a customer needs a ride, and mark it returned. Each RO shows its current loaner assignment. Optional per shop (show_loaners).

Track shop equipment and tools — a tech checks a tool out and returns it, so you know who has the diagnostic tool or the torque wrench. A calibration-due alert flags equipment that needs servicing or recertification before it drifts out of spec. Optional per shop (show_equipment).

A week/day staff schedule grid plus a PTO inbox — employees request time off, a manager approves or denies, and the grid shows coverage. Optional per shop (show_employee_schedule).

A public TV display for the lobby — a clean, customer-safe view of the day's queue so waiting customers can see where their car is in the line. Open it on a spare screen and leave it up. Optional per shop (show_wait_screen).

Define your bays (general, alignment, and so on) so the appointment calendar (§1.5) and dispatch board (§4.1) can place work against real capacity. Mobile shops skip bays entirely.

Daedalus runs completely on its own — you can write estimates, build repair orders, invoice, and schedule with no outside accounts at all. A few optional services plug in when you want more. Here is the whole list, whether you need it, and where to set it up. Nothing here is required to start.

Group multiple shops under a corporate group and see KPIs rolled up across every member shop — car count, revenue, and the rest, aggregated for the chain. Group-level visibility is restricted to platform administrators; individual shop users continue to see only their own shop's data. Optional per shop (show_corporate_rollup).

Mint API keys to connect outside systems to Daedalus. The secret bearer token is shown once at creation; after that you only ever see metadata, and you can revoke a key at any time. Optional per shop (show_integrations).

Subscribe a URL to Daedalus events. Each delivery is POSTed with an X-Daedalus-Signature header — hex(HMAC-SHA256(secret, body)) — so your receiver can verify the call genuinely came from Daedalus. A test-send lets you confirm wiring before you depend on it.

Configure your vehicle-history provider (Carfax or AutoCheck) and Daedalus deep-links into it for a vehicle. This is a deep link driven by your configured provider + partner ID today — not a licensed in-app data feed.

An in-app notification system with a server-side outbox backs the alerts you see (and the outbound email/SMS the rest of the product sends). The outbox is the single, auditable path messages flow through, which is also how comms consent and opt-out (§12.3) get enforced uniformly.

• Postgres (Fly Managed): customer, vehicle, RO, estimate, invoice, payment, communications, audit log — all the relational shop data, shop-isolated by row-level shop_id filtering enforced at the repo layer
• SQLite (persistent volume): per-instance knowledge base, calibration captures, JWT revocation list, auth user table. Survives every deploy via a Fly mounted volume.

Every write carries a shop_id. Every read filters by it. Audit-tested across customer, vehicle, RO, estimate, invoice, payment, appointment, technician, time-clock, parts, and notes tables. Two shops sharing the platform can't see each other's data even by URL-guessing.

Connect your own S3-compatible bucket (AWS S3, Backblaze B2, Cloudflare R2, Wasabi, MinIO). Daedalus encrypts the backup client-side before upload using a key you generate and hold — we never see your data in plaintext on the way out. Restore is tested end to end. This is separate from the local mirror in §10.4, which pulls from our API rather than from your bucket.

The mirror is read-only and pulls from our API, not from your bucket — it is a copy that stays current, not a second place the shop can be operated from. If Daedalus is unreachable you can point an install at that SQLite file and read yesterday's data; you cannot write to it.

• JWT in HttpOnly cookies, not localStorage — immune to XSS token theft
• bcrypt password hashing, cost 12; per-row hash-version column for future algorithm rotation
• Per-IP + per-username rate limits on login, signup, and forgot-password
• Refresh-token rotation with per-user revocation list (logout clears all your tokens server-side, not just the client)
• Beta-invite tokens are single-use, time-boxed, raw token never stored (only a hash)

Two-factor authentication (TOTP). Turn on 2FA from Settings → Sign-in & security: scan the QR into any authenticator app, verify a code, and save the backup codes. Strongly recommended for owners and managers. The TOTP math is hand-rolled (no third-party dependency); the secret and backup codes can be cleared with a verified disable.

• Content-Security-Policy header — no inline scripts in production except where explicitly nonce'd
• Strict CORS (allow-list of two domains: daedalusautomotive.com + .app)
• Secure / SameSite cookies; HTTPS-only enforced via Fly edge

Every meaningful state change writes an audit-log row: who, when, what changed, from what value to what value. Shop-scoped (you only see your own); viewable from Insight → Audit log. Tamper-resistant by design — append-only — there's no UPDATE / DELETE path through the API.

• No third-party analytics, no marketing trackers, no Google. The marketing page makes one HTTP call: fetching its own CSS.
• Crash reporting via Sentry is opt-in only; when enabled, PII is stripped before send
• Your customer data is never used to train shared models

The full data-rights machinery — subject-access exports, erasure, consent, communications law, retention, and your shop's own regulatory obligations — has its own chapter (Chapter 12).

Two request kinds back the privacy rights a customer can exercise:

• Export — serialize every customer-tied row (the customer, their vehicles, ROs, invoices, and communications) into a single JSON dataset for a subject-access / portability request.
• Erasure — a GDPR Article 17 deletion with the tax-retention exception. Personal data is removed/archived while the financial records the law requires you to keep are retained under a legal hold (§12.4). Erasure can't quietly destroy the invoices you're obligated to keep for tax.

A background scanner watches for aging requests so a statutory deadline (GDPR ~1 month / CCPA 45 days) doesn't slip by unnoticed. Optional per shop (show_privacy_dsr); managed from Settings → Privacy & data.

Terms / Privacy consent is captured at signup and stamped with the exact version the user agreed to, from a single source of truth (currently v1.1, effective 2026-06-15) — never a hardcoded guess. When the published version changes, the drift is detected against that constant and users are prompted to re-consent. Withdrawal is recorded with an audit trail.

Every outbound message respects the communications-law rules so a marketing campaign can't become a liability:

• Consent capture before marketing contact, recorded per customer
• Opt-out / unsubscribe honoured on every channel; an opted-out customer is suppressed
• Quiet hours so texts don't go out at 2 a.m.
• Transactional vs. marketing split — an approval link or "your car's ready" is transactional and always goes through; promotional sends are gated on consent

When a shop churns, its operational data is eligible for cleanup after a grace period — but financial records the law requires (invoices, payments) are protected by a legal-hold carve-out so they survive a 7-year tax-retention window regardless of the operational grace. Reconciling "erase the customer" (§12.1) with "keep the tax records" is the same legal-hold mechanism in both directions.

The shop-facing side: a per-shop compliance profile keyed on your state, tracking the obligations that actually apply to you and the deadlines that generate fines if you miss them.

• State profile + applicable obligations — configurable per shop, since the rules vary by state
• License & permit renewals with expiry reminders
• Technician certifications (ASE, EPA 609) and their expiry
• Equipment inspections due dates
• Hazardous-waste / used-oil disposal log for your EPA / state records

Deadline reminders are emitted by a background worker so a license renewal or a cert expiry doesn't sneak up on you. Managed from the Compliance page; writes require the shop-settings permission.

Two layers: Fly's managed Postgres snapshots (5-day retention, daily) cover the cloud-hosted relational data; your own BYO-bucket schedule (if enabled) handles encrypted exports of everything — Postgres dump + per-instance SQLite + uploaded photos. A tools/mirror-to-live recovery script ingests a bucket back into a fresh Daedalus instance for full disaster recovery.

• /healthz + /health endpoints (no auth) for uptime checks
• Fly platform health checks every 30s
• Anthropic API balance / quota visible in the Settings panel for master_dev

• Customer / vehicle / RO data → Postgres → never wiped by a redeploy
• Auth tokens / KB / per-shop assets → SQLite on Fly volume → never wiped by a redeploy
• Logs / metrics → Fly's log retention (90 days)

Founding shops lock in the founding rate: 50% off their plan, for life — Solo $50.00/mo, Shop $75.00/mo, Shop Plus $125.00/mo. Full access, and the price never changes as long as your account stays active. It follows you up a tier too: move from Solo to Shop and you pay half of Shop, not half of Solo. When the founding window closes, new shops join at the standard tiers below.

Solo $99.99/mo (1 seat) · Shop $149.99/mo (5 seats) · Shop Plus $249.99/mo (unlimited seats). A seat is a login. Technicians on your roster are not seats — they don't sign in, so you can have as many as you like on any tier and still clock them, pay them and assign them work. If a downgrade leaves you over your seat count, everyone keeps working for 7 days (Settings shows the date), then the most recently added logins are switched off — never the owner, nothing deleted, reversible from Team & Roles. Cancel anytime; your data stays exportable. Customers — the drivers your shop serves — are always free. Daedalus does not charge per-RO or per-vehicle: a shop is a shop. Current numbers always live on the pricing page.

The billing plumbing for your shop's own subscription is built on Stripe: start a checkout for a plan, open the Stripe customer portal to manage your card and invoices, and see your current plan, status, and seat count in Settings → Subscription. Stripe's webhooks keep your subscription state in sync server-to-server (signed and idempotent).

If a payment fails. Cards expire and banks decline things; it is not treated as a crisis. Stripe retries the charge automatically several times across about three weeks, and nothing changes for your shop while it does — everyone keeps working, and Settings → Subscription shows the status as past due so you know to update the card. Updating it clears the flag as soon as the next attempt succeeds; there is nothing else to do.

If about two weeks go by with the payment still unpaid, Daedalus stops you opening new work — no new repair orders or estimates. Everything else stays exactly where it was. You can still sign in, read every record, invoice and collect payment on work already done, and export all of your data. Nothing is hidden and nothing is deleted. Fix the card and full access comes straight back.

Already shipped: in-shop card charges through a Stripe Terminal reader, the SaaS subscription billing (§1.4, §14.3), customer-portal pay-the-invoice-online and deposit-at-approval — both via Stripe Connect destination charges, settling straight to your own Stripe account. Those activate for your shop as soon as you finish connecting Stripe in Settings → Online Payments.

What's still landing here: a Square option and broader payment-service-provider choice.

One-way live export of invoices + payments into QuickBooks or Xero over their APIs. File export (CSV / QuickBooks journal / IIF) is available today (§6.5); the live API sync is the upgrade.

The connection itself is built — Settings → Accounting shows a Live sync card with the real state per provider. What it still needs is a registered developer application with Intuit and with Xero, which we have to hold as a platform and cannot self-issue. Until those exist the card says Unavailable here rather than offering a Connect button that could not work, and the file export produces the same journal entries in the meantime.