Portfolio Worker Architecture

TattooAPI does not depend on a local computer or tunnel for production portfolio intake. The v1 operating model separates the public API, temporary media staging, private workers, review, and approved portfolio storage.

Public apps and webhooks
  -> hosted TattooAPI HTTPS API
  -> private object storage for staged media
  -> private worker review systems
  -> classification and workflow packaging
  -> human review
  -> approved portfolio storage
  -> governed projections through TattooAPI

Review-gated surface: this workflow can stage evidence and prepare review records, but it cannot publish, promote, or write approved portfolio data without TattooAPI policy checks and human approval.

Private workers cannot write directly to approved portfolio storage, mutate canonical runtime tables, activate public surfaces, change identity mappings, or publish inbound media. They return classification and review evidence to TattooAPI.

Hosting Roles

Layer	v1 posture	Notes
TattooAPI public API	Hosted HTTPS API	Receives communication webhooks, owns policy, review, projection, and approved write services
TattooAPI runtime	Runtime truth after governed promotion	Does not receive direct inbound text-message mutations
Object storage	Private staging	Stores raw/staged media privately with lifecycle rules
Communications buffer	Inbox and conversation history	Keeps artist-facing SMS/MMS conversation history and manual inbox context
Private workers	Private persistent compute	Run classifier jobs and future specialist review tasks
Approved portfolio storage	Reviewed portfolio/media lake	Receives only reviewed assets with ownership, lineage, rights, consent, and distribution posture
Specialist review tools	Optional research support	Review-only legal/compliance research, never canonical authority

Worker Model

Start with one private worker. Add more during onboarding bursts:

worker-01: communication intake hydration
worker-02: image classification and tag/caption suggestions
worker-03: source-pack or social hydration
worker-04: legal/compliance review evidence

Workers should use TattooAPI rules/context and return evidence to TattooAPI. They should not be treated as public API hosts or canonical storage.

Storage Rule

Raw originals should not live only on a worker filesystem. Use private object storage prefixes such as:

portfolio-intake/
  highlevel/
    pending/YYYY/MM/DD/<intakeId>/<providerMessageId>/
    classified/YYYY/MM/DD/<intakeId>/
    rejected/YYYY/MM/DD/<intakeId>/
    approved-raw/YYYY/MM/DD/<intakeId>/

Use signed/private access and lifecycle retention for staged media. Long-term curated portfolio records belong in the approved portfolio lake after review.

Public Docs Boundary

Public docs can explain the architecture and contracts. They should not include:

real provider IDs
private phone numbers
bucket endpoints
access keys
communication provider tokens
approved storage tokens
partner or worker API keys
local private network URLs
raw media staging URLs

Start Here

Research Archive

Platform Readiness

Portfolio Worker Architecture

Portfolio Worker Architecture

Hosting Roles

Worker Model

Storage Rule

Public Docs Boundary

​Portfolio Worker Architecture

​Hosting Roles

​Worker Model

​Storage Rule

​Public Docs Boundary

Portfolio Worker Architecture

Hosting Roles

Worker Model

Storage Rule

Public Docs Boundary