Log in Book a demo
How it works

From dockside to delivered report.

Every step in the SurveyOS pipeline, in the order it actually happens. Built for the field reality of marine inspection — not a generic forms app retrofitted for boats.

  1. 01
    Phase 1

    Set up the vessel

    Every inspection attaches to a vessel record. SurveyOS uses a vessel-centric architecture — not session-centric like other tools — so a 1984 Egg Harbor 35.5 with twin Cat 3208T engines carries its full history forward: prior inspections, service records, component-level hours, standards references.

    • Create or import the vessel with HIN, builder, model, dimensions, propulsion type
    • Add components with nested hierarchy (engines, transmissions, shafts, fuel tanks, electrical)
    • Each component tracks its own serial, hours, service interval, and longitudinal history
    • Templates auto-match the vessel category — inboard-diesel sportfish vs. sailing vessel vs. outboard
  2. 02
    Phase 2

    Capture in the field

    On the tablet. Single-checkpoint focus. Works offline. Every answer, every photo, every measurement gets captured with a timestamp, actor, and device — before anything leaves the dock.

    • Sessions materialize all checkpoints upfront so the full inspection is available offline
    • Photo capture includes SHA-256 anchoring on the device before upload
    • "Not inspected" requires a reason — enforced in the UI and by database constraint
    • Findings flagged during inspection pull observation text forward automatically
    • Sea-trial data captured in structured snapshots: RPM, speed, oil pressure, coolant temp, boost, EGT, smoke note
  3. 03
    Phase 3

    Findings with structure

    A finding in SurveyOS has three required fields: observed fact, inferred cause (optional but labeled), and recommendation. Severity and impact classification are required. Evidence sufficiency is evaluated — CRITICAL and HIGH findings without attached photos get flagged at report time.

    • Severity tiers: CRITICAL · HIGH · MEDIUM · LOW · WATCH
    • Impact types: SAFETY · SEAWORTHINESS · COMPLIANCE · VALUE · INSURANCE_READINESS · COSMETIC · PERFORMANCE · MAINTENANCE
    • CRITICAL findings require at least one risk impact or explicit business impact — enforced by validation
    • Standards references attach by family + key (ABYC · NAMS · SAMS · OEM) without reproducing copyrighted text
    • Supersession preserves lineage — a reopened finding links back to its original bidirectionally
  4. 04
    Phase 4

    Compose reports

    One inspection, multiple deliverables. The report composer applies scope filters for each audience — the insurance report excludes cosmetic and maintenance items; the pre-purchase survey includes everything except strictly-cosmetic; the mechanic assessment focuses on performance and maintenance. All from the same source findings.

    • Mechanic Assessment · Pre-Purchase Survey · Insurance Readiness · Owner Readiness · Appraisal · Damage · Claim Packet
    • Permission-gated: a mechanic cannot issue a pre-purchase survey; a surveyor can issue any report kind
    • Each report issuance freezes the payload with a SHA-256 content hash
    • Reissuing the same kind increments version and supersedes the prior
    • Evidence referenced by an issued report is auto-frozen — any attempt to modify it hits a DB trigger
  5. 05
    Phase 5

    Work orders without retyping

    Findings convert directly to work-order lines. Every line preserves the source finding ID — traceability upstream stays intact. Work completion writes to service history automatically. Findings stay open until a surveyor explicitly resolves them after reinspection — auto-close is never the default.

    • Severity-driven urgency suggestion (CRITICAL → IMMEDIATE, requires approval before work begins)
    • Mechanic tier can convert findings and complete work; inspector tier cannot
    • Completed work auto-writes a ServiceHistoryEntry per line, categorized by type
    • Reinspection flow supports verification before resolve — optionally with before/after evidence
  6. 06
    Phase 6

    Audit, deliver, integrate

    Every state change writes an append-only audit row at the database level. Reports deliver as PDF, DOCX, or HTML bundle. Partner firms on Firm and Enterprise tiers get API access for integration with claims systems, CRM, and policy-binding workflows.

    • Append-only audit: DB trigger refuses UPDATE/DELETE on audit_events
    • Exports ship as CSV + JSON with the content hash preserved for tamper-evidence
    • Webhooks fire on engagement.created · finding.added · report.issued · work_order.completed
    • REST API with tenant-scoped tokens, RLS-enforced access
    • SSO / SAML on Firm and Enterprise tiers
For technical evaluators

Built on a foundation your security team will approve.

Postgres 16Managed, encrypted at rest. Row-level security enforced for every tenant-scoped table.
TypeScript end-to-endSame types from database to tablet UI. Zod validation at every API boundary.
Next.js 14 · App RouterServer components, streaming responses, native offline capabilities via service workers.
S3-compatible evidenceAWS S3, Cloudflare R2, or bring-your-own via presigned URLs. SHA-256 anchored.
Append-only auditDB trigger refuses any UPDATE or DELETE on audit_events. Export-friendly.
RBAC with blended roles7 roles × 40+ actions. Principals can carry multiple roles — surveyor + mechanic on one person.

See the whole pipeline on a real vessel.

20-minute walk-through, no slides. Field capture → findings → four reports.

Book a demo See outputs first