Project Status
TattooAPI is currently in the internal-runtime and operator-proof phase. The ontology is broad enough to guide the product, but the public surface should stay narrow until runtime authority and operator workflows are proven.This page is a public-facing status summary. The repo control plane remains the source of truth:
project-context/ontology/platform-wave-roadmap.md, project-context/ontology/overnight-execution-workboard.md, and the PRD under project-context/TattooAPI - Vision + Ontology.Current Wave Posture
| Wave | Status | Meaning |
|---|---|---|
| Wave A | Closed | Source-backed ontology nouns, source-pack structure, and lane scorecards are established. |
| Wave B | Contract-complete enough | Deterministic functions, action vocabulary, and execution contracts exist for the internal platform layer. |
| Wave C | Contract-complete enough | Policies and workflow contracts exist for runtime-governed execution. |
| Wave D | Active | Convex runtime adoption, internal SDK convergence, and legacy runtime isolation remain the main bottleneck. |
| Wave E | Active | Internal operator workbenches are live against Convex-backed runtime truth and are being proven through executed loops. |
| Wave F | Blocked; readiness only | Public read SDKs, read envelopes, and website/free-tool concepts are being designed, not launched. |
| Wave G | Planned; manifest readiness only | Governed dataset manifests can be prepared from operator history, but harvest remains gated. |
| Wave H | Planned; evaluation readiness only | Tattoo intelligence tasks can be specified and evaluated later, with no model training dependency yet. |
Runtime Truth
The target runtime is self-hosted Convex. The current local checkpoint is green onconvex_self_hosted, with Wave D runtime, Wave E operator, Kinetic Engine, API build, and Wave D guardrail checks passing.
The active cutover goal is simple:
- Convex is the normal read and mutation authority for internal runtime execution.
- File-backed runtime state is limited to bootstrap, degraded fallback, fixture, and maintenance compatibility use.
- Supabase-backed routes are legacy unless explicitly cut over to the runtime adapter or internal Convex admin surface.
- Internal SDK roots should expose operator-safe reads and mutations by default, with maintenance and reseed helpers kept behind explicit compatibility entrypoints.
- Some D3 routes are method-boundary cutovers:
GETreads may be runtime-backed whilePOST,PUT,PATCH, orDELETEremain explicitly blocked or legacy-only until a governed internal Convex mutation contract exists.
Auth And Access
WorkOS is the default authentication authority for authenticated and internal-beta access.- Human/team access uses WorkOS/AuthKit bearer tokens.
- Machine and agent access uses WorkOS API Keys through
X-API-Key. - Convex maps verified WorkOS identities to TattooAPI actors, roles, studio scopes, and artist scopes.
- Valid WorkOS credentials without an active TattooAPI actor mapping return
403. - Local TattooAPI API key management is retired in WorkOS mode and returns
410. - Public writes remain blocked.
Public Boundary
The public API and docs should stay conservative while Waves D and E close.- No public write expansion.
- No public ranking formula API.
- No public proof, legal, or compliance mutation path.
- No public SDK launch until read envelopes and operator governance are proven.
- Public discovery docs should describe only supported current behavior.
- Kinetic Engine descriptors can describe internal actionability, blocked states, and governed route paths, but they do not expose public execution.
Access Model
TattooAPI should be read as a projection-based platform, not a flat public/private API.- Public projections are redacted, publish-state-aware, and rights-cleared.
- Future owner-scoped writes belong on explicit authenticated owner route families, not broad public writes.
- Participant-scoped data such as bookings, sessions, quotes, and transaction posture should not become broad public read data.
- Operator projections remain internal for trust, proof, compliance, ranking, legal, and canonical workflow authority.
- Another studio should not see another studio’s draft or unpublished portfolio assets, raw model observations, private pricing data, or client/session records.
Cross-Wave Programs
Several programs now span the waves without creating new ontology noun families:- Marketplace trust, ranking, transaction-readiness, and portfolio proof.
- Pricing and financial-infrastructure depth on existing quote, payment, payout, financing, and market-economics nouns.
- Portfolio Hydration V1 for Sanity CMS, CRM exports, GPT Vision metadata observations, and Firecrawl or Perplexity evidence, all staging-only until operator approval.
- Future SDK, website, free-tool, tattoo.co integration, guest-spot marketplace, governed delist intake, and Ghostline or Tattoo Sketch ideas.
Wave F+ Gate Summary
Wave F+ work should proceed as readiness and preview until activation gates are met.- Wave F: public read envelopes, SDK/tool contracts, public page candidates, and free-tool concepts stay read-only and preview-only.
- Wave G: governed datasets require review lineage, rights posture, consent posture, and auditability before harvest.
- Wave H: intelligence tasks can be specified and evaluated, but no model training starts without governance-cleared data.
Studio, ArtistProfile, PortfolioAsset, and Design data, not broad public mutation or unreviewed scraping.
See Future Wave Gates.
What To Build Against Today
Use the current public read surface and treat it as transitional:Usable This Week
Public no-auth reads (promoted):GET /healthGET /studios
- runtime docs metadata
- legacy auth compatibility routes
- Stripe webhook ingress
- search autocomplete helper
GET /search
GET /artistsGET /artists/[id]GET /portfoliosGET /portfolios/[id]GET /designsGET /designs/[id]
GET /me/portfolio-assetsGET /me/portfolio-assets/[id]GET /me/designsGET /me/designs/[id]
Hydration Status
The next data priority is governed first-party hydration, not broad scraping.- Google Workspace row extraction is staged with
71,080rows. - Google directory hydration is verified with
63,209promotable rows. - The current sync reports expect
28,894canonical studio profiles and3,996canonical artist profiles with source lineage. - Creative canary promotion has
5selected candidates in canonicalPortfolioAssetandDesignrecords. - External law/compliance canaries now flow through the Ontology Guidance MCP and source-pack staging as review-ready artifacts only.
- Current law sync packs include HI/NV and CA/TX/NY/FL/WA citation-backed canaries plus Git-like diff reports for same-cohort refreshes.
- Sanity managed-studio connections are scaffolded for selected tattoo.agency-managed studios, but extraction remains blocked until real project IDs, datasets, and local token env aliases are configured.
- Sanity tokens are not stored in git, docs, reports, API responses, Mastra, or Convex.
Internal Agent Runtime
Mastra is now adopted as the internal supervised-agent runtime for Wave E work.- Convex plus the internal SDKs remain canonical runtime authority
- Mastra uses a mixed-maturity agent registry: five fully wired agents and the rest scaffolded but visible in Studio
- Runtime mutation tools are approval-gated and default to dry-run
- Local Studio and Swagger endpoints are internal development infrastructure, not public API products.
