> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tattoo.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Data Hydration Source Packs

> How first-party and approved media data moves into TattooAPI without broad scraping or unsafe promotion.

# Data Hydration Source Packs

TattooAPI hydrates real-world tattoo data through source packs first, then review, then canonical runtime promotion.

The current rule is:

* source data is evidence
* reviewed candidates are promotion inputs
* TattooAPI canonical tables are runtime truth
* raw exports do not rename ontology nouns

Portfolio data has an additional rule: it is a core creative proof pillar. A portfolio image is not ready for reuse just because it exists in an approved media source. It must carry source lineage, owner tenant, artist attribution, rights posture, consent posture, review state, and distribution eligibility before TattooAPI can project it to Studio OS, Artist OS, websites, tattoo.co, partners, API guidance, or external discovery surfaces.

## Current Inputs

| Source                         | Current posture                                                                                               | What it can affect                                                                    |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| First-party sheets             | Row extraction and directory hydration are staged and verified                                                | `Studio`, `ArtistProfile`, source references, promotion links, law/compliance staging |
| Managed-studio media sources   | Connection registry exists, extraction is blocked until approved project IDs and token aliases are configured | `PortfolioAsset`, `Design`, linked artist/studio evidence                             |
| Existing local creative packs  | Canary promotion is active for a small reviewed cohort                                                        | `PortfolioAsset`, `Design`, creative source lineage                                   |
| Ontology refinery law canaries | HI/NV and CA/TX/NY/FL/WA source packs are staged/review-ready                                                 | Jurisdiction, law, citation, and bloodborne-pathogen requirement review inputs        |
| Law sync diff reports          | Same-cohort diffing is active for refresh detection                                                           | Review warnings for new, changed, missing, and unchanged citation units               |
| External research sources      | Delayed for broad import                                                                                      | Named gap-filling only after reviewed cohorts exist                                   |

## Current Counts

The current checked-in hydration reports show:

* `71,080` first-party rows extracted
* `63,209` promotable directory rows
* `28,894` expected canonical studio profiles from directory sync
* `3,996` expected canonical artist profiles from directory sync
* `5` promoted creative canary candidates
* `3` managed-studio media connections scaffolded
* `0` media-source tokens stored in reports or git
* `27` HI/NV law-compliance canary rows in the current refresh candidate
* `26` CA/TX/NY/FL/WA law-compliance canary rows staged from official sources

## Promotion Rules

Directory hydration is non-destructive:

* non-empty incoming fields can improve canonical records
* blank incoming values must not erase existing canonical values
* every promoted record needs an `externalSourceReference`
* every promoted record needs a `canonicalPromotionLink`

Portfolio hydration is managed-studio only:

* tokens live only in local env aliases
* registry files store the alias name, not the token value
* published media records can promote only when studio and artist identities resolve
* drafts, unresolved artists, and missing rights/consent posture stay staging-only

Law and compliance hydration is source-pack first:

* external acquisition nodes produce official-source records and run manifests
* ontology guidance can validate lane, noun, required field, and review-queue posture
* staging uploads write source-pack files only
* diff reports show new, changed, missing, and unchanged citation units
* missing rows are review warnings, not deletion instructions
* public legal advice and canonical runtime promotion remain disabled until operator approval gates exist

## Operator Verification

Internal operators use repo-native inventory, preview, and verifier gates before any promotion. Public docs describe the contract and boundaries; internal command names, staging paths, provider identifiers, and token aliases stay out of the public surface.

## What Not To Do Yet

* Do not broad-scrape the market into canonical runtime tables.
* Do not promote media records when artist identity is unresolved.
* Do not expose media-source tokens through API responses, docs, reports, or runtime records.
* Do not activate public writes or public SEO pages from staged evidence.
* Do not treat law sync diffs as automatic legal updates.
* Do not let external scraping apps write directly to TattooAPI runtime.

The deeper repo source of truth is `project-context/ontology/governed-hydration-sprint.md`.