Portable cognitive + operational unit.

• title
• intent
• steps
• mnemonic
• assets
• visibility (public/private)

Poster, Postcard, Study Card, PDF, QR-linked view.

ACTIVE – first-class entity.

Below is the final, lockable SessionCard MLV.md.

It is written to be: • authoritative • boring • mechanical • implementation-ready • non-expansive

Nothing here presumes AI, subscriptions, trips, or coaching automation. Everything else must compose on top of this.

⸻

MLV V1.2 — SessionCard

(Skills & Sessions Only · Canonical Primitive)

Status

LOCKED (V1.2) Any change requires a version bump and explicit migration notes.

⸻

0. Scope Lock (Read First)

This chapter defines the lowest stable primitive of the system.

Explicitly out of scope: • AI generation or chat • Subscriptions or plans • Background jobs • Automation pipelines • Multi-user collaboration • Dynamic pricing • Trip orchestration • Coaching orchestration

If it is not required to print, scan, sell, and deliver a 90-minute session, it does not belong here.

All future systems must compose on top of SessionCard, not modify it.

⸻

1. What a SessionCard Is

A SessionCard is a portable, human-first, deterministic unit that represents one guided skill or session.

It is: • printable • scannable (QR) • sellable • memorable • repeatable

It is not: • a chat • a workflow • a dashboard • a subscription • an AI artifact

A SessionCard is filled once by a human and can then be rendered indefinitely into physical and digital assets.

⸻

2. Canonical Fields (Authoritative)

2.1 Core Structure

Field Type Constraint Purpose slug string unique URL + QR anchor title string ≤ 40 chars Session title hook string ≤ 70 chars Postcard headline promise string ≤ 120 chars Outcome statement steps string[] 3–7 items Guided session flow materials string[] optional Apps / tools required durationMin number fixed = 90 Session length difficulty enum beginner / intermediate / advanced / expert Expectation setting exposure enum public Promotional visibility

Rules • No optional logic. • No derived fields. • No hidden metadata. • No polymorphism.

⸻

2.2 Authoring Rule

Human fills once → system renders forever

The system may never: • rewrite the card silently • mutate historical content • “optimize” wording automatically

⸻

3. Deterministic Asset Press

A SessionCard produces exactly three assets.

3.1 Asset Matrix

Asset Format Use Source Postcard 4×6 cm PDF + QR Street / cafés / events Template + card fields Study Card 3×5 cm PDF Learner handout Filtered card fields Coach Script A4 PDF Session delivery Markdown render

3.2 Rendering Rule

SessionCard JSON → template → PDF → print / email / download

No AI. No background jobs. No runtime mutation.

⸻

4. Access Layer (Single Relationship)

4.1 CardAccess

Purpose: gate full card visibility.

Field Type cardId reference userId reference type enum expiresAt datetime

Access types • SESSION — paid (€50) • GRANTED — manual / free • TRIAL — 24h

4.2 Access Flow

QR scan → /card/{slug} → promotional view → payment / grant → CardAccess row → full card unlocked

No subscriptions. No role hierarchies. No soft permissions.

⸻

5. User Instance (Private Memory)

5.1 UserCardInstance

Created after first unlocked session.

Field Purpose userId owner cardId reference notes session notes answers step reflections memoryAid rhyme / mnemonic

Rules • Always private • Never public • Never shared • Optional AI interaction later, not required

⸻

6. Session Mechanics (90-Minute Clock)

Session Flow 1. Choose SessionCard 2. Open Coach Script 3. Follow steps in order 4. Capture notes + memoryAid 5. Save UserCardInstance

Deliverables • Study Card PDF • Updated UserCardInstance • Any referenced templates (manual)

⸻

7. Money Flow (Two Levers Only)

Lever Price Mechanism Postcard €5 Gumroad link Session €50 Calendly → Stripe → CardAccess

No bundles. No funnels. No lock-in.

⸻

8. Minimal Tech Contract

Required • Prisma models: • SessionCard • CardAccess • UserCardInstance • Next.js route: • /card/[slug] • /card/[slug]/pdf?type=postcard|study|script • PDF rendering: • Markdown / template → Puppeteer • Auth: • NextAuth (Google) — unlock only

Explicitly forbidden (at this layer) • Cron jobs • Queues • Webhooks beyond payment confirmation • AI calls • Background sync

⸻

9. Relationships to Other Chapters (Declarative Only)

Skills

Every Skill is represented internally as a SessionCard. Skills do not define structure — they supply meaning.

Trips

Trips are ordered sequences of SessionCards. Cards remain the unit of QR, print, and study.

Pricing

Offers may store immutable snapshots of SessionCards. Cards are not retroactively mutated.

Coaching Mode

Coaching operates over SessionCards. The card is the session memory unit.

⸻

10. Canonical Constraint (Memorize This)

If it cannot be printed and delivered without AI, it does not belong in SessionCard.

⸻

11. Versioning • V1.2 — Skills & Sessions only • Next possible versions: • V1.3 — Card Bundles (still no AI) • V2.0 — Coaching orchestration (composed, not mutated)

⸻

End of Chapter

SessionCard is the atomic unit.

Everything else is orchestration.

⸻

If you want, next we can derive the exact Prisma schema + guards from this file, line by line, with zero interpretation.

Retrospective check:

This is a good and compatible nuance, and it does not break the MLV. It only refines the Asset Press section. Nothing structural is missing.

I’ll do three things, cleanly: 1. Confirm the 11×17 proportion system 2. Map every asset to that system (mechanical, no ambiguity) 3. State explicitly whether anything is missing (short answer: no)

⸻

1. Confirming the 11×17 Proportion System

You are defining a single parent ratio, equivalent to how ISO A-series works, but using ANSI B (11×17 in) as the root.

This is valid and actually stronger for differentiation.

Canonical Parent • Poster / Master Canvas • 11 × 17 inches (ANSI B, portrait) • Ratio ≈ 1 : 1.545

All other assets are fractional surfaces of this, preserving ratio.

This is exactly analogous to: • A3 → A4 → A5 → A6 but in imperial / ANSI geometry.

Good choice.

⸻

2. Correct Asset Size Mapping (Authoritative)

Below is the correct, exact mapping. I’ll also flag where you were already right.

A. Master Poster (Public Promo)

Asset Size Notes Poster 11 × 17 in Root proportion

Used for: • café walls • events • street visibility • QR entry point

✅ Correct as stated.

⸻

B. Full Study / Technical Report

(Exception you explicitly allow — and correctly so)

Asset Size Notes Full Study / Technical PDF 8.5 × 11 in Same ratio as 11×17, half surface

This is: • exactly half of 11×17 • same proportion • familiar to printers • suitable for: • guided tour knowledge layers • garden / design studies • technical project reports • structured “full card” exports

✅ This exception is coherent and should be explicitly allowed, as you described.

⸻

C. Postcard / Study Card / Prompt Card

(Same physical size, different filtering)

Asset Size Notes Postcard / Study / Prompt Card 5.5 × 8.5 in Quarter of 11×17

This is: • one quarter of the poster surface • same ratio • equivalent to ANSI Half Letter • perfect for: • postcards • revision cards • prompt cards • study summaries

✅ Your intuition here was correct.

⸻

D. (Optional) Micro Card — Eighth Surface

(Only if ever needed later, not required now)

Asset Size Notes Micro Card 4.25 × 5.5 in One eighth of 11×17

This would be: • pocket-sized • mnemonic-only • rhyme / memory aid focus

⚠️ Not required in current MLV. Mentionable later, not now.

⸻

3. How This Integrates into the MLV (Small Patch Only)

You do not need a new version.

You only adjust Section 3 — Deterministic Asset Press.

Replace the asset table with this (conceptually)

All SessionCard assets derive from a single parent canvas: 11 × 17 inches (portrait). All child assets preserve this ratio.

Then list: • Poster → 11×17 • Full Study / Technical PDF → 8.5×11 • Postcard / Study / Prompt Card → 5.5×8.5 • (Optional future) Micro → 4.25×5.5

No logic change. No schema change. No code impact beyond templates.

⸻

4. Did We Leave Anything Out?

Short answer: No.

Longer answer: Everything you described fits cleanly into the existing MLV without adding fields or concepts.

Specifically: • Distinct visual language from A-series documents → ✅ handled • Clear separation from general document engine → ✅ preserved • Physical-first, print-native thinking → ✅ reinforced • Cards usable for: • skills • trips • garden projects • technical studies → ✅ already allowed via “Full Study / Technical PDF” • No accidental AI creep → ✅ still locked out • No schema bloat → ✅ unchanged

This nuance strengthens the system instead of expanding it.

⸻

5. One Canonical Sentence to Add (Optional, but Good)

You may want to add one line to the MLV:

“SessionCard assets deliberately use the 11×17 inch proportion system to remain visually and cognitively distinct from standard A-series documents used elsewhere in the platform.”

That’s enough.

⸻

Bottom line • Your size logic is sound • Your exception is correct • Nothing important is missing • The MLV remains lockable

When you’re ready, the next mechanical step would be: • define the PDF template contracts (no code yet, just slots)

But you are right to pause here.

This version is solid.