# Tamás Tanya research synthesis

Evidence register for goal-v1 A-01, A-03, A-06, A-09 and A-10. Prepared from the frozen launch packet and the transferred Linux evidence on 2026-09-02 UTC / 2026-09-03 Europe/Budapest. This document establishes source provenance and product reasoning. Functional and visual acceptance belongs to `qa-report.md`.

## Evidence labels

- **Verified source fact:** the identified source contains the statement. This does not establish present-day availability or implementation.
- **Client-provided 2027 offer:** capacity, price or commercial term supplied by the client, subject to final operational confirmation.
- **Proposed:** a future workflow or commercial scope shown for discussion.
- **Demo assumption:** an editable illustrative value, date, person, booking, rate or campaign result. It is not a real reservation or forecast.
- **Dependent:** requires selected PMS, channel manager or account verification before activation.

## Exact source register

The original Mac paths are provenance, not mounted paths. The Linux paths below are the readable remote-workspace evidence copies. SHA-256 identifies the bytes inspected.

### Frozen goal

Original: `/Users/agency/Documents/Agty/sales-call-preps/outputs/delegating-goal-runs/20260903-001520-tamastanya-five-concept-demo/goal-v1.md`

Remote evidence: `/home/matt/mirror/sales-call-preps/outputs/delegating-goal-runs/20260903-001520-tamastanya-five-concept-demo/goal-v1.md`

SHA-256: `08750ff181b125647adbe535d330e50400b5840843f0e53b80de7260212ff8e2`

### Reference HTML

Original: `/Users/agency/Library/CloudStorage/GoogleDrive-matyas@clientsflow.hu/My Drive/Tools & Knowledge/Google AI Studio/tamástanya.html`

Remote evidence: `/tmp/tamastanya-five-concept-demo-inputs/reference.html`

SHA-256: `de66e0715defb493714915dfa7830272f0d488a1280e4cf060bc19c445b59bd7`

### Converted 2027 offer

Original: `/Users/agency/Documents/Agty/sales-call-preps/scraped-sites/tamastanya.hu/materials/esküvői-arajanlat-2027.md`

Remote evidence: `/tmp/tamastanya-five-concept-demo-inputs/materials/esküvői-arajanlat-2027.md`

SHA-256: `802225b885189e7613bc683d2bdb5106ab7b4d347682a066f4dca736e7aa9cc2`

### Client material inventory

Original: `/Users/agency/Documents/Agty/sales-call-preps/scraped-sites/tamastanya.hu/materials/drive-materials-inventory.md`

Remote evidence: `/tmp/tamastanya-five-concept-demo-inputs/materials/drive-materials-inventory.md`

SHA-256: `44ac0fce8d01dfbc231d0287b594c2b250ff3e84a3fc9c5c83fa7577e9d9f06d`

### Current-site scrape

Original: `/Users/agency/Documents/Agty/sales-call-preps/scraped-sites/tamastanya.hu/tamastanya.hu_scraped.json`

Remote evidence: `/home/matt/mirror/sales-call-preps/scraped-sites/tamastanya.hu/tamastanya.hu_scraped.json`

SHA-256: `4af5b522b2a7d52374ada03a447792c301150d0de310fe7e14add2e80fa5aa8a`

### Keyword data

Original: `/Users/agency/Documents/Agty/sales-call-preps/scraped-sites/tamastanya.hu/assets/data/keywords.json`

Remote evidence: `/home/matt/mirror/sales-call-preps/scraped-sites/tamastanya.hu/assets/data/keywords.json`

SHA-256: `5f7099e231670b75d6821683d60ff85a5f37dfcd30cb8f047c76196587eed588`

### Keyword presentation

Original: `/Users/agency/Documents/Agty/sales-call-preps/scraped-sites/tamastanya.hu/assets/html/23-keyword-table-tamastanya.html`

Remote evidence: `/home/matt/mirror/sales-call-preps/scraped-sites/tamastanya.hu/assets/html/23-keyword-table-tamastanya.html`

SHA-256: `aff13f3d2190cac5aaab8ae92bd486677d30065cd1f6156975513c5b4722b042`

### Sitemap recommendation

Original: `/Users/agency/Documents/Agty/sales-call-preps/scraped-sites/tamastanya.hu/assets/html/28-sitemap-tamastanya.html`

Remote evidence: `/home/matt/mirror/sales-call-preps/scraped-sites/tamastanya.hu/assets/html/28-sitemap-tamastanya.html`

SHA-256: `3f4256e9d49415af29e7316a26b78842dad9da1842b2029d0e445cede1063838`

### Intended Cat2it interaction reference

Original: `/Users/agency/Documents/Agty/KERTÚJÍTÓK/manual-entry-app/index.html`

Remote evidence: `/tmp/tamastanya-five-concept-demo-inputs/cat2it-canonical/manual-entry-app-index.html`

SHA-256: `1cc438cf486579d9b3679479d653e631ceaddec0c6ec08ab8652ec0d3bdb8464`

### Companion dashboard pattern

Original: `/Users/agency/Documents/Agty/GHL funnel/full_dashboard_sandbox.html`

Remote evidence: `/tmp/tamastanya-five-concept-demo-inputs/cat2it-canonical/full-dashboard-sandbox.html`

SHA-256: `7165d33aca81d3b2a5613e2448b11b4db366fe85d117a6b15f9614b49ddf4a63`

### Research receipts and source URLs

- Preflight: `/tmp/tamastanya-source-preflight.md`.
- Transcript receipt: `/tmp/tamastanya-transcript-research.md`. Source call `Sales call · Tamás Tanya · 2026-08-18`, transcript ID `01M09T810XS4Q6XGB1JT88851S`. [Notion transcript](https://app.notion.com/p/3c09cef986ad815daedefd844f646e5d?pvs=204), [Fireflies recording](https://app.fireflies.ai/view/01M09T810XS4Q6XGB1JT88851S). T# locators below refer to the speaker-labelled transcript, not an AI summary.
- Booking receipt: `/tmp/tamastanya-booking-best-practices.md`.
- Final Cat2it discovery receipt: `/tmp/cat2it-panel-research.md`, SHA-256 `c056014a2ec221d0b1b6fff3894f9bd79802313edf371d26fe1be0908bbf9908`. Re-read after the parent replaced the initial transfer with final Mac bytes. Both canonical HTML hashes above remained unchanged.
- Client email provenance: [Missive material handoff](https://mail.missiveapp.com/#inbox/conversations/8f19ea31-4dfd-46a3-9dcf-df4dee74968c). Its reference is recorded in the transferred inventory. This documentation did not independently re-open the full email thread.
- [Client Drive folder](https://drive.google.com/drive/folders/16XlVeDdtwHq2Zdu8fc2-ejBok_euT_hp), [2027 offer source document](https://docs.google.com/document/d/1CoaM1S-THblXpknGN_DPjN_AlNYwskRl/edit), [current website](https://www.tamastanya.hu/).

The indexed Notion transcript is the latest verified call. The receipt records fresh Fireflies searches and direct retrieval failing with HTTP 429. No later call or final commercial commitment is inferred.

## Business evidence translated into the demo

| Evidence | Source locator | Product decision and status |
|---|---|---|
| Weddings are the main profile and qualified demand is the immediate objective | T#109, T#179–184 | Wedding-first planner is the recommended entry. Proposed UX |
| First visitor question is the date, but publishing the entire wedding calendar is undesirable | T#125–131 | Accept multiple requested dates and show request-specific alternatives. Calendar concept shows demo opportunities, not the owner's complete live wedding calendar |
| Accommodation sales can consume wedding capacity and the estate can remain empty | T#166–177 | Owner explicitly releases selected weekends after checking event and room blocks. Exact release date and rule remain proposals |
| A standard wedding offer should return by email, optionally after editing | T#117–124 | Request-response preview and editable owner content fields. Standard offer sending is proposed. Local simulation performs no email send |
| One administration point is wanted | T#136–139, T#164 | Unified owner calendar, enquiry pipeline, rates and channels. Live synchronization remains dependent |
| The owner rarely reaches a computer | T#103 | Urgent actions, concise records, reminders and explicit save controls |
| Owner-managed text, images and updates are useful | T#095–101 | Content editor for approved website fields. A production publishing process is not established |
| Venue visits, corporate events, birthdays, buffet and Torkoskodás matter | T#109–116 | Shared service sections and occasion-specific enquiry routes |
| Check-in support was requested | T#216–227 | Explain as a separate future operational step. Do not collect identity documents in the enquiry demo |
| Arrival/departure handling at the second property can count one night as two days | T#147–155 | Stay flow separates arrival and departure and counts nights, with departure strictly after arrival |
| Booking options for both guest and owner sides were promised for investigation | T#212–214 | Five alternatives plus one owner work surface, compared on conversion, workload, inventory complexity and suitability |

## Second property

**Verified source fact:** T#142 explicitly identifies another property and website, transcribed as `TomikaVendékház.hu`. The scrape at original line 1266 contains `Tomika Vendégház & Wellness` and `www.tomikavendeghaz.hu`. The strongest domain evidence is the scrape, not the uncertain automatic transcription.

The likely URL is `https://www.tomikavendeghaz.hu/`. HTTPS, canonical redirect, live booking behavior and account ownership were not independently verified. The demo uses a property switch and a separate Tomika enquiry path without claiming a live cross-property connection.

The client offer lines 358–360 list 17 guests and whole-property rates of 250,000 Ft/night for one night, 220,000 Ft/night for two nights and 200,000 Ft/night for three nights. These are **client-provided 2027 prices**, not today's availability. The inventory also identifies [Tomika Vendégház 2027.jpg](https://drive.google.com/file/d/1_K5bi9dW2GMOI8W0WoBr76g-n659j4a1/view).

## Material facts and numeric boundaries

The converted offer is the content source, already converted to Markdown before this task.

| Claim | Exact source location | Use |
|---|---|---|
| 24-hectare estate, weddings for 30–300 | Offer lines 22–23 | Guest introduction and factual metric strip, client-provided label |
| 85 on-site beds plus 17 at Tomika | Offer line 25 | Two-property positioning, not live inventory |
| Detailed total 112 across multiple properties | Offer lines 371–378 | 49 room/kisház beds + 36 cabin beds + 17 Tomika + 10 neighbouring guesthouse. Do not describe 112 as Tamás Tanya on-site capacity |
| Arrival 14:00, departure 10:00 | Offer line 379 | Stay guidance |
| Accommodation requires separate booking | Offer lines 382–385 | An event request or wedding reservation never silently reserves rooms |
| Wedding deposit 500,000 Ft | Offer lines 400–403 | Source-labelled wedding detail. Demo status changes do not take payment |
| Gerendás 160, Jurta 106, Grill 300, ceremony garden 80 expandable | Offer lines 412–419 | Venue fit examples with confirmation required |
| Contact email and phone | Offer lines 11–12 and current scrape | Contact area |

The offer's cancellation, cash settlement and deposit terms are evidence of supplied terms. This prototype does not implement or validate their legal operation. The noisy transcript system names `NTAC`, `vendégen.hu`, `felhőmatrac` and `Entagbookingszállás.hu` do not identify a confirmed provider or API.

## Search evidence and marketing assumptions

`keywords.json` contains 52 expressions. The source table is dated 2026-08-18 and attributes volume data to DataForSEO Google Ads for Pest megye location 20429 and Hungary 2348. Monthly search volume is neither unique customers nor expected bookings. Missing volume is no data, not zero demand.

| Exact keyword | Pest/month | Hungary/month | Pest CPC Ft | Hungary CPC Ft |
|---|---:|---:|---:|---:|
| `tamás tanya` | 390 | 1000 | 160 | 254 |
| `esküvői helyszín pest megye` | 110 | 390 | 348 | 486 |
| `étterem cegléd` | 260 | 390 | 128 | 125 |
| `kirándulás pest megye` | 210 | 320 | 60 | 53 |
| `szállás cegléd` | 50 | 170 | 100 | 251 |
| `rendezvényhelyszín pest megye` | 20 | 50 | 376 | 429 |

Terms such as `szállás csemő`, `vendégház csemő`, `diáktábor pest megye` and `céges rendezvény helyszín pest megye` retain the source's no-data status. Relevant demand justifies separate wedding, stay, event, camp and buffet messages. It does not prove future results.

The frozen packet's 200,000 Ft monthly media budget, former 180,000 Ft management assumption, 3% landing conversion and 15% close rate are planning inputs. The current proposal replaces that former fee with 150,000 Ft per month. T#248–260 supports discussing an initial Google test budget, but does not establish an accepted spend or management fee. Average booking values, margins, channel splits and package prices in the offer are proposal inputs. ROI must be recalculated from the currently shown inputs and never treated as guaranteed revenue.

## Cat2it interaction provenance

The parent clarified that the intended canonical interaction source is the KERTÚJÍTÓK manual-entry application registered above. Preserve the discovery caveat: **no literal Cat2it or Cat2it Talk artifact/name was found** by the source scout. The project therefore applies the intended manual-entry panel patterns with explicit provenance, rather than claiming an independently identified Cat2it-branded product.

Only generic interaction concepts are used. No private application code, endpoints, credentials, records or secret-bearing system overview is copied into this demo.

| Canonical source locator | Reusable pattern | Tamás Tanya application target |
|---|---|---|
| `manual-entry-app-index.html:279–295` | Lead list and new-entry separation, today's reminders | `owner.js` due-today record emphasis, pipeline and manual enquiry capture |
| `manual-entry-app-index.html:336–362` | Internal note, dated reminder, explicit save | `owner.js` booking detail with owner note and next action |
| `manual-entry-app-index.html:740–766` | Inline note, reminder and stage editing | `owner.js` editable booking detail and pipeline stage control |
| `manual-entry-app-index.html:837–875` | Visible save state, preserve edits on failure | `owner.js` booking-detail form exposes unsaved changes and acknowledges local save. Remote error/retry behavior remains production work |
| `manual-entry-app-index.html:896–925` | Read-only reminder preview | Read-only booking document preview without sending. Editable outgoing templates remain a proposed workflow |
| `full-dashboard-sandbox.html:328–336` | Compact primary navigation, secondary operational tools | Daily owner work surface plus separate calendar, pipeline, content, rates, channels and marketing views |

Voice recognition and automatic extraction are not inferred to be required or live merely because they exist in the source. Implementation and QA evidence must distinguish applied local behavior from remaining production work.

## Booking research and integration boundary

The booking receipt supports short branching forms, keeping supplied dates and guest count, visible statuses and explicit next steps. [GOV.UK form structure](https://www.gov.uk/service-manual/design/form-structure) is the general form reference. [Booking.com ARI documentation](https://developers.booking.com/connectivity/docs/ari) distinguishes availability, rates, inventory and restrictions. It supports the model, not a claim that this property uses Booking.com's API.

[Szallas.hu's official channel-manager information](https://szallas.hu/channel-manager-info) was checked by the parent during this run. It supports synchronization through approved channel-manager providers. It does not verify Tamás Tanya's selected provider, private access, mapped rooms, two-property support or a direct custom API.

Proposed operating route: owner updates a central inventory or PMS, the own-site booking engine reads the same inventory, and an approved channel manager distributes the supported room availability and rates to Szallas.hu. Every external edge remains **dependent on provider and mapping confirmation**. Phone, email and social enquiries enter manually unless a separate connection is verified.

An enquiry, temporary hold, confirmed event, room block, maintenance closure and owner-released weekend are distinct states. Production holds need an explicit expiry policy. In this local prototype the decision date is a reminder and holds remain active until the owner manually changes them. No clock-driven expiration or automatic release is implemented. A release is an explicit owner decision and cannot override a confirmed block. Wedding and mixed event/stay requests require owner confirmation. Any future instant booking is limited to precisely priced, conflict-free products with verified availability.

NTAK reporting is a separate process. This demo makes no legal implementation claim, sends no statutory report and captures no identity documents. A live check-in route is a separate selected-PMS decision.

## Four common operating scenarios

| Scenario | What the owner enters | What the guest sees or receives | What the owner gets |
|---|---|---|---|
| Wedding enquiry | Event holds, protected dates, venue capacity and optional offer template | Multiple-date request, guest count, venue and accommodation questions, labelled proposed alternatives | One enquiry with preferred dates, separate event/stay needs and a consultation next step |
| Release an empty weekend | Selected date, property, capacity, release decision and minimum stay | Only the deliberately released group or stay opportunity | Demand linked to that release, with conflicts still checked before confirmation |
| One-night Tomika stay | Tomika's rate, capacity, restrictions and blocks | Distinct arrival/departure fields and a one-night result | Property-specific request and occupancy period without counting departure as a second night |
| Confirm an event with accommodation | Offer, note, deposit status, separate room block and confirmation decision | A clear request/hold/confirmed status distinction | A traceable pipeline change and associated calendar blocks, with follow-up visible |

These scenarios describe the proposed operational contract. The local prototype uses sample data and cannot confirm a real booking, process payment or synchronize a channel.

## Real photo provenance

The preflight originally reported missing local photo bytes. This was resolved by importing twelve real photographs into `demo/assets`: ten from the client's current website and two original Drive files. No generated imagery is used. The manifest records full source URLs, byte counts, dimensions, SHA-256 hashes and the asset worker's decode/visual checks. Files remain unmodified source bytes. This documentation independently checked the recorded image hashes against the local files.

- `ceremony-guests.jpg` is client Drive original `2048-DSC-2365.jpg`, [source](https://drive.google.com/file/d/1gVJHOhK_XtA915f11zefnVM5SeTVYJx8/view). SHA-256 `ae87ca3a93c62dc2c09998edbb9ae2aa7d1b9957fc35773b44d40b31f487f4b5`.
- `aerial.jpg` is client Drive original `dji1757660896122.jpg`, [source](https://drive.google.com/file/d/1Q8lfuRpsj1NQYWDA_b8qGzV6TKcvlp3J/view). SHA-256 `0055819a0546255a163763daef8a530ecb19855f4e6756e76a6d7e0db0167d7a`.

For all twelve individual source URLs and hashes, see [asset manifest](assets/manifest.json). The gallery uses the Drive originals alongside website photographs. Venue cards use illustrative photographs of the estate, not evidence that each pictured room is the named venue. The demo must not infer live availability, review counts, awards or guest quotations from photography.

## Evidence limits

Unresolved production choices are the PMS, channel manager, room and venue mapping, cross-property allocation, release policy, payment and cancellation rules, approved communication templates and statutory check-in route. The source reference contains unsupported testimonial and badge content. The demo retains the proof role with actual imagery and an explicitly planned review slot instead of fabricated endorsements.