ETS data model (proposed, v0.1)

Proposed schema for the ETS27 site and its AI concierge, with the mapping back to WordPress, Whova and Eventbrite. Written 2026-10-13.

Companion files: ets-content-inventory.md (what exists today and the evidence) and ../prototype/data/ets.sample.json (a fixture that follows this model). Field names below are the fixture's field names unless a row says "production only".

1. Principles

1. Per-edition facts, stable identities. A person is stable; their title, employer, bio and photo are not. Model Person once and Appearance per edition. The fixture flattens one edition (ETS26 stand-ins) and keeps the WordPress archive record under wp.
2. One source of truth per field. Staff edit speakers, FAQ, venue and hotel in WordPress and the agenda in Whova. Anything the front end or concierge builds from them is a disposable snapshot, never a second editable copy (human-operable parity).
3. Honest gaps. An unknown value is null with a status, never an invented value. Stand-in data carries placeholder: true and a basis.
4. Readable ids. spk-greg-brown, ses-d2-1330-breakout-a, spn-itron, tkt-industry-phase1. A model can cite them, and a person can read them in a log.
5. Plain text at the boundary. WPBakery shortcodes, HTML and entities are stripped when data enters the model.
6. Time. ISO date, local 24-hour HH:MM, one event timezone (America/Chicago).
7. One-hop answers. Every entity must answer its visitor questions (section 4) from its own fields or its direct references. If answering needs a two-hop join, add a field.
8. Only announced data reaches visitors. Production adds a status (invited, confirmed, announced, withdrawn) to speakers, sessions and sponsors; the public front end and the concierge read announced only.

2. Entity map

Edition (event) 1--* Day 1--* Session *--* Appearance *--1 Person
     |                          |  |            (speaker or moderator)
     |                          |  +-- type: SessionType (format: keynote, panel ...)
     |                          +----- track: Track (theme, optional)
     |                          +----- room: Room (in Venue)   sponsor_ids: Sponsor
     +--1 Venue 1--* Hotel, Room
     +--* Sponsor *--1 SponsorTier
     +--* TicketClass
     +--* FAQ
     +--* Post (news, video)
     +--* Edition (past: archive, satellites)

Pages in the standard site map onto the same entities:

3. Source of truth and sync

Snapshot rule: the job that builds a snapshot validates it (referential integrity, no HTML, times valid), diffs it against the last good one, and refuses to publish a snapshot that drops more than a threshold of speakers or sessions.

4. Entities

Each entity has a field table and the visitor questions it must answer. "WP" is WordPress, "WV" is Whova, "EB" is Eventbrite. Required means required in the fixture.

4.1 Edition (event)

Visitor questions:

4.2 Day

Four days for ETS27 (Mon May 3 to Thu May 6); the fourth is a half day as in ETS23, ETS24 and ETS26.

4.3 SessionType and Track

Whova's eight "tracks" are formats. The model splits them: SessionType is the format, Track is an optional theme.

SessionType ids: registration, ceremony, keynote, ets_talk, fireside, panel, town_hall, breakout, workshop, short_doc, meal, break, reception, each with label, speaker_led, note. Mapping:

Track fields: id, label, color_hint. ETS26 had no thematic tracks. The fixture invents seven placeholders from recurring session themes (ai-digital, resilience-security, customer-affordability, policy-planning, grid-edge, load-growth, people-community) and flags them placeholder: true, basis: invented. For ETS27, decide whether themes come from Whova tags or a WordPress list.

4.4 Session

4.5 Person and Appearance (fixture: speakers[])

Person key and matching: key on normalized first last, with an alias table (Chima and Chimaobi Chijioke, Rudy D. and Rudy Garza, H.G. and H G Chissell). The ETS26 to ETS25 match used last name plus first initial, then a manual check: 35 of 147 matched (31 exact, 4 by name variant).

4.6 Venue, Hotel, Room

4.7 SponsorTier and Sponsor

Tier benefits and prices are not published anywhere.

4.8 TicketClass

4.9 FAQ

Starter set (8): when and where, theme, register and cost, who should attend, hotel, getting around, dress, speak sponsor or volunteer. Likely next: accessibility, parking, wifi, dietary needs, children, international visitors, recordings, refunds in detail, what is included.

4.10 Post

5. Concierge snapshot, component catalog and tools

The project brief puts a compact knowledge snapshot in a cached prompt prefix and has the concierge answer with one structured result, {say, ui}, where ui is a list of components from an allow-listed catalog that carry record ids. The renderer draws each component from the site's own data by id and drops unknown ids. This model is built for that: ids are readable and stable, and every record carries its placeholder and confirmed flags.

5.1 Lean snapshot (goes in the prefix)

Keep the prefix to the fields the model needs to choose and cite; the renderer reads the rest by id.

Measured on the fixture: about 31.6 KB compact JSON, roughly 8,000 tokens by a characters-divided-by-four estimate (ids tokenize heavily, so measure with the real tokenizer). That fits the brief's 6 to 10 thousand token budget. Bios, descriptions, photos, wp archive blocks and source blocks stay out of the prefix. A real ETS27 lineup of 100 to 150 speakers will push the prefix up; at that point switch the speaker block to search (5.3).

5.2 Component catalog

Names follow the brief's first cut. Props are the few the model controls; the right-hand column is what the renderer reads by id.

Entities the first cut does not yet cover: past editions and videos (edition_timeline, video_card) and FAQ as a first-class item (faq_item, or keep using text_block). The sample marker is renderer-owned: any component that draws a record with placeholder: true shows it, and the model cannot switch it off.

5.3 Tools (only if the snapshot outgrows the prefix)

Everything else (event, venue, tickets, sponsors, days, tracks) is small enough to stay in the prefix. Every tool result keeps the placeholder and confirmed flags.

6. Placeholder and provenance conventions

• placeholder (bool): true means "stands in for ETS27 data that does not exist yet; replace when real data arrives." False means a real, published fact, still subject to as_of and verify_before_display.
• basis: real, real-gap, real-partial, ets26-real, ets26-adapted, invented, derived.
• confirmed_for_ets27 (speakers, sponsors): false for every stand-in. Real people in the fixture are there because they spoke at ETS26; none is confirmed for ETS27.
• owner_to_confirm (FAQ): the answer needs a Zpryme decision before launch.
• UI rule: wherever placeholder is true, show a visible "sample data" marker. The concierge states stand-ins as examples, never as announcements.
• The provenance block in the fixture lists sources with retrieval dates, which fields are real, adapted, invented or derived, counts, manual corrections and known data issues.

7. Normalization rules

8. About the fixture

prototype/data/ets.sample.json follows this model with the keys meta, provenance, event, editions, venue, agenda (days, tracks, session_types, sessions), speakers, sponsor_tiers, sponsors, tickets, faq, posts.

Choices that differ from the original ask:

• Four days, not three. ETS27 is announced as May 3 to 6, 2027. Days 1 to 3 hold the full program; day 4 is the half day. If a prototype wants exactly three days, take d1 to d3.
• Real ticket tiers instead of placeholders. They were readable on the public Eventbrite panel, so the fixture carries them with an as_of date.
• Speakers come from Whova, with WordPress photos where a returning speaker exists. The WordPress archive holds ETS25, not ETS26. 26 photos come from WordPress featured_media, 33 from the Whova CDN, 18 speakers have no usable photo (generic avatar omitted).
• Gaps are kept on purpose. 41 speakers have no bio and 18 no photo, so prototypes must design for missing data, as the real lineup will have.

Checks run: the file parses as UTF-8 JSON; no HTML or entities in any string; every session, speaker, sponsor and day reference resolves; all bios are at most 60 words; all 103 image URLs returned HTTP 200 on 2026-10-13.

Do not paste the whole file into a model prompt (about 200 KB). Build the lean snapshot in section 5.1 from it (about 31.6 KB, roughly 8,000 tokens) and let the renderer read full records by id.

9. Facts only Zpryme can supply

Venue and hotel for ETS27; whether the ETS27 Whova event exists and whether an official Whova API credential is available; an Eventbrite API token or a person who will keep the ticket table current; ticket inclusions and discount rules; sponsor tier benefits and the ETS27 partner list; which FAQ answers are right (dress, accessibility, parking, recordings); whether the ETS23 and ETS24 press logos may be reused.