CrewSheet

Day 20 of 30 — the Aviation arc opens, on a game-day switch

CrewSheet is photo-driven flight log capture for FAA Part 91 and Part 135 corporate turbine operators. It is live today at crewsheet.flights, with two panel adapters shipped day one — Honeywell Apex for the Pilatus PC-24 and Garmin G1000 / G1000 NXi for most of the GA glass-cockpit world. Ty Flippin is co-founder, 50/50 — Pilatus PC-24 Check Airman, CRO consultant inside the TechCXO network, the operator who named the problem and validated the proof. CrewSheet is the Day 20 launch slot in the 30-day run, and it is the third game-day switch — TalzDx wasn’t ready this morning, CrewSheet came off the bench, same shape as the Day 3 PartFoundry switch off Florida Condo Tracker and the Day 15 Swole Labor Services switch off the audience-pick build. The pattern is now a feature of the methodology, not a bug in the calendar.

The switch

The slot was supposed to be TalzDx — physician-built MSK clinical decision support, the Healthcare arc opener. TalzDx slipped on regulatory-validation readiness; the displaced venture goes back to the bench and re-slots clean when it’s actually ready. CrewSheet earned the slot the way ventures earn slots in this process — a real operator named a real problem out loud, and the first vision pass against the proof image came back clean.

The discipline of the run is to name slips and switches when they happen. The Day 3 PartFoundry post named the Florida Condo Tracker pullback in paragraph one; the Day 15 Swole Labor post named the audience-pick deferral the same way. Today’s post does the same. This is the third proof: when the slot needs more runway, the bench gets the slot, and the methodology absorbs the change without breaking the cadence.

The problem

Every corporate flight department and charter operator closes every flight with the same ritual. The crew shuts down, climbs out, and a pilot — usually the PIC, sometimes the SIC, often whoever is least tired — hand-fills a paper or PDF aircraft log sheet from the panel: total flight time, fuel quantity remaining, fuel used, Hobbs delta, cycles, route, crew assignments. Then the same numbers get re-keyed into ForeFlight for the pilot logbook. Then the same numbers get re-keyed into CAMP Systems (or Veryon, or Traxxall) for the maintenance tracking program.

Three transcriptions. Three opportunities for the wrong number to land in the wrong system. Three opportunities for the airframe-total-time number that drives the next inspection interval to drift from what’s actually on the panel. 14 CFR 91.417 requires Part 91 operators to keep accurate total time in service on the airframe and every life-limited part. 14 CFR 135.63 requires Part 135 operators to keep load manifests for 30 days and pilot records for 12 months. 14 CFR 1.1 defines time in service as wheels-up to wheels-down — not Hobbs, not block time — and the data model has to keep all three because maintenance tracking, pilot logging, and operator scheduling each use a different one. The paper-and-re-key workflow that produced these records when flight departments ran on greaseboards is the same workflow most departments still run today.

The back-of-the-envelope cost is real and not small: roughly one pilot-hour per flight across the three systems, on top of the actual flight. A 10-tail Part 135 shop flying 60 legs a month is shipping 600 pilot-hours a year into transcription. The cost is real, the error rate is real, and the audit posture under the next FAA records check is exactly as good as the most tired pilot on the worst Tuesday of the month.

Ty Flippin works with the operators living this every day. The PC-24 fleet he’s closest to runs Honeywell Apex avionics; the broader fleet he sees across the TechCXO network runs Garmin G1000 / G1000 NXi on Cessna, Cirrus, Diamond, and King Air B-series airframes. Same problem, different panel. The Velocity Process answer is the same in both cases: capture the panel once, extract the data once, validate it once, sign it once, and let the three downstream systems consume the same signed source of truth.

The proof — April 27, 2026

Ty’s email arrived April 27, 2026. Subject line: “Could you screen scrape this image?” Attached: a photo of a PC-24 Honeywell Apex multi-function display, engine page, real flight, real numbers he already knew.

One Claude Vision call. Claude Sonnet 4.5 via AWS Bedrock. A panel-specific system prompt that names what’s where on the Apex MFD — the N1 for engines 1 and 2, the ITT bars, the fuel flow indicators, the oil pressure and oil temperature gauges, the total fuel quantity in pounds, the fuel used in pounds. The schema the response had to land in: flight time hours, total fuel quantity, fuel used, Hobbs value, cycles, N1 per engine, self-rated confidence, free-text notes. Strict JSON output. Output capped at 400 tokens to keep the cost target honest.

The extraction came back matching the panel — flight time, total fuel, fuel used — at high self-rated confidence. No fine-tuning. No bespoke OCR pipeline. No template-matching against a panel layout database. Just the photo, the prompt, and the schema.

That single API call is the canonical Phase 1 acceptance test image documented in the CrewSheet CLAUDE.md. The HoneywellApexAdapter is built around the system prompt that produced that result. The production cost target — under $0.05 per flight across all extractions — is set against the token math of that call: cached system prompt at 1-hour TTL, ~3K input tokens per image including the photo, output capped at 400 JSON tokens, two panel photos plus one Hobbs photo per flight.

Honeywell Apex is the harder of the two day-one panels. There are not many training images of Apex on the public internet — it’s a much rarer panel than the Garmin G-series. The vision pass landing clean on Apex first, then generalizing to Garmin G1000 / G1000 NXi on the same panel-adapter pattern, is the proof that the architecture is not Apex-specific. It is the pattern.

What CrewSheet does

Crews snap photos of the glass-cockpit panel and the Hobbs meter at engine shutdown. The captain or the pilot monitoring lifts an iPad, frames the panel, and uploads two panel photos plus one Hobbs photo per flight. CrewSheet routes the images to the appropriate panel adapter based on the aircraft’s registered panel type, extracts flight data via Claude Sonnet 4.5 over AWS Bedrock, validates the extraction against the prior flight’s totals and the aircraft’s running airframe time using an eight-rule validation engine, and produces three signed outputs from one source of truth — a printable PDF aircraft log sheet, a ForeFlight-compatible logbook CSV, and a CAMP Systems-formatted maintenance update.

The flow has four moves:

Move 1 — Capture. The crew shoots the panel post-shutdown and the Hobbs meter, and the pre-flight reference photo if the operator prefers the pre/post pattern. The photos upload to S3 (KMS-encrypted, versioned), the API enqueues an SQS job for the worker, and the API returns 202 Accepted to the client with the image identifiers. The capture is asynchronous and tablet-optimized — the captain doesn’t wait on the extraction to finish before closing the cockpit.

Move 2 — Extract. The worker pulls the SQS job, loads the image from S3, routes to the appropriate PanelAdapter (Honeywell Apex or Garmin G1000), and calls Claude Sonnet 4.5 on AWS Bedrock with the panel-specific system prompt cached at 1-hour TTL. The model returns strict JSON matching the ExtractedPanelData schema — flight time hours, total fuel quantity, fuel used, Hobbs value, cycles, N1 per engine (or RPM/MAP for piston G1000), self-rated confidence, free-text notes. The worker writes the extraction to flight_images.extracted_data and enqueues the validation job.

Move 3 — Validate. Eight validation rules run inline against the extracted values and the aircraft’s prior-flight history: hobbs_continuity (this flight’s Hobbs start matches the prior flight’s Hobbs end within 0.2 hours — error), hobbs_delta_matches_tis (Hobbs delta within 5% of computed time in service — warning), fuel_balance (fuel used + fuel remaining ≈ fuel at start within 3% — error), cycles_at_least_one (any flight that landed has ≥ 1 cycle — error), airframe_time_monotonic (aircraft total time only increases — error), pic_assigned (every flight has at least one crew member with the PIC role — error), route_icao_valid (origin and destination are valid ICAO idents — warning), engine_cycle_increment (engine cycles incremented by the flight’s cycle count — warning). Errors block PIC finalization; warnings surface inline but do not block. The validation surface mirrors the discipline a Part 135 chief pilot brings to reading the log sheet before it goes in the records — except it runs in seconds, not on Sunday mornings, and the audit log captures every override with a reason.

Move 4 — Sign and export. The PIC reviews the extraction, corrects any value the validation engine flagged, signs the flight log via the Cognito-authenticated UI, and the status transitions to finalized with an immutable audit-log record. The three exports generate in parallel: WeasyPrint renders the HTML aircraft log sheet template to PDF (with the 14 CFR 135.63(c) load-manifest fields rendered for Part 135 legs); the ForeFlight exporter writes the Aircraft and Flights CSV sections (one row per pilot-flight pair, so a multi-crew leg produces multiple rows); the CAMP exporter rolls airframe and engine totals forward and increments cycles into a CAMP Systems-compatible CSV. All three artifacts land in S3, versioned, and are downloadable from the flight detail page.

Two panel adapters Day 1, not one

The original April 27 acceptance image was a Pilatus PC-24 Honeywell Apex MFD; the Honeywell Apex adapter is the anchor of the architecture. Over the 13-day production build window the Garmin G1000 / G1000 NXi adapter landed alongside it on the same panel-adapter pattern, which expanded the day-one addressable fleet from “Pilatus PC-24” to most of the GA glass-cockpit world.

Honeywell Apex (Pilatus): PC-24, PC-12 NGX with Apex.

Garmin G1000 / G1000 NXi: Cessna 172/182/206 Skyhawk/Skylane/Stationair, Cessna 208 Caravan (NXi), Cirrus SR22 (Perspective+ is a G1000 variant with Cirrus cockpit styling), Diamond DA40/DA42/DA62, Beechcraft King Air B200/B250/B350.

Both adapters implement the same PanelAdapter(ABC) interface — extract(image_bytes) -> ExtractedPanelData. The interesting differences between Apex and G1000 are in the system prompt: Apex MFDs show N1, ITT, fuel flow in pounds-per-hour, and total fuel in pounds because the PC-24 is a turbofan; G1000 piston aircraft show RPM/MAP rather than N1, and the EIS (Engine Indication System) strip on the PFD displays fuel in gallons, which the adapter converts to pounds using a configurable AVGAS-density constant (6.0 lb/gal for 100LL, 6.7 lb/gal for Jet A on the Caravan / King Air variants). Both adapters cache the static system prompt at 1-hour TTL on AWS Bedrock to keep the per-flight cost target under $0.05 across the typical 2-panel + 1-Hobbs photo pattern.

The Phase 2 list is in line: Garmin G3000 / G5000 (Citation Latitude / Longitude / M2 / Sovereign, Embraer Phenom 300, HondaJet, Daher TBM 900-series, King Air 350ER), then Honeywell Primus Epic (Falcon, Gulfstream), then Collins Pro Line Fusion. Same Bedrock model, same JSON schema, different system prompt per panel — the architecture generalizes because the April 27 vision pass said it would, and the G1000 adapter landing on the same pattern is the proof.

The cryptographic audit chain is the regulatory wedge

Phase 1 ships an immutable audit log on every state transition — operator creation, aircraft onboarding, flight log creation, photo upload, vision extraction, validation result, manual override (with reason), PIC finalization, export generation, amendment. The log captures the actor identity (operator admin or pilot), the actor email, the action verb, the entity type and ID, the before-state and after-state JSONB snapshots, and the IP address and user agent on the originating request.

The audit posture matters because the next FAA records inspection asks the same question every time: who made this entry, when did they make it, what was the entry before they touched it, and what did they change it to? CrewSheet answers that question structurally, by construction, for every state transition. The Part 91 maintenance-records requirement under 14 CFR 91.417 and the Part 135 maintenance-records requirement under 14 CFR 135.439 both presuppose this kind of attribution; most flight departments produce it manually through paper-and-signature processes that are exactly as good as the most diligent person who touched them. CrewSheet produces it automatically.

A precise distinction the launch holds: CrewSheet is not itself SOC 2 / FedRAMP / HIPAA certified at launch. The wedge is that CrewSheet produces the evidence shape a SOC 2 review will require for AI-assisted operational records — the audit trail is built in, not bolted on. SOC 2 readiness is scoped separately (a Silverback SecureStackScan engagement, on a separate engagement letter). The Day 19 PlanWright “audit-chain wedge” language is the same discipline applied here.

Live in production — eight days of debugging is the signal

Eight days of production debugging since May 12 produced a backlog of real operational lessons, captured in docs/BACKLOG.md in the CrewSheet repository. The signal in those items is that the surface is live, real photos are landing, and real bugs are surfacing the way they only surface against real cockpit input. The launch is calling the production debugging out explicitly — same posture as Day 4 CompliancePulse naming the paying-customer list and Day 16 NameIntel verifying the MCP server live during the readiness audit. The product-state proof is the thing that distinguishes a defensible launch from a pre-launch.

Three specific bugs the production-debugging backlog already caught and is fixing:

The Hobbs misread. The Apex vision extractor returned a 6,496-hour reading (the running Hobbs total on the panel) in the flight_time_hours field, which the UI then tried to apply to time_in_service_hours. The frontend now filters implausible flight-time values (anything over 24 hours gets rejected with a “did you mean this was the Hobbs?” prompt), and the Apex system-prompt tightening is on this week’s punch list (docs/BACKLOG.md item 6) — the disambiguation language needs to make explicit that flight_time_hours is the elapsed time for this leg only, distinct from the running Hobbs total. The data quality story is the prompt itself, not the model; this is the kind of bug you only catch when a real pilot uploads a real photo with the elapsed-time indicator near the Hobbs readout.

The pre-token Lambda crash. The Cognito pre-token-generation Lambda crashed when response.claimsOverrideDetails was null on a synthetic V1 event; Cognito surfaced the failure as invalid_grant with no error_description, which masked the real cause for hours before CloudWatch surfaced the actual stack trace. The defense-in-depth fix on this week’s punch list (docs/BACKLOG.md item 8) wraps the handler body in a try/except, logs the exception, and returns the event unchanged — degraded mode where the user gets a token without custom claims (the API will then 403 cleanly), but the failure mode is visible.

Cognito token expiry. Cognito ID tokens expire after 60 minutes; returning to the tab after that lands on a cryptic 401. The 10-minute fix (docs/BACKLOG.md item 4) is auto-redirect on 401: clear the stored token, redirect to /sign-in. The better fix (also this week) is silent refresh via the 30-day Cognito refresh token. Both ship within the first week of the production cohort.

A pre-launch product does not have a production-debugging backlog. The backlog is the proof that the surface is real.

Three architectural choices that put CrewSheet on the right side of the operator-trust threshold

Vision over AWS Bedrock, not the consumer Claude API. Same enterprise-tier posture that put Day 10 CounselExpress on the right side of United States v. Heppner (SDNY, February 2026) — operator data (pilot PII, FAA certificate numbers, medical classes, route history) belongs inside an enterprise contractual envelope where Anthropic’s data-handling commitments apply, not on the consumer endpoint. Same model. Same vision quality. Different legal posture. Mandatory for a regulated-vertical product. The system prompt + adapter schema is cached at 1-hour TTL with a cross-region inference profile; the per-flight cost target clears under $0.05 across the typical 2-panel + 1-Hobbs pattern.

Validation by default, not by opt-in. The eight validation rules run on every extraction. There is no “skip validation” toggle. There is no “trust the model” shortcut. The rules are listed openly on the crewsheet.flights Specifications block — no hidden validation, no opaque scoring. Errors block PIC finalization; warnings surface inline. The override path requires a manually-entered reason and produces an audit-log entry. Same posture as a Part 135 chief pilot reading the sheet before it goes in the records — except the rules don’t get tired, don’t take Sundays off, and don’t drift over time.

Multi-tenant by construction, not by configuration. Every business table carries an operator_id foreign key. The Cognito pre-token-generation Lambda injects operator_id and role into the JWT custom claims on every authentication event. The SQLAlchemy OperatorScopedQuery mixin auto-scopes reads to the authenticated operator’s tenant boundary on every API call. There is no admin override path that crosses tenants. There is no service-account that reads multiple tenants. Cross-tenant data movement is not a configuration option — it is structurally absent from the system. Same discipline as the Day 19 PlanWright per-workspace tenant fence.

The thesis behind the launch — the operator at the cap table

CrewSheet sits inside Theme #4 of the 30-day run — the Autopilot economy, alongside the Day 16 NameIntel buyer-change proof and the Day 19 PlanWright supervisor-change proof. The Day 20 CrewSheet launch is the operator-validated-founder face of the same thesis — the third proof in the run, after Day 3 PartFoundry (Taylor Merrill / Aaron Vedlitz / Todd) and Day 9 CogleGroup (Jim Hasty / Todd), that the cap-table shape where the operator-domain expert sits at 50% (not at 5%) is the answer to why the Velocity Process clears 13-day delivery into regulated verticals when nothing else does.

The Substack dropping with the Day 22 WhatAreWeWearing launch this Friday — “The operator sits at the table at 50%” — names CrewSheet as the third proof of the pattern and writes through the structural argument. Three ventures into the pattern, the cap-table shape is no longer an experiment. It is the answer.

Ty Flippin is a Pilatus PC-24 Check Airman and a CRO consultant inside the TechCXO network. He works with the operators living the audit-records problem every day. He sent the email on April 27 because he is the customer. He is the co-founder because he is the customer who has the cap-table-level commitment to make the venture defensible to the next customer. The other two ventures in the pattern are the same shape: Taylor Merrill (plastics, Rubbermaid alum) at PartFoundry; Jim Hasty (the AI services GP partnership) at CogleGroup. CrewSheet completes the three-venture proof.

Pricing & business model

• Per-tail SaaS, structured so the unit economics fit a 1-tail owner-flown Cirrus and a 25-tail Part 135 fleet on the same product. The four-tier pricing structure is in the public schema.jsonld for search and LLM crawlers; the human-facing landing page surfaces design-partner pilot pricing rather than a self-serve table during the design-partner window. The design-partner conversation is the right shape for this stage of the venture — Ty fields the inbound at hello@crewsheet.flights and the tail-count-specific quote comes out of that conversation.
• Design-partner cohort opens today. Pilot pricing through the first 60 days in exchange for two 30-minute feedback calls a month, then step to a standard plan when the validation surface is settled. We are deliberately picking the early-access cohort for shape, not for volume — Part 91 / 135 operators flying a Day-1 supported panel who actually carry the audit obligation under 91.417 / 135.63 / 135.439 / 1.1.
• Revenue model: Per-tail SaaS. ARR scales with fleet size, not pilot count. The unit economics on the per-flight vision cost (< $0.05) clear even at the design-partner pilot-pricing tier; the unit economics on the standard plan clear with substantial headroom.

The Phase 2 list — Garmin G3000 / G5000, Honeywell Primus Epic, Collins Pro Line Fusion — opens the corporate-jet operator segment (Citation, Phenom 300, HondaJet, TBM, King Air 350ER, Falcon, Gulfstream), which is materially higher-value per tail than the Phase 1 GA glass-cockpit segment. The Phase 1 cohort is the proving ground; the Phase 2 cohort is where the venture clears the standard-plan economics.

The Velocity Process notes

What Claude Code handled across the 13-day production-build window: the Next.js 15 + React 19 + Tailwind v4 + shadcn/ui marketing surface and cockpit-tablet-optimized application UI at crewsheet.flights — landing, sign-in flow, operator dashboard, aircraft management, pilot management, flight detail page with the photo-upload-and-extraction-panel surface, audit-log viewer; the FastAPI 0.115+ backend (Python 3.12) — SQLAlchemy 2.x async models, Alembic migrations, Pydantic v2 schemas, the seven routers (auth, operators, aircraft, pilots, flights, images, exports), the OperatorScopedQuery mixin, the Stripe webhook receiver at /webhooks/stripe; the FastAPI worker — SQS long-poll loop, the panel-adapter routing layer, the validation-rule runner, the three exporters (PDF via WeasyPrint, ForeFlight CSV, CAMP CSV); the two panel adapters — HoneywellApexAdapter against the April 27 acceptance image as canonical regression input, GarminG1000Adapter against a reference set covering Cessna / Cirrus / Diamond / King Air B-series airframes; the AWS CDK v2 (TypeScript) stack on VelocityStack — six stacks (network, data, auth, api, web, worker) extending VelocityStack with mandatory tags and the auto-provisioned $500/mo budget alarm, deployed to the dedicated AWS account client-crewsheet-prod (867321193113, us-east-1, profile crewsheet-prod); the GitHub Actions OIDC deploy pipeline with the --platform linux/amd64 Docker buildx for Apple Silicon → Fargate; the Cognito pre-token-generation Lambda, the KMS-backed column encryption helpers for sensitive PII, the S3 bucket policies and lifecycle rules; the marketing-site tracking package (site/llms.txt, site/robots.txt, site/schema.jsonld, site/meta-tags.html with the GA4 placeholder pending).

What required human judgement: the partnership shape (50/50 vs. an operator-as-advisor model — Ty’s domain expertise and customer access aren’t “5% advisor” inputs, they’re the venture; the third proof of the operator-at-50% pattern); the decision to ship Garmin G1000 alongside Honeywell Apex on Day 1 rather than holding to a strict PC-24-only Phase 1 (the panel-adapter pattern’s whole point is it generalizes, and shipping a second adapter on Day 1 is the proof — same Bedrock model, same JSON schema, different system prompt per panel; the addressable fleet expanded from “Pilatus PC-24” to most of the GA glass-cockpit world); leading the launch with the operator-validated founding team rather than feature copy — operator-validated founding is the defensible moat in a regulated vertical and feature copy isn’t; the precise wording around SOC 2 / FedRAMP / HIPAA — CrewSheet is not certified at launch; the audit-log-on-every-state-change is a product claim that the audit-chain evidence shape is structurally complete, not a certification claim about CrewSheet itself.

What broke — and what the readiness pass caught: three integrity problems made it into the late-stage launch surface and were pulled before go-live. (1) The marketing-site source files (site/schema.jsonld, site/meta-tags.html, site/robots.txt) carried the old crewsheet.com domain references from before the .com unavailability was confirmed and the .flights registration landed on May 10. The deployed Next.js metadata at crewsheet.flights was correct (different source); the unbuilt static files were stale. The Day 14 GEOPress stale-domain sweep precedent applied — the source-of-truth hygiene fix swept all three files before 7:00 AM ET on launch day. (2) The live landing page initially carried a “Director of Operations · Part 135 fleet · 6 tails” attributed testimonial that was a copywriting placeholder, not a real operator quote — same class as the Day 14 GEOPress fabricated-testimonials catch and the Day 15 Swole Labor fabricated-reviews catch. The readiness pass caught it; the testimonial was reframed to a Picture this. aspirational scenario with no attribution line, and the section heading was changed from “From the field” (which signals customer voice) to match the editorial typographic treatment elsewhere on the page. (3) The live landing page Specifications block initially called Garmin G1000 a Phase 2 item even though the G1000 adapter had shipped to production the night before. Three landing-page strings (editorial header, Target-aircraft row, Phase 1 design-partner CTA) were updated to put G1000 on the Day 1 list — same architecture-claim hygiene posture the Day 19 PlanWright “the audit chain is the product, not a feature flag” discipline applies.

What I’d do differently: lock the domain before any tracking-package source file is generated. The crewsheet.com → crewsheet.flights sweep in site/schema.jsonld, site/meta-tags.html, and site/robots.txt is 10 minutes of work that didn’t have to exist if the domain registration had landed before the tracking package was authored. Add to the Velocity Process checklist: register the domain before writing the schema.jsonld, even if the product name is still under name-validation review. Also: ship the staging environment alongside the prod deployment, not as docs/BACKLOG.md item 2 — eight days of “deploy and pray” was workable for the launch window but is not workable for the Phase 1 design-partner cohort going forward, and staging.crewsheet.flights is the next infra investment.

What’s next this week

• Day 20 (today): crewsheet.flights is live; the Honeywell Apex and Garmin G1000 / G1000 NXi panel adapters are both shipped; the eight-rule validation engine is running inline on every extraction; the three exports (PDF + ForeFlight CSV + CAMP CSV) are generating from one source of truth; the Cognito Hosted UI + Stripe webhook receiver + audit log are live in production; eight days of production debugging is published in the build feed as proof of life.
• Day 21 (Thu May 21): PatentFlow. The Regulated Legal arc reopens (Day 10 CounselExpress was the first leg) — same enterprise-tier-vision and audit-chain-by-construction posture, different vertical. Stephen + Virginia + Todd are co-founders; the USPTO MCP server with 51 tools is the architectural anchor.
• This week — Phase 1 punch list (sourced from docs/BACKLOG.md in the CrewSheet repo): Cognito 401 auto-redirect (10-minute fix); GA4 property populated on crewsheet.flights; pre-token Lambda try/except defense-in-depth around the invalid_grant-masking failure mode; Apex prompt tightening for the Hobbs-vs-flight-time disambiguation per the May 12 production bug; delete-image endpoint + × button for orphan failed extractions; integration test pack (5 fixtures, one per external boundary — Cognito ↔ API, Worker ↔ Bedrock, Stripe webhook, S3 presigned URL, pre-token Lambda); staging environment at staging.crewsheet.flights; CloudWatch dashboard for the vision pipeline (job rate, success/failure ratio, p50/p95 latency, Bedrock token consumption, confidence distribution, queue depth, DLQ depth).
• Design-partner conversations: Ty’s first-call list runs through the week. Goal by Day 27: first paying operator onboarded with ≥10 flights logged end-to-end and Stripe billing converted from pilot pricing to a standard plan. The Phase 1 acceptance criterion in docs/CrewSheet_Technical_Design.md §9 — “First design partner has logged ≥10 flights end-to-end without intervention from Silverback engineering” — is the metric the week is measured against.
• Phase 2 list: Garmin G3000 / G5000 (Citation, Phenom 300, HondaJet, TBM 900-series, King Air 350ER), Honeywell Primus Epic (Falcon, Gulfstream), Collins Pro Line Fusion. Phase 2 design-partner outreach opens after the Phase 1 acceptance criterion is met.

Want to talk

If you fly any of these airframes — Pilatus PC-24 or PC-12 NGX, Cessna 172/182/206/208 Caravan, Cirrus SR22, Diamond DA40/DA42/DA62, or King Air B200/B250/B350 — your panel is supported today. Sign up at crewsheet.flights and start logging flights this afternoon. The design-partner cohort opens today.

If you fly a Citation, Phenom 300, HondaJet, TBM, or King Air 350ER on a Garmin G3000 / G5000 panel, you’re at the front of the Phase 2 list. Email hello@crewsheet.flights with your tail number and panel type and we’ll slot your panel adapter in the right order.

If you operate a Part 91 or Part 135 fleet of any size — corporate flight department, charter operator, fractional, owner-operator — Ty Flippin is the right first call. ty.flippin@techcxo.com. Ty is a Pilatus PC-24 Check Airman and a CRO consultant in the TechCXO network; he carries the operator-side cap-table commitment that makes the design-partner conversation a real conversation, not a sales call.

CrewSheet is co-built 50/50 with Ty Flippin and lives inside the Autopilot-economy thesis the rest of the 30-day run is organized around. Live today at crewsheet.flights. Tomorrow: PatentFlow — the Regulated Legal arc reopens.