Good — you are exactly at the correct inflection point.

What you are describing is not a new feature set, it is the natural closure of the original MLV into a production-ready instrument whose outputs finally touch money, print, and people.

Below is a clean, finalised MLV v1.2 definition, explicitly tying together: • study cards • training / coaching sessions • trips & itineraries • posters / postcards / technical PDFs • assistant modes • FareHarbor + booking surfaces • weekly cash-flow reality

This is a round-up and lock-in, not new speculation.

⸻

MLV v1.2 — Document Instrument → Asset Pipeline

Core Truth (unchanged, reaffirmed)

One document remains the semantic authority. Everything else is a projection.

This still holds. What changes is what we allow the projections to be.

⸻

1. The Missing Piece (Now Explicit)

Until now, your system stopped at: • document → pagination → pages → export

The next stage is:

Document → Asset Family → Physical / Commercial Outputs

You are not adding workflows. You are formalising the outputs that already exist implicitly.

⸻

2. Canonical Asset Family (NEW, LOCKED)

Every “thing you sell or use” now belongs to a single Asset Family, derived from one authoritative Study Entity.

The Study Entity (Canonical)

A Study Entity represents one of the following: • a skill • a workflow • a training session • a chapter • a trip • a city agenda • a roadtrip • a coaching module

It lives in:

/study-guides/<slug>/

It contains pure meaning, not format.

⸻

3. Asset Projections (Standardised Outputs)

From one Study Entity, you can deterministically generate:

A. Study Card (1-page, atomic) • Purpose • Context • Core logic • Inputs / outputs • Time block (e.g. 90 minutes) • Join / booking references (optional)

This is your universal primitive.

⸻

B. Technical PDF (multi-page) • Expanded logic • Diagrams • Narrative • References • Used for: • training • onboarding • trip planning • professional use

⸻

C. Poster (promotional) • Title • Cities / dates / flow • Core promise • QR / booking references • Derived directly from the same data

⸻

D. Postcard (souvenir + viral) • Minimal information • Dates / cities • “I’m going here” • QR for others to join • Pre-trip or post-trip use

⸻

E. Itinerary / Agenda Sheet • Weekly departures • Join-in points • Arrival / departure logic • Used by: • travellers • agents • FareHarbor listings

⸻

🔒 Important rule None of these assets introduce new meaning. They are views, not sources.

⸻

4. Trips Are Not Special — They Are Studies

This is the key unblocking insight.

A trip is just a Study Entity with: • geography • time • logistics • booking hooks

Therefore: • City Highlight Tours • Guided Roadtrips • Weekly Departures • Join-in Sessions

→ are all Study Entities with travel metadata.

That is why your trip posters, postcards, itineraries, and training PDFs can share the exact same format.

You are not mixing domains — you are unifying them.

⸻

5. Booking Integration (Explicit, Non-Authoritative)

Booking systems (FareHarbor, widgets, agents) are external projections.

In the Study Entity you store only:

bookingRefs: { city?: "cordoba" | "granada" | "madrid" | "malaga" | "sevilla" productType?: "session" | "roadtrip" | "full-journey" externalId?: string joinRules?: JoinRule[] }

These refs can be rendered as: • buttons • QR codes • links • voucher lines

But never control the document.

⸻

6. Assistant Modes (Now Cleanly Resolved)

You do not need more assistants.

You need one Coaching Mode, with internal roles.

Coaching Mode (Primary)

This mode: • replaces generic chat • contains all structured prompting • is document-aware • writes only through canonical surfaces

Internal sub-roles (not separate modes): • Planner • Trainer • Trip Designer • Pricing Clarifier • Autopilot (structured Prisma-form emulation)

All of them output into: • Study Entities • Study Cards • Structured fields

⸻

7. Autopilot (Clarified, Safe)

Autopilot does not invent.

It does: • Given a title + intent • Generates: • Study Entity skeleton • Standard fields • Suggested asset outputs • User edits • Document saves • Assets render

This is MLV → MVM compliant.

⸻

8. Weekly Reality (Why This Works Now)

This system directly supports: • weekly paid coaching sessions (90-min) • live or online training • trip onboarding • trip promotion • postcards before departure • vouchers • agent briefs • last-minute join-ins

All from one surface.

No dashboards. No automation engines. No duplicated state.

⸻

9. Final MLV v1.2 Statement (Lock This)

The Document Instrument now guarantees that every meaningful study — whether a skill, session, or journey — can deterministically produce a family of physical and commercial assets without introducing new authority.

This is the completion of your original intent.

You are no longer asking “what should this be”. You are deciding “which assets do I emit this week”.

⸻

What I Recommend Next (Very Concrete)

Pick one and we execute it fully: 1. Define the canonical Study Entity schema (fields only) 2. Define the Study Card markdown template 3. Define the Poster / Postcard render rules 4. Define the Trip Study subtype (extra fields only) 5. Define the Coaching Mode system prompt

Say the number.

You are no longer designing — you are operating.