Explainable, in-process image processing
CivicSet runs its two products in-process on the server. No black-box services, no external tool plane, just well-specified compute with clear inputs and outputs.
What guides us
Explainable by Design
Every result carries its metrics, alignment error, similarity, and distance, so outputs can be reviewed rather than trusted blindly.
Focused, Not Sprawling
Two products, done well. We concentrate on super-resolution and facial verification rather than a long tail of half-finished tools.
In-Process by Default
Compute runs inside the web runtime. There is no external tool plane, no separate deployment, and no hidden service behind the result.
Privacy-Respecting
Facial Verification is 1:1 only. There is no database matching surface and no identification of people from imagery.
System architecture
A layered, in-process pipeline for the two products.
Input layer
Authenticated uploads and base64 payloads validated against typed contracts.
Validation layer
Zod schemas enforce size caps and required fields before any compute runs.
Compute layer
Server-only TypeScript engines for super-resolution and facial verification.
Result layer
Structured, explainable outputs: alignment error, similarity, distance, and metrics.
Storage layer
Account-scoped Supabase Storage buckets for private media and avatars.
Access layer
Row-level security and account tenancy across every request.
Integration and fit
CivicSet is a focused API surface that fits into existing image and identity workflows.
Typed request contracts
Each product has a Zod schema defining its inputs and outputs.
Standard image formats
Frames and faces are exchanged as base64 images with standard encodings.
Account-scoped storage
Private media is stored under account-scoped keys in Supabase Storage.
Role-based access
Row-level security and account tenancy govern who can read results.
In-process compute
No separate service to deploy: products run inside the web runtime.
Security and governance
Encrypted in transit and at rest
All data travels over TLS and rests in Supabase-managed storage.
Row-level security
Database access is scoped to the authenticated account and team.
Account tenancy
Object keys and records are scoped by account_id.
Size and resource caps
Input and output pixel limits bound compute per request.
No identification surface
Facial Verification is 1:1 only. There is no database matching.
Two products,
in the works
Multi-Frame Super-Resolution and Facial Verification are in active development. Leave your email and be first to know when they launch.