0pt — your data

Data services on demand for the Nordics + Europe. Compose a data job, pay 50 % to start, watch production live, validate with full provenance, deliver anywhere. Owned by SIAX Technology AB. Honest accuracy is the moat: every field carries source, freshness and confidence; nothing is guessed.

Live: https://0pt.app · Contract: CLAUDE.md + docs/

Two planes (see docs/02-architecture.md)

• Edge (Vercel, this app) — marketing, catalog, the order lifecycle, customer portal, admin portal, and the API route handlers. Defers to the data engine when ENGINE_URL is set.
• Engine (services/api, runs on a VPS) — FastAPI orchestrator + worker pipeline doing the compliant sourcing (official API → bulk → authorized web → licensed → else level 0). Never on Vercel (long jobs). Bypass/stealth/proxy-rotation/fake-account paths are excluded by design (CLAUDE.md §1).

Routes

Area	Routes
Marketing	/ (hero, filosofi, katalog, motorn, visualiseringar, täckning, editorial, bevis, priser, footer)
Catalog	/katalog, /katalog/[id]
Sourcing map	/kallor
Order lifecycle	/bestall → /bestall/beskriv → /bestall/forskott → /order/[id] → /order/[id]/validera
Customer portal	/portal, /portal/subscriptions, /portal/files, /portal/integrationer, /portal/settings
Admin portal	/admin, /admin/sources, /admin/jobs, /admin/customers, /admin/verktyg
API	/api/{health,estimates,catalog,sources,vehicles,screen,orders,orders/[id],subscriptions,admin/metrics,uploads,auth/*,ai/parse,payments/*,webhooks/stripe,connections/db-grant}
Data platform (P0)	/api/0pt, /api/0pt/documents/capture, /api/0pt/documents/[documentId]/extraction, /api/0pt/lakehouse/mappings[/[mappingId]/writes], /api/0pt/sources/[sourceId]/query, /api/0pt/sources/rate-policies[/[id]] — ⚠ these read tenant_id/project_id from the request body or query string, not a server session. See Known issues below.

Design system

Mono/editorial, light, radius 0, Inter + JetBrains Mono, single red #e40014, animated grain, scroll-reveal motion. No photography — imagery is rendered data (DataArtifact). Every fact shows a provenance square (ProvenanceBadge). Full spec: docs/05-design-system.md.

Run locally

pnpm install
pnpm dev                       # Next.js on http://localhost:3000

# data engine (separate, optional)
cd services/api && pip install -r requirements.txt && uvicorn orchestrator.main:app --reload

Deploy

• Frontend → Vercel (project 0pt, scope Simon Axelsson's projects), domain 0pt.app.
• Engine + DB + embeds → one VPS via infra/docker-compose.yml (Postgres+pgvector, Redis, api, worker, NocoDB, Metabase, Caddy).
• Env inventory: .env.example — not on main yet. It exists on branch/PR feature/0pt-env-example (github.com/sax3l/0pt PR #3, unmerged as of this pass), added after discovering .gitignore's blanket .env* rule had silently kept it out of every commit despite docs/09-build-plan.md Phase 0 requiring it. Until that PR merges, use docs/08-infrastructure.md as the source of truth for env var names.

Status

Frontend (marketing, catalog, order lifecycle UI, customer + admin portals) and the edge API route handlers build and typecheck green. That is a statement about the code compiling and running, not about the platform being production-ready — read Known issues below before relying on any of this against real tenants or real money.

Integrations are env-guarded and activate when their keys/DB are provided:

1. Database — Vercel → Storage → Postgres (sets POSTGRES_URL) → durable persistence (schema in sql/001_init.sql). Without it, orders fall back to an in-memory, non-durable store (lib/orders-store.ts).
2. Stripe keys → payments (app/api/payments/*, app/api/webhooks/stripe) — this is wired code, not just a plan. Resend is documented as the email provider (docs/08-infrastructure.md) but has no call site anywhere in this repo yet — treat "+ email" as not-yet-implemented, not merely unconfigured.
3. VPS for the engine (services/api) → set ENGINE_URL so edge routes defer to it (lib/engine.ts). Unset, several routes (/api/screen, /api/vehicles, /api/ai/parse) fall back to calling public sources directly or computing locally instead.
4. AUTH_SECRET + DEV_LOGIN_KEY → a guarded dev-only login (app/api/auth/login/route.ts): an HMAC-signed session cookie (lib/auth.ts), not a real auth system. Full OAuth via Auth.js is Phase 3 of docs/09-build-plan.md and has not been built — see Known issues.

Known issues

Blunt on purpose, per CLAUDE.md's own house rule ("flag conflicts ... and propose the reconciliation rather than guessing"). These are open, real gaps as of this pass — not silently patched, not guessed at.

1. No authentication or tenant scoping is wired anywhere in this repo. The only thing that exists is the DEV_LOGIN_KEY dev gate described above. There is no session-to-org/tenant binding at all — app/api/orders/route.ts's own GET handler carries the literal comment // GET /api/orders — list (org scoping added with auth)., i.e. not yet. As a direct consequence, the newer P0 data-platform routes read tenant_id/project_id from the client-supplied request body or query string instead of a server-bound session:

   • app/api/0pt/lakehouse/mappings/route.ts and .../[mappingId]/writes/route.ts
   • app/api/0pt/sources/rate-policies/route.ts and .../[sourceRatePolicyId]/route.ts
   • app/api/0pt/sources/[sourceId]/query/route.ts
   • src/services/document-capture-service.ts (called from app/api/0pt/documents/capture/route.ts)

   This violates the platform-wide hard rule that tenant_id must be server-bound to an authenticated session and never read from client input. It is not a deliberate two-tier design — it exists because no auth/session system has been built yet. Do not expose these routes to untrusted callers before Phase 3 (docs/09-build-plan.md) lands.

2. The CL0UD/N0D/AUD0/ST0RE platform clients are real code, but mock-only. src/clients/{cl0ud,n0d,aud0,st0re,st0re-lakehouse}-client.ts are genuine, typechecked TypeScript with real tests — but every one of them runs against an in-memory mock today. Corrected this pass: CL0UD_URL/N0D_URL/AUD0_URL/ST0RE_URL are never read via process.env anywhere in this repo — verified by grepping the whole tree; the only hits are a code comment and a TODO/it.todo in tests/p0/iceberg-write-service.test.ts describing ST0RE_URL as future work, not an actual read. Every client only accepts an optional constructor baseUrl (st0reBaseUrl, cl0udBaseUrl, n0dBaseUrl, aud0BaseUrl), and every service that instantiates one (src/services/*.ts) is called from its route handler with no options, so all of them resolve to the in-memory mock today. Read this as "real code, mock-only, not live-verified, no env wiring at all yet" wherever it comes up — not "integrated" or "connected."

3. 0pt's data-quality/QA enforcement code does not exist in this repo. src/services/quality-check-service.ts, src/services/quality-report-service.ts, src/types/quality-check.ts, src/types/quality-report.ts, src/data-platform/services/catalog-service.ts, sql/002_p0_dataset_quality.sql, and sql/003_*.sql were at one point described, in docs/ICEBERG_WRITE_BOUNDARY.md, docs/11-lakehouse-write-plan.md, and docs/P0_QUERY_SOURCE_FLOW.md, as if they were already built and tested. git log --all for every one of those paths returns zero commits, on any branch, ever — they have never existed in this repository; the sql/ directory today holds only 001_init.sql and 004_iceberg_write_boundary.sql. 0pt's QA/quality-check stage is spec/target only right now. Corrected as of this pass: all three of the docs above, plus docs/12-edge-capability-api.md, now consistently state this — each carries its own "fabricated, not built" callout, and docs/P0_DATASET_QUALITY_FLOW.md (added by an earlier parallel pass) is the explicit, clearly-labeled target-spec doc for what this stage should look like once built. Treat any other doc that asserts the QA stage already exists as wrong until it actually lands.

4. Two diverged git remotes both claim to be "the 0pt repo." origin in this checkout is github.com/sax3l/0pt. A separate Gitea remote, git.siax.io/sax3l/0pt, shares at least part of the same history — services/api/workers/adaptive_router.py is byte-for-byte identical between GitHub's current main and a Gitea post-fix PR branch — but Gitea's main independently accumulated three 2026-07-13 commits adding a real WAF-bypass/proxy-rotation/fake-identity scraper stack (services/scrapers/*, since removed via a Gitea PR) that never touched GitHub's main. Which remote is authoritative, which is deployed to 0pt.app, and whether the two should be kept in sync is unresolved — Simon's decision, not something this pass or any doc should silently assume.

5. 0pt is registered as API-only in the platform's six-surface capability model, not "api/cli/mcp/ui/job/sdk" across the board. 14 0pt.* capabilities are registered in cl0ud's packages/capability-registry/src/registry.ts today (verified by name: query_source, document_ocr, write_external_record, lakehouse_mapping_manage, lakehouse_write, source_rate_policy_manage, screen_sanctions, estimate_compute, vehicle_lookup, catalog_list, source_registry_list, order_create, order_payment, write_iceberg_table). None has cliEnabled/mcpEnabled true. Surfaces, checked per-entry: 11 have ['api'] only, lakehouse_write and write_iceberg_table have ['api', 'job'], and write_external_record has ['job'] only (no api surface at all) — so it is not quite "api everywhere plus job for the two heaviest," one capability is job-only. If any doc anywhere describes a live siax 0pt ... CLI or an 0pt MCP tool, it is describing a target, not current reality.

6. No evidence a "t_0pt" dedicated-node N0D auth pattern is built. sax3l/n0d was searched in full (all branches, all commits, all files) — zero references to t_0pt exist anywhere in that repo. Treat any claim that this is already built/tested as unconfirmed.

© 2026 SIAX Technology AB. Not affiliated with Protosell.