READ ME FIRST
How to Review the LOTOMIX Investor Data Room
Target reading time: 30–45 seconds
Welcome to the LOTOMIX Investor Data Room
This Data Room is structured to separate current operating evidence, pipeline, management targets and financial-model assumptions.
We recommend reviewing the Investment Overview first, followed by the Business & Economics, Rollout and Financial sections before opening the underlying source documents.
How to Read the Information
Use the following controlled labels.
A signed or formally completed contractual / corporate document.
Physical infrastructure currently installed where supported by operating evidence.
Currently active in the operating environment.
Functionality has been tested but should not automatically be interpreted as proven at full commercial scale.
Identified future opportunity or expressed interest that has not yet converted into deployment or recognised revenue.
A financial or operating assumption contained in the approved management model.
A future execution objective.
Observed operating or financial data as of the stated date.
Historical material retained for traceability but no longer the current basis for investment analysis.
IMPORTANT
Potential network access, pipeline, installed locations, activated locations, monetised locations and completed locations are different metrics and should not be interpreted interchangeably.
Financial Information
BC 6.7 is the current principal management financial model for the LOTOMIX investment case.
Investor-facing summaries may simplify calculations for readability, but detailed financial assumptions and projections should reconcile to BC 6.7.
GTV and LOTOMIX recognised revenue are reported separately.
Current vs Forward-Looking
Current information is based on available operating, contractual or technical evidence.
Forward-looking information includes pipeline, management targets, sensitivities and financial-model assumptions.
Forward-looking information should not be interpreted as guaranteed operating performance.
Recommended Review Sequence
Short on Time?
How Claims Are Supported
Where underlying evidence exists, the Data Room provides direct links to the canonical source rather than duplicating documents across multiple sections.
Document Versions
Investors should rely on documents marked CURRENT / APPROVED or EXECUTED / FINAL for current analysis. Historical material remains available for traceability.
Current Financial Model
BC 6.7
Current Principal Management Financial Model
Current Rollout Definitions
Canonical interpretation of network, pipeline, location and screen metrics.
Need to Verify a Claim?
Key claims linked to underlying source documentation.
Want to Test the Downside?
Driver-based downside analysis, not assuming the base case.
Confidential Investor Information
This Data Room contains confidential investor information subject to the existing approved confidentiality notice / NDA terms. Unauthorized distribution is strictly prohibited.
Certain legal, KYC, banking or commercially sensitive documents may require additional access permissions. Where access is restricted, the Data Room shows RESTRICTED ACCESS rather than a broken link.
Data Dates
Current operating metrics should be read together with their stated "Data as of" or "Last Updated" date. This is especially relevant to rollout, pipeline, advertisers, users, cash and financial actuals.
Do not display undated operating metrics as live information.
Different Elements Are at Different Stages
Different elements of LOTOMIX are at different stages of maturity. For example:
• A contract may be executed
• Infrastructure may be deployed
• Technology may be tested
• A revenue stream may still be modelled
• A rollout milestone may remain a management target
The Data Room therefore uses explicit status labels rather than presenting all information as equally mature.
Start Review
Returning Investor?
Recommended Starting Point
Begin with the 3-Minute Investment Overview.
Use the analytical sections to test the investment case, and the Evidence Map / Full Data Room to verify the underlying claims.
UNDERSTAND → TEST → VERIFY
LOTOMIX
Caso de Inversión de Un Vistazo
Resumen de Comité de Inversión en una pantalla
TODAY
WHAT EXISTS
~7,000
Potential FENAMIX network perimeter
~370
Existing reader footprint
1,200+
Current rollout / expressed-interest pipeline
Core Platform
Developed / testing
BC 6.7
Current financial model
CURRENT FINANCING
THE ASK
€3M
CURRENT FUNDRAISING REFERENCECapital intended to support technology completion, hardware, deployment, commercial activation and working capital.
NEXT 3 MILESTONES
WHAT HAPPENS NEXT
December 2026
NOT STARTEDBroad commercial rollout target
March 2027
NOT STARTEDAdditional display deployment
April 2027
NOT STARTED~770 completed locations targeted
MANAGEMENT ROADMAP
WHAT DRIVES THE CASE?
CRITICAL DRIVERS
Rollout
MODELActivated / monetised locations
Base: 770 POS target · Actual: —
Traffic
MODEL ASSUMPTIONActual location footfall
Base: 800 visits/day · Actual: —
Interaction
MODEL ASSUMPTIONReader capture rate
Base: 30% capture · Actual: —
Advertising
MODEL RANGEFill + realised CPM / pricing
Base: €6–€9 CPM · Actual: —
Digital
MODEL ASSUMPTIONMAU + monetisation / conversion
Base: 20–30% MAU · Actual: —
Capital Efficiency
MODELDeployment cost + OPEX discipline
Base: BC 6.7 OPEX · Actual: —
WHAT COULD MOVE THE CASE?
PRINCIPAL EXECUTION RISKS
Rollout Conversion
Mitigation: Pipeline-to-installation tracking + phased deployment gates
Advertising Monetisation
Mitigation: Commercial team + agency channel + fill monitoring
Digital Adoption
Mitigation: Product iteration + acquisition cost discipline
Scale Execution
Mitigation: Production hardening + load testing before scale
Cash / Capital Efficiency
Mitigation: Rolling forecast + milestone-gated capital deployment
WHAT IS PROVEN TODAY?
EVIDENCE STATUS
CONTRACT
FENAMIX / relevant executed agreements
EVIDENCE AVAILABLEDEPLOYMENT
Existing physical reader footprint
DEPLOYEDTECHNOLOGY
Core functionality developed / tested
PARTIALLY VALIDATEDCOMMERCIAL
Current activity classified by actual status
VALIDATION REQUIREDFINANCIAL
BC 6.7 driver-based model
MODELLEDPIPELINE
1,200+ expressed-interest / rollout pipeline
EARLY DATAWHAT REMAINS TO PROVE?
Pipeline → Activated Locations
Modelled CPM → Realised CPM
Installed Screens → Paid Fill
Digital Users → Paying Behaviour
Modelled Unit Economics → Actual Contribution
Tested Technology → Scale Evidence
INVESTMENT CASE IN ONE SENTENCE
LOTOMIX is seeking to convert an existing lottery-retail network position, deployed infrastructure and developed technology into a broader monetised operating network, with the current €3M financing intended to fund the next stage of deployment and commercial validation.
LOTOMIX — Confidential Investor Information
Financial Model: BC 6.7
Data as of 2026-10-01
LOTOMIX Investor Data Room
Investment overview, operating model, financial case and supporting due diligence evidence
~370
Existing reader footprint
DEPLOYED1,200+
Rollout / expressed-interest pipeline
PIPELINE~7,000
Potential FENAMIX network perimeter
POTENTIAL NETWORK~770
Completed-location target by Apr 2027
MANAGEMENT TARGET€3M
Current financing reference
FUNDRAISINGStart Here
Understand what LOTOMIX is, what exists today, how the business monetises, what the financing unlocks and where the principal evidence sits.
8 DESTINOS PRINCIPALES
El Data Room en ocho puertas
INVESTMENT OVERVIEW
La tesis de inversión, punto de inflexión actual, milestones principales, preguntas clave y evidencia headline.
BUSINESS & ECONOMICS
Cómo LOTOMIX genera ingresos y cómo se desarrollan las economics desde una localización hasta network scale.
NETWORK & ROLLOUT
Footprint físico actual, pipeline, configuración de hardware y el roadmap desde el estate actual hasta los próximos milestones.
FINANCIALS & FUNDING
Modelo financiero actual, sensibilidades, funding requirement, use of funds y análisis de liquidez.
TECHNOLOGY & PRODUCT
Arquitectura de plataforma, product maturity, ticket validation, administración integration y scalability readiness.
COMMERCIAL TRACTION
Relaciones contracted, pilots, oportunidades comerciales activas, advertising activity y evidencia de pipeline actual.
LEGAL & CORPORATE
Estructura corporativa, acuerdos materiales, legal readiness, regulatory matters, IP y transaction preparation.
EVIDENCE & FULL DATA ROOM
Acceso directo a acuerdos ejecutados, documentos fuente, modelos financieros, materiales técnicos y evidencia histórica.
What Exists Today
What the Capital Unlocks
Next Milestones
MANAGEMENT ROADMAPDecember 2026
Broad commercial rollout target
March 2027
Additional display deployment
April 2027
~770 completed locations targeted
What Must Be Proven
Verify the Case
New to LOTOMIX?
Start with the 3-Minute Investment Overview before opening the underlying due diligence materials.
Already reviewed the case?
See the latest material changes, updated KPIs and newly added evidence.
Análisis detallado (drill-down): sensibilidades y vías de salida
SENSIBILIDADES · AÑO DE LANZAMIENTO
¿Qué ocurre si el rendimiento baja?
Stress test ilustrativo sobre BC 6.7. Los porcentajes son relativos al caso base, no tasas absolutas ni escenarios aprobados por dirección.
| Variable | Adverso | Base | Favorable |
|---|---|---|---|
| Tráfico diario | 75% | 100% | 110% |
| Tasa de interacción | 80% | 100% | 110% |
| Ocupación publicitaria | 70% | 100% | 115% |
| CPM del lector | 85% | 100% | 110% |
| Despliegue monetizable | 75% | 100% | 110% |
| Ingresos media retenidos | 416.710 € | 872.757 € | 1.171.566 € |
| Ingresos ilustrativos | 971.530 € | 1.427.578 € | 1.726.387 € |
| EBITDA ilustrativo | -95.954 € | 360.094 € | 658.903 € |
Explorar un escenario personalizado
Ingresos: 1.427.578 € · EBITDA: 360.094 €
Fórmulas, fuentes y alcance
Peso del lector = 240 interacciones × 26 días × 2 impactos × CPM 5,60 € / 1.000. Peso trasera = 112,32 €/mes. Peso frontal retenido = 400 € × 70% conversión comercial × 70% LOTOMIX = 196 €/mes. Tráfico, interacción y CPM afectan solo al peso PPI; ocupación y despliegue afectan al conjunto media.
Se aplica el ratio ponderado a 872.757,34 € de ingresos media del año de lanzamiento. El resto de ingresos, coste de ventas (158.641,22 €) y OPEX (908.842,80 €) permanecen constantes. Es una aproximación anual: no recalcula el calendario mensual, costes variables, CAPEX, caja ni el efecto del despliegue en app o SaaS. No sustituye al modelo completo.
Fuente: BC 6.7, supuestos y desglose de ingresos activos del portal. El caso base reproduce ingresos y EBITDA del año de lanzamiento.
Vías de salida estratégicas
Operadores de lotería y gaming
Distribución y adquisición digital de clientes.
Plataformas de tecnología de loterías
Software, integración y relaciones con puntos de venta.
Grupos omnicanal del sur de Europa
Conexión entre red física y experiencia digital.
Retail media e infraestructura de pagos
Red conectada, audiencias medibles y capacidad transaccional.
Precedentes de M&A y valor ilustrativo
| Operación | Valor anunciado | Múltiplo / referencia | Fuente |
|---|---|---|---|
| Flutter–Sisal (2021) | €1.913bn | 7.71× EBITDA FY2021E (€248m) | Flutter |
| DraftKings–Jackpocket (2024) | $750m | EBITDA no publicado en el anuncio | SEC / DraftKings |
Sisal: ratio calculado de contraprestación anunciada (incluido repago de deuda) / EBITDA consolidado previsto; incluye 13 M€ atribuibles a minoritarios. Jackpocket: contraprestación anunciada, no múltiplo de EBITDA. Las diferencias de escala, rentabilidad, jurisdicción y derechos requieren ajustes.
Ejemplo ilustrativo: EBITDA proyectado Año 3 BC 6.7 × 7,71 = 56.121.325 €
Resultado mecánico de aplicar un precedente histórico: no es una valoración actual, un precio de equity ni una previsión de venta. Estas categorías de comprador son hipótesis estratégicas; no indican interés ni negociaciones.
Continúa tu revisión
LOTOMIX
Technology, digital media and consumer services integrated into Spain's mixed-lottery retail environment
Investor Summary — Current Data Room Edition
A · INVESTMENT SNAPSHOT
~7,000
Potential FENAMIX network perimeter
CONTRACTUAL NETWORK ACCESS~370
Existing reader footprint
DEPLOYED1,200+
Current rollout / expressed-interest pipeline
PIPELINE~770
Completed-location target by April 2027
MANAGEMENT TARGET€3M
Current financing reference
FUNDRAISINGB · WHAT EXISTS TODAY
Existing Foundation
C · INVESTMENT OPPORTUNITY
LOTOMIX is seeking to convert an existing network position, deployed infrastructure and developed technology into broader commercial scale.
The financing supports:
D · REVENUE ARCHITECTURE
DIGITAL MEDIA
Reader, rear-display and large-format advertising.
SAAS
Recurring platform fee from paying administrations where applicable.
TRANSACTIONS
LOTOMIX fee on eligible transaction activity.
MEMBERSHIPS
Premium consumer subscriptions.
PEÑAS
Commission / participation economics under the approved product and legal structure.
GTV and LOTOMIX recognised revenue are reported separately.
E · CURRENT NETWORK & ROLLOUT
These numbers are not cumulative or equivalent.
Current Hardware Architecture
Where the complete three-screen configuration applies: 1 completed location = up to 3 monetisable digital surfaces.
Not all existing 370 locations currently have all three displays.
F · FUNDING & USE OF CAPITAL
Current Financing: €3M
G · KEY FINANCIAL DRIVERS
Rollout
Number and timing of activated / monetised locations.
Advertising
Traffic, fill and realised CPM / pricing.
SaaS
Number of paying administrations.
Digital
MAU, transactions, paying conversion.
Cost
Hardware deployment and central OPEX.
Detailed driver model available in BC 6.7.
FENAMIX Economic Treatment: The current 30% FENAMIX revenue share applies to the large-format advertising display economics and not to reader or rear-display advertising revenue.
H · What Must Be Proven
Rollout Conversion
Can pipeline convert into active and monetised locations?
Advertising Economics
Can inventory achieve sufficient fill and realised pricing?
Unit Economics
Can actual locations develop toward BC 6.7 contribution assumptions?
Digital Adoption
Can users become active, transact and convert to paid services?
Operating Leverage
Can contribution scale faster than central operating costs?
Downside Framework
BC 6.7 includes driver-based sensitivity analysis for materially weaker execution.
Management can respond by adjusting discretionary deployment and expenditure where operationally and contractually possible.
I · NEXT MILESTONES
MANAGEMENT ROADMAPDecember 2026
Broad commercial rollout target
March 2027
Additional display deployment
April 2027
Approximately 770 completed locations targeted
Evidence Status Legend
J · EVIDENCE & DATA ROOM LINKS
Source Control
Want to Test the Case?
LOTOMIX Investor Data Room
Confidential — Investor Review
Data as of 3 de octubre de 2026 · Current Financial Model: BC 6.7
EXECUTIVE VERSION — VALUE CREATION BRIDGE
| Today | Milestone | Evidence Created |
|---|---|---|
| Pipeline | Activated locations | Actual network conversion |
| Modelled CPM | Paid campaigns | Realised CPM |
| Modelled SaaS | Paying administrations | Actual MRR |
| Tested technology | Production operation | Reliability data |
| Modelled unit economics | Mature location cohorts | Actual contribution |
| Forecast runway | Post-investment execution | Actual capital efficiency |
CURRENT vs FUTURE STATE
LOTOMIX — Current State vs Future State
What exists today versus what the current investment plan is intended to build.
TODAY = EVIDENCE
Current / Deployed / Tested
FUTURE STATE = EXECUTION OF THE APPROVED PLAN
Management Target / Planned / Modelled — not guaranteed
STATUS LEGEND
INVESTMENT THESIS TRANSITION
TODAY
Assets
Technology
Network Access
Pipeline
€3M FINANCING
EXECUTION
Deployment
Commercialisation
Digital Activation
FUTURE OPERATING STATE
Larger Monetised Network
Recurring Economics
Operating Evidence
Bridge: CAPITAL + EXECUTION + VALIDATION
Network
TODAY
Current / Deployed / Tested
These figures are not combined — each has a distinct meaning.
CURRENT PLAN — AFTER SUCCESSFUL EXECUTION
Management Target / Planned / Modelled
3,370 is a longer-term management target, not visually dominant.
Physical Infrastructure
TODAY
Current / Deployed / Tested
Where actual count is not available: CURRENT COUNT TO BE VERIFIED. Future rollout quantities are not substituted.
CURRENT PLAN — AFTER SUCCESSFUL EXECUTION
Management Target / Planned / Modelled
Labelled REFERENCE DEPLOYMENT CASE — not CURRENT ESTATE.
Software Platform
TODAY
Current / Deployed / Tested
CURRENT PLAN — AFTER SUCCESSFUL EXECUTION
Management Target / Planned / Modelled
Classification: PLANNED SCALE STATE. Future scale not claimed as already technically proven.
Ticket Validation
TODAY
Current / Deployed / Tested
CURRENT PLAN — AFTER SUCCESSFUL EXECUTION
Management Target / Planned / Modelled
Scale validation required. Future scale is not used as proof of current readiness.
Administration Integration
TODAY
Current / Deployed / Tested
CURRENT PLAN — AFTER SUCCESSFUL EXECUTION
Management Target / Planned / Modelled
Classification: OPERATING MODEL TARGET.
Advertising Network
TODAY
Current / Deployed / Tested
Not populated with theoretical media capacity.
CURRENT PLAN — AFTER SUCCESSFUL EXECUTION
Management Target / Planned / Modelled
Classification: MODELLED / MANAGEMENT COMMERCIAL TARGET. Full future fill not implied.
Advertising Economics
TODAY
Current / Deployed / Tested
Where unavailable: COMMERCIAL VALIDATION DATA ACCUMULATING. BC assumptions not shown as actual results.
CURRENT PLAN — AFTER SUCCESSFUL EXECUTION
Management Target / Planned / Modelled
Label: MODELLED ECONOMICS.
FENAMIX Economics
TODAY
Current / Deployed / Tested
This is a structural commercial rule, not a future target. Same treatment in both columns.
CURRENT PLAN — AFTER SUCCESSFUL EXECUTION
Management Target / Planned / Modelled
Structural rule unchanged by scale.
SaaS
TODAY
Current / Deployed / Tested
If not commercially active at scale: COMMERCIAL ACTIVATION.
CURRENT PLAN — AFTER SUCCESSFUL EXECUTION
Management Target / Planned / Modelled
Not all completed locations are automatically paying SaaS customers.
App / Consumer Digital
TODAY
Current / Deployed / Tested
No forecast downloads in the TODAY column.
CURRENT PLAN — AFTER SUCCESSFUL EXECUTION
Management Target / Planned / Modelled
BC 6.7 planning assumptions where numerical values are shown.
Transactions
TODAY
Current / Deployed / Tested
CURRENT PLAN — AFTER SUCCESSFUL EXECUTION
Management Target / Planned / Modelled
GTV is not used as company revenue.
Memberships
TODAY
Current / Deployed / Tested
CURRENT PLAN — AFTER SUCCESSFUL EXECUTION
Management Target / Planned / Modelled
2.5% conversion assumption is not presented as achieved performance.
Peñas
TODAY
Current / Deployed / Tested
These three are not merged.
CURRENT PLAN — AFTER SUCCESSFUL EXECUTION
Management Target / Planned / Modelled
Commercial Traction
TODAY
Current / Deployed / Tested
Target accounts are not shown as traction.
CURRENT PLAN — AFTER SUCCESSFUL EXECUTION
Management Target / Planned / Modelled
Emphasis on repeatable commercial conversion, not simply a larger logo list.
Revenue
TODAY
Current / Deployed / Tested
Always include Data as of [date]. No forecast values in TODAY.
CURRENT PLAN — AFTER SUCCESSFUL EXECUTION
Management Target / Planned / Modelled
Explicit label: MANAGEMENT FORECAST. Not visually styled like actual historical revenue.
Revenue Mix
TODAY
Current / Deployed / Tested
If commercial revenue not yet mature: Revenue mix still developing during commercial activation.
CURRENT PLAN — AFTER SUCCESSFUL EXECUTION
Management Target / Planned / Modelled
Unit Economics
TODAY
Current / Deployed / Tested
If not: EARLY VALIDATION DATA.
CURRENT PLAN — AFTER SUCCESSFUL EXECUTION
Management Target / Planned / Modelled
Newly activated locations are not compared directly with mature future-state locations without showing ramp.
OPEX
TODAY
Current / Deployed / Tested
CURRENT PLAN — AFTER SUCCESSFUL EXECUTION
Management Target / Planned / Modelled
OPEX increases with scale but is expected to grow differently from revenue / contribution. Not implied to remain flat.
EBITDA / Operating Leverage
TODAY
Current / Deployed / Tested
CURRENT PLAN — AFTER SUCCESSFUL EXECUTION
Management Target / Planned / Modelled
No future EBITDA target without a clear forecast label. Link to BC 6.7 for actual values.
Cash / Funding
TODAY
Current / Deployed / Tested
CURRENT PLAN — AFTER SUCCESSFUL EXECUTION
Management Target / Planned / Modelled
€3M does not automatically produce a specific valuation outcome. Use Funding → Milestones Bridge.
Team / Organisation
TODAY
Current / Deployed / Tested
No unnecessary biographies.
CURRENT PLAN — AFTER SUCCESSFUL EXECUTION
Management Target / Planned / Modelled
No headcount numbers not contained in BC 6.7.
Reporting / Governance
TODAY
Current / Deployed / Tested
CURRENT PLAN — AFTER SUCCESSFUL EXECUTION
Management Target / Planned / Modelled
Classification: POST-INVESTMENT GOVERNANCE FRAMEWORK.
Risk Profile
TODAY
Current / Deployed / Tested
CURRENT PLAN — AFTER SUCCESSFUL EXECUTION
Management Target / Planned / Modelled
Use 'more validated' rather than 'risk eliminated'. Future state is not stated as no-risk or low-risk.
WHAT CHANGES
WHAT DOES NOT CHANGE
From Existing Foundation to Commercial Scale
Today, LOTOMIX already has network access, an existing reader footprint, developed technology and an identified rollout pipeline.
The current financing plan is intended to convert those assets into a broader activated and monetised network, with stronger advertising, SaaS and digital economics and materially more operating evidence.
The future-state column represents the successful execution of the current management plan — not current operating performance or guaranteed outcomes.
LOTOMIX INVESTOR DATA ROOM — EXECUTIVE INDEX
Índice Ejecutivo del Data Room de Inversor
Acceso en un clic a la información requerida para entender, testear y verificar el caso de inversión LOTOMIX. El mapa de navegación del Data Room — los documentos subyacentes permanecen en sus ubicaciones controladas existentes.
⚠ No crea nuevo contenido. No duplica BC 6.7, contratos, definiciones de KPI o definiciones de rollout. No expone KYC, legal o banking restringido. No coloca documentos superseded antes de los actuales.
Cómo está organizado este Data Room
El Data Room de inversor separa los resúmenes de inversión de la evidencia subyacente de due diligence. El análisis actual orientado al inversor se organiza en ocho categorías principales, mientras que los contratos ejecutados, archivos técnicos, modelos financieros y otros materiales fuente permanecen accesibles a través de enlaces directos de evidencia y el repositorio del Full Data Room. La información actual, histórica, modelada y de pipeline se distingue claramente en todo momento.
Búsqueda global del Data Room
Resultados priorizan CURRENT → EXECUTED → EVIDENCE → SUPERSEDED. Los documentos superseded no aparecen antes que los actuales.
Últimas actualizaciones materiales
Últimas actualizaciones significativas: financieras, comerciales, rollout, legales, técnicas. Útil para inversores que regresan.
Ocho categorías principales
Cada categoría muestra Start Here, Then Review y Evidence para que el inversor no abra documentación cruda antes de entender el contexto.
Paths por persona de inversor
Atajos para distintos revisores. Usan contenido existente únicamente.
Inversor / IC
Revisor Financiero
Revisor Comercial
Revisor Técnico
Revisor Legal
Funciones de acceso rápido
¿Verificar un claim?
¿Necesita los números?
¿Necesita los contratos?
¿Necesita el tech?
Secuencia de revisión recomendada
Proporciona orientación sin forzar un único workflow.
Investor Last Mile Due Diligence Pack
El conjunto limitado de documentos y análisis requeridos para la revisión final del Comité de Inversión.
El propósito NO es reproducir el Data Room completo. Es identificar el pequeño número de materiales que respaldan directamente la decisión de inversión final. Solo material crítico para la decisión.
20
Total Items
15
MUST READ
5
IF NEEDED
20
Max Target
LOTOMIX — Investment Committee Last Mile Pack
The limited set of documents and analyses required for final Investment Committee review
Current Investor Deck
Waterhouse V0.5 — September 2026
Current Financial Model
BC 6.7
Data as of
October 2026
Release Candidate
RC1
Key Facts
~370
Existing reader footprint
1,200+
Pipeline
~7,000
Potential network perimeter
~770
April 2027 management target
€3M
Financing reference
BC 6.7
Current financial model
Key Questions This Pack Answers
Readiness Status — Document Readiness, Not Investment Rating
Financial Package
Current / reconciled / review required
Rollout Evidence
Available / review required
Technology
Summary available
Legal
Readiness matrix available
Core Contracts
Available / restricted
Financial Definitions — Visible Inside Relevant Material
This curated pack contains the principal materials required to understand, test and verify the current LOTOMIX investment case. Full supporting due diligence documentation remains available in the Investor Data Room.
Understand → Test → Verify
Three Review Layers
El Last Mile Pack está organizado en tres capas de revisión, manteniendo el paquete conciso.
Layer A — Investment Decision
The executive materials required to understand the transaction.
Layer B — Analytical Validation
The models and analyses required to test the investment case.
Layer C — Core Evidence
The source documents required to verify the most material claims.
IC Review Paths
Rutas de lectura para revisión de 30 y 60 minutos, rutas de profundización y handoff especialista.
30-Minute Review
Recommended reading-order sequence. These are guides, not rigid time commitments. Detailed technical / legal source documents are not mandatory in this fast track.
60-Minute Review
For deeper committee preparation. This is a review path, not a new content layer.
Deeper if Questioned
For each Last Mile document, a route to deeper detail — keeps the pack compact without sacrificing depth.
Specialist Handoff
If IC wants deeper review, the Last Mile Pack routes specialists deeper rather than containing all specialist material itself.
Change Log, Evidence Check & Final Status
Registro de cambios, verificación de evidencia, material excluido y principio final de selección.
Final Pack Status
Status refers only to document readiness. Do not use "APPROVED INVESTMENT" or similar language.
Last-Mile Evidence Check
Before marking the pack ready, verify every MUST READ item opens correctly.
Broken MUST READ links
0 required
Superseded MUST READ documents
0 required
Unresolved material financial mismatches
0 required
Material deck / Data Room contradictions
0 required
Last Mile Pack Change Log
Only material pack changes need logging. Maintain when RC changes (RC1 → RC2): review whether any Last Mile material changed and update model version, deck, rollout, evidence, status.
| Change | Reason | Affected Item | Date |
|---|---|---|---|
| Initial Last Mile Pack created | Curated IC review pack established | All | 2026-10-01 |
Excluded from Last Mile
These remain accessible in the Full Data Room where appropriate, but are not in the Last Mile Pack.
Final Control
✗ Do not exceed approximately 20 items.
✗ Do not include superseded models.
✗ Do not include historical decks.
✗ Do not duplicate canonical source files.
✗ Do not remove downside.
✗ Do not remove rollout reconciliation.
✗ Do not remove BC 6.7.
✗ Do not turn the Last Mile Pack into another full Data Room.
✗ Do not expose restricted KYC or banking information.
Final Selection Principle
DOES THIS DOCUMENT MATERIALLY HELP AN INVESTMENT COMMITTEE DECIDE?
If the answer is no, it should not be in the Last Mile Pack.
El Data Room completo permanece disponible. Este paquete curado contiene los materiales principales para entender, probar y verificar el caso de inversión actual de LOTOMIX.
Final Investor Decision Matrix
Una vista estructurada de las principales tesis de inversión, la evidencia disponible hoy, las preguntas restantes y la información requerida para resolverlas.
El inversor toma la decisión final. Esta matriz NO recomienda, NO puntúa, NO asigna probabilidades, NO clasifica las tesis.
12
Principal Theses
1
Evidence Available
2
Partially Validated
9
Validation Required
LOTOMIX — Investment Decision Framework
A structured view of the principal LOTOMIX investment theses, the evidence available today, the remaining questions and the information required to resolve them
Current Financial Model
BC 6.7
Current Investor Deck
Waterhouse V0.5 — September 2026
Data as of
October 2026
Release Candidate
RC1
The matrix below separates current investment evidence from the questions that still depend on commercial, operating, technical or legal validation. It is intended to help Investment Committee reviewers identify exactly what is known today, what remains uncertain and where the relevant evidence is located.
Legend
Investor Use Case — Move row by row asking:
Connected Sections
Master Decision Matrix
Tesis → Evidencia hoy → Pregunta restante → Qué la resuelve → Documento a revisar.
Evidence Views
Evidencia de decisión, próxima evidencia y qué NO resuelve la pregunta.
Decision Evidence — Strongest Current Form
For each thesis, the strongest current form of evidence — whether supported by contract, actual operating data, or management model.
01 · Network Access
Executed contract
02 · Pipeline Conversion
Pipeline records
03 · Rollout Execution
Installation records
04 · Advertising Monetisation
Paid commercial activity where available
05 · Location Unit Economics
BC 6.7 unit model
06 · Multi-Revenue Model
Per-stream maturity classification
07 · SaaS Recurring Economics
Pricing model (€30/month reference)
08 · Digital Consumer Economics
Product testing / technical user flows
09 · Technology Readiness
Testing / operating evidence
10 · Legal / Regulatory Executability
Legal / contractual documentation
11 · Capital Sufficiency
BC 6.7 cash model
12 · Operating Leverage
BC 6.7 operating leverage model
Next Evidence — What Would Improve Confidence
Exactly what would improve confidence next. Measurable evidence — not vague "more traction".
01 · Network Access
Pipeline conversion
02 · Pipeline Conversion
Scheduled → Installed conversion rate
03 · Rollout Execution
Monthly installation velocity
04 · Advertising Monetisation
Repeat advertiser + realised CPM
05 · Location Unit Economics
Mature location contribution
06 · Multi-Revenue Model
Repeat revenue + retention per stream
07 · SaaS Recurring Economics
Paying MRR / retention
08 · Digital Consumer Economics
MAU / transactions
09 · Technology Readiness
Scale test / operating performance
10 · Legal / Regulatory Executability
Closure of launch-critical legal items
11 · Capital Sufficiency
Actual vs budget / runway
12 · Operating Leverage
Actual contribution vs OPEX growth
What Does NOT Resolve the Question
Analytical control — makes the matrix strong by distinguishing what would NOT answer the remaining question.
01 · Network Access
02 · Pipeline Conversion
03 · Rollout Execution
04 · Advertising Monetisation
05 · Location Unit Economics
06 · Multi-Revenue Model
07 · SaaS Recurring Economics
08 · Digital Consumer Economics
09 · Technology Readiness
10 · Legal / Regulatory Executability
11 · Capital Sufficiency
12 · Operating Leverage
Decision Framework
LOTOMIX's current investment case is supported by a combination of executed contractual relationships, existing physical infrastructure, developed technology and a driver-based financial model.
Several important components — particularly broader rollout conversion, advertising monetisation, digital adoption, mature unit economics and scale performance — will continue to be validated through execution.
The Decision Matrix makes those distinctions explicit so the Investment Committee can evaluate each element of the thesis independently.
The Final Page Must Answer
Final Control
✗ Do not recommend investment.
✗ Do not score the theses.
✗ Do not assign probabilities.
✗ Do not rank theses.
✗ Do not invent evidence.
✗ Do not present future validation as current proof.
✗ Do not create new financial assumptions.
✗ Do not alter BC 6.7.
✗ Do not turn 1,200+ pipeline into contracted deployment.
✗ Do not turn 770 into a current metric.
✗ Do not treat tested technology as proven scale.
✗ Do not treat GTV as revenue.
Once the transaction process begins, the initial Decision Matrix is preserved. Later updates show Initial Evidence → New Evidence → Current View. The original state of diligence is not retrospectively rewritten.
Abrir Full Data Room / Due Diligence: modelo completo, contratos, evidencia y riesgos
RESUMEN EJECUTIVO · BC 6.7
Resumen de métricas y estado de documentos
Vista consolidada de los indicadores financieros clave del modelo BC 6.7 y del estado de evidencia del Data Room institucional. Fuente única de verdad: LOTOMIX BC 6.7 — September 2026 / Waterhouse / Investment Committee.
Métricas financieras clave
Financiación equity
€3.0M
Sin redención · Sin repago
Lectores PPI iniciales
370
Base instalada existente
POS Fase 1
770
2.310 dispositivos · 28"+48"+reader
Tarjetas NFC
200K
Capa de adquisición · No en P&L core
Periodo
Revenue
EBITDA
Margen
Caja cierre
Launch Year · Nov 26–Oct 27
€1.43M
€0.36M
25.2%
€1.12M
Año 2 · Nov 27–Oct 28
€5.21M
€3.06M
58.8%
—
Año 3 · Nov 28–Oct 29
€10.21M
€7.28M
71.2%
€5.13M
Estado del paquete de revisión Waterhouse
74
Registros totales
57
Disponibles para revisión
14
Registros con archivo
2
Borradores internos
35
Referencias fuente
5
Restringidos disponibles
11
Archivados / audit trail
1
URL pendiente
16
Items de seguimiento
Cobertura de revisión de Waterhouse
77%
La mayoría de registros del Data Room están disponibles para Waterhouse mediante archivos subidos, borradores internos, evidencia restringida, referencias fuente o materiales archivados de audit trail. Los registros sin URL pública directa no son automáticamente documentos faltantes. Los elementos restantes se clasifican como follow-up normal de due diligence o resolución técnica de URL.
BC 6.7 es la fuente financiera actual. Las cifras son proyecciones de dirección y no están auditadas. BC 6.4 y BC 6.3 están archivadas solo para audit trail. Las apuestas oficiales de lotería y GTV no son revenue de LOTOMIX. NFC es una capa de adquisición, no una línea de revenue separada en el P&L core. Las subvenciones permanecen excluidas del caso base hasta concesión formal.
VALUE CREATION BRIDGE
Value Creation Bridge
How execution converts current uncertainty into measurable operating evidence
The purpose is operational de-risking and evidence creation — not forecasting a future company valuation. The objective is to show how the quality of the investment case improves as management converts assumptions into actual evidence and pipeline into revenue-producing operations.
NO VALUATION MULTIPLE ASSUMPTIONS
This section does not forecast future company valuation, target exit multiple, IRR, investor return or share-price target. No SaaS / advertising / EBITDA / revenue multiples or comparable-company valuation are inserted. Successful execution would produce a business supported by more operating evidence and reduced dependence on unvalidated assumptions — not a guaranteed valuation increase.
CORE VALUE-CREATION LOGIC
TODAY
EXECUTION
STRONGER OPERATING EVIDENCE
REDUCED EXECUTION UNCERTAINTY
Reduced uncertainty ≠ guaranteed value appreciation.
Master Value-Creation Table
How each milestone improves the quality of the investment case.
| Current Position | Execution Milestone | New Evidence Created | Uncertainty Reduced |
|---|---|---|---|
| Network access & pipeline | Pipeline → activated locations | Actual conversion rate, installation velocity, monetised count | Network conversion risk |
| 770 locations (management target) | Progressive rollout delivery | Completed locations, monthly velocity, cost per location | Execution / deployment risk |
| Modelled CPM framework | Paid campaigns across inventory | Realised CPM, effective slot price, renewals | Advertising pricing risk |
| Assumed inventory utilisation | Commercialise active inventory | Actual fill, sold vs available, advertiser conversion | Advertising demand / utilisation risk |
| First campaign | Repeat commercial behaviour | Advertiser retention, renewal, repeat spend | Repeatability risk |
| Modelled SaaS (€30/month ref.) | Paying SaaS administrations | Paying count, MRR, conversion, churn | Recurring revenue validation risk |
| Download / adoption assumptions | Downloads → MAU → repeat usage | Activation rate, MAU, retention cohorts | Consumer engagement risk |
| Modelled transaction economics | Actual transaction activity | Real GTV, transaction count, fee revenue | Transaction behaviour / monetisation risk |
| Peña model assumptions | Legally approved peña activation | Active peñas, participants, fee revenue | Community adoption / monetisation risk |
| Tested technology | Production operation | Availability, stability, incident history | Production-readiness risk |
| Functioning technology | Scale operation | Availability under scale, device health, headroom | Technology scale risk |
| Hardware purchased | Installed → activated → monetised | Installation cost, activation time, revenue per asset | Capital productivity risk |
| BC 6.7 modelled unit economics | Mature location cohorts | Actual reader/rear/large revenue, contribution | Unit-economics risk |
| Planned OPEX structure | Contribution > central cost growth | Revenue/contribution/OPEX/EBITDA progression | Operating leverage risk |
| Modelled runway | Capital deployed to plan | Actual deployment, burn, cash balance, runway | Funding / liquidity execution risk |
| Data Room & KPI definitions | Monthly / quarterly reporting | Actual vs budget, forecast updates, risk evolution | Information / governance risk |
| Legal review status | Launch-critical legal completion | Executed terms, payment architecture, regulatory evidence | Legal implementation risk |
| Commercial interest | Interest → contracted → repeat | Pipeline conversion, contracted value, repeat revenue | Commercial conversion risk |
Value-Creation Blocks
Network — Access to Activated Locations
CURRENT POSITION
LOTOMIX has access to the broader FENAMIX network perimeter, approximately 370 existing reader locations, and 1,200+ locations in the current rollout / expressed-interest pipeline.
EXECUTION MILESTONE
Convert pipeline into scheduled → installed → activated → monetised locations.
EVIDENCE CREATED
Network conversion risk
The investment case becomes less dependent on potential network access and more supported by operating network evidence.
Rollout — Target to Actual Delivery
CURRENT POSITION
Approximately 770 completed locations by April 2027 is currently a MANAGEMENT TARGET.
EXECUTION MILESTONE
Progressively deliver completed locations according to the approved rollout plan.
EVIDENCE CREATED
Execution / deployment risk
Do not describe the target itself as value created. Value creation comes from evidence of successful execution against the target.
Advertising — Modelled CPM to Realised CPM
CURRENT POSITION
Reader advertising currently uses a modelled CPM framework, including the existing planning range where applicable.
EXECUTION MILESTONE
Run paid campaigns across sufficient inventory and periods.
EVIDENCE CREATED
Advertising pricing risk
The investment case moves from modelled media economics toward observed media economics.
Advertising — Modelled Fill to Observed Fill
CURRENT POSITION
Future advertising revenue depends materially on assumed inventory utilisation.
EXECUTION MILESTONE
Commercialise active reader, rear-display and large-format inventory.
EVIDENCE CREATED
Advertising demand / utilisation risk
One of the most important commercial validation milestones.
Advertising — First Campaign to Repeat Advertiser
CURRENT POSITION
The strongest evidence is not simply a first campaign but repeat commercial behaviour.
EXECUTION MILESTONE
EVIDENCE CREATED
Repeatability risk
SaaS — Modelled Recurring Revenue to Actual MRR
CURRENT POSITION
SaaS economics may be modelled using the current €30/month reference where applicable.
EXECUTION MILESTONE
Convert activated administrations into paying SaaS administrations.
EVIDENCE CREATED
Recurring revenue validation risk
Do not classify forecast SaaS as recurring revenue before payments begin.
Digital — Downloads to MAU
CURRENT POSITION
The consumer model includes future download / adoption assumptions.
EXECUTION MILESTONE
EVIDENCE CREATED
Consumer engagement risk
Downloads alone do not materially validate the digital investment thesis.
Digital — MAU to Monetised Users
CURRENT POSITION
Continue the digital funnel from active engagement to monetised behaviour.
EXECUTION MILESTONE
EVIDENCE CREATED
Digital monetisation risk
Transactions — GTV to Recognised Revenue
CURRENT POSITION
Transactional economics are currently driven by model assumptions where applicable.
EXECUTION MILESTONE
Generate actual transaction activity.
EVIDENCE CREATED
Transaction behaviour and monetisation risk
Maintain GTV ≠ LOTOMIX Revenue throughout.
Peñas — Model to Real Participation
CURRENT POSITION
The peñas business case contains assumptions around administrations, number of peñas, members, average participation and applicable fee.
EXECUTION MILESTONE
Activate legally and commercially approved peña functionality and measure actual participation.
EVIDENCE CREATED
Community adoption / monetisation risk
Do not imply legal completion or commercial validation unless supported.
Technology — Tested to Production
CURRENT POSITION
Core technology has been materially developed and important functionality is under testing / validation.
EXECUTION MILESTONE
Complete production-readiness requirements and begin broader commercial operation.
EVIDENCE CREATED
Production-readiness risk
Technology — Production to Scale
CURRENT POSITION
Functioning technology is not automatically proof of scale.
EXECUTION MILESTONE
Support larger location count, device estate, user activity, ticket-validation volume and advertising events.
EVIDENCE CREATED
Technology scale risk
This distinction must remain explicit.
Hardware — Purchased to Revenue-Producing
CURRENT POSITION
The value-creation event is not hardware purchased. The economically relevant progression is capital invested in hardware becoming revenue-producing infrastructure.
EXECUTION MILESTONE
EVIDENCE CREATED
Capital productivity risk
Unit Economics — Modelled to Observed
CURRENT POSITION
BC 6.7 provides modelled location economics.
EXECUTION MILESTONE
Generate sufficient mature location cohorts.
EVIDENCE CREATED
Unit-economics risk
This may be one of the most important value-creation events in the entire investment case.
Location Cohorts
CURRENT POSITION
Newly activated locations should not be judged against mature model economics immediately.
EXECUTION MILESTONE
EVIDENCE CREATED
Maturity-misjudgement risk
Only where this type of ramp is supported by actual model / operating data. Do not invent specific maturity periods.
OPEX — Planned Structure to Demonstrated Operating Leverage
CURRENT POSITION
BC 6.7 models how central costs scale with the network.
EXECUTION MILESTONE
Grow contribution faster than central operating cost.
EVIDENCE CREATED
Operating leverage risk
The relevant proof is actual operating leverage, not simply revenue growth.
Cash — Modelled Runway to Demonstrated Capital Discipline
CURRENT POSITION
BC 6.7 models capital requirements and cash runway.
EXECUTION MILESTONE
Deploy capital according to plan while adjusting discretionary investment to actual commercial evidence.
EVIDENCE CREATED
Funding / liquidity execution risk
Governance — Investment Case to Actual Reporting
CURRENT POSITION
The Data Room contains KPI definitions, reporting structure, financial reconciliation and risk framework.
EXECUTION MILESTONE
Produce consistent monthly and quarterly investor reporting.
EVIDENCE CREATED
Information / governance risk
Legal — Review to Operational Implementation
CURRENT POSITION
Legal readiness may vary by functionality.
EXECUTION MILESTONE
Complete launch-critical legal / contractual requirements for the relevant product modules.
EVIDENCE CREATED
Legal implementation risk
Do not describe this as regulatory risk eliminated unless the evidence supports that conclusion.
Commercial Pipeline — Interest to Contracted Value
CURRENT POSITION
Each step creates stronger evidence. Do not present interest as economic value creation until it converts.
EXECUTION MILESTONE
EVIDENCE CREATED
Commercial conversion risk
Quality of Evidence Ladder
A factual maturity framework — not a score. Different LOTOMIX revenue streams may sit at different levels.
LEVEL 1
MANAGEMENT ASSUMPTIONLEVEL 2
THIRD-PARTY INTERESTLEVEL 3
TEST / PILOTLEVEL 4
PAID COMMERCIAL ACTIVITYLEVEL 5
REPEAT COMMERCIAL ACTIVITYLEVEL 6
SCALED HISTORICAL EVIDENCEQuality of Revenue
Value creation is not only more revenue but potentially better quality revenue.
Quality of Network
The quality of the network evidence increases at each stage.
Quality of Advertising Evidence
Makes the commercial de-risking process highly intuitive.
Quality of Digital Evidence
The higher-value evidence is further down the funnel.
Value-Creation Bridge
Current Investment Case
Execution Milestones
Stronger Evidence
Higher Quality of Earnings / Operating Evidence
Used carefully — does not imply a valuation conclusion.
Milestone → Uncertainty Reduced
| Milestone | Current Status | Evidence Produced | Main Uncertainty Reduced |
|---|---|---|---|
| Broader commercial launch | MANAGEMENT TARGET (Dec 2026) | Administration activation, platform operation, advertising monetisation, real user behaviour | Commercial activation risk |
| Additional display deployment | MANAGEMENT TARGET (Mar 2027) | Deployment efficiency, large-format inventory growth, commercialisation at scale, device management | Deployment scale risk |
| First / recurring advertising campaigns | PENDING EVIDENCE | Realised CPM, fill, renewals, repeat spend | Advertising pricing & demand risk |
| Paying SaaS base | PENDING EVIDENCE | Paying count, MRR, conversion, churn | Recurring revenue validation risk |
| App MAU | PENDING EVIDENCE | Activation rate, MAU, retention cohorts | Consumer engagement risk |
| Transaction activity | PENDING EVIDENCE | Real GTV, fee revenue, repeat behaviour | Transaction monetisation risk |
| Peñas adoption | PENDING EVIDENCE | Active peñas, participants, fee revenue | Community adoption risk |
| Mature location economics | PENDING EVIDENCE | Actual contribution per location cohort | Unit-economics risk |
| Operating leverage | PENDING EVIDENCE | Contribution growth > OPEX growth, EBITDA progression | Operating leverage risk |
Value-Creation Events on the Roadmap
December 2026
Broad Commercial Rollout Targeted
MANAGEMENT TARGETPOTENTIAL EVIDENCE
Do not describe as completed before evidence exists.
March 2027
Additional Display Deployment
MANAGEMENT TARGETPOTENTIAL EVIDENCE
April 2027
~770 Completed Locations Targeted
MANAGEMENT TARGETPOTENTIAL EVIDENCE
Important Qualification: This does not automatically create a particular company valuation.
Financial Evidence Progression
Over time, forecast dependence should decrease as operating history increases.
Investor Risk Evolution
Risks do not disappear — evidence shifts.
Rollout
Advertising
Technology
Digital
Unit economics
Liquidity
Link to Investment Thesis
Every value-creation milestone connects back to one or more investment theses.
Monitor & Connect
How LOTOMIX Creates Investment Evidence
The current LOTOMIX investment case already contains tangible assets: network access, an existing physical footprint, developed technology and identifiable rollout demand.
The next stage of value creation is operational rather than theoretical: converting those assets into activated locations, paid advertising, recurring SaaS, digital engagement, observed unit economics and measurable operating leverage.
Successful execution would progressively reduce the proportion of the investment case dependent on assumptions and increase the proportion supported by actual operating evidence.
INVESTMENT THESIS VALIDATION
Validación de tesis de inversión
Los supuestos clave detrás del caso de inversión LOTOMIX, la evidencia que los respalda hoy y los hitos para validarlos. Conecta tesis → supuesto crítico → evidencia → validación → qué la desafiaría.
⚠ Framework factual de madurez. No constituye una recomendación de inversión. Cada tesis debe testarse frente a evidencia actual e hitos futuros.
Tabla maestra de tesis
¿Qué ya está parcialmente de-riesgado?
Solo ítems con evidencia. Ningún ítem está totalmente de-riesgado.
Relación de red
Marco de acceso documentado existente.
Riesgo materialmente reducidoHuella existente
Despliegue físico de lectores ya existente.
Riesgo materialmente reducidoDesarrollo de producto
Tecnología núcleo sustancialmente desarrollada.
Riesgo materialmente reducidoFuncionalidad técnica
Flujos clave probados.
Riesgo materialmente reducidoInterés de mercado
Pipeline actual de administraciones existe.
Riesgo materialmente reducido¿Qué queda por de-riesgar?
Conectado al KPI Cockpit.
Tesis → KPI
Cada tesis vinculada a KPIs medibles.
Conversión de red
→ activated-locations · monetised-locations · rollout-velocity
Publicidad
→ advertising-fill · realised-cpm · revenue-per-location
Digital
→ mau · transactions-per-mau · paying-conversion
Financiero
→ revenue · contribution · burn · runway
Escala
→ system-availability · device-health · scan-capacity
Tesis → Caso adverso
El análisis adverso no se desconecta de la tesis.
Próximos 3 eventos de validación
Despliegue comercial amplio
Diciembre 2026
OBJETIVO DE DIRECCIÓNEvidencia requerida: Ubicaciones activadas y monetizadas
Tesis afectada: T1
Despliegue de pantallas adicionales
Desde marzo 2027
OBJETIVO DE DIRECCIÓNEvidencia requerida: Inventario publicitario en vivo y fill
Tesis afectada: T2
Escala de ubicaciones completadas
~770 ubicaciones para abril 2027
OBJETIVO DE DIRECCIÓNEvidencia requerida: Ubicaciones completadas y contribución por ubicación
Tesis afectada: T3
Evolución del caso de inversión
Posición actual: entre riesgo de despliegue y riesgo comercial. Los riesgos previos no están totalmente eliminados.
Preguntas que el Comité de Inversión debe responder
Sin veredicto en nombre del inversor.
Framework de tesis de inversión
LOTOMIX ya dispone de varios de los activos fundacionales para el despliegue comercial, incluyendo acceso de red, huella física existente y tecnología desarrollada.
El caso de inversión depende principalmente de convertir esos activos en ubicaciones activadas, ingresos publicitarios y digitales medibles, unit economics validados y apalancamiento operativo dentro del envelope de capital planificado.
El Data Room debe permitir probar cada supuesto de forma independiente frente a evidencia actual y hitos operativos futuros.
MAPA DE EVIDENCIA · TRAZABILIDAD AFINACIÓN → EVIDENCIA
Mapa de Evidencia de Inversión
Afirmaciones clave de inversión y la evidencia disponible en el Data Room.
Leyenda — hechos actuales vs proyecciones
| Afirmación de inversión | Estado actual | Evidencia soporte | Ubicación en el Data Room |
|---|---|---|---|
A.LOTOMIX tiene acceso contractual a la red de lotería mixta FENAMIX, aproximadamente 7.000 puntos de venta potenciales. | CONTRATADO Contratado | ||
B.LOTOMIX / infraestructura asociada dispone de aproximadamente 370 ubicaciones con lector existentes en la huella operativa. | DESPLEGADO Desplegado / huella existente | ||
C.Más de 1.200 puntos adicionales han manifestado interés / están en el pipeline actual de despliegue. ⚠ No describir como ingresos contratados ni despliegue garantizado. | PIPELINE Pipeline / demanda expresada | ||
D.La plataforma software, validación de tickets, arquitectura backend e integración de administración están materialmente desarrolladas y en pruebas operativas. | EN PRUEBAS Desarrollado / pruebas / pre-comercial | ||
E.La validación de tickets ha sido probada y opera correctamente en el entorno de desarrollo actual. ⚠ No implicar certificación regulatoria salvo documentación que la acredite. | VALIDADO Validado en entorno de pruebas | ||
F.LOTOMIX combina tecnología de lotería-retail con una red física de publicidad digital en lector, pantalla trasera y pantalla gran formato. | DESPLEGADO Infraestructura desplegada / despliegue en expansión | ||
G.El despliegue comercial amplio se prevé durante diciembre 2026, con despliegue adicional de pantallas desde marzo 2027. ⚠ Objetivo de ejecución de dirección, no un resultado garantizado. | PLANIFICADO Planificado | ||
H.El plan actual de dirección prevé aproximadamente 770 ubicaciones completadas para abril 2027. | OBJETIVO DIRECCIÓN Objetivo de dirección | ||
I.LOTOMIX tiene múltiples líneas de ingresos identificadas: publicidad digital, SaaS/tarifas de plataforma, economía transaccional, monetización de app, membresías, sindicatos/peñas y servicios digitales. ⚠ No presentar ingresos previstos como ingresos existentes. | MODELADO Modelado / parcialmente comercializado | ||
J.El 30% de cesión FENAMIX aplica específicamente a los ingresos de la pantalla gran formato y no a los ingresos de lector ni de pantalla trasera. | CONTRATADO Estructura comercial contractual | ||
K.BC 6.7 es el modelo financiero principal actual que soporta las proyecciones operativas y financieras del caso base. | MODELADO Modelo financiero de dirección | ||
L.El caso de inversión se ha sometido a stress test con ocupación publicitaria, tráfico y despliegue materialmente inferiores. | MODELADO Análisis de escenarios | ||
M.La defensibilidad de LOTOMIX se basa en la combinación de acceso físico al retail, hardware desplegado, integración software, relaciones operativas en el sector lotería, infraestructura publicitaria y ecosistema transaccional / de usuarios. ⚠ No presentar el foso como absoluto ni imposible de replicar. | DESPLEGADO Activos existentes + foso basado en ejecución |
El caso de inversión de LOTOMIX está soportado por una combinación de acuerdos ejecutados, una huella física existente, tecnología desarrollada, preparación activa de despliegue y un modelo financiero basado en drivers. Las previsiones y los objetivos de despliegue permanecen claramente separados de la evidencia contratada o desplegada existente.
EVIDENCE GAP CLOSURE PLAN
Plan de Cierre de Brechas de Evidencia
Qué queda por demostrar, cómo LOTOMIX pretende validarlo y qué evidencia operativa cerrará cada pregunta de inversión. El propósito no es debilitar el caso de inversión, sino distinguir claramente entre evidencia disponible, supuestos respaldados principalmente por modelado de dirección, validación que debería surgir durante el despliegue comercial y evidencia que requiere completion técnica, legal, comercial u operativa.
⚠ No fabricar evidencia. No presentar evidencia futura esperada como si ya existiera. No marcar un supuesto validado porque dirección cree que es razonable. No usar datos de piloto pequeño como prueba a escala de red sin contexto.
Evidence Types
Supporting evidence is classified into eight controlled types. This classification is used throughout the Evidence Gap Plan.
Contractual Evidence
Executed agreements, amendments and formal commitments.
Physical Evidence
Installed hardware, location records and deployment evidence.
Technical Evidence
Testing, architecture, platform operation and performance.
Commercial Evidence
Paid campaigns, contracts, invoices, repeat customers.
Operating Evidence
Actual usage, traffic, activation and location-level performance.
Financial Evidence
Recognised revenue, contribution, cash flow and actual-vs-budget results.
Legal / Regulatory Evidence
Legal opinions, authorisations, contracts and compliance documentation.
Management Model
BC 6.7 and approved planning assumptions.
Master Evidence Gap Table
Claim → Evidence Today → Gap → Validation Method → KPI / Proof → Owner → Status. No arbitrary evidence score.
| Claim / Assumption | Evidence Available | Evidence Gap | Validation Method | KPI / Proof | Owner | Status |
|---|---|---|---|---|---|---|
Network access to FENAMIX mixed-lottery retail network Contractual Evidence | Executed relationship documentation, contractual terms, network documentation | Network access ≠ deployment conversion. How much of the available network converts to active LOTOMIX locations? | Rollout conversion tracking | Pipeline Conversion Rate | Commercial | EVIDENCE AVAILABLE |
~370 existing reader locations form current physical footprint Physical Evidence | Installation inventory, hardware records, location records, photographs | Exact installed / online / activated / monetised counts require reconciliation — do not answer all four with the same number | Reconciled installation / device database | Installed / Online / Activated / Monetised counts | Operations | PARTIALLY VALIDATED |
1,200+ additional locations in expressed-interest / rollout pipeline Commercial Evidence | FENAMIX communications, registrations, rollout-interest records | Pipeline-to-installation conversion not yet demonstrated at broader commercial scale | Pipeline → Scheduled → Installed → Activated tracking | Pipeline Conversion Rate | Commercial | EARLY DATA |
LOTOMIX can execute the approved rollout schedule Operating Evidence | Existing physical deployment, rollout plan, administration demand, operating preparation | Actual deployment velocity at the scale required for the near-term plan | Installations per week/month, activation/month, scheduling-to-activation time, install cost, hardware lead time | Installations per week/month | Operations | EXECUTION VALIDATION REQUIRED |
Reader economics may use 800 visits/day Management Model | Management / model assumption | Reliable observed traffic across a representative location sample | Location traffic measurement, reader interaction telemetry, administration-level traffic reporting | Traffic distribution (high/medium/lower) | Operations | VALIDATION REQUIRED |
Reader capture rate ~30% Operating Evidence | Management / model assumption | Observed conversion from location traffic to reader interaction across representative sample | Track visitors, scans/interactions, capture, variance by location and time period | Observed capture rate | Operations | OPERATING VALIDATION REQUIRED |
Two monetisable advertising impacts per interaction Technical Evidence | Model assumption | Confirm both impressions are technically delivered, commercially saleable, and satisfy approved measurement methodology | Advertising-delivery logs / telemetry | Billable impression count vs technical display events | Technology | TECHNICAL EVIDENCE REQUIRED |
Future media revenue depends on advertising fill Commercial Evidence | Current commercial pipeline / advertiser activity where available | Observed fill across a meaningful commercial period | Track inventory available / sold / delivered / paid campaigns — separately for reader, rear, large-format | Fill rate by screen type | Commercial | COMMERCIAL VALIDATION REQUIRED |
Reader planning may use €6–€9 CPM Commercial Evidence | Management / model reference | Actual realised market pricing at scale | Track contracted CPM, realised CPM, effective price after discounts, agency channel, campaign duration | Realised CPM (not list price) | Commercial | COMMERCIAL VALIDATION REQUIRED |
Rear-display advertising economics Commercial Evidence | Defined advertising loop / inventory mechanics | Actual advertiser willingness to pay for rear-display inventory | Paid campaigns demonstrating realised slot price, occupancy, advertiser renewal | Realised rear-display slot price | Commercial | COMMERCIAL VALIDATION REQUIRED |
Large-format display revenue depends on slots, pricing, occupancy, FENAMIX 30% share Commercial Evidence | Model assumption | Actual commercial economics across operating displays | Track gross advertiser revenue, discounts, FENAMIX share, LOTOMIX net revenue, revenue per large display, repeat advertisers | Net revenue per large display | Commercial | COMMERCIAL VALIDATION REQUIRED |
Advertisers will return after first campaign Commercial Evidence | Initial commercial activity / discussions where documented | Repeat purchasing behaviour | Track First Campaign → Campaign Completed → Renewal → Repeat Spend | Advertiser Renewal / Repeat Rate | Commercial | WAITING FOR OPERATING DATA |
Sales cycle duration Commercial Evidence | Initial commercial activity | Actual time required to convert advertiser from opportunity to paid campaign | Track first contact → proposal → negotiation → contract → live campaign | Observed Sales Cycle | Commercial | DATA ACCUMULATING |
SaaS activation ~€30/month Commercial Evidence | Model / activation reference | Actual conversion from activated administration to paying SaaS administration | Track active administrations, paying administrations, billing start, MRR, churn | SaaS Paying Penetration | Digital / Product | COMMERCIAL VALIDATION REQUIRED |
SaaS retention over time Operating Evidence | Model assumption | Evidence that administrations continue paying over time | Monthly cohorts of paying administrations — retained, cancelled, suspended, unpaid | SaaS retention / churn by cohort | Digital / Product | TIME-BASED VALIDATION REQUIRED |
App downloads ~250,000 Operating Evidence | Planning reference | Actual acquisition performance and acquisition cost | Track downloads, source, organic vs paid, acquisition spend | Downloads + CAC | Digital / Product | VALIDATION REQUIRED |
MAU sensitivity 20% / 25% / 30% Operating Evidence | Planning sensitivity reference | Observed active-user behaviour | Track registrations, MAU, DAU, repeat sessions, retention cohorts | MAU / Registered Users and MAU / Downloads | Digital / Product | VALIDATION REQUIRED |
15 transactions per MAU per month Operating Evidence | Planning reference | Actual transaction frequency | Track active transacting users, transactions, transactions per MAU, frequency by cohort | Transactions per MAU | Digital / Product | DIGITAL MONETISATION VALIDATION REQUIRED |
Transaction GTV Financial Evidence | Model assumption | Actual gross transaction volume | Backend transaction records — GTV tracked separately from LOTOMIX recognised revenue | GTV vs LOTOMIX revenue, avg transaction amount, frequency, seasonality | Finance | VALIDATION REQUIRED |
0.5% transaction fee Financial Evidence | Model reference | Confirm actual realised economics after contractual terms, transaction mechanics, payment costs, legal structure | Actual fee recognition from transaction records | Realised transaction fee % | Finance | VALIDATION REQUIRED |
Membership conversion ~2.5% Commercial Evidence | Planning reference | Actual paid conversion | Track eligible users, paying members, tier, MRR, conversion | Membership conversion rate | Digital / Product | COMMERCIAL VALIDATION REQUIRED |
Membership retention Operating Evidence | Model assumption | Whether paid users remain subscribed | Track cohorts — month 1, 2, 3 and subsequent periods | Churn, retention, MRR retention | Digital / Product | TIME-BASED VALIDATION REQUIRED |
Peñas adoption (administrations, peñas, members, participation) Operating Evidence | BC 6.7 model assumptions | Actual participation behaviour | Track administrations offering peñas, peñas created, participants, repeat participation, avg monthly participation | Peñas participation rate | Digital / Product | PRODUCT / COMMERCIAL VALIDATION REQUIRED |
Peñas legal structure Legal / Regulatory Evidence | Pending | Any legal element remaining pending before commercial activation | Final legal analysis, consumer terms, administration terms, payment/ownership structure, prize-handling framework | Executed legal documentation | Legal | LEGAL CONFIRMATION REQUIRED |
Wallet / payment architecture Legal / Regulatory Evidence | Pending design | Unresolved legal or technical architecture around planned wallet / payment flow | Payment-provider agreement, funds-flow diagram, legal review, technical integration, reconciliation tests | Executed payment architecture + legal review | Legal | LEGAL + TECHNICAL VALIDATION REQUIRED |
Ticket-validation accuracy Technical Evidence | Functionality technically tested where evidenced | Formalised performance metrics across broader ticket samples / live usage | Track successful reading rate, error rate, processing time, unsupported formats, fallback | Validation accuracy metrics | Technology | TECHNICAL EVIDENCE REQUIRED |
Technology production readiness Technical Evidence | Developed / tested components | Some components may require production hardening before broad commercial deployment | Production-readiness checklist, monitoring, backup, security controls, release/rollback, incident process | Production-readiness sign-off | Technology | PRE-LAUNCH TECHNICAL EVIDENCE |
Technology scale — infrastructure supports larger network Technical Evidence | Architecture / testing | Evidence that infrastructure can support planned larger network | Load testing, capacity testing, device-fleet testing, performance monitoring, production data | Expected Load vs Tested Load vs Actual Load | Technology | SCALE VALIDATION REQUIRED |
Device fleet operations at scale Operating Evidence | Current device management | Ability to manage hundreds/thousands of distributed devices efficiently | Track online devices, remote updates, incidents, MTTR, replacement, device uptime | Device uptime, MTTR | Technology | SCALE OPERATING VALIDATION REQUIRED |
Hardware failure / maintenance profile at scale Operating Evidence | BC 6.7 assumptions where contained | Actual failure / maintenance profile at larger scale | Track device failure rate, maintenance incidents, replacement cost, downtime | Failure rate, downtime | Operations | VALIDATION REQUIRED |
Hardware / deployment cost at scale Financial Evidence | Approved procurement / deployment cost (BC 6.7) | Actual cost at scale | Compare budget cost vs actual cost for reader, rear display, large display, logistics, installation | Deployment Cost per Location | Operations | VALIDATION REQUIRED |
Installation capacity at required velocity Operating Evidence | Operating preparation | Actual capacity to install and activate locations at required velocity | Track installations per team, installations per month, lead time, rework, failed installations | Installations per team/month | Operations | OPERATING VALIDATION REQUIRED |
Location contribution (BC 6.7 assumptions) Financial Evidence | BC 6.7 model | Observed contribution from mature locations | Measure Recognised Location Revenue minus Direct Location Costs = Actual Contribution, by activation cohort | Actual contribution per location cohort | Finance | VALIDATION REQUIRED |
Location payback period Financial Evidence | Model assumption | Actual time for location contribution to recover incremental deployment capital | Only calculate once deployment cost is actual, mature contribution data exists, commercial ramp is observable | Actual payback months | Finance | VALIDATION REQUIRED |
Operating leverage — OPEX scales sub-linearly with locations Financial Evidence | BC 6.7 model | Observed evidence that contribution scales faster than central OPEX | Track locations, contribution, OPEX, EBITDA — Network Growth vs OPEX Growth | OPEX per location, EBITDA margin trend | Finance | VALIDATION REQUIRED |
Cash burn vs BC 6.7 forecast Financial Evidence | BC 6.7 forecast | Actual post-investment cash usage | Monthly opening cash, operating cash, capex, working capital, closing cash | Actual vs budget cash burn | Finance | FINANCIAL OPERATING EVIDENCE |
Runway supports planned capital deployment Financial Evidence | BC 6.7 forecast | Whether actual capital deployment and commercial performance support planned runway | Rolling forecast incorporating actual revenue, burn, capex, working capital — preserve Original BC 6.7 Runway and Current Forecast Runway | Original vs Current Forecast Runway | Finance | VALIDATION REQUIRED |
Potential public funding Financial Evidence | Potential in certain planning cases | Formal approval / award | Only classify as CONFIRMED PUBLIC FUNDING once formal documentary evidence exists | Formal award documentation | Finance | POTENTIAL / TARGET |
38 of 38 gap items shown. No material evidence gap remains UNASSIGNED.
Commercial Proof by Revenue Stream
Each stream may be at a different validation stage.
| Revenue Stream | Current Evidence | Missing Evidence | Closure KPI |
|---|---|---|---|
| Reader advertising | 370-reader estate + SEUR campaign evidence | Realised fill + CPM at scale | Reader fill, realised CPM |
| Rear advertising | Defined inventory mechanics | Paid campaigns demonstrating slot price | Realised rear slot price |
| Large-format advertising | Model economics + FENAMIX 30% share structure | Actual commercial economics across operating displays | Net revenue per large display |
| SaaS | Model / activation reference (€30/month) | Paying MRR + retention | SaaS paying penetration, MRR |
| Transactions | Model reference (0.5% fee) | Actual GTV + realised fee | GTV, realised fee % |
| Memberships | Model reference (2.5% conversion) | Actual paid conversion + retention | Membership conversion, churn |
| Peñas | BC 6.7 model assumptions | Participation behaviour + legal structure | Peñas participation rate |
| App monetisation | Product / testing | MAU + monetisation | MAU, transactions per MAU |
Investment Thesis Gap Map
Network Thesis
Needs:
Advertising Thesis
Needs:
Unit-Economics Thesis
Needs:
Digital Thesis
Needs:
Scale Thesis
Needs:
Funding Thesis
Needs:
Evidence Gap → Value Creation
The remaining evidence gaps are exactly what the investment plan is designed to test.
Evidence Gap → Capital
Rollout Conversion
Supported by Deployment capital
CPM / Fill
Supported by Advertising commercialisation
Technology Scale
Supported by Platform hardening
User Adoption
Supported by Digital activation
Capital alone does not guarantee validation — it enables the execution that generates evidence.
Evidence Gap → Timing
Evidence Gap → Owner
Operations
Rollout / location performance
Commercial
Fill / CPM / advertisers
Technology
Production / scale
Digital / Product
MAU / transactions / memberships
Finance
Contribution / cash / runway
Legal
Peñas / payment / privacy
Top Evidence to Be Created Next
The limited number of evidence items directly associated with the next current milestones. Not ranked by an arbitrary score — updated dynamically as evidence is generated.
Evidence Validation Governance
Automatic Evidence Closure
An evidence gap can change status only when the required source has been attached / verified — with source, date and owner/verification. A gap cannot become VALIDATED merely because the field was manually marked complete without campaign evidence.
Partial Validation
PARTIALLY VALIDATED is allowed — e.g. actual CPM exists for 10 locations, one advertiser, one month. This is useful evidence but may not represent network-scale performance. Evidence is not forced into a validated / not-validated binary.
Representativeness
For operating evidence, where relevant: Sample Size, Period, Locations Covered, Revenue / Volume Covered. A small pilot is not presented as network-scale proof.
Evidence Age
Every actual validation item shows "Evidence as of [date]". Where evidence becomes stale or business conditions change: REVALIDATION MAY BE REQUIRED. Historical evidence does not remain equally representative forever.
Validation History
When a gap closes, the original assumption is preserved alongside the evidence progression.
Evidence Created This Quarter
✓ First repeat advertiser
✓ First mature location cohort
✓ Actual SaaS MRR
✓ Actual transaction behaviour
✓ Load-test completion
Evidence Still Being Built
• Network-scale fill and CPM
• Mature location contribution across cohorts
• SaaS retention beyond month 3
• Advertiser renewal rate
• Technology scale under production load
Evidence Gap ≠ Risk. Some evidence gaps represent normal early-stage validation rather than a specific adverse event. The Risk Register is linked only when a gap materially affects a risk.
Executive Investor View
Understandable in under one minute.
| Area | Evidence Today | What Comes Next |
|---|---|---|
| Network | Contract + existing footprint | Pipeline conversion |
| Advertising | Infrastructure + commercial activity | Fill + realised CPM + renewals |
| SaaS | Model / activation | Paying MRR + retention |
| Digital | Product / testing | MAU + monetisation |
| Technology | Developed / tested | Production + scale evidence |
| Unit Economics | BC 6.7 model | Mature location actuals |
| Financial | Forecast model | Actual vs budget + runway |
From Assumptions to Evidence
LOTOMIX's current investment case combines existing contractual, physical and technical evidence with a number of operating assumptions that will be validated progressively during commercial rollout.
The purpose of the Evidence Gap Closure Plan is to identify those assumptions explicitly and define the operating data, commercial proof, technical evidence or legal documentation required to convert them into verified facts.
As these gaps close, investor analysis can rely progressively less on management assumptions and more on actual operating history.
CORE FRAMEWORK
Cross-References
INVESTMENT CASE PROOF PROGRESSION
Progresión de Prueba del Caso de Inversión
Cómo el caso de inversión LOTOMIX progresa de fundación contractual a evidencia operativa repetible. El propósito no es crear otra previsión, sino mostrar la progresión de evidencia requerida para mover el caso de acceso estratégico y economía modelada hacia rendimiento operativo repetible, medible y escalable.
⚠ No crear puntuación de inversión. No declarar toda la empresa en una sola etapa de prueba. No tratar un contrato como prueba de ingresos. No tratar instalación como prueba de monetización. No tratar primeros ingresos como ingresos recurrentes.
CENTRAL PROGRESSION
Contractual Foundation
EVIDENCE AVAILABLEWhat it means: LOTOMIX has the contractual / strategic rights and relationships required to access the relevant operating environment.
Evidence required: Executed FENAMIX agreement, relevant annexes, administration agreements, material commercial contracts.
Next proof point: Conversion of access into actual deployment
Physical Deployment
DEPLOYEDWhat it means: Hardware exists in real operating locations.
Evidence required: Installation inventory, hardware records, deployment evidence — ~370 existing reader locations.
Next proof point: Active operating locations
Operational Activation
VALIDATION REQUIREDWhat it means: Installed infrastructure is actively functioning within the intended operating environment.
Evidence required: Backend telemetry, administration activation records, device status, operating usage.
Next proof point: Commercial monetisation
Paid Commercial Revenue
COMMERCIAL VALIDATION REQUIREDWhat it means: The operating infrastructure begins to produce recognised LOTOMIX revenue.
Evidence required: Contracts, invoices, billing records, recognised revenue, payment records.
Next proof point: Revenue repeats
Repeat Revenue
WAITING FOR OPERATING DATAWhat it means: Commercial activity occurs across more than one period or purchase cycle.
Evidence required: Renewals, retention, repeat transactions, recurring billing, repeat campaign spend.
Next proof point: Unit economics become observable and representative
Validated Unit Economics
VALIDATION REQUIREDWhat it means: There is enough operating history to compare actual economics against BC 6.7.
Evidence required: Representative sample across sufficient locations, periods, campaigns, users.
Next proof point: Repeatability across larger cohorts
Repeatable Scale
SCALE VALIDATION REQUIREDWhat it means: LOTOMIX demonstrates the operating model can be replicated across a larger number of locations without disproportionate performance reduction.
Evidence required: Rollout, technology, hardware, commercial, economics, operations evidence at scale.
Next proof point: Operating leverage
Operating Leverage
FINANCIAL MODEL / FUTURE VALIDATIONWhat it means: Revenue and contribution increase faster than the central operating-cost base.
Evidence required: Actual financial history demonstrating contribution growth, OPEX growth, EBITDA progression, cash performance — reconciled with BC 6.7.
Next proof point: Sustained operating leverage
Where LOTOMIX Sits Today
Different parts of the business are at different proof stages. The company is NOT forced into one single stage — parallel systems progress independently.
| Area | Current Proof Stage | Note |
|---|---|---|
| FENAMIX relationship | Contractual Foundation | Contractual network access / potential network (~7,000-point perimeter) |
| Reader network | Physical Deployment | ~370 existing reader locations deployed |
| Ticket validation | Technical / Operational Validation | Functionality technically tested |
| Advertising | Commercial Validation Required | Infrastructure + current commercial activity |
| SaaS | Current actual maturity | Activation status — paying penetration pending |
| App | Product / User Validation | Product / technical readiness |
| Peñas | Product / Legal / Commercial | Legal structure pending before commercial activation |
| Unit Economics | Modelled / Early Actual | BC 6.7 model — early actual evidence |
| Network Scale | Future Validation | Repeatable scale not yet demonstrated |
| Operating Leverage | Financial Model / Future | Forecast model — actual validation future |
Proof Matrix by Revenue Stream
| Revenue Stream | Infrastructure | First Revenue | Repeat Revenue | Unit Economics | Scale Evidence |
|---|---|---|---|---|---|
| Reader advertising | DEPLOYED | IN PROGRESS | NOT YET VALIDATED | NOT YET VALIDATED | NOT YET VALIDATED |
| Rear-display advertising | DEPLOYED | NOT YET VALIDATED | NOT YET VALIDATED | NOT YET VALIDATED | NOT YET VALIDATED |
| Large-format advertising | DEPLOYED | NOT YET VALIDATED | NOT YET VALIDATED | NOT YET VALIDATED | NOT YET VALIDATED |
| SaaS | AVAILABLE | NOT YET VALIDATED | NOT YET VALIDATED | NOT YET VALIDATED | NOT YET VALIDATED |
| Transactions | AVAILABLE | NOT YET VALIDATED | NOT YET VALIDATED | NOT YET VALIDATED | NOT YET VALIDATED |
| Memberships | AVAILABLE | NOT YET VALIDATED | NOT YET VALIDATED | NOT YET VALIDATED | NOT YET VALIDATED |
| Peñas | NOT YET VALIDATED | NOT YET VALIDATED | NOT YET VALIDATED | NOT YET VALIDATED | NOT YET VALIDATED |
| App monetisation | AVAILABLE | NOT YET VALIDATED | NOT YET VALIDATED | NOT YET VALIDATED | NOT YET VALIDATED |
Revenue Stream Progressions
Each revenue stream has its own maturity sequence. Streams are at different stages — do not collapse them into one.
Reader Advertising
Rear-Display Advertising
9,360 passes/month is an operating inventory metric — not commercial proof.
Large-Format Advertising
30% FENAMIX share applies only to large-format advertising revenue.
SaaS
€30/month is a pricing reference — paying penetration pending actual data.
Transactions
GTV ≠ LOTOMIX Revenue.
Memberships
2.5% conversion remains an assumption until actual data exists.
Peñas
Legal / product readiness must not be skipped before commercial proof.
Parallel Proof Progressions
Technology Proof
Rollout Proof
Standard visual language used across the Data Room.
Commercial Proof
Financial Proof
This progression is not automatic.
Operating Leverage Chain
Do not declare operating leverage based solely on forecast numbers.
Next Proof Points
Populated from current execution priorities. Items already validated are not displayed as future proof points.
More Activated Locations
KPI: Number activated
Evidence: Backend telemetry + activation records
Thesis: Network thesis
Actual Advertising Fill
KPI: Sold / available inventory
Evidence: Inventory delivery logs
Thesis: Advertising thesis
Realised CPM / Pricing
KPI: Campaign economics
Evidence: Contracted + realised CPM records
Thesis: Advertising thesis
Repeat Advertiser
KPI: Second contracted campaign
Evidence: Second contract, invoice, campaign delivery — not stated intention
Thesis: Commercial repeatability
Paying SaaS Base
KPI: Actual MRR
Evidence: Billing records + paying administrations
Thesis: Recurring revenue thesis
Actual MAU
KPI: App analytics
Evidence: MAU / registered users + retention cohorts
Thesis: Digital thesis
Mature Location Contribution
KPI: Recognised revenue less direct cost
Evidence: Cohort contribution data across sufficient periods
Thesis: Unit economics thesis
Technology Scale Evidence
KPI: Load vs tested vs actual
Evidence: Load test results + production monitoring
Thesis: Scale thesis
Evidence Quality Control
What qualifies as sufficient evidence at each stage. No manual relabelling without supporting evidence.
Timeline Overlay
Roadmap milestones overlaid without implying certainty.
Broader commercial rollout may create additional operational / commercial evidence
Additional display deployment may create broader advertising and device-scale evidence
770 completed-location target may provide stronger rollout and scale evidence
Validation History
For each material proof point, an audit trail of de-risking is preserved.
Post-Investment Status Progression
As evidence develops, statuses move only when evidence exists. Historical status changes are preserved.
Proof ≠ Guarantee. Each successive stage reduces dependence on unvalidated assumptions but does not eliminate commercial, operational or financial risk.
Current vs Future State
Shows where LOTOMIX is now versus the current plan.
Evidence Gap Plan
Identifies missing evidence. Proof Progression shows the maturity sequence that evidence creates.
More mature evidence → less dependence on assumptions → stronger operating case.
Executive Investor View
Compact summary — approximately six lines.
| Proof Area | Evidence Today | Next Proof |
|---|---|---|
| Network | Access + deployed reader footprint | Pipeline conversion / activation |
| Advertising | Infrastructure + current commercial activity | Fill + realised pricing + repeat |
| SaaS | Current activation status | Paying MRR + retention |
| Digital | Product / technical readiness | MAU + monetisation |
| Unit Economics | BC 6.7 model / early data | Mature actual contribution |
| Scale | Existing deployment | Repeatable rollout + operating leverage |
No overall score. No percentage validated, maturity score or investment readiness score. Different evidence categories cannot be meaningfully collapsed into one number — stage descriptions only.
From Access to Operating Proof
LOTOMIX's current investment case is already supported by contractual relationships, existing physical infrastructure, developed technology and identifiable rollout demand.
The next phase of the investment case is about converting those foundations into progressively stronger forms of evidence: active locations, paid revenue, repeat revenue, observed unit economics, repeatable deployment and ultimately operating leverage.
The Data Room tracks these stages separately so investors can distinguish clearly between what has already been demonstrated and what remains to be validated through execution.
CENTRAL PROGRESSION
Cross-References
Cronología de Progresión de Evidencia
Cómo el caso de inversión LOTOMIX progresa de fundación contractual a evidencia operativa.
Evidence Progression Timeline
How the LOTOMIX investment case moves progressively from contractual foundation to operating evidence
The purpose is to show how the investment case becomes progressively less dependent on assumptions as actual operating evidence accumulates.
Do not imply that reaching one stage guarantees progression to the next.
§ 27 · INVESTOR 'WHY THIS MATTERS' NOTE
The LOTOMIX investment case becomes stronger when assumptions are replaced by operating evidence. This timeline shows which forms of evidence already exist and which validation steps remain ahead.
No promotional language is required.
§ 28 · DO NOT CALL IT 'CONFIDENCE SCORE'
Although the concept is investor confidence, do not label any section 'Investor Confidence Score'. Use:
The Data Room should provide evidence.
The investor decides how much confidence to place in it.
§ 1 · CREATE THE MASTER TIMELINE
| Evidence Stage | What It Proves | Current LOTOMIX Evidence | Next Proof Point |
|---|---|---|---|
| CONTRACTUAL EVIDENCE | the contractual framework exists. | — | — |
| PHYSICAL DEPLOYMENT | LOTOMIX has moved beyond concept and has physical infrastructure in the market. | — | — |
| OPERATIONAL ACTIVATION | installed infrastructure is genuinely operating. | — | — |
| PAID COMMERCIAL EVIDENCE | someone is actually paying for the economic proposition. | — | — |
| REPEAT REVENUE | commercial activity is beginning to repeat rather than occurring as a one-off event. | — | — |
| VALIDATED UNIT ECONOMICS | Show when LOTOMIX has enough operating evidence to compare actual economics meaningfully with BC 6.7. | — | — |
| SCALE EVIDENCE | the model is becoming repeatable at a larger scale. | — | — |
| OPERATING LEVERAGE | — | — | — |
Each stage should display:
Do not create an overall confidence score.
§ 2 · STAGE 1
CONTRACTUAL FOUNDATION
PROVES:
the contractual framework exists.
Evidence:
DOES NOT PROVE:
§ 3 · STAGE 2
PHYSICAL DEPLOYMENT
PROVES:
LOTOMIX has moved beyond concept and has physical infrastructure in the market.
Existing Reader Footprint:
approximately 370 existing reader locations where still current.
Evidence:
DOES NOT PROVE:
§ 4 · STAGE 3
OPERATIONAL ACTIVATION
PROVES:
installed infrastructure is genuinely operating.
Progression:
Evidence:
KEY KPI:
Activated Locations
Do not use installed count as a substitute.
§ 5 · STAGE 4
PAID COMMERCIAL EVIDENCE
PROVES:
someone is actually paying for the economic proposition.
Show the first point where operating infrastructure begins generating recognised revenue.
Evidence:
Advertising
Paid campaign.
SaaS
Paying administration.
Transactions
Actual LOTOMIX fee revenue.
Membership
Paying subscriber.
Peñas
Recognised LOTOMIX fee revenue.
Do not include these as paid commercial evidence:
§ 6 · STAGE 5
REPEAT REVENUE
PROVES:
commercial activity is beginning to repeat rather than occurring as a one-off event.
Evidence:
This should be visually important.
Do not classify first revenue as repeat revenue.
§ 7 · STAGE 6
VALIDATED UNIT ECONOMICS
Show when LOTOMIX has enough operating evidence to compare actual economics meaningfully with BC 6.7.
Evidence:
Use:
Do not declare unit economics validated from a single location or a single campaign.
§ 8 · STAGE 7
SCALE EVIDENCE
PROVES:
the model is becoming repeatable at a larger scale.
Show evidence that LOTOMIX can reproduce the model across a broader estate.
Evidence:
Rollout
Repeated activation of locations.
Technology
Larger device fleet and load.
Commercial
Broader advertiser demand.
Operations
Support capability.
Economics
Stable / understandable unit economics across cohorts.
It does NOT mean all business risk disappears.
§ 9 · STAGE 8
OPERATING LEVERAGE
Show evidence that contribution growth is outpacing central OPEX growth.:
Evidence:
This should be based on actual operating history. Do not classify forecast EBITDA as operating leverage evidence.
§ 10 · SHOW LOTOMIX'S CURRENT POSITION BY AREA
Do NOT place the whole company at one single stage.
| Area | Current Evidence Stage | Next Evidence |
|---|---|---|
| Network relationship | Contractual Foundation | Deployment conversion |
| Reader network | Physical Deployment | Activation / monetisation |
| Ticket validation | Technical / Operational Evidence | Production-scale evidence |
| Advertising | Current commercial stage | Repeat paid revenue |
| SaaS | Current maturity | Paying MRR / retention |
| Digital | Product / early usage stage | MAU / monetisation |
| Unit Economics | Model / early actual | Representative cohorts |
| Scale | Future validation | Repeatable network evidence |
| Operating Leverage | Model / early actual | Historical financial evidence |
Populate only using current evidence.
§ 11 · CREATE A QUARTERLY VERSION
For quarterly investor reporting show a compact timeline:
For each material area, identify only the progression that genuinely occurred.
Example — Advertising:
Do not move stages simply because time passed.
§ 12 · CREATE 'NEW EVIDENCE SINCE LAST REVIEW'
New Evidence Created Since Last Review
Maximum approximately 5–7 items.
Examples:
Every item should link to source evidence.
§ 13 · CREATE 'ASSUMPTIONS STILL DOMINANT'
Areas Still Primarily Modelled
Examples where applicable:
This prevents the timeline from implying that the entire business has become actual simply because some areas have.
§ 14 · CREATE 'EVIDENCE QUALITY' DEFINITIONS
CONTRACTUAL
Documented contractual position.
PHYSICAL
Installed / deployed evidence.
OPERATIONAL
System / location actively operating.
COMMERCIAL
Paid customer / advertiser evidence.
REPEAT
Commercial behaviour repeated.
ECONOMIC
Observed unit economics.
SCALE
Repeated evidence across a broader estate.
FINANCIAL
Operating leverage / cash history.
These are categories, not scores.
§ 15 · SOURCE EVERY TIMELINE EVENT
Every material timeline event should include:
Examples:
Paid Campaign — 12/2026
Source: campaign / invoice evidence.
Load Test Completed — [date]
Source: technical test record.
Do not allow timeline events based only on management narrative.
§ 16 · DO NOT USE PLANNED MILESTONES AS COMPLETED EVIDENCE
The following remain future until actual evidence exists:
§ 17 · CREATE A SEPARATE FORWARD-LOOKING ROW
Under the evidence timeline show:
Next Expected Validation Events
Examples:
Do not visually merge with completed evidence.
§ 18 · CONNECT CAPITAL TO EVIDENCE
For each significant new evidence stage, optionally show:
Capital Category Supporting It
Hardware / Deployment Capital
Commercial Capital
Technology Capital
Digital Capital
Do not imply direct one-to-one causality where multiple factors contribute.
§ 19 · CONNECT TO INVESTMENT THESIS
Each timeline stage should show which thesis it strengthens.
This provides a direct connection between execution and IC reasoning.
§ 20 · CONNECT TO EVIDENCE GAPS
When evidence is created, update the relevant Evidence Gap Closure Plan.
Example:
Status may become EARLY ACTUAL EVIDENCE, not necessarily FULLY VALIDATED.
§ 21 · CONNECT TO DECISION MATRIX
When the evidence level changes materially, update the Final Investor Decision Matrix.
Example:
Before:
"Will advertisers pay?"
After:
"Is the realised pricing repeatable across wider inventory?"
The question should evolve with the evidence.
§ 22 · CONNECT TO FORECAST ACCURACY
Actual evidence such as rollout, fill, CPM, cost should feed the Forecast Accuracy Tracker.
This allows the investor to see both:
This allows the investor to see both evidence maturity and forecast accuracy.
§ 23 · CREATE 'PROOF DENSITY' WITHOUT A SCORE
Do NOT create:
Instead show factual counts where useful:
Only if these counts are meaningful.
Do not convert them into an overall rating.
§ 24 · INVESTOR-FACING DESIGN
Use a clean horizontal timeline on desktop. Recommended visual:
Below each stage show only: current status, one or two evidence examples, next proof point.
Do not display long paragraphs in the visual.
§ 25 · MOBILE DESIGN
On mobile use a vertical progression. Each stage should show:
Avoid horizontal scrolling.
§ 26 · PDF / PRINT
The executive timeline should export cleanly in landscape format. Include:
Do not include interactive-only information without static equivalent.
§ 29 · PRESERVE HISTORICAL TIMELINE
Do not remove earlier evidence events when later evidence arrives.
These form the historical proof chain.
Correct errors through documented amendment rather than silent removal.
§ 30 · CREATE MATERIAL-EVENT FILTER
Only include events that materially increase understanding of:
Do not include:
The timeline should remain meaningful.
§ 31 · CREATE 'EVIDENCE REGRESSION' HANDLING
Evidence can sometimes weaken.
Do not remove prior evidence. Add the new evidence and update current interpretation.
Evidence progression is not guaranteed to move in only one direction. This is important.
§ 32 · CREATE 'EVIDENCE REVISED' STATUS
Where new data materially changes interpretation, use:
And explain:
Do not present the timeline as an uninterrupted success story.
§ 33 · CREATE A CURRENT QUARTER FOCUS
Quarterly reporting should highlight:
This is more useful than repeating the full historical timeline every quarter.
Link to full history where required.
§ 34 · DO NOT DUPLICATE PROOF PROGRESSION
Use the existing Proof Progression framework as the conceptual structure.
This change adds: dates + evidence events + quarterly movement.
It should not become a separate competing conceptual model.
§ 35 · DO NOT DUPLICATE VALUE CREATION
Cross-link them. Do not repeat the same narrative in both.
§ 36 · DO NOT DUPLICATE DAY 0 VS TODAY
Keep roles distinct.
§ 37 · INVESTOR SUMMARY
From Assumptions to Operating Evidence
LOTOMIX's investment case begins with contractual access, existing infrastructure and management assumptions.
Commercial execution progressively adds stronger forms of evidence: operating locations, paid revenue, repeat revenue, observed unit economics, repeatable scale and ultimately financial operating history.
The Evidence Progression Timeline preserves that evolution so investors can see exactly when and how the original investment case becomes supported by actual operating data.
§ 38 · NAVIGATION
Integrate under:
Cross-link to:
Do not create a new homepage category.
FINAL CONTROL
✗ Do not create an investor confidence score.
✗ Do not assign probabilities.
✗ Do not imply later evidence stages are guaranteed.
✗ Do not classify pipeline as commercial evidence.
✗ Do not classify first revenue as repeat revenue.
✗ Do not classify repeat revenue as scale evidence.
✗ Do not classify forecast economics as actual unit economics.
✗ Do not rewrite historical events.
✗ Do not hide negative or revised evidence.
✗ Do not create a separate competing proof framework.
THE PERMANENT EVIDENCE CHAIN MUST REMAIN:
with dates, sources, and next proof points attached to each stage.
SAVE ALL CHANGES IN THE EDITOR ONLY. DO NOT PUBLISH.
INVESTMENT CASE
Una posición construida, no un punto de partida teórico.
Esta sección explica por qué LotomiX no es simplemente una app de loterías. Es una posición de infraestructura construida que combina acceso contractual al canal, hardware instalado, software operativo, captura de datos y retail media monetizable.
Acceso al Canal
Marco estratégico y ruta documentada de acceso al canal de lotería minorista mixta.
Infraestructura Instalada
Dispositivos SphereScan/PPI, equipos de punto de venta minorista y soportes digitales.
Software Operativo
LotoAds, LotomiX, telemetría, APIs, gestión de campañas y software operativo.
Capa de Monetización
Retail media, DOOH, campañas CPM, participación en ingresos y potencial de datos comerciales.
Business Case
Una visión estructurada de por qué LotomiX es invertible.
Problema
El canal de lotería mixta sigue sin digitalizar suficientemente, con procesos manuales, telemetría limitada, operaciones fragmentadas y baja monetización de medios.
GROUP STRUCTURE
PREMIA TECH GROUP Estructura Operativa
PREMIA TECH GROUP actúa como la estructura holding que coordina las tres unidades operativas principales del ecosistema: SPHERE, LOTOMIX y LOTOADS. Juntas combinan infraestructura, software de consumo y monetización de retail media en una plataforma integrada.
HOLDING COMPANY
PREMIA TECH GROUP
Coordinación del grupo
Ecosistema operativo integrado que combina infraestructura minorista, software y monetización.
Hoja de Ruta
Cronograma de Ejecución
La hoja de ruta separa lo que ya es operativo de lo que se está expandiendo, revisando o preparando para la due diligence de inversores.
Phase 1
Base Operativa
Phase 2
Despliegue Comercial
Phase 3
Expansión de Software
Phase 4
Capa de Producto Consumo
Phase 5
Revisión Inversor & Legal
Esta actualización para inversores resume el estado del software en Premia Tech Group, incluyendo SphereScan/Sphere, LotomiX y LotoAds.
Modelo de ingresos
How LOTOMIX Makes Money
Esta es la explicación principal del modelo de negocio de LOTOMIX. El inversor identifica quién paga, por qué paga y qué ingresos retiene LOTOMIX. Otras secciones del Data Room remiten a este bloque mediante un resumen breve y un enlace.
Retailer SaaS
Pagador
Establecimiento adherido
Servicio
Acceso a la plataforma y herramientas contratadas
Ingreso
Tarifa recurrente por establecimiento activo y facturable
DOOH / Retail Media
Pagador
Anunciante o agencia
Servicio
Publicidad en lectores, pantallas traseras y pantallas frontales
Ingreso
Publicidad comercializada según el formato y las condiciones del modelo
App / Digital Advertising
Pagador
Anunciante o cliente de campañas
Servicio
Publicidad y comunicaciones digitales, sujetas a audiencia disponible y consentimiento cuando corresponda
Ingreso
Campañas o impactos monetizados según los supuestos documentados
Memberships
Pagador
Usuario suscriptor
Servicio
Funcionalidades premium
Ingreso
Suscripción, según precio y conversión del modelo activo
Peñas / Transaction Services
Pagador
Usuario, peña o establecimiento, según el servicio y contrato
Servicio
Tecnología y gestión
Ingreso
Comisiones o tarifas expresamente contempladas en BC 6.7
No se añade como ingreso activo ningún fee transaccional que no esté incluido en BC 6.7. Cualquier fee transaccional adicional queda como sensibilidad upside fuera del caso base hasta su validación.
| Soporte | Descripción | Especificación | Participación FENAMIX |
|---|---|---|---|
| PPI Reader | Publicidad del lector | 11,6″ lector | Sin participación |
| Rear Screen | Publicidad de pantalla trasera | 23,8″ vertical (actual) | Sin participación |
| Large-Format Front Screen | Publicidad frontal LOTOADS | 43″ (actual) · 48″ (procurement BC 6.7) | 30% sobre neto |
El reparto del 30% de FENAMIX aplica exclusivamente a la publicidad en pantalla frontal de gran formato. No aplica a la publicidad del lector PPI ni a la pantalla trasera.
Existente / histórico
43″ — unidades instaladas de muestra/históricas
BC 6.7 Fase 1
48″ — procurement previsto (770 unidades)
Las apuestas oficiales de lotería son volumen de transacción (GTV), no ingresos de LOTOMIX. Solo las tarifas o comisiones aplicables se reconocen como ingresos.
| Concepto | Tratamiento | ¿Es ingreso LOTOMIX? |
|---|---|---|
| Volumen de apuestas (GTV) | Volumen de transacción | No |
| Premios y saldos de usuarios | Pasivo / fondos de terceros | No |
| Tarifa o comisión aplicable | Ingreso de servicio | Sí |
| Ingreso reconocido (Peñas Y1) | Comisión de tecnología/gestión | 117.024 € |
Customer Acquisition & Referral Layer
Las tarjetas NFC (200.000 en BC 6.7) funcionan como capa de captación de clientes y trazabilidad de referencias. Dirigen usuarios a la app y a las peñas, permitiendo medir la adquisición por canal.
| Fuente | Estado comercial | Evidencia disponible | Driver financiero | Ingreso caso base Y1 | Dependencias |
|---|---|---|---|---|---|
| Retailer SaaS | Operativo | Plataforma desplegada, tarifa definida | POS activos facturables × tarifa mensual | 247.340 € | Adhesión de establecimientos, activación de facturación |
| DOOH / Retail Media | Parcial: lectores operativos, pantallas en prueba | 370 lectores PPI, campaña SEUR | POS-mes × ocupación × precio por formato | 872.757 € | Instalación de pantallas, validación de fill, rate cards de agencia |
| App / Digital Advertising | Previsto | App en desarrollo, infraestructura de notificaciones prevista | Usuarios registrados × campañas × CPM (€6) | 7607 € | Lanzamiento de app, consentimiento de usuarios, escala de audiencia |
| Memberships | Previsto | Definición de producto avanzada | Usuarios × 1,5% conversión × ARPU €25 | 182.850 € | Lanzamiento de app, integración de pagos, funcionalidades premium |
| Peñas / Transaction Services | En prueba | Estructura legal de peñas pendiente de validación | Peñas × 3% conversión pagante × ARPU €8 | 117.024 € | Estructura legal, vía SELAE, wallet/custody |
La existencia de software operativo no debe presentarse automáticamente como evidencia de ingresos comerciales.
Continúa tu revisión
La Primera Red Publicitaria Integrada de 3 Pantallas para Lotería
Despliegue Fase 1 BC 6.7: 770 POS · 2.310 dispositivos
LA RED PUBLICITARIA DE LOTERÍA MÁS POTENTE
3 Touchpoints Publicitarios
Impacto máximo en el punto de venta
Audiencia Captiva de Alto Valor
Jugadores, ganadores y personas en cola
Programmático & DOOH
Inventario CPM con campañas premium
Interactivo & Dinámico
Pop-ups, promociones y contenido en tiempo real
Ingresos Recurrentes Escalables
Suscripciones + CPM + Data & Analytics
Vista Explotada — Ecosistema de 3 Pantallas
Pantalla Frontal LotoAds
- Publicidad DOOH de alto impacto
- Campañas CPM premium
- Visibilidad de marca
- Contenido interactivo
- Retail media
Lector PPI SphereScan
- Validación de premios
- Verificación de boletos
- Promociones interactivas
- Pop-ups instantáneos
- Campañas cross-selling
- NFC / QR
Pantalla Trasera
- Publicidad para clientes en cola
- Alto dwell time
- Visibilidad premium
- Marketing de cola
- Campañas programáticas
Fotografías reales de hardware instalado · Evidencia visual bajo NDA · No renders ficticios
770
Puntos de Venta
BC 6.7 Fase 1 — circuito completo
2,310
Pantallas Digitales
3 por ubicación (770 × 3)
370
Lectores PPI Instalados
Pantallas táctiles capacitivas activas de 11,6"
+400
Lectores en Despliegue
BC 6.7 Fase 1: 770 POS (370 + 400)
3
Touchpoints Publicitarios
Por ubicación
LotoAds CMS
Interfaz ilustrativa de LotoAds CMS
43"
11.6"
23.8"
- Gestión centralizada de contenido
- Control remoto de pantallas
- Programación de campañas
- Segmentación de audiencia
- Analítica de rendimiento
- Monitorización en tiempo real
- Una sola plataforma
CÓMO FUNCIONA LA RED
Beneficios Clave
Visibilidad Máxima
3 Touchpoints
DOOH Programático
Campañas CPM
Interactivo
Data & Insights
Ingresos Recurrentes
Retail Media
Una ubicación minorista. Tres touchpoints digitales. Una plataforma publicitaria centralizada. Máxima monetización de cada visita de cliente.
El pipeline de expansión de LOTOMIX se extiende más allá del circuito inicial de Fase 1 de 770 POS. Las ubicaciones futuras no se tratan como inventario activo de tres pantallas hasta que estén instaladas y activadas.
La estructura contractual Sphere/PPI cubre el lector PPI, la capa de pantalla trasera, la instalación y la explotación, sujeta a verificación legal final de los acuerdos ejecutados y anexos a nivel de tienda. El reparto FENAMIX 70/30 aplica solo al contrato de pantallas grandes LotoAds de 43", sujeto a verificación legal final.
LA PRIMERA Y ÚNICA RED DE RETAIL MEDIA DE LOTERÍA DE 3 PANTALLAS
MÉTRICAS Y SUPUESTOS · RESUMEN ORIENTADO AL INVERSOR
Métricas Operativas Clave y Supuestos
Resumen compacto de los valores aprobados vigentes. Las categorías distinguen visualmente hechos actuales, pipeline, objetivos de dirección y supuestos de modelo. Fuente: Registro Maestro KPI (BC 6.7). Previsión de dirección, no auditada.
Hechos y activos existentes / acuerdos ejecutados.
Red potencial FENAMIX
puntos de venta / points of sale
7,000
Contracted network access / potential footprint
Huella de lectores existente
ubicaciones / locations
370
Existing / deployed footprint
Lector A1D / PPI
pantalla / screen
11.6-inch
Current commercial specification
Pantalla trasera
pantalla / screen
23.8-inch
Current specification
Pantalla gran formato LOTOADS
pantalla / screen
43-inch
Current commercial specification
Economía comercial FENAMIX
% del revenue publicitario de pantalla gran formato / % of large-format advertising revenue
30% FENAMIX / 70% LOTOMIX
Contractual commercial structure
Modelo financiero
BC 6.7
Current principal management financial model
Ronda de capital
€3 million
Current fundraising parameters
Rango valoración pre-money
€12m–€15m
Current fundraising parameters
Interés expresado / demanda, no despliegue contratado.
Lista de espera / interés de despliegue actual
ubicaciones adicionales / additional locations
1,200+
Pipeline / expressed interest
Objetivos de ejecución de dirección, no resultados garantizados.
Ubicaciones completadas objetivo — abril 2027
ubicaciones / locations
770
Management rollout target
Objetivo de red a largo plazo
ubicaciones / locations
3,370 by 2029
Long-term management target
Despliegue comercial amplio
fecha / date
December 2026
Management execution target
Despliegue adicional de pantallas
fecha / date
March 2027
Management execution target
770 ubicaciones completadas
fecha / date
April 2027
Management rollout target
Supuestos de modelo, no datos operativos medidos salvo validación.
Configuración de despliegue completo inicial (500 ubicaciones)
ubicaciones y pantallas / locations & screens
500 locations / 1,500 screens
Reference deployment case
Supuesto SaaS
por mes / per month
€30
Approved base assumption
Visitas diarias por lector
visitas/día / visits/day
800
Model assumption
Tasa de captura / lectura
%
30%
Model assumption
Lecturas por lector y día
lecturas/día / readings/day
240
Model assumption
Días operativos
días/mes / days/month
26
Model assumption
Impresiones por lector y mes
impresiones/lector/mes / impressions/reader/month
12,480
Model assumption
Rango CPM del lector
CPM
€6–€9
Model assumption
Slot publicitario pantalla trasera
10s slot / 100s loop / 10 advertisers
Operating assumption
Pasadas mensuales por pantalla trasera
pasadas/mes / passes/month
9,360
Operating assumption
Slots publicitarios gran formato
slots publicitarios / advertising slots
10
Model assumption
Precio referencia gran formato
por slot/mes / per slot/month
€40
Model assumption
Descargas de app
descargas / downloads
250,000
Planning reference
Sensibilidad MAU
% de descargas / % of downloads
20% / 25% / 30%
Model assumption
Transacciones por MAU
apuestas/MAU/mes / bets/MAU/month
15
Behavioural assumption
Comisión de transacción
% del GTV / % of GTV
0.5%
Model assumption
Conversión a membresía
%
2.5%
Model assumption
Mix de membresía
%
40% Lottery / 30% Football / 30% Full-Plus
Model assumption
Modelo de peñas / sindicatos
500 admin × 5 = 2,500 peñas × 20 members = 50,000 positions
Model assumption
Referencia de financiación pública
por administración / per administration
€10,000
Target / potential support assumption
GTV (volumen de transacción) ≠ revenue reconocido LOTOMIX. Descargas ≠ usuarios activos. Objetivos de despliegue no son resultados garantizados. Los supuestos de modelo no son datos operativos medidos salvo validación.
FINANCIAL MODEL RECONCILIATION
Reconciliación del modelo financiero
Asegurar que cada número financiero para inversores reconcilia con BC 6.7 y traza a su driver operativo. BC 6.7 permanece como la fuente financiera de control. No se crea un segundo modelo.
⚠ Capa de reconciliación y trazabilidad. No constituye un segundo modelo ni una valoración. Cada número material debe trazar: supuesto → driver → cálculo → estado financiero → flujo de caja.
Mapa maestro de reconciliación
Fuente financiera de verdad actual
BC 6.7
MODELO FINANCIERO PRINCIPAL ACTUAL DE DIRECCIÓNTodos los resúmenes financieros para inversores deben reconciliarse con BC 6.7. Las versiones anteriores pueden permanecer por trazabilidad histórica pero no deben poblar páginas actuales.
November 2026 – October 2029 · Estado: Management forecast · Not audited
Mapa de fuente financiera
Cadenas de drivers por línea de ingresos
Publicidad lector
Supuestos del modelo salvo telemetría real.
Pantalla trasera
El volumen de pases NO es ingresos. Usa fill y precio de BC 6.7.
Gran formato (43"/48")
El 30% FENAMIX aplica SOLO a gran formato. No a lector ni trasera.
SaaS
Pagadoras ≠ activadas ≠ instaladas salvo que BC 6.7 lo establezca.
Transacciones
GTV NUNCA se incluye en ingresos reconocidos. €2,275M GTV × 0,5% ≈ €11.375.
Membresías
Descargas ≠ usuarios activos ≠ miembros pagadores.
Peñas
Los €400K NO son ingresos LOTOMIX. Son GTV.
App / comunicaciones
Sin figuras plug. Cada línea con driver documentado.
Reconciliación de rollout a ingresos
El reconocimiento de ingresos sigue la curva de activación de BC 6.7. La fecha de instalación ≠ fecha de ingresos maduros salvo que el modelo lo establezca.
Diferencias de timing
Reconciliación 370 / 500 / 770
Huella de lectores existente
Referencia de despliegue completo inicial (donde aplique)
Objetivo de ubicaciones completadas abril 2027
500 ubicaciones ≠ 1.500 ubicaciones. Ubicaciones y pantallas son separadas.
Recuento de pantallas (config 500)
No aplicar la economía de una pantalla a las 1.500 indiscriminadamente.
Calidad de ingresos
ACTUALCONTRACTEDCOMMERCIAL ACTIVATIONMODELLEDFUTUREPrevisión separada de histórico real.
Bruto vs neto
Valor bruto: GTV, gasto bruto de anunciantes, ingresos brutos de gran formato.
Ingresos reconocidos LOTOMIX: Solo el importe atribuible a LOTOMIX.
No mostrar valor bruto bajo titular 'Revenue'.
Contribución
Ingresos reconocidos − costes directos por ubicación = Contribución.
No restar OPEX central a nivel de contribución. Misma definición en Unit Economics, Financial Model, KPI Cockpit y Downside.
EBITDA
Una definición BC 6.7: Contribución − OPEX central.
No usar EBITDA ajustado/operativo/gestión interchangeably. Todaadjuste divulgado separadamente.
Mapa OPEX
No reagrupar costes de forma que cambie la interpretación económica.
Capex
• Capex hardware
• Capex instalación
• Capex tecnología / desarrollo
• Otra inversión capitalizada
No tratar toda inversión como OPEX. No capitalizar si BC 6.7 lo trata como gasto.
Working capital / Flujo de caja
EBITDA ± WC − Capex ± otros = Flujo neto de caja.
EBITDA no es sustituto de flujo de caja.
Necesidad de financiación
Caja apertura + proceeds + OCF − capex − WC = Caja cierre.
€3M conectado al modelo de caja real. Cierre año lanzamiento: €1,124,373.
Runway
Caja / burn neto aprobado (forward-looking).
No calcular runway desde un único mes histórico.
Downside / Upside
Alteran drivers, no % arbitrario. Fluyen: Revenue → Contribución → EBITDA → Caja → Runway.
Solo supuestos aprobados en BC 6.7.
Por qué el cálculo simplificado puede diferir de BC 6.7
Mensual / Anual / Run-rate
Especificar en cada métrica. Run-rate ≠ anual real.
Moneda e impuestos
IVA incl/excl, bruto/neto, antes/después revenue share, nominal euros.
Redondeo
€19.394 → €19.4k; €1.070.500 → €1.07m. Reconcilia al valor exacto.
Porcentajes
Denominadores consistentes. 30% FENAMIX solo sobre gran formato.
Registro de supuestos financieros
Reconciliación real vs presupuesto
Preparado para reporting futuro. No poblar reales futuros.
No sobrescribir el presupuesto original con previsiones posteriores.
Dashboard de integridad del modelo
Vista admin interna. Objetivo: cero discrepancias materiales sin resolver antes de publicación.
Líneas de ingresos reconciliadas
0
Objetivo: 0
Líneas que requieren revisión
0
Objetivo: 0
Discrepancias unit economics
0
Objetivo: 0
Discrepancias de rollout
0
Objetivo: 0
Problemas GTV / ingresos
0
Objetivo: 0
Problemas bruto / neto
0
Objetivo: 0
Problemas de definición EBITDA
0
Objetivo: 0
Discrepancias de flujo de caja
0
Objetivo: 0
Referencias de fuente obsoletas
0
Objetivo: 0
Flags de consistencia automática
No corregir automáticamente casos ambiguos. Requiere revisión de dirección.
¿Qué mueve más el modelo?
Drivers materiales del modelo, no puntuación numérica inventada.
Reconciliación del deck de inversor
Comparación financiera completa entre el deck Waterhouse y BC 6.7: ingresos, conteo de red, unit economics, uso de fondos, EBITDA, rollout, valoración, necesidad de caja.
Cómo funciona el modelo LOTOMIX
Definiciones financieras para inversores
Revenue
Ingresos reconocidos atribuibles a LOTOMIX (no GTV).
GTV
Valor bruto de transacciones; no es ingresos LOTOMIX.
Gross Media Revenue
Gasto bruto de anunciantes antes de revenue share.
LOTOMIX Net Revenue
Importe atribuible a LOTOMIX tras revenue share.
Contribution
Ingresos − costes directos por ubicación.
EBITDA
Contribución − OPEX central (una definición BC 6.7).
Cash Burn
EBITDA ± WC − Capex.
Capex
Inversión en hardware, instalación y tecnología.
Working Capital
Cobros − pagos + inventario.
Runway
Caja / burn neto aprobado (forward-looking).
MRR
Ingresos recurrentes mensuales.
ARR
Ingresos recurrentes anuales (no run-rate).
Integridad financiera
BC 6.7 es el modelo financiero de control para el caso de inversión LOTOMIX actual.
Los resúmenes para inversores se simplifican por claridad, pero todos los outputs financieros materiales deben reconciliarse con los mismos drivers operativos, supuestos de rollout y lógica de reconocimiento de ingresos.
Donde los cálculos unitarios simplificados difieren de las previsiones consolidadas por timing de rollout, ramp comercial o efectos de flujo de caja, la reconciliación se divulga, no se oculta.
USE OF FUNDS & CAPITAL EFFICIENCY
Uso de fondos y eficiencia de capital
Cómo la financiación propuesta de €3M se convierte en capacidad operativa medible, progreso comercial y reducción de riesgo. Todas las asignaciones monetarias provienen directamente de BC 6.7 o el plan de financiación aprobado.
⚠ No se inventan porcentajes ni ratios de eficiencia. El gasto no se equipara a progreso. El inventario no se clasifica como capacidad desplegada. BC 6.7 permanece como fuente de control.
La financiación propuesta de €3M de LOTOMIX pretende convertir una base tecnológica y de red existente en un despliegue comercial más amplio.
La eficiencia de capital debe evaluarse no solo por categoría de gasto, sino por la capacidad operativa y la evidencia comercial creada por ese gasto.
Tabla maestra de uso de fondos
Capital por categoría
Tecnología y plataforma
Outputs
- Hardening de producción
- Escalabilidad backend
- Integración de administraciones
- Gestión de dispositivos
- Mejoras de validación de billetes
- Monitorización
- Seguridad
- Funcionalidad app/digital
- Reporting
KPI
- Items de readiness completados
- Estabilidad de plataforma
- Integraciones completadas
- Flota de dispositivos soportada
- Problemas críticos resueltos
→ Readiness comercial dic 2026
Adquisición de hardware
Outputs
- Lectores A1D/PPI
- Pantallas traseras
- Pantallas grandes LOTOADS
- Equipamiento asociado
KPI
- Unidades pedidas
- Unidades entregadas
- Unidades instaladas
- Unidades activas
→ Hardware para 770 POS
Despliegue e instalación
Outputs
- Localizaciones inspeccionadas
- Localizaciones programadas
- Localizaciones instaladas
- Localizaciones activadas
- Localizaciones completadas
KPI
- Coste de instalación por localización
- Instalaciones por mes
- Tiempo de activación
- Tasa de completitud
- Desviación de despliegue
→ 770 localizaciones completadas
Activación de administraciones
Outputs
- Administraciones contactadas
- Programadas
- Onboarded
- Activadas
- Pagando SaaS
- Monetizadas comercialmente
KPI
- Coste de onboarding por administración activada (cuando existan datos)
→ Activación de administraciones
Comercialización publicitaria
Outputs
- Capacidad de ventas media
- Adquisición de anunciantes
- Engagement de agencias
- Operación de campañas
- Medición
- Reporting
- Operaciones creativas
KPI
- Anunciantes cualificados
- Propuestas
- Campañas contratadas
- Campañas en vivo
- Anunciantes recurrentes
- Fill
- CPM/precio realizado
- Ingresos publicitarios
- Tasa de repetición
→ Monetización de inventario
Activación consumer y digital
Outputs
- Lanzamiento/crecimiento de app
- Adquisición de usuarios
- CRM
- Membresías
- Peñas
- Activación transaccional
KPI
- Usuarios registrados
- MAU
- Usuarios pagadores
- Transacciones
- Miembros de peñas activos
→ Adopción digital
Personal
Outputs
- Personal crítico de escala
- Contratación discrecional faseable
KPI
- Cobertura de roles críticos
- Contratación discrecional vs tracción
→ Equipo de ejecución
Working capital
Outputs
- Timing de procurement de hardware
- Pagos a proveedores
- Cobros publicitarios
- Lead times de rollout
- Inventario
- Necesidades de caja operativa
KPI
- Caja mínima / runway
→ Runway de ejecución
Cadena de hardware
El inventario en almacén no es capacidad de red activa.
11.6" A1D / PPI reader
400 × 300 €
28" rear display
770 × 300 €
48" front screen
770 × 750 €
Instalación ≠ Activación ≠ Monetización
El despliegue de capital no se confunde con éxito comercial.
Uso de fondos → Output
Output → KPI
KPI → Hito
Despliegue de capital por fase
Fase 1
Fase 1 — Readiness de lanzamiento
Soporta
Tecnología, hardware inmediato, onboarding de administraciones, operaciones de lanzamiento
Objetivo
Rollout comercial amplio dic 2026
Fase 2
Fase 2 — Escala de despliegue
Soporta
Equipamiento adicional, instalación, operaciones de campo, rollout de pantallas
Objetivo
Hitos de expansión mar/abr 2027
Fase 3
Fase 3 — Escala de monetización
Soporta
Adquisición de anunciantes, activación SaaS, adopción digital, crecimiento de ingresos
Objetivo
Economía recurrente / repetida medible
Comprometido
Gasto contractual / pedido
Planificado
Aprobado, no comprometido legalmente
Desplegado
Ya gastado
Restante
Disponible bajo el plan de financiación
No clasificar gasto previsto como comprometido.
Gating de capex
Controles de asignación de capital de dirección, no tramos de financiación de inversor salvo estructura legal.
Capital en riesgo antes de validación
Desplegado antes de validación
Gasto discrecional de crecimiento front-loaded
Desplegado tras validación
Tras demostrar unit economics
Evitar front-load de gasto discrecional excesivo antes de validar unit economics. No inventar porcentajes objetivo.
Métricas de eficiencia de capital (futuras)
Usar solo cuando existan datos reales. No mostrar valores artificiales hoy.
Payback por localización
Capital incremental por localización ÷ contribución mensual. Solo si coste de capital y contribución están definidos y se incluye ramp-up.
No usar contribución madura desde el día 1 si BC 6.7 incluye ramp.
Payback de red
No multiplicar payback individual. Considerar OPEX central, timing de rollout, inventario, ramp comercial, working capital.
Usar BC 6.7. Si no está soportado, no inventarlo.
Productividad de capital
La productividad de capital mejora cuando LOTOMIX convierte hardware y gasto operativo en localizaciones activas generadoras de ingresos rápidamente, y esas localizaciones producen contribución en línea con el modelo.
Eficiencia de capital real vs presupuesto
Parte de reporting post-inversión. No poblar reales futuros.
Control de sobrecoste
Umbrales aprobados por dirección. No inventar disparadores.
Control de infradespliegue / output
El infragasto puede ser eficiencia o retraso. Requiere explicación. Si el capital se despliega sin output, revisión de productividad.
Capital → evidencia
Hardware
Pedidos / facturas / evidencia de entrega
Instalación
Registros de despliegue
Tecnología
Completitud de hitos / documentación técnica
Comercial
Campañas / contratos / CRM
Working capital
Registros financieros
No exponer facturas sensibles en la vista principal. Usar drill-down del Data Room.
Reporting de inversor (post-inversión)
Cómo LOTOMIX evalúa la eficiencia de capital
El objetivo es medir progresivamente cómo el capital se convierte en infraestructura desplegable → localizaciones activadas → localizaciones monetizadas → contribución → generación de caja. Una vez exista historial operativo suficiente, los ratios de eficiencia podrán reportarse con resultados reales.
No crear ratio sintético de retorno si no hay datos reales suficientes.
Importe de financiación
€3M
Valoración pre-money
Parámetro de ronda actual donde se divulgue
Uso de fondos
Cómo se despliegan los proceeds
Valor de la empresa
Análisis de valoración separado
No tratar la ronda de €3M como un ingreso operativo.
Capital inversor vs financiación pública potencial
No combinar en un único importe de financiación salvo explicación clara.
Si la ejecución comercial es más lenta
Qué categorías pueden ralentizarse, diferirse, permanecer fijas o protegidas.
Protegido
Plataforma core, mantenimiento, red existente, compliance crítico
Escalable
Nuevas compras de hardware, contratación discrecional, marketing de crecimiento, expansión acelerada
Marco de eficiencia de capital
La financiación propuesta debe evaluarse contra la capacidad operativa que crea, no simplemente el importe gastado.
LOTOMIX vincula el despliegue de capital a outputs medibles: readiness de plataforma, instalación de hardware, activación de administraciones, monetización publicitaria, adopción digital y runway de caja.
A medida que se acumulen datos comerciales, estos outputs pueden compararse directamente con el presupuesto para evaluar si el capital se convierte en capacidad generadora de ingresos al ritmo asumido en BC 6.7.
INSTITUTIONAL RISK REGISTER
Registro institucional de riesgos
Riesgos clave de inversión, indicadores de aviso observables, mitigaciones de dirección y ownership. Conecta directamente a BC 6.7, Investor KPI Cockpit, Downside Survival, Rollout Reconciliation, Technology Readiness y Regulatory & Legal Readiness.
⚠ No se ocultan riesgos materiales. No se exagera la efectividad de la mitigación. No se trata el pipeline como garantizado. No se describe la tecnología como probada a escala sin evidencia.
Registro maestro de riesgos
Mapa riesgo → KPI
Cada riesgo material conecta a uno o más KPIs monitorizados.
Rollout
Publicidad
Digital
Caja
Tecnología
Legal
Mapa riesgo → BC 6.7
Mapa riesgo → acción de dirección
Trigger → Acción inmediata → Escalación → Respuesta financiera.
No implementar acciones automáticamente sin aprobación de dirección.
Operaciones
Rollout / instalaciones
Comercial
Publicidad / conversión de anunciantes
Tecnología
Plataforma / escala / dispositivos
Finanzas
Caja / OPEX / modelo
Legal / Dirección
Regulatorio / contratos
No dejar riesgos materiales sin owner. Si la ownership no está resuelta: RISK OWNER REQUIRED.
Revisión mensual
Riesgos operativos y comerciales
Revisión trimestral
Riesgos estratégicos, financieros y de gobernanza
Escalación inmediata
Problemas materiales legales, de liquidez, seguridad o contractuales
No hard-codear gobernanza de board no aprobada. Estructura de monitorización recomendada para el Data Room.
Current watch items
Riesgos que actualmente requieren más atención de dirección según el estado aprobado. No se ranquean como mejores/peores.
Ejecución de rollout
Trigger: instalaciones/mes vs plan
Acción: priorizar high-readiness locations
Próxima revisión: mensual
Readiness tecnológica
Trigger: gates de readiness sin completar
Acción: checklist formal + QA
Próxima revisión: inmediata
Working capital
Trigger: gasto precede cobranza
Acción: forecasting de caja + capex gating
Próxima revisión: mensual
Solo poblar con issues actuales reales. No fabricar preocupaciones para llenar el panel.
Historial de riesgos cerrados
Registro interno de riesgos materiales resueltos. No se eliminan riesgos históricos una vez resueltos.
Riesgo
—
Issue original
—
Mitigación completada
—
Evidencia
—
Fecha de cierre
—
Riesgos emergentes / monitoring
Nuevos riesgos no suficientemente materiales para el registro principal. Mostrar al inversor solo si son materialmente relevantes.
Marco de gestión de riesgos
Los principales riesgos de inversión de LOTOMIX se monitorizan a través de indicadores operativos, comerciales, técnicos y financieros observables, en lugar de evaluaciones cualitativas genéricas.
Donde un riesgo afecta al caso financiero, el driver de BC 6.7 correspondiente y la sensibilidad de downside deben ser identificables.
Las acciones de dirección pueden entonces vincularse al trigger operativo subyacente, permitiendo ajustar el despliegue de capital y el ritmo de ejecución conforme se desarrolla la evidencia real.
INVESTOR REPORTING & GOVERNANCE
Marco de reporting y gobernanza de inversor
Cómo LOTOMIX reportará ejecución, rendimiento financiero, despliegue de capital y cambios materiales después de la inversión. Reporting consistente, basado en evidencia, comparable con el caso original, enfocado en métricas materiales y transparente respecto a varianzas.
⚠ No sobrescribir BC 6.7 con previsiones posteriores. No cambiar fechas de milestones original retrospectivamente. No redefinir KPIs sin documentar el cambio. No presentar datos preliminares como finales. No tratar GTV como ingresos reconocidos. No tratar hardware comprado como capacidad desplegada.
Tres vistas financieras
El reporting post-inversión debe distinguir siempre entre presupuesto original, real y previsión actual. Nunca sobrescribir el presupuesto original de BC 6.7 con la última previsión.
Presupuesto original
Caso de inversión aprobado basado en BC 6.7. Históricamente preservado.
Real
Rendimiento financiero y operativo observado.
Previsión actual
Expectativa forward-looking de dirección basada en rendimiento real e información operativa actualizada.
Reporte mensual de inversor — estructura estándar
Pack de reporting conciso que puede entenderse rápidamente, no una presentación operativa larga.
Executive snapshot
Solo los KPIs más importantes. Cada uno muestra Actual, Presupuesto, Varianza y, donde sea relevante, Mes Anterior.
Installed Locations
Activated Locations
Monetised Locations
Completed Locations
Advertising Fill
Revenue per Monetised Location
MAU
Monthly Recognised Revenue
EBITDA
Cash
Runway
Rollout vs plan
La varianza debe explicar qué cambió, por qué y qué hace dirección. Evitar explicaciones genéricas.
Reporting de hardware
⚠ Hardware comprado no debe interpretarse como capacidad comercial operativa.
Lectores
Pantallas traseras
Pantallas grandes
Reporting publicitario mensual
Reporting económico FENAMIX
El 30% de FENAMIX aplica solo a ingresos publicitarios de gran formato. No aplicar a reader o pantalla trasera.
Reporting SaaS
⚠ No asumir que todas las administraciones activas son clientes pagadores. Fee de referencia: €30/mes.
Reporting digital
⚠ No usar downloads como active users. No usar GTV como ingresos LOTOMIX.
Reporting de membresías
Donde no exista historial suficiente para retención, mostrar DATA ACCUMULATING en lugar de una tasa asumida.
Reporting de peñas
⚠ No reportar volumen total de participación como ingresos de la empresa.
Rendimiento financiero
Usar las mismas definiciones que BC 6.7. No cambiar definiciones de EBITDA o contribución después de la inversión sin documentar el cambio.
Bridge de ingresos mensual
Solo usar componentes soportados por datos reales. El objetivo es explicar el cambio, no solo reportar el total.
Bridge de EBITDA
Reporting de caja
⚠ Runway debe usar la metodología de previsión aprobada. No usar cálculo simplista de caja / burn del último mes si el gasto futuro cambia materialmente.
Capital raised vs capital deployed
⚠ No interpretar capital gastado como milestone alcanzado.
Productividad de capital
Conectar gasto con outputs. Donde haya gasto sin output esperado, flag para revisión de dirección.
Gasto hardware
→
Localizaciones instaladas / activadas
Gasto tecnología
→
Milestones de readiness entregados
Gasto comercial
→
Campañas / anunciantes / ingresos
Gasto digital
→
Usuarios activados / monetización
Working capital
→
Runway / soporte de rollout
Actual vs budget
Cada KPI importante soporta Budget, Actual, Varianza absoluta y varianza porcentual donde sea matemáticamente significativo. Usar N/M — Not Meaningful donde el denominador sea cero o la comparación sea engañosa.
Comentario de varianza
Comentario conciso para desviaciones materiales. Los umbrales de materialidad deben ser aprobados por dirección. No inventarlos.
Actualización de previsión
En cada ciclo de previsión aprobado: Original BC 6.7 Budget sin cambios, Latest Actuals actualizado, Current Forecast actualizado. La previsión debe indicar fecha, horizonte y cambios clave de supuestos.
Log de cambios de previsión
El inversor siempre debe entender por qué cambió la previsión.
No reescribir la historia
Si el rendimiento real está por debajo del plan, no modificar el presupuesto histórico para hacer desaparecer la varianza. Mantener Original Budget y Actual visibles. Si el rendimiento supera el plan, no aumentar retrospectivamente el objetivo original. El caso de inversión debe permanecer auditable.
Revisión trimestral de inversor
No crear una arquitectura de reporting separada del marco mensual. El reporte trimestral profundiza las mismas métricas.
Tracking de tesis de inversión
A final de trimestre, cada tesis principal con evidencia actual, progreso desde la inversión y próxima validación. No puntuar la tesis. Usar etiquetas factuales de madurez/estado.
Tracking de unit economics
Una vez existan datos suficientes, comparar Actual vs modelo BC 6.7. Uno de los análisis trimestrales más importantes.
Análisis de cohortes
Una vez exista historial suficiente: cohortes de localizaciones activadas por mes (ramp de ingresos, monetización, contribución) y cohortes de usuarios por mes de adquisición (activación, retención, transacciones, conversión pagada). No crear análisis de cohortes antes de que existan datos suficientes.
Tracking de milestones
⚠ No cambiar la columna Original Target retrospectivamente. Si la fecha esperada cambia, mostrarla separadamente.
Evitar usar ON TRACK sin evidencia operativa clara.
Reporting de riesgos
Incluir solo Current Watch Items materiales: riesgo, trigger, evidencia actual, mitigación, owner, próxima revisión. No reproducir el registro completo cada mes.
Desarrollos materiales del periodo
Solo eventos que afecten materialmente: outlook financiero, rollout, tecnología, posición legal, tracción comercial, financiación, estructura corporativa. No llenar con reuniones ordinarias.
Gobernanza de cambios materiales
⚠ No inventar derechos de gobernanza no contenidos en documentos reales de accionistas o inversión. Esto es un marco de reporting, no un sustituto de acuerdos legales de gobernanza.
Aplica a: presupuesto, estrategia de rollout, uso de fondos, arquitectura tecnológica, contratos mayores, scope de producto, financiación.
Log de decisiones de dirección
Registro de definiciones de KPI
Cada KPI reportado tiene una definición estable. Las mismas definiciones se usan en reporting de dirección, inversor, board, Data Room y modelo financiero. No crear una definición para dirección y otra para inversores.
Data cutoff, preliminar vs final, fuentes y calidad
Data cutoff
Cada reporte mensual muestra Reporting Period y Data Cut-Off Date. Importante donde finanzas cierran después de datos operativos, ingresos publicitarios son provisionales o la caja se actualiza diariamente.
Preliminar vs final
Figuras provisionales: PRELIMINARY. Confirmadas: FINAL. No reemplazar silenciosamente sin preservar trazabilidad.
Calidad de datos
No presentar métricas operativas preliminares con el mismo estatus evidenciario que resultados financieros finales.
Fuentes de reporting
Excepciones de reporting
Issues materiales no resueltos deben ser visibles para dirección antes de distribuir reportes de inversor.
Timeline de reporting mensual
No inventar un día específico de reporting salvo aprobación de dirección. Workflow configurable que soporte luego un calendario formalmente acordado.
Refresh trimestral de previsión
El modelo incorpora despliegue real, rendimiento publicitario real, métricas de usuario reales, capex actualizado, OPEX actualizado y posición de caja actualizada. BC 6.7 permanece visible como benchmark original del caso de inversión.
Plan anual
Arquitectura preparada para crear Annual Budget separado del Original Investment Case BC 6.7. En periodos posteriores, los inversores pueden comparar tesis original, plan operativo anual y rendimiento real. No sobrescribir uno con otro.
Acceso del inversor
Área dedicada Investor Updates dentro del Data Room. No duplicar archivos fuente subyacentes.
Archivo de reportes
Preservar todos los updates históricamente. Los reportes deben ser inmutables o versionados una vez distribuidos.
¿Qué cambió este periodo?
Máximo 5–7 items materiales. No llenar con actividad rutinaria.
¿Qué importa ahora?
3–5 milestones operativos próximos. Cada uno con target, owner y evidencia requerida.
Filosofía de reporting
El reporting de inversor de LOTOMIX está diseñado para preservar el caso de inversión original mientras proporciona visibilidad transparente de la ejecución real y la última previsión de dirección.
Las varianzas se explican en lugar de eliminarse, y los cambios de previsión se documentan en lugar de incorporarse retrospectivamente al presupuesto original.
DEAL READINESS & CLOSING CHECKLIST
Deal readiness y closing checklist
Vista estructurada de la documentación, aprobaciones y acciones requeridas para pasar de la decisión de inversión al closing. No predice ni define condiciones legales finales de closing. Proporciona un checklist práctico de dirección.
⚠ La documentación final de transacción permanece sujeta a negociación legal y documentación formal de inversor. No inventar condiciones de closing, derechos de inversor ni aprobaciones legales.
Deal readiness snapshot
Data Room
AVAILABLEActual / controlado.
Corporativo
AVAILABLEDocumentación clave disponible.
Financiero
AVAILABLEBC 6.7 actual.
Tecnología
AVAILABLEEvidencia técnica disponible.
Legal
AVAILABLEMatriz de readiness disponible.
Comercial
AVAILABLEMapa de evidencia disponible.
Documentos de transacción
PENDINGSujeto al proceso de inversión.
Master closing checklist
No etiquetar automáticamente un item como CONDITION PRECEDENT salvo que esté formalmente incluido en los documentos de transacción.
Dashboard de readiness de closing
⚠ No crear un porcentaje global que pueda implicar falsamente certeza de cierre legal. Mostrar solo progreso por workstream.
Corporate
6 / 9
completado / total
Financial
3 / 5
completado / total
Legal
0 / —
completado / total
Technology
2 / 4
completado / total
Regulatory
1 / 2
completado / total
KYC
0 / 3
completado / total
Transaction Documents
0 / —
completado / total
Documentación corporativa
Asegurar que la estructura corporativa mostrada en el Data Room coincide con la posición corporativa registrada más reciente. Si algún registro permanece pendiente: REGISTRATION PENDING. No presentar cambios corporativos no registrados como completados.
Capitalización actual
Current shareholders
AVAILABLE
Ownership percentages
AVAILABLE
Share classes
AVAILABLE
Outstanding rights
AVAILABLE
Options / warrants / convertibles
AVAILABLE
Shareholder agreements
AVAILABLE
Capitalización post-inversión ilustrativa
Solo una vez que los términos de la transacción estén suficientemente definidos. No crear una cap table post-money final antes de que se acuerden importe, valoración, instrumento y tratamiento de accionistas.
ILLUSTRATIVE — SUBJECT TO FINAL TRANSACTION TERMSConsents de accionistas
⚠ No asumir qué aprobaciones son legalmente requeridas. Usar LEGAL CONFIRMATION REQUIRED hasta que el counsel de la transacción confirme.
Parámetros de transacción
€3M de financiación y €12M–€15M de rango pre-money permanecen como parámetros aprobados de fundraising. Clasificar como CURRENT FUNDRAISING PARAMETERS, no AGREED TRANSACTION TERMS, hasta que se acuerden formalmente con el inversor.
⚠ No inventar términos de deal. Track de importe, valoración, instrumento, entidad, ownership, derechos de gobernanza, información, reserved matters, anti-dilution, liquidation preference, transfer rights y protecciones de inversor solo cuando sean relevantes a negociaciones reales.
Term sheet
⚠ Donde exista un term sheet, enlazar con acceso restringido apropiado. No resumir economía sensible de forma inexacta.
Documentación de inversión
⚠ Solo mostrar documentos que realmente existen. Documentos futuros: TO BE PREPARED IF REQUIRED.
Investment / Subscription Agreement
TO BE PREPARED IF REQUIREDShareholders' Agreement
TO BE PREPARED IF REQUIREDArticles / Bylaws Amendments
TO BE PREPARED IF REQUIREDDisclosure Letter
TO BE PREPARED IF REQUIREDCorporate Resolutions
TO BE PREPARED IF REQUIREDPowers of Attorney
TO BE PREPARED IF REQUIREDNotarial Documentation
TO BE PREPARED IF REQUIREDRegistration Documentation
TO BE PREPARED IF REQUIREDWorkstreams de due diligence
⚠ No implicar que el due diligence está completo solo porque se haya subido documentación. Usar DATA ROOM MATERIAL AVAILABLE separado de REVIEW COMPLETED.
Tracker de Q&A de inversor
Permite a dirección trackear preguntas de Waterhouse y futuros inversores sin duplicar respuestas.
Tracker de DD request list
Contratos materiales
⚠ No reproducir términos comercialmente sensibles en resúmenes no restringidos salvo aprobación.
FENAMIX agreement
Parties · Effective date · Term · Status · Dependency · Data Room
Administration agreements
Parties · Effective date · Term · Status · Dependency · Data Room
Technology agreements
Parties · Effective date · Term · Status · Dependency · Data Room
Hardware suppliers
Parties · Effective date · Term · Status · Dependency · Data Room
Software providers
Parties · Effective date · Term · Status · Dependency · Data Room
Advertising agreements
Parties · Effective date · Term · Status · Dependency · Data Room
Major customer / advertiser agreements
Parties · Effective date · Term · Status · Dependency · Data Room
Financing agreements
Parties · Effective date · Term · Status · Dependency · Data Room
Material leases
Parties · Effective date · Term · Status · Dependency · Data Room
Professional-service agreements
Parties · Effective date · Term · Status · Dependency · Data Room
Change-of-control / consents de inversión
Revisar acuerdos materiales por cláusulas que puedan requerir consent, notificación o waiver en relación con inversión, cambio de ownership, cambio de gobernanza o aumento de capital. No determinar requisitos legales automáticamente. Flag LEGAL REVIEW REQUIRED donde sea relevante.
Propiedad intelectual
El inversor debe entender qué posee la empresa y qué licencia. Si la evidencia de ownership es incompleta: IP CHAIN OF TITLE REVIEW REQUIRED.
Readiness tecnológica de closing
No es un duplicado de due diligence técnico. Solo track de deliverables a nivel de transacción.
Control de BC 6.7 en closing
El proceso de transacción inversora referencia el mismo modelo financiero actual.
BC 6.7 — CURRENT PRINCIPAL FINANCIAL MODEL⚠ Si un modelo posterior del caso de inversión se aprueba formalmente durante negociaciones, preservar BC 6.7 — ORIGINAL FUNDRAISING MODEL y añadir la versión posterior separadamente. No sobrescribir el modelo que los inversores revisaron originalmente.
Deuda / pasivos
⚠ No clasificar trade payables ordinarios como deuda financiera salvo que sea apropiado.
Readiness fiscal
⚠ No proporcionar conclusiones fiscales desde el Data Room. Usar TAX ADVISER REVIEW donde se requiera.
Empleo / equipo
⚠ No exponer información personal de compensación innecesaria. Usar agregado o acceso restringido donde sea apropiado.
Continuidad de persona clave
⚠ No crear compromisos de empleo o arreglos de retención que no hayan sido acordados.
Readiness regulatoria
Para closing, identificar solo issues que puedan afectar materialmente la transacción o el rollout a corto plazo. No convertir cada tarea legal de producto en una condición de closing.
Protección de datos
Litigios / reclamaciones
⚠ Solo incluir asuntos relevantes a la transacción y soportados por documentación legal. No exponer asuntos personales sensibles no relacionados en el Data Room inversor.
Seguros
⚠ No implicar que existe cobertura de seguro donde la documentación no esté disponible.
Banca / recepción de fondos
⚠ No mostrar números de cuenta bancaria en secciones de acceso general de inversores. Usar acceso restringido.
KYC / AML readiness
⚠ Solo almacenar material KYC altamente sensible en áreas de acceso restringido. No exponer documentos de identidad ampliamente.
⚠ No exponer información sensible de KYC en secciones de acceso general de inversores.
KYC del inversor
No asumir la entidad legal inversora del inversor hasta que se confirme.
Signing
Documentos de transacción ejecutados.
Closing / Completion
Inversión legal y financieramente completada.
⚠ No asumir que signing y closing ocurren en la misma fecha. Si la estructura final proporciona signing y closing simultáneos, actualizar el marco.
Condiciones entre signing y closing
⚠ No poblar condiciones precedentes hipotéticas antes de que el counsel las confirme.
Proceso de aumento de capital
⚠ No asumir la estructura final. Usar TRANSACTION STRUCTURE — LEGAL CONFIRMATION REQUIRED hasta que se acuerde.
Control de ejecución de documentos
⚠ No permitir que drafts no firmados aparezcan visualmente equivalentes a acuerdos ejecutados.
Control de fondos de closing
⚠ No marcar la transacción como completa solo porque se iniciaron los fondos.
Costes de transacción
⚠ No inventar estimaciones. Distinguir costes de transacción de gastos operativos donde el tratamiento contable difiera.
Proceso de disclosure
⚠ No crear ni interpretar warranties de transacción hasta que el counsel proporcione los documentos finales.
Warranties / representations
No redactar warranties automáticamente. Solo una categoría de tracking. Dirección debe poder mapear evidencia del Data Room contra warranties finales una vez recibidas.
Transaction Warranties — Subject to Final Legal DocumentationÍndice de documentos de closing
⚠ Solo crear carpetas / placeholders donde sea técnicamente útil. No poblar con documentos fabricados.
Closing blockers actuales
Solo items que genuinamente previenen la progresión de la transacción. No clasificar preguntas ordinarias de DD como blockers.
| Blocker | Owner | Dependency | Next Action |
|---|---|---|---|
| No current management-identified closing blockers — subject to investor and legal review | |||
Open items
Un item abierto de DD puede requerir trabajo pero no prevenir la completación de la inversión. Distinto de blockers.
Dependencias de terceros
No mostrar tareas controladas por dirección como dependencias de terceros.
Matriz de responsabilidad
⚠ Solo asignar responsabilidad una vez acordado. Donde no esté claro, usar TO BE CONFIRMED. No inventar mandatos de advisers.
Actualizaciones corporativas post-closing
⚠ No implementar ningún cambio antes del closing.
Control financiero post-closing
Se convierten en la posición de apertura del Investor Reporting Framework.
Day 1 investor baseline
Crea la baseline contra la que se medirá el progreso post-inversión.
Baseline de use of funds post-closing
⚠ No reasignar silenciosamente gasto material entre categorías. Las reasignaciones materiales deben documentarse.
Transición de acceso de inversor
Una vez cerrada la transacción, el acceso del inversor puede pasar de Fundraising Data Room a Investor Reporting Area. Preservar acceso histórico de DD donde sea apropiado.
Timeline del proceso de inversión
⚠ No insertar fechas salvo que estén acordadas.
QA final
⚠ No marcar la transacción READY TO CLOSE salvo que el counsel de la transacción y dirección hayan confirmado los requisitos relevantes.
Closing readiness
LOTOMIX ha estructurado el Data Room para que los principales materiales corporativos, financieros, comerciales, tecnológicos y legales puedan transicionar directamente a due diligence confirmatorio y ejecución de transacción.
Los requisitos finales de closing dependerán de la estructura de transacción acordada y la documentación legal definitiva.
FIRST 100 DAYS EXECUTION DASHBOARD
Dashboard de ejecución de primeros 100 días
Cómo LOTOMIX convierte el capital de inversión en milestones operativos durante la primera fase después del closing. Conecta closing → capital → ejecución → activación comercial → KPIs medibles. Funciona como plan de ejecución de dirección.
⚠ No presentar como compromiso contractual, schedule garantizado, sustituto del plan operativo aprobado o nueva previsión financiera. No crear targets numéricos artificiales de Day 30/60/90 que no estén en el plan aprobado.
Resumen de ejecución de dirección
⚠ No poblar datos faltantes con supuestos.
—
Capital desplegado
Actual
—
Localizaciones activadas
Actual
—
Localizaciones monetizadas
Actual
—
Ingresos reconocidos
Actual
—
Runway
Current forecast
Day 0 — Baseline de closing de inversión
En la completación de la transacción, bloquear la posición inicial. Todo el progreso subsiguiente de 100 días se mide desde esta baseline.
Caja
Red
Hardware
Tecnología
Comercial
Digital
Financiero
Cuatro fases de ejecución
Ventanas de planificación de dirección. No tratar cada milestone como requerido en un día numerado exacto.
MOVILIZAR
Days 1–30
Convertir readiness de closing en capacidad de ejecución activa.
ACTIVAR
Days 31–60
Pasar de preparación a actividad comercial medible.
ESCALAR
Days 61–90
Aumentar despliegue solo donde la evidencia operativa y comercial soporte aceleración.
VALIDAR
Days 91–100
Medir si la tesis de inversión empieza a convertirse en evidencia operativa repetible.
Fase 1 — Movilizar
Objetivo primario: convertir readiness de closing en capacidad de ejecución activa.
Capital
Tecnología
Hardware
Operaciones
Comercial
Gobernanza
Outputs de Fase 1
Track de completación de outputs, no de actividad. No reportar reuniones celebradas como outputs mayores salvo que resulten en una decisión o milestone medible.
Tecnología
Checklist de production-readiness materialmente avanzado / completado.
Hardware
Schedule de procurement aprobado.
Operaciones
Cola de rollout priorizada establecida.
Comercial
Plan inicial de activación de anunciantes operando.
Finanzas
Presupuesto de despliegue de capital aprobado activado.
Gobernanza
Baseline de KPI de inversor bloqueada.
Fase 2 — Activar
Objetivo primario: pasar de preparación a actividad comercial medible. Track Installed → Activated → Monetised. No foco exclusivo en volumen de instalación.
Activación comercial
⚠ El objetivo es prueba de monetización, no solo prueba de despliegue.
Anunciantes
Publicidad
Administración
Fase 3 — Escalar
Objetivo primario: aumentar despliegue solo donde la evidencia operativa y comercial soporte aceleración. El despliegue de capital debe empezar a responder a evidencia operativa real.
Scale gate
Antes de acelerar materialmente el despliegue de Fase 3, revisar. Si una o más áreas underperforman materialmente, dirección debe poder ralentizar el despliegue en lugar de seguir automáticamente el schedule original de gasto.
Plataforma
¿Estable para soportar localizaciones adicionales?
Operaciones
¿Puede el equipo instalar y soportar la siguiente ola?
Hardware
¿Está el inventario alineado con localizaciones programadas?
Comercial
¿Se está monetizando el inventario publicitario?
Economía
¿Se desarrollan las unit economics razonablemente contra BC 6.7?
Caja
¿Soporta la última previsión la aceleración?
Fase 4 — Validar
Objetivo primario: medir si la tesis de inversión empieza a convertirse en evidencia operativa repetible.
Tabla maestra de 100 días
⚠ No poblar objetivos numéricos salvo que ya existan en el plan operativo aprobado.
Ownership de milestones
Evitar dependencia excesiva a nivel individual. Usar ownership funcional donde sea apropiado.
Mapa de dependencias
Permite entender retrasos causalmente en lugar de solo reportarlos.
Instalación de hardware
Depende de:
Activación comercial
Depende de:
Monetización digital
Depende de:
Camino crítico de 100 días
Solo milestones donde el retraso afectaría materialmente la ejecución subsiguiente. No clasificar cada tarea como crítica.
Tracking de despliegue de capital
Capital Available
—
Capital Committed
—
Capital Deployed
—
Capital Remaining
—
Vista de caja de 100 días
⚠ Usar BC 6.7 / última previsión aprobada. No crear un modelo de caja standalone de 100 días.
Opening cash
—
Investment proceeds
—
Planned deployment
—
Operating burn
—
Committed capex
—
Closing forecast cash
—
Updated runway
—
Ejecución tecnológica
Solo items launch / scale-critical.
Ejecución de hardware
Ejecución de red
⚠ Reportar conteo absoluto y conversión mensual / de periodo. No usar el perímetro potencial de 7.000 como progreso operacional.
Ejecución publicitaria
⚠ El objetivo de 100 días es probar monetización repetible, no acumular propuestas.
Ejecución digital
⚠ No celebrar downloads independientemente si el uso activo es débil.
Validación de unit economics
⚠ No forzar datos de etapa temprana en una conclusión de economía madura si la muestra no es representativa. Usar EARLY VALIDATION DATA donde sea apropiado.
Reader Advertising Revenue / Location
Rear Display Revenue / Location
Large Display Net Revenue / Location
SaaS / Paying Administration
Contribution / Monetised Location
Enfoque de cohortes
Para localizaciones activadas durante los primeros 100 días, empezar a trackear cohortes por fecha de activación: tiempo a monetización, ramp de ingresos, fill publicitario, contribución. No comparar una localización recién activada con una localización BC 6.7 madura sin ajustar por ramp.
Validación comercial de 100 días
Esto es validación, no un ejercicio de pass/fail.
¿Puede LOTOMIX activar localizaciones de forma consistente?
Evidence: —
¿Pueden las localizaciones activas generar ingresos publicitarios pagados?
Evidence: —
¿Pueden los anunciantes renovar o repetir?
Evidence: —
¿Puede la activación SaaS empezar a escalar?
Evidence: —
¿Puede la actividad de usuario convertirse en comportamiento monetizable?
Evidence: —
¿Puede la dirección desplegar capital sin exceder materialmente el plan?
Evidence: —
Watch items de 100 días
Solo poblar issues actuales.
Lógica de escalación
⚠ Si un milestone crítico es DELAYED o BLOCKED, requerir causa, impacto financiero, respuesta de dirección, timing actualizado e impacto en el siguiente milestone. No simplemente mover la fecha sin registrar por qué.
Disciplina de revisión de plan
Preservar Original 100-Day Objective y mostrar separadamente Current Expected Outcome si el plan cambia. No sobrescribir targets originales. Esto refleja el principio Budget → Actual → Forecast.
Conexión al roadmap
⚠ No cambiar milestones de diciembre 2026, marzo 2027 o abril 2027 sin evidencia operativa aprobada. Usar fecha de closing real y roadmap aprobado.
December 2026
Rollout comercial amplio
March 2027
Despliegue adicional de pantallas
April 2027
Aproximadamente 770 localizaciones completadas
Checkpoints de inversor
Day 30
Capital desplegado, deliverables mayores, rollout, comercial, técnico, riesgos, caja, próximas prioridades.
Day 60
Activación, monetización, unit economics tempranas, conversión de anunciantes, ejecución operativa, productividad de capital.
Day 90
Evidencia de escala, repetibilidad, real-vs-modelo, caja, próxima decisión de rollout.
Revisión de primeros 100 días
Debe convertirse en un major investor update.
No definir éxito solo por gasto
No recompensar dinero gastado, hardware pedido o personal contratado salvo que produzcan outputs operativos pretendidos. Foco en capacidad creada, localizaciones activadas, ingresos generados, evidencia producida.
No definir éxito solo por instalaciones
Un outcome fuerte de 100 días requiere progresión hacia monetización, no solo instalación de hardware. La instalación es un KPI intermedio.
Update de tesis a Day 100
Para cada tesis: evidencia al closing, nueva evidencia después de 100 días, próxima validación. No proporcionar un score global de inversión.
Update de riesgo a Day 100
Actualizar el Risk Register. Los riesgos pueden permanecer abiertos, aumentar, reducir, resolverse o generar nuevos. Preservar el registro original.
Reforecast financiero a Day 100
Solo si es apropiado y aprobado, usar evidencia actual de Day 100 para actualizar Current Forecast preservando Original BC 6.7 Investment Case. Mostrar cambios de supuestos mayores explícitamente.
Ejecución después del closing
Los primeros 100 días de LOTOMIX después de la inversión se gestionarán en torno a outputs medibles en lugar de solo gasto.
El despliegue de capital se vinculará a readiness tecnológica, activación de red, monetización comercial, validación de unit economics y liquidez.
El progreso se evaluará contra el caso de inversión original preservando visibilidad del rendimiento real y cualquier previsión revisada.
ASSUMPTIONS THAT MATTER · BC 6.7
Los supuestos que importan
El número limitado de drivers operativos que determinan materialmente el resultado financiero de LOTOMIX. Un inversor no debería necesitar entender cada línea de BC 6.7 antes de entender qué impulsa el resultado. Todos los valores provienen directamente de BC 6.7, sensibilidades adversas aprobadas y datos operativos verificados donde estén disponibles.
⚠ Esta página NO crea un nuevo modelo financiero. No crea nuevos porcentajes de adverso. No usa valores del caso base como datos reales. No altera BC 6.7.
Core Driver Dashboard
Base Case from BC 6.7 · Downside from approved sensitivities · Actual from observed operating data. No upside column — focus is on what happens if assumptions are weaker.
| Critical Driver | Base Case | Downside | Actual | Financial Impact |
|---|---|---|---|---|
1. Rollout / Active Locations Network Thesis | 770 completed locations by Apr 2027 370 existing + 400 new readers · 770 rear 28" + 770 front 48" · 2,310 devices | SENSITIVITY MODEL REQUIRED | HISTORICAL DATA AVAILABLE 370 installed Existing reader estate (operating data). Activated / monetised counts NOT YET VALIDATED. | Revenue, EBITDA, cash / runway |
2. Location Traffic Network Thesis | 800 visits / day Implied by 240 interactions ÷ 30% capture rate | SENSITIVITY MODEL REQUIRED | NOT YET VALIDATED NOT YET VALIDATED Telemetry / footfall data not yet available at network scale | Reader interactions, monetisable impressions, digital acquisition |
3. Reader Capture / Interaction Rate Network Thesis | 30% capture → 240 interactions / day 800 visits × 30% = 240 readings/day (BC 6.7 ppiInteractionsPerDay) | SENSITIVITY MODEL REQUIRED | NOT YET VALIDATED NOT YET VALIDATED Post-launch validation KPI once telemetry exists | Impressions, media inventory, reader advertising revenue |
4. Advertising Fill Advertising Thesis | Y1 exit 50% · Y2 exit 60% · Y3 exit 70% BC 6.7 fill ramp (fillLaunchStart 15% → fillY1Exit 50% → fillY2Exit 60% → fillY3Exit 70%) | 30% fill (approved sensitivity) Year 2 net screen media: €2.23M at 30% fill vs €3.71M at 50% base (BC 6.7 fill sensitivity) | NOT YET VALIDATED NOT YET VALIDATED Campaign / platform data not yet available at scale | Available inventory → sold inventory → delivered paid campaigns |
5. Realised CPM / Media Price Advertising Thesis | €5.60 CPM (reader) BC 6.7 ppiCpmEur = €5.60. Large-format uses slot price, not CPM. | SENSITIVITY MODEL REQUIRED | NOT YET VALIDATED NOT YET VALIDATED Realised CPM requires paid campaign data — not yet available | Inventory × Fill × Realised Price = Advertising Revenue |
6. Digital Adoption / MAU Digital Thesis | 40% monthly active rate BC 6.7 monthlyActiveRate = 0.40. Registered users: 150.5K Y1, 263K Y2, 395K Y3. | SENSITIVITY MODEL REQUIRED | NOT YET VALIDATED NOT YET VALIDATED App analytics not yet commercially available (launch 1 Dec 2026) | Transactions, app monetisation, membership conversion, communications inventory |
7. Transaction / Paying Conversion Digital Thesis | AI membership 1.5% · Peñas 3% BC 6.7: aiMembershipConversion 1.5% (€25 ARPU), penasPayingConversion 3% (€8 ARPU). 15 tx/MAU/month is a planning reference requiring BC 6.7 reconciliation. | SENSITIVITY MODEL REQUIRED | NOT YET VALIDATED NOT YET VALIDATED Conversion data requires post-launch app analytics | Digital monetisation validation — GTV ≠ Revenue |
8. Deployment Cost / OPEX Capital Efficiency Thesis | Y1 OPEX €0.91M · Hardware €300–€750/unit PPI reader €300/unit · Rear 23.8" €300/unit · Front 43" €750/unit · Install €120/POS · Gobo €150/POS · Y1 OPEX €€908.8k | SENSITIVITY MODEL REQUIRED | PARTIALLY VALIDATED €225K software paid Software programme: €225K paid to date, €375K future commitment (BC 6.7) | How quickly LOTOMIX scales × how efficiently it scales = EBITDA |
Driver 1 — Rollout / Active Locations: tracked separately
The financially relevant driver is revenue-producing locations, not hardware installed.
Driver 4 — Advertising Fill: tracked separately
Sold Inventory / Available Inventory — track separately where economically meaningful
Driver 6 — Digital Adoption / MAU: tracked separately
Downloads ≠ MAU. Track separately.
Driver Equations
The central formula: Inventory × Fill × Realised Price = Advertising Revenue. Every driver flows into EBITDA and cash.
PHYSICAL ECONOMICS
DIGITAL ECONOMICS
COMPANY ECONOMICS
CASH ECONOMICS
Driver Chains — How Each Revenue Line Is Built
Every planning input is labelled MODEL ASSUMPTION until validated by observed data. GTV is never shown as company revenue.
Reader Economics (PPI)
Label every planning input MODEL ASSUMPTION until validated. This makes reader economics transparent rather than hidden inside BC 6.7.
Reader CPM Reference — ~370 readers
€6
CPM
€19.4k
/ month
€7
CPM
€22.6k
/ month
€8
CPM
€25.9k
/ month
€9
CPM
€29.1k
/ month
MODELLED REVENUE at 70% fill / 370 readers. BC 6.7 base case uses €5.60 CPM. Not current revenue.
Large-Display Economics (43" front screens)
30% FENAMIX share applies to large-format (48") front-screen wholesale revenue ONLY. Do not apply the 70% factor to reader or rear-display revenue.
Digital Transaction Example
GTV ≠ Revenue. The 0.5% transaction fee is an upside sensitivity excluded from BC 6.7 base case until validated.
Peñas Driver Example
Official lottery stakes remain GTV, not LOTOMIX revenue. Peñas technology/service revenue is the LOTOMIX line.
Driver → Financial Impact
Populated only from the approved BC 6.7 sensitivity model. Where BC 6.7 cannot isolate a driver, the impact is not estimated manually.
| Driver | Change vs Base | Revenue Impact | EBITDA Impact | Cash / Runway |
|---|---|---|---|---|
| Rollout | Slower rollout | SENSITIVITY MODEL REQUIRED | SENSITIVITY MODEL REQUIRED | SENSITIVITY MODEL REQUIRED |
| Traffic | Lower footfall | SENSITIVITY MODEL REQUIRED | SENSITIVITY MODEL REQUIRED | SENSITIVITY MODEL REQUIRED |
| Capture | Lower interaction rate | SENSITIVITY MODEL REQUIRED | SENSITIVITY MODEL REQUIRED | SENSITIVITY MODEL REQUIRED |
| Fill | 30% vs 50% (Y2) | €2.23M vs €3.71M | Lower contribution | Shorter runway |
| CPM | Lower realised price | SENSITIVITY MODEL REQUIRED | SENSITIVITY MODEL REQUIRED | SENSITIVITY MODEL REQUIRED |
| MAU | Lower adoption | SENSITIVITY MODEL REQUIRED | SENSITIVITY MODEL REQUIRED | SENSITIVITY MODEL REQUIRED |
| Conversion | Lower paying conversion | SENSITIVITY MODEL REQUIRED | SENSITIVITY MODEL REQUIRED | SENSITIVITY MODEL REQUIRED |
| Cost / OPEX | Higher deployment cost | No direct revenue impact | Lower margin | Higher cash use |
One-at-a-Time Sensitivity
Where BC 6.7 supports it, the investor can see the effect of changing a single driver in isolation. Drivers may not be independent if the detailed model links them.
Detailed single-driver isolation requires the full BC 6.7 sensitivity engine. This dashboard shows where the model can isolate; BC 6.7 provides the math.
Combined Downside Scenario
Combined downside scenario must come from the approved BC 6.7 sensitivity model. Do not add individual downside impacts unless BC 6.7 mathematically supports doing so. Single-driver sensitivity ≠ Combined downside.
Validation, Measurement & Reforecast Discipline
As commercial data accumulates, assumptions become actual KPIs. The original BC 6.7 assumption is never overwritten.
What Changes First?
How frequently actual data should become measurable for each driver.
Rollout
Measured continuously / monthly
Deployment tracker
Traffic
Measured once telemetry exists
Footfall / telemetry
Fill
Measured campaign by campaign / monthly
Ad platform / CMS
CPM
Measured from paid campaigns
Campaign billing
MAU
Measured through app analytics
App analytics
Cost
Measured from procurement / finance
Procurement / finance
Reporting frequencies are not hard-coded where systems do not yet support them.
What Would Make Us Reforecast?
Management-approved trigger levels. Until thresholds are approved, the placeholder is shown — this prepares management discipline.
| Driver | Original Assumption | Reforecast Trigger | Current Status |
|---|---|---|---|
| Rollout | 770 by Apr 2027 | THRESHOLD TO BE APPROVED | Pending |
| Fill | 50% Y1 exit | THRESHOLD TO BE APPROVED | Pending |
| CPM | €5.60 reader base | THRESHOLD TO BE APPROVED | Pending |
| MAU | 40% monthly active | THRESHOLD TO BE APPROVED | Pending |
| Deployment cost | €300–€750/unit | THRESHOLD TO BE APPROVED | Pending |
Actual vs Model Evolution
As commercial data accumulates: Original BC 6.7 vs Actual vs Current Forecast. The original assumption is never overwritten.
| Driver | Original (BC 6.7) | Actual | Current Forecast |
|---|---|---|---|
| CPM | €5.60 (BC 6.7) | NOT YET VALIDATED | Pending actual data |
| Fill | 50% Y1 exit | NOT YET VALIDATED | Pending actual data |
| MAU | 40% monthly active | NOT YET VALIDATED | Pending actual data |
This is the correct post-investment reporting structure. Example: Original CPM €5.60 → Actual CPM Y → Current Forecast CPM Z.
Why These Assumptions Matter
Each driver maps to a principal investment thesis. As assumptions become measured, forecast uncertainty falls.
Driver → Investment Thesis
Rollout
Network thesis
Fill / CPM
Advertising thesis
MAU / Conversion
Digital thesis
Deployment cost / OPEX
Capital efficiency / operating leverage thesis
Link to Value Creation
This connects the downside concern ("what if the assumptions are wrong?") with the broader de-risking framework: each assumption that becomes measured evidence reduces forecast uncertainty.
Link to KPI Cockpit
Actual versions of these drivers should also appear in the Investor KPI Cockpit — activated locations, fill, realised CPM, MAU, revenue, deployment cost. This ensures assumptions gradually become actual KPIs.
What Drives LOTOMIX?
The financial outcome is primarily driven by how quickly LOTOMIX converts locations into monetised capacity, how effectively that inventory is sold, how users engage with the digital ecosystem and how efficiently the company deploys capital while scaling.
BC 6.7 contains the detailed driver model; this dashboard isolates the assumptions that investors should monitor most closely.
WHICH ASSUMPTIONS REALLY MATTER — AND WHAT HAPPENS IF THEY ARE WRONG?
Understandable in less than two minutes.
Cross-References
FINANCIALS · BC 6.7
BC 6.7 — September 2026 / Waterhouse / Investment Committee
Modelo institucional integrado de 36 meses con 370 lectores PPI operativos, circuito Fase 1 de 770 POS, 400 lectores adicionales, 770 pantallas traseras de 23,8", 770 pantallas frontales de 43", 200.000 tarjetas NFC como overlay separado, OPEX basado en drivers, sin repago de equity y €0 de subvención en el caso base. Las cifras son proyecciones de dirección y están sujetas a revisión inversora, legal, operativa y financiera salvo indicación expresa de auditoría.
⚠ Previsión de dirección BC 6.7. No auditada. No constituye asesoramiento financiero ni valoración formal. BC 6.7 no incluye valoración formal.
1 · Resumen de la inversión
Investment & Use of Funds
Financiación contemplada
3.000.000 €
Modelo BC 6.7
Instrumento contemplado
Equity
Sin repago ni redención obligatoria
Entidad receptora
Por confirmar
Ver documentación vigente
Hitos que financiará
Fase 1 + lanzamiento
770 POS, software, adquisición Sphere
Estado de la operación
Los términos de la ronda no están formalizados. El importe de €3M es un supuesto del modelo BC 6.7, no una oferta de inversión firmada.
Distinción de entidad receptora
No se supone que invertir en ASTERDAIL, LOTOMIX o PREMIA TECH GROUP represente la misma operación. La entidad receptora se identifica según la documentación vigente. Ver Corporate & Ownership para el detalle societario.
Fuente: BC 6.7 · LTX-DOC-FIN-BC67-001
2 · Estructura societaria
Estructura societaria
Diagrama sencillo. Se distingue marca comercial, sociedad y grupo. Las sociedades no se presentan como filiales ni las participaciones como actuales si solo forman parte de una estructura prevista.
Grupo / Holding
PREMIA TECH GROUP
Denominación legal por confirmar
Sociedad operativa
LOTOMIX
Red nacional de lotería conectada y retail media
Entidad receptora: por confirmar
Sociedad operativa
MAGNÆRA
Máquinas de vending inteligentes y NEXUS
Adquisición propuesta — pendiente de completar
SPHERE RADIO
370 lectores PPI desplegados. Integración en el Grupo tras cierre de adquisición.
Provisión BC 6.7: €450.000 — no completada
ASTERDAIL es la marca comercial del portal; PREMIA TECH GROUP es el grupo; LOTOMIX y MAGNÆRA son sociedades operativas. La estructura mostrada distingue marca, sociedad y grupo.
3 · Uso de fondos
Uso de fondos — BC 6.7
Categorías comprensibles. El desglose detallado se conserva bajo el desplegable. La caja disponible no se contabiliza como gasto.
Adquisición de Sphere y necesidades asociadas
450.000 €
Periodo
Cierre de adquisición (previsto 2026-2027)
Fuente
BC 6.7 · CAPEX · capexSphereAcquisition
Hito asociado
Cierre de adquisición Sphere
Hardware
1.144.500 €
Periodo
Procurement Fase 1 (nov 2026 – mar 2027)
Fuente
BC 6.7 · CAPEX · unitCosts
Hito asociado
Entrega de hardware para 770 POS
Instalación y logística
227.200 €
Periodo
Despliegue Fase 1 (mar – abr 2027)
Fuente
BC 6.7 · CAPEX · installation + gobo + other
Hito asociado
770 localizaciones instaladas (14 abr 2027)
Software y servicios tecnológicos
375.000 €
Periodo
Compromiso futuro (nov 2026 – abr 2027)
Fuente
BC 6.7 · SOFTWARE_COSTS · softwareFutureCommitment
Hito asociado
Hardening de lanzamiento y integración
Necesidades operativas y liquidez
1.124.373 €(caja, no gasto)
Periodo
Caja de cierre del año de lanzamiento
Fuente
BC 6.7 · Annual Summary · closingCash
Hito asociado
Caja operativa tras Fase 1
Uso de caja de lanzamiento (CAPEX + compromiso software): 2.183.768 €. Caja de cierre año 1: 1.124.373 €. Total financiación: 3.000.000 €.
4 · Conciliación con los €3M
Conciliación con los €3M
No se fuerzan las partidas de gasto a sumar €3M si parte de la financiación permanece como caja. El OPEX acumulado de 36 meses no se presenta como gasto financiado íntegramente por la ronda: se consideran los ingresos y flujos operativos previstos.
Financiación recibida (equity)
Supuesto BC 6.7 — no formalizado
3.000.000 €
Desembolsos iniciales (CAPEX + software)
Uso de caja de lanzamiento
−2.183.768 €
Contribución operativa (EBITDA año 1)
Ingresos operativos previstos, no financiación
360.094 €
Liquidez disponible (caja cierre año 1)
Caja, no un gasto
1.124.373 €
✓ Conciliación: 3.000.000 € − 2.183.768 € + 360.094 € − 51.953 € = 1.124.373 €
OPEX de 36 meses no financiado íntegramente por la ronda
El OPEX del año de lanzamiento (908.843 €) se cubre con la financiación y los ingresos operativos previstos (1.427.578 €). El OPEX acumulado de 36 meses no se presenta como gasto financiado íntegramente por la ronda de €3M. La conciliación respeta el calendario mensual de caja de BC 6.7.
5 · Evitar doble contabilización
Verificación de doble contabilización
Provisión Sphere de €450.000 aparece una sola vez
Incluida en CAPEX (450.000 €), no duplicada en otras partidas.
Pagos de software ya realizados no se incluyen como desembolsos futuros
€225k pagado excluido; solo €375k compromiso futuro en uso de caja.
Partidas de hardware no duplicadas entre CAPEX y costes de lanzamiento
Hardware (pantallas, lectores, NFC) clasificado en CAPEX; no duplicado en OPEX.
Instalación, logística y servicios clasificados conforme al modelo
Instalación y gobo en CAPEX por POS; otros lanzamiento en CAPEX one-off.
Caja disponible no contabilizada como gasto adicional
Caja de cierre (1.124.373 €) es liquidez, no gasto.
✓ Todas las verificaciones superadas — sin doble contabilización detectada
6 · Condiciones y dependencias
Condiciones y dependencias
Se distinguen compromisos contractuales de presupuestos y estimaciones. Una asignación del modelo no se presenta como obligación contractual sin documentación.
Cierre de financiación
Compromiso contractualTerms under discussionDesembolso
€3M equity (supuesto del modelo)
Depende de
Acuerdo de inversión firmado
Adquisición de Sphere
Compromiso contractualPropuesta — pendiente de cierreDesembolso
€450k (provisión CAPEX)
Depende de
Acuerdo de adquisición firmado, financiación completada
Pedidos y entregas de hardware
PresupuestoPOs pendientes de cargaDesembolso
€928.5k hardware + €216k NFC
Depende de
POs firmadas con proveedores (Guangzhou Licon y otros)
Instalaciones
Presupuesto770 POS objetivo 14 abr 2027Desembolso
€207.9k instalación + gobo + €19.3k otros
Depende de
Hardware entregado, equipos de instalación, coordinación FENAMIX
Entrega tecnológica
Compromiso contractualEn ejecución — hardening de lanzamientoDesembolso
€375k compromiso futuro (€225k ya pagado)
Depende de
Contrato de software, hitos de entrega
Activación comercial
EstimaciónFase retail operativa; consumer en desarrolloDesembolso
Cubierto por OPEX operativo (no CAPEX)
Depende de
Establecimientos instalados, app consumer, campañas
7 · Términos de inversión
Términos de inversión
Terms under discussion
Los términos de la ronda no están formalizados. No se calcula una participación definitiva.
| Término | Valor | Estado |
|---|---|---|
| Importe de la ronda | 3.000.000 € | Supuesto modelo |
| Valoración pre-money | Por confirmar | Terms under discussion |
| Valoración post-money | Por confirmar | Terms under discussion |
| Participación resultante | No calculada | Terms under discussion |
| Derechos y condiciones | Bajo discusión | Terms under discussion |
No usar valor ilustrativo del Año 3 como valoración actual
El enterprise value ilustrativo del Año 3 (EBITDA × múltiplo de precedentes) es una referencia estratégica, no una valoración actual de la ronda. No se utiliza como valoración pre-money ni post-money.
Documento de referencia: Term Sheet Draft (Waterhouse) — borrador, no firmado.
8 · Contacto profesional
Contacto profesional
Ángel Blázquez
CEO
Denominación corporativa correspondiente(por confirmar en documentación vigente)
Email corporativo verificado(pendiente de confirmación)
Las referencias a direcciones iCloud se sustituyen cuando existe un correo corporativo confirmado. No se inventan direcciones de correo.
9 · Verificación
Verificación
Importes reconcilian con BC 6.7
Financiación 3.000.000 € = supuesto BC 6.7. Uso de caja 2.183.768 € = CAPEX año 1.
Estructura actual distinguida de estructura prevista
Sphere marcada como adquisición propuesta, no como filial actual. Participaciones previstas no presentadas como actuales.
Entidad receptora no presumida
No se supone que ASTERDAIL, LOTOMIX o PREMIA TECH GROUP sean la misma operación.
Términos no formalizados identificados
Terms under discussion. No se calcula participación definitiva ni se usa EV Año 3.
OPEX 36 meses no presentado como financiado por la ronda
OPEX año 1 (908.843 €) cubierto por financiación + ingresos operativos (1.427.578 €).
Pagos de software no duplicados
€225k pagado excluido de necesidades futuras; solo €375k compromiso futuro.
✓ Verificación completada — importes reconcilian con BC 6.7 y estructura actual/distinta de la prevista
Modelo Financiero BC 6.7
BC 6.7 — September 2026 / Waterhouse / Investment Committee
Modelo institucional integrado de 36 meses con 370 lectores PPI operativos, 770 POS de Fase 1, 400 lectores adicionales, 770 pantallas traseras de 23,8", 770 pantallas frontales de 43", 200.000 tarjetas NFC como overlay separado, OPEX basado en drivers, sin repago de equity y €0 de subvención en el caso base.
Modelo de Previsión y Gestión Interactivo
Este modelo es una previsión de gestión interactiva para revisión privada de inversores. NO está auditado. Los resultados de valuación son indicativos y dependen de supuestos, ejecución del despliegue, tasa de ocupación de medios, CPM, contratos, validación legal e implementación técnica. Las estimaciones de CPM e impactos requieren validación de medios independiente. Las cifras financieras se basan en documentación fuente actual y están sujetas a revisión de inversor, legal y financiera. Todas las cifras están pendientes de validación financiera a menos que estén marcadas como documentadas en fuente.
770
POS Fase 1
370 existentes + 400 lectores nuevos
370
Lectores iniciales
Dato operativo
770 + 770
Capas de pantalla
Procurement / despliegue Fase 1
€1.428M
Revenue Año Lanzamiento
BC 6.7 · Nov-26–Oct-27
€0.360M
EBITDA Año Lanzamiento
25,22% margen
€10.213M
Revenue Año 3
BC 6.7 previsión de dirección
€7.276M
EBITDA Año 3
71,23% margen
€0.621M
Caja mínima
Dashboard BC 6.7
Estado de valoración — no se incluye valoración formal
BC 6.7 actualiza el forecast financiero y la evidencia para comité de inversión. No constituye valoración formal, fairness opinion ni recomendación de inversión.
Despliegue de red — 36 meses
Despliegue Fase 1 — 770 POS activos / circuito completo de 2.310 dispositivos antes del 14 de abril de 2027
Mes 1
Nov 2026
370
POS activos
0
circuitos 3 pantallas
Mes 2
Dec 2026
370
POS activos
0
circuitos 3 pantallas
Mes 3
Jan 2027
370
POS activos
0
circuitos 3 pantallas
Mes 4
Feb 2027
370
POS activos
0
circuitos 3 pantallas
Mes 5
Mar 2027
646
POS activos
530
circuitos 3 pantallas
Mes 6
Apr 2027
770
POS activos
770
circuitos 3 pantallas
Mes 7
May 2027
770
POS activos
770
circuitos 3 pantallas
Mes 12
Oct 2027
770
POS activos
770
circuitos 3 pantallas
Mes 24
Oct 2028
2370
POS activos
2370
circuitos 3 pantallas
Mes 36
Oct 2029
3370
POS activos
3370
circuitos 3 pantallas
El objetivo de Fase 1 de 770 localizaciones parte de 370 lectores PPI operativos más 400 lectores nuevos. La monetización de pantallas traseras y frontales comienza progresivamente desde marzo de 2027 a medida que las ubicaciones entran en operación. La expansión a 2.370 y 3.370 POS sigue siendo una previsión de despliegue de dirección sujeta a sitios firmados, suministro de hardware, capacidad de instalación, coordinación FENAMIX y ejecución comercial.
Streams de ingresos — Year 1
¿Quién paga, por qué paga y qué retiene LOTOMIX? Ver explicación principal del modelo de ingresos.
Revenue retenido de screen media
PPI + rear 28-inch + front 48-inch retained economics
872.757,34 €
Tarifas plataforma / WebApp
Active POS fee schedule
247.340,00 €
Revenue Peñas
Technology/service revenue separated from lottery stakes
117.024,00 €
Revenue membresía IA
1.5% conversion and €25 ARPU assumption
182.850,00 €
Revenue notificaciones / mailings
Consent, delivery and CPM-dependent
7606,56 €
TOTAL REVENUE Year 1
1.427.577,90 €
Reparto FENAMIX 70/30 — alcance
FENAMIX participa únicamente en el revenue publicitario wholesale de pantallas frontales de 48 pulgadas al 30%. La publicidad PPI, pantallas traseras, tarifas de plataforma, suscripciones, Peñas, notificaciones y economía NFC quedan fuera del revenue-share FENAMIX en el modelo actual.
OPEX basado en drivers
Año 1
908.842,80 €
Payroll
Minimum operating team + ramp
663.200,00 €
Fixed central overhead
Base overhead
45.725,00 €
Cloud / DevOps / monitoring
Usage + revenue-linked proxy
19.198,43 €
Field maintenance
Active POS
87.972,00 €
Customer service
User / POS capacity
24.500,00 €
Replacement reserve
Hardware reserve
8247,38 €
Grant administration
New POS administration
60.000,00 €
Año 2
1.681.112,75 €
Payroll
Scaled operating team
927.000,00 €
Fixed central overhead
Scaled central overhead
78.486,00 €
Cloud / DevOps / monitoring
Usage + revenue-linked proxy
52.061,75 €
Field maintenance
Active POS
235.488,00 €
Customer service
User / POS capacity
126.000,00 €
Replacement reserve
Hardware reserve
22.077,00 €
Grant administration
New POS administration
240.000,00 €
Año 3
2.026.083,94 €
Payroll
Scaled operating team
954.810,00 €
Fixed central overhead
Scaled central overhead
80.840,58 €
Cloud / DevOps / monitoring
Usage + revenue-linked proxy
102.134,61 €
Field maintenance
Active POS
419.016,00 €
Customer service
User / POS capacity
280.000,00 €
Replacement reserve
Hardware reserve
39.282,75 €
Grant administration
New POS administration
150.000,00 €
El impuesto de sociedades está modelizado como previsión de dirección y permanece sujeto a revisión contable y fiscal.
La D&A procede del modelo y debe reconciliarse con la política final de capitalización de hardware, software y activos vinculados a la adquisición.
CAPEX
Sphere acquisition & clean-up
450.000,00 €
Software future commitment
375.000,00 €
Rear 28-inch display
300,00 €/unit
Additional PPI reader
300,00 €/unit
Front 48-inch screen
750,00 €/unit
Installation
120,00 €/POS
Exterior / gobo activation
150,00 €/POS
Initial 200k NFC cards
216.000,00 €
Año 1
2.183.768,34 €
Año 2
2.604.931,66 €
Año 3
1.620.000,00 €
El uso de caja de lanzamiento BC 6.7 incluye adquisición/regularización de Sphere, procurement de hardware, instalación, activación exterior, finalización/seguridad/integración de software y el tramo inicial de 200.000 tarjetas NFC.
Hitos de rentabilidad y liquidez
EBITDA mensual positivo
Mes 6
Apr 2027
EBIT y beneficio neto positivo
Mes 7
May 2027
Caja mínima al cierre
Mes 18
Apr 2028
620.666,50 €
FCF mensual positivo
Mes 7
May 2027
La Fase 1 se completa el 14 de abril de 2027. El EBITDA mensual se vuelve positivo en abril de 2027; el FCF mensual se vuelve positivo en mayo de 2027. La caja mínima se produce en abril de 2028 en el modelo de cash-flow BC 6.7.
Financiación
Equity inicial
€3.0M
Repago principal
€0
Redención obligatoria
No
Repago Month 12
No
€3.0 million equity financing case with no principal repayment or mandatory redemption.
Sensibilidad de subvención
Caso base
€0
Excluido hasta concesión formal
Caso medio
1.925.000,00 €
€5,000/POS · 50% success · 770 POS
Caso upside
5.390.000,00 €
€10,000/POS · 70% success · 770 POS
Las subvenciones permanecen excluidas de ingresos y liquidez hasta concesión formal. Las sensibilidades no forman parte del caso base.
Sensibilidad de fill Year 2
Fill 30%
2.226.586,14 €
Revenue media neta
Fill 50%
3.710.976,90 €
Revenue media neta
Fill 70%
5.195.367,65 €
Revenue media neta
Qué cambió con BC 6.7
BC 6.4: 500-POS initial network
BC 6.7: 770-location Phase 1 circuit by 14 Apr 2027
BC 6.4: 130 new readers
BC 6.7: 400 additional PPI readers + 770 rear displays + 770 front screens
BC 6.4: July 2026–June 2029 period
BC 6.7: Launch Year Nov-26–Oct-27, then Year 2 and Year 3
BC 6.4: Year 3 revenue €19.27M
BC 6.7: Year 3 revenue €10.21M with more conservative assumptions
BC 6.4: Year 3 EBITDA €15.58M
BC 6.7: Year 3 EBITDA €7.28M with updated launch cash and costs
NFC as long-term acquisition concept
Initial 200,000-card NFC overlay disclosed separately and excluded from core P&L
Caveats de due diligence
Figures are management forecasts and are not audited.
BC 6.7 should be the only active financial source shown to investors; BC 6.4 and BC 6.3 must remain archived.
NFC/Peñas overlay is excluded from the core P&L until legal, pricing, conversion and pilot assumptions are validated.
FENAMIX 30% participation applies only to wholesale 48-inch front-screen advertising revenue.
Rear/front installed counts, supplier quotes, payment rails, proof-of-play methodology and legal structure remain key diligence items.
Registro de fuentes
BC 6.7 workbook
CurrentLOTOMIX_BC_6_7.xlsx
Tratamiento: Sole active financial model for investor-facing KPIs
Próxima evidencia: Upload signed source workbook to Data Room
Executive memo
CurrentLOTOMIX_BC_6_7_Executive_Memo_Waterhouse
Tratamiento: Narrative explanation of BC 6.7 changes, timeline and use of funds
Próxima evidencia: Upload final memo PDF/DOCX to Data Room
Business breakdown
CurrentPremiaTech September 2026 breakdown
Tratamiento: Monetisation architecture, revenue streams and source-register update
Próxima evidencia: Upload final deck and PDF
BC 6.4
ArchivedJuly 2026 Waterhouse model
Tratamiento: Superseded by BC 6.7; retained for audit trail only
Próxima evidencia: Mark as archived / do not use for current KPIs
BC 6.3
SupersededLegacy model
Tratamiento: Historical reference only; do not use for current KPIs or valuation
Próxima evidencia: Keep archived with warning
Matriz de evidencia
| Métrica | Hoja | Valor portal | Estado | Próximo doc |
|---|---|---|---|---|
| Opening reader estate | Assumptions / Deployment | 370 readers | Operating data | Reader inventory and installation evidence |
| Phase 1 POS target | Deployment / Launch Timeline | 770 POS | Management plan | Supplier, installation and site activation evidence |
| Launch-Year revenue | Annual Summary | €1.428M | Forecast | BC 6.7 source workbook |
| Launch-Year EBITDA | Annual Summary | €0.360M | Forecast | BC 6.7 source workbook |
| Year 3 revenue | Annual Summary | €10.213M | Forecast | BC 6.7 source workbook |
| Year 3 EBITDA | Annual Summary | €7.276M | Forecast | BC 6.7 source workbook |
| Launch cash use | Annual Summary / Procurement | €2.184M | Management plan | Supplier quotes, PO and installation plan |
| NFC overlay | NFC_200K_OVERLAY | €425k retained before direct costs | Excluded sensitivity | Pilot, legal and pricing validation |
Riesgos BC 6.7
BC 6.7 no está auditado
Supuesto: Management forecast pending independent validation
La Fase 1 depende de plazos de proveedor e instalación
Supuesto: Hardware available Madrid by 1 Mar 2027 and 45-day installation window
Los supuestos de media fill y tarifas requieren validación comercial
Supuesto: Launch-year exit fill 50%, Y2 60%, Y3 70%
Estructura legal y pricing de Peñas/NFC pendiente de validación
Supuesto: NFC overlay excluded from core P&L
Integración técnica y pasarelas de pago siguen siendo camino crítico
Supuesto: Software future commitment €375k after €225k paid
BC 6.7 portal synchronisation
September 2026 BC 6.7 supersedes BC 6.4 as the active investor-facing financial model.
Continúa tu revisión
FUNDING → MILESTONES BRIDGE · LÓGICA DE INVERSIÓN
Funding → Milestones Bridge
Cómo la inversión propuesta convierte los activos existentes de LOTOMIX en escala comercial medible.
LOTOMIX no capta capital para validar el concepto inicial. La financiación actual pretende convertir una relación de red existente, infraestructura desplegada, tecnología desarrollada y pipeline de rollout actual en una operación comercial más amplia.
El despliegue de capital debe evaluarse, por tanto, frente a hitos operacionales medibles más que frente al gasto en solitario.
No se implica que el riesgo de ejecución esté eliminado.
PUENTE VISUAL — LÓGICA COMPLETA EN ~60 SEGUNDOS
PHASE 0 — POSITION AT INVESTMENT
Posición existente antes del nuevo despliegue de capital
Red
- Relación comercial FENAMIX
- Perímetro potencial de red ~7.000 puntos
- ~370 ubicaciones con lector existentes
- 1.200+ ubicaciones en pipeline de interés / rollout
Tecnología
- Plataforma software LOTOMIX desarrollada
- Funcionalidad de validación de tickets
- Arquitectura backend
- Trabajo de integración con administraciones
- Pruebas operativas en curso
Infraestructura física
- Huella de lectores A1D / PPI existente
- Arquitectura de hardware actual
- Infraestructura de pantallas publicitarias definida y parcialmente desplegada
Arquitectura comercial
- Múltiples líneas de ingresos identificadas
- Modelo publicitario
- SaaS
- Transacciones
- Monetización de app
- Membresías
- Peñas
Preparación de inversión
- Modelo financiero BC 6.7 actual
- Sensibilidades adverso / base / favorable
- Roadmap de rollout comercial actual
- Materiales de inversión Waterhouse y due diligence
POSICIÓN ACTUAL — ACTIVOS EXISTENTES / DESARROLLO / INFRAESTRUCTURA DESPLEGADA
No se muestran ingresos proyectados en este bloque.
Fase 1 — Preparación de lanzamiento comercial
NEAR-TERM EXECUTION MILESTONEObjetivo de capital
Completar los requisitos inmediatos para el rollout comercial amplio: desarrollo final de software, hardening de plataforma, escalabilidad backend, onboarding de administraciones, procurement de hardware, inventario, operaciones de instalación, activación de equipo comercial, preparación de ventas publicitarias y capital circulante.
Hito objetivo
Rollout comercial amplio objetivo durante diciembre 2026.
Riesgo principal reducido
Riesgo de ejecución de producto / lanzamiento.
Evidencia de consecución
Fase 2 — Expansión de red
MANAGEMENT ROLLOUT TARGETObjetivo de capital
Financiar la transición de la huella existente hacia un estate operativo sustancialmente mayor: lectores adicionales, pantallas traseras, pantallas LOTOADS de gran formato, logística de instalación, activación de administraciones, soporte de campo, conectividad y capacidad de mantenimiento.
Hito objetivo
Despliegue adicional de pantallas desde marzo 2027; aproximadamente 770 ubicaciones completadas objetivo abril 2027 (objetivo de dirección, no un recuento de instalaciones contratadas existentes).
Riesgo principal reducido
Riesgo de rollout / despliegue.
Evidencia de consecución
Fase 3 — Monetización publicitaria
COMMERCIAL VALIDATIONObjetivo de capital
Convertir el estate físico en una red publicitaria digital medible: adquisición de anunciantes, ventas de medios, gestión de campañas, infraestructura de ad-serving, uso de pantalla, reporting, medición y relaciones con agencias / marcas.
Hito objetivo
Seguir % de pantallas activas comercialmente, ocupación / fill publicitario, CPM realizado, número de anunciantes activos, tasa de anunciantes recurrentes, renovación de campañas e ingresos publicitarios mensuales. Economía realizada, no valor bruto de inventario.
Riesgo principal reducido
Riesgo de monetización publicitaria.
Evidencia de consecución
Fase 4 — Monetización digital / app
GROWTH / MONETISATION MILESTONEObjetivo de capital
Escalar el ecosistema digital orientado al consumidor y activar líneas adicionales: adquisición de usuarios de app, activación de cuentas, escaneo / almacenamiento de tickets, funcionalidad wallet donde sea legal y técnicamente aplicable, funcionalidad peñas, suscripciones / membresías, monetización transaccional y de comunicaciones.
Hito objetivo
Seguir por separado: descargas, usuarios registrados, MAU, volumen transaccional, GTV, revenue LOTOMIX, miembros pagadores, conversión a membresía y participación de peñas. Las descargas no sustituyen usuarios activos; el GTV no sustituye el revenue LOTOMIX.
Riesgo principal reducido
Riesgo de adopción de consumidor / monetización digital.
Evidencia de consecución
Fase 5 — Palanca operativa
FINANCIAL INFLECTIONObjetivo de capital
Demostrar que la escala produce un modelo operativo progresivamente más fuerte.
Hito objetivo
Seguir ingresos por ubicación activa, ingresos publicitarios por pantalla, ingresos SaaS por administración pagadora, margen de contribución, OPEX mensual, EBITDA, cash burn, runway, capital circulante y conversión de caja. Acercarse a sostenibilidad de caja operativa / break-even EBITDA según BC 6.7 (fecha y economía aprobadas tomadas directamente de BC 6.7 — no inventadas aquí).
Riesgo principal reducido
Riesgo de financiación / sostenibilidad.
Evidencia de consecución
Fase 6 — Opcionalidad de escala
OPORTUNIDAD DE DIRECCIÓN A MÁS LARGO PLAZOSolo tras los hitos anteriores: expansión más allá de 770 ubicaciones, mayor penetración del estate FENAMIX, progresión hacia el objetivo de 3.370 ubicaciones a más largo plazo, mayor inventario publicitario, mayor base de consumidores, monetización adicional de producto y alianzas estratégicas. La expansión a largo plazo no se presenta como parte del estate desplegado existente.
CAPITAL AT WORK
01
Producto
Capital desplegado: Finalización de plataforma, fiabilidad y escalabilidad.
Resultado: Plataforma operativa desplegable comercialmente.
02
Red
Capital desplegado: Hardware, instalaciones y activación de administraciones.
Resultado: Mayor huella física activa.
03
Publicidad
Capital desplegado: Capacidad de ventas, infraestructura de campañas y activación comercial.
Resultado: Inventario de pantallas monetizado.
04
Digital
Capital desplegado: Capacidad de crecimiento y monetización de app.
Resultado: Ecosistema activo de usuarios y transacciones.
05
Capital circulante
Capital desplegado: Inventario, timing de rollout y liquidez operativa.
Resultado: Capacidad de ejecutar el rollout sin constreñir el crecimiento.
MILESTONE GATES — MARCO DE MONITORIZACIÓN
Lanzamiento comercial
Evidencia requerida
- Plataforma lista
- Administraciones activas
- Hardware operativo
- Primera actividad comercial
Escala de despliegue
Evidencia requerida
- Expansión de ubicaciones
- Instalación de hardware
- Telemetría en vivo
- Adopción de administraciones
Validación publicitaria
Evidencia requerida
- Anunciantes activos
- Fill realizado
- CPM
- Ingresos recurrentes
Validación digital
Evidencia requerida
- Usuarios activos
- Actividad transaccional
- Membresías / peñas pagadoras
Escala financiera
Evidencia requerida
- Unit economics mejorando
- Mayor margen de contribución
- OPEX controlado
- Camino hacia break-even
Qué la financiación NO debe interpretarse como
- No financia 7.000 instalaciones inmediatas
- No garantiza que el pipeline de 1.200+ se convierta totalmente
- No garantiza el fill publicitario
- No garantiza subvenciones públicas
- No garantiza la adopción de usuarios
- No garantiza el objetivo de rollout de abril 2027
La inversión proporciona los recursos necesarios para ejecutar frente a estas oportunidades y medir el rendimiento comercial resultante.
Punto de inflexión de inversión
Antes de la financiación
- Acceso a red
- Huella instalada existente
- Tecnología
- Pruebas actuales
- Demanda de rollout
- Arquitectura comercial
Tras financiación y ejecución exitosa
- Red operativa más amplia
- Inventario publicitario digital monetizado
- Economía de plataforma recurrente
- Actividad digital de consumidor
- Unit economics medibles por ubicación
- Incertidumbre de rollout y monetización sustancialmente reducida
Tabla de monitorización de dirección
· uso interno / restringido| Hito | Objetivo | Real | Desv. | Estado | Evidencia | Propietario |
|---|---|---|---|---|---|---|
| Huella de lectores existente (~370) | ~370 | ~370 | 0 | COMPLETED | Operations | |
| Finalización de plataforma software | Production release | — | — | IN PROGRESS | Technology | |
| Rollout comercial amplio | Dec 2026 | — | — | NOT STARTED | Commercial | |
| Despliegue adicional de pantallas | Mar 2027 | — | — | NOT STARTED | Operations | |
| Ubicaciones completadas | ~770 by Apr 2027 | — | — | NOT STARTED | Operations | |
| Validación publicitaria | Realised fill / CPM | — | — | NOT STARTED | Commercial | |
| Monetización digital / app | MAU / paying members | — | — | NOT STARTED | Digital | |
| Break-even EBITDA (BC 6.7) | Per BC 6.7 | — | — | NOT STARTED | Finance |
Los hitos futuros no se marcan como ON TRACK salvo información de dirección que lo respalde.
ENLACES AL DATA ROOM
“Mi capital no desaparece en gasto corporativo general. Financia pasos específicos que pueden medirse, evidenciarse y compararse frente a la tesis de inversión.”
Continúa tu revisión
UNIT ECONOMICS BY LOCATION · DEL LA UNIDAD A LA RED
Unit Economics by Location
Desde una administración activada hasta la economía a escala de red.
MODEL RECONCILIATION REQUIRED — Esta sección usa los valores canónicos del Master KPI Registry (hardware 11,6"/23,8"/43", CPM lector €6–€9, SaaS €30/mes). El modelo BC 6.7 carga actualmente valores distintos (11,9"/28"/48", CPM €5,60, SaaS €40). La discrepancia está registrada en el Master KPI Registry. No se muestran figuras inconsistentes; los importes de red se reconcilian con BC 6.7 mediante timing, rampa y fill.
1 · DEFINIR LA UNIDAD ECONÓMICA
Una ubicación LOTOMIX activada puede contener varios componentes monetizables. La configuración completa desplegada:
1 × Lector A1D / PPI
Interacción de ticket de lotería; lectura / validación de ticket; interfaz digital al cliente; impresiones publicitarias.
1 × Pantalla trasera
Inventario publicitario digital continuo.
1 × LOTOADS gran formato
Inventario publicitario de alta visibilidad.
1 ubicación completa = hasta 3 superficies publicitarias digitales.
No toda ubicación existente tiene actualmente las tres pantallas salvo evidencia de despliegue. Distíngase ubicación solo-lector de ubicación completa.
2 · PERFIL A — UBICACIÓN CON LECTOR EXISTENTE
Economía del lector A1D / PPI existente
800
visitas/día
30%
tasa de captura
240
lecturas/día
26
días operativos/mes
6,240
lecturas/mes
12,480
impresiones monetizables/mes
Rango de CPM modelizado actual: €6–€9. Ingresos publicitarios del lector = 12.480 impresiones / 1.000 × CPM.
Ingresos lector: €74.88 (CPM €6) – €112.32 (CPM €9) / mes
MODEL ASSUMPTIONS — mostrar ACTUAL por separado cuando exista telemetría3 · PERFIL B — UBICACIÓN LOTOMIX COMPLETA
Economía de una ubicación completa (lector + trasera + gran formato + SaaS)
Publicidad lector
12.480 impresiones/mes × CPM realizado = ingresos lector. Base (CPM €7,5): €93.60/mes
Publicidad pantalla trasera
Slot 10 s · bucle 100 s · 10 posiciones · 10 h/día · 26 días/mes ≈ 9.360 pasadas/mes por pantalla.
Precio comercial BC 6.7 (no inventado del volumen de pasadas). Bruto mensual base: €112.32/mes
Publicidad gran formato (43")
10 posiciones · precio lista €40/slot/mes = €400 bruto. Escenarios de precio realizado: €320 / €280 / €240 / €200.
Cesion FENAMIX 30% aplica SOLO a gran formato: bruto − 30% = neto LOTOMIX.
Base: bruto €280.00 − FENAMIX €84.00 = neto €196.00/mes
El 30% FENAMIX NO se aplica a publicidad de lector ni a pantalla trasera.
4 · ECONOMÍA SaaS
Referencia SaaS actual: €30/mes por administración pagadora. Identificar: entidad pagadora, número de administraciones pagadoras, timing de activación y si SaaS es incremental al ingreso publicitario. No se aplica SaaS a ubicaciones inactivas o no pagadoras.
5 · WATERFALL DE REVENUE POR UBICACIÓN (BASE)
El coste directo a nivel de ubicación no está aislado en BC 6.7; la contribución se calcula a nivel de red en el modelo financiero. No se restar OPEX central aquí.
6 · BRUTO VS NETO
Gross Media Revenue (43")
€280.00/mes
− FENAMIX 30%
€84.00/mes
LOTOMIX Net Revenue (43")
€196.00/mes
No usar gasto bruto de anunciantes como revenue reconocido LOTOMIX.
7 · TRES ESCENARIOS ECONÓMICOS (UNA UBICACIÓN COMPLETA)
| Métrica (mes) | Adverso | Base | Favorable |
|---|---|---|---|
| Revenue lector | €74.88 | €93.60 | €112.32 |
| Revenue pantalla trasera | €78.62 | €112.32 | €129.17 |
| Gran formato bruto | €200.00 | €280.00 | €320.00 |
| Cesion FENAMIX (30%) | €60.00 | €84.00 | €96.00 |
| Gran formato neto | €140.00 | €196.00 | €224.00 |
| SaaS | €0.00 | €30.00 | €30.00 |
| Total revenue LOTOMIX | €293.50 | €431.92 | €495.49 |
| Costes directos | MODEL RECONCILIATION REQUIRED — coste directo no aislado en BC 6.7 | ||
| Contribución | MODEL RECONCILIATION REQUIRED — ver BC 6.7 a nivel de red | ||
Adverso: tráfico/captura/CPM/fill menores, SaaS retrasado. Base: BC 6.7. Favorable: supuestos aprobados del modelo. No se crea escenario optimista nuevo.
8 · ESCALAR LA UNIT ECONOMICS
1
1 ubicación
Entender la unidad.
100
100 ubicaciones
Escala comercial inicial.
500
500 ubicaciones completas
1.500 pantallas (500 lectores + 500 traseras + 500 gran formato).
770
770 ubicaciones completadas
Objetivo de dirección — ~770 para abril 2027.
3,370
3.370 ubicaciones
Solo caso de gestión a largo plazo.
OBJETIVO A LARGO PLAZO — NO DESPLIEGUE ACTUAL
Run-rate ilustrativo a madurez completa (base): €431.92/ubicación/mes. No se multiplica automáticamente: BC 6.7 consolida con timing de rollout, rampa publicitaria, fill y activación SaaS. El run-rate × ubicaciones NO equivale al consolidado BC 6.7; la diferencia se explica por timing, rampa y ocupación.
9 · No usar multiplicación simple donde no es válida. El escalado de red contempla timing de rollout, instalaciones parciales, rampa publicitaria, fill distinto, timing de activación SaaS, onboarding escalonado, comisión FENAMIX e ingresos de app/transacción que no son atribuibles directamente a ubicaciones individuales. Los valores a escala de red deben reconciliarse con BC 6.7; si unit economics × ubicaciones ≠ BC 6.7, se explica por timing, rampa u ocupación — no se fuerza la coincidencia.
10 · PUENTE DE ECONOMÍA POR UBICACIÓN
11 · ¿QUÉ MUEVE LA UNIT ECONOMICS?
Tráfico
Más tráfico cualificado aumenta el volumen de interacción disponible.
Tasa de captura
Mayor % de visitantes interactuando con el lector aumenta la actividad monetizable.
Fill publicitario
Mayor uso del inventario disponible aumenta el ingreso publicitario realizado.
CPM / precio realizado
Mayor precio efectivo de medios aumenta ingresos sin hardware adicional.
Configuración de pantallas
Una ubicación completa de 3 pantallas tiene mayor capacidad de monetización que una solo lector.
No implicar relaciones lineales donde BC 6.7 las modela de forma distinta.
12 · CURVA DE MADUREZ DE UBICACIÓN
1. Instalada
Hardware desplegado físicamente.
2. Activada
Administración operando la plataforma.
3. Monetizable
Inventario publicitario técnicamente disponible.
4. Comercialmente activa
Publicidad / SaaS generando ingresos.
5. Madura
Ubicación operando cerca de la economía base planificada.
Una ubicación instalada NO se cuenta automáticamente como ubicación totalmente monetizada.
13 · UNIT ECONOMICS REAL VS MODELADA
| KPI | Modelo | Real | Desv. |
|---|---|---|---|
| Tráfico diario | 800 | — | — |
| Tasa de captura | 30% | — | — |
| Impresiones | 12,480 | — | — |
| Fill publicitario | — | — | — |
| CPM | €6–€9 | — | — |
| Revenue publicitario | €431.92 | — | — |
| SaaS | €30.00 | — | — |
| Contribución | — | — | — |
Commercial validation data accumulating — no se fabrican resultados reales.
14 · LÓGICA DE BREAK-EVEN DE RED
Contribución por ubicación activa × número de ubicaciones comercialmente maduras debe cubrir la base de coste operativo central para alcanzar break-even operativo. Se usa solo la estructura OPEX aprobada de BC 6.7. No se calcula un nuevo recuento de ubicaciones de break-even salvo que el modelo subyacente lo soporte.
15 · PALANCA OPERATIVA
La palanca operativa de LOTOMIX depende de expandir el número de ubicaciones generadoras de ingresos más rápido que la base de coste operativo central.
Progresión BC 6.7 entre escala de red, ingresos, margen de contribución, OPEX y EBITDA — factual y basada en el modelo.
16 · ENLACES AL MODELO FINANCIERO
Comprensión, no duplicación: no se reproduce el modelo financiero completo aquí.
17 · EL MOTOR ECONÓMICO DE LOTOMIX
- Una administración proporciona el punto físico de distribución.
- El lector crea interacción con el cliente e inventario publicitario.
- Las pantallas adicionales aumentan la capacidad de medios monetizable.
- SaaS añade economía de plataforma recurrente.
- Los productos digitales y transaccionales crean economía adicional a nivel de red.
- La escala viene de replicar la unidad operativa en una red activa en expansión controlando el OPEX central.
18 · CONTROL DE DATOS CRÍTICO
Antes de publicar cualquier figura calculada, se contrasta con BC 6.7, el Master KPI Registry, el tratamiento comercial FENAMIX, la especificación de hardware actual y el plan de rollout vigente. Si un valor derivado entra en conflicto con BC 6.7, se marca MODEL RECONCILIATION REQUIRED en lugar de mostrar figuras inconsistentes al inversor.
Continúa tu revisión
REVENUE QUALITY & RECURRENCE
Revenue Quality & Recurrence
Entender cómo cada flujo de ingresos de LOTOMIX se comporta, escala y convierte en valor económico recurrente.
No repite el forecast de ingresos: explica calidad, recurrencia, madurez y dependencias. Fuentes de control: BC 6.7 y el modelo de ingresos aprobado.
1 · MATRIZ DE CALIDAD DE REVENUE
| Flujo | Tipo | Recurrencia | Madurez | Driver principal | Dependencia |
|---|---|---|---|---|---|
| Publicidad lector | MEDIA / ADVERTISING | Ocupación | COMMERCIAL ACTIVATION | Tráfico, tasa de interacción, impresiones, CPM realizado | Demanda de anunciantes y fill |
| Publicidad pantalla trasera | MEDIA / ADVERTISING | Ocupación | COMMERCIAL ACTIVATION | Pantallas activas, horas, slots, fill, precio | Demanda de anunciantes y ocupación |
| Publicidad gran formato LOTOADS | MEDIA / ADVERTISING | Ocupación | COMMERCIAL ACTIVATION | Fill, precio realizado, contratos de anunciantes | Canal FENAMIX y demanda de anunciantes |
| SaaS | SUBSCRIPTION RECURRING | Recurrente | PRE-COMMERCIAL | Administraciones activas pagadoras | Tasa de activación pagadora |
| Comisiones por transacción | TRANSACTIONAL | Basado en uso | MODELLED | MAU, frecuencia, ticket medio, GTV | Adopción de usuario y actividad |
| Monetización app / digital | DIGITAL MONETISATION | Basado en uso | PRE-COMMERCIAL | MAU, frecuencia de interacción, impresiones | Adopción de la app |
| Membresías | MEMBERSHIP | Basado en uso | FUTURE PRODUCT | Conversión, precio, retención | Descargas y conversión a pago |
| Peñas | COMMISSION | Basado en uso | PRE-COMMERCIAL | Peñas activas, retención, participación media | Adopción comunitaria |
| Comunicaciones / CRM | DIGITAL MONETISATION | Basado en uso | FUTURE PRODUCT | MAU, inventario de comunicación, precio | Adopción de la plataforma |
2 · TIPOS DE REVENUE CONTROLADOS
No se usan etiquetas vagas (predecible, garantizado, estable) sin evidencia contractual.
3 · CLASIFICACIÓN DE MADUREZ
Los ingresos futuros no aparecen visualmente equivalentes a los actuales.
4 · PUBLICIDAD LECTOR
MEDIA / ADVERTISING. El revenue no es recurrente solo por instalación. Un lector instalado crea inventario monetizable, pero el revenue realizado depende de demanda de anunciantes y utilización comercial.
Inventario disponible
Impresiones técnicas del lector
Inventario vendido
Fill / ocupación publicitaria
Revenue realizado
Inventario vendido × CPM realizado
Donde exista performance publicitaria real, se distingue de la modelización BC 6.7.
5 · PUBLICIDAD PANTALLA TRASERA
MEDIA / ADVERTISING. Se distingue disponibilidad técnica de ocupación comercial. No se calcula revenue solo de impresiones teóricas.
6 · PUBLICIDAD GRAN FORMATO LOTOADS
MEDIA / ADVERTISING. Bruto de anunciantes − 30% FENAMIX = neto LOTOMIX. El 30% aplica SOLO a gran formato 43"/48"; no a lector ni trasera.
Refleja contratos recurrentes donde existan, revenue por campaña donde no, y ocupación realizada real.
7 · SAAS
SUBSCRIPTION RECURRING. Referencia €30/mes. Driver principal: administraciones activas pagadoras (no tráfico ni fill).
Sin datos de churn/retención contractuales, no se inventan. Retención a establecer conforme escala la base pagadora.
8 · COMISIONES POR TRANSACCIÓN
TRANSACTIONAL / USAGE-BASED. Referencia 0,5% de comisión. Drivers: MAU, frecuencia, ticket medio, GTV, fee LOTOMIX.
El volumen total de transacciones NO se clasifica como revenue.
Recurrente solo en la medida en que la actividad de usuario se repite.
9 · MEMBRESÍAS
SUBSCRIPTION / MEMBERSHIP. Referencia: 2,5% conversión, 6.250 suscriptores en el caso de planificación de 250.000 descargas.
Sin retención comercial establecida: MODELLED RETENTION / TO BE VALIDATED (no dato observado).
10 · PEÑAS
COMMISSION / TRANSACTIONAL. Modelo: 500 administraciones × 5 peñas = 2.500 peñas × 20 miembros = 50.000 posiciones × €8 media mensual = €400.000 GTV mensual × 30% fee.
Los €400.000 GTV NO se presentan como turnover LOTOMIX.
11 · APP / MONETIZACIÓN DIGITAL
DIGITAL MONETISATION. No se agrega todo lo digital en un único headline. Drivers: MAU, frecuencia, impresiones, inventario de comunicación, actividad transaccional, precio realizado.
PRE-COMMERCIAL / MODELLED12 · SCORECARD DE CALIDAD DE REVENUE
| Flujo | Recurrente? | Contratado? | Dep. tráfico? | Dep. fill? | Dep. adopción? | Evidencia |
|---|---|---|---|---|---|---|
| Publicidad lector | NO | PARTIALLY | YES | YES | NO | COMMERCIAL ACTIVATION |
| Publicidad trasera | NO | PARTIALLY | NO | YES | NO | COMMERCIAL ACTIVATION |
| Gran formato LOTOADS | PARTIALLY | PARTIALLY | NO | YES | NO | COMMERCIAL ACTIVATION |
| SaaS | YES | PARTIALLY | NO | NO | PARTIALLY | PRE-COMMERCIAL |
| Comisiones transacción | PARTIALLY | NO | NO | NO | YES | MODELLED |
| Monetización app | PARTIALLY | NO | NO | PARTIALLY | YES | PRE-COMMERCIAL |
| Membresías | YES | NO | NO | NO | YES | FUTURE PRODUCT |
| Peñas | PARTIALLY | NO | NO | NO | YES | PRE-COMMERCIAL |
| Comunicaciones / CRM | PARTIALLY | NO | NO | PARTIALLY | YES | FUTURE PRODUCT |
Herramienta de clasificación factual, no un ranking.
13 · REVENUE RECORRENTE VS VARIABLE
Más estructuralmente recurrente
SaaS · membresías de pago · contratos publicitarios recurrentes una vez contratados.
Dependiente de uso / actividad
Comisiones de transacción · peñas · monetización de app.
Dependiente de media / ocupación
Publicidad lector · pantalla trasera · gran formato.
No se presenta revenue de suscripción modelada como recurrente si las suscripciones no han lanzado comercialmente.
14 · ESCALERA DE MADUREZ DE REVENUE
No se mueven flujos a Etapa 4 o 5 sin datos reales de apoyo.
15 · REVENUE CONTRATADO / EVIDENCIADO
- Compromisos publicitarios firmados
- Clientes SaaS pagadores
- Transacciones reales
- Membresías activas
- Comisiones realizadas
- Facturas
- Otra evidencia comercial documentada
REVENUE PREVISTA (FORECAST)
- Fill publicitario futuro
- Activación SaaS futura
- Usuarios proyectados
- Membresías proyectadas
- Comisiones proyectadas
- Participación peñas proyectada
16 · CONCENTRACIÓN DE REVENUE
Concentración por anunciante, canal, ubicación, flujo y socio estratégico. Sin datos suficientes, no se fabrican métricas.
Revenue concentration analysis will become more representative as commercial deployment scales.
17 · VISIBILIDAD DE REVENUE PUBLICITARIA
| Métrica | Real / Actual | Caso base | Adverso |
|---|---|---|---|
| Pantallas activas | N/A — validación comercial pendiente | 770 | 770 |
| Inventario disponible | N/A — validación comercial pendiente | BC 6.7 | BC 6.7 |
| Fill rate | N/A — validación comercial pendiente | 100% | 70% |
| CPM / precio realizado | N/A — validación comercial pendiente | €7.50 | €6.00 |
| Revenue media mensual | N/A — validación comercial pendiente | BC 6.7 | BC 6.7 |
| Revenue neto LOTOMIX | N/A — validación comercial pendiente | BC 6.7 | BC 6.7 |
La columna Real no se rellena con supuestos. Base y adverso según BC 6.7.
18 · FRAMEWORK DE KPIs DE REVENUE RECORRENTE
MRR/ARR reales solo con revenue pagador real.
19 · PRIORIDADES DE VALIDACIÓN DE REVENUE
Publicidad
- Fill
- CPM / precio realizado
- Retención de anunciantes
SaaS
- Activación pagadora
- Retención
App
- MAU
- Engagement
- Monetización
Membresías
- Conversión
- Retención
Peñas
- Adopción
- Miembros activos
- Frecuencia de participación
Transacciones
- Frecuencia
- GTV
- Comisión LOTOMIX realizada
Conecta con el framework de monitorización de KPIs post-inversión.
20 · EVOLUCIÓN DE CALIDAD DE REVENUE
El objetivo de LOTOMIX no es solo aumentar el volumen de revenue, sino aumentar progresivamente la proporción respaldada por comportamiento repetido real y performance comercial medible.
21 · NO AGREGAR DEMASIADO PRONTO
No se muestra un único headline “Recurring Revenue” si incluye forecast publicitario, transacciones proyectadas, membresías proyectadas, SaaS no activado o peñas proyectadas. Solo revenues que cumplan una definición recurrente consistente.
22 · CONEXIÓN CON BC 6.7
Toda cifra de flujo en esta página debe reconciliarse con BC 6.7. Si el cálculo del sitio difiere del modelo financiero vigente, se muestra internamente REVENUE RECONCILIATION REQUIRED. No se altera BC 6.7 automáticamente.
23 · ARQUITECTURA DE REVENUE
LOTOMIX combina varios modelos económicos distintos:
- Revenue media monetiza inventario digital físico.
- Revenue SaaS monetiza administraciones activas mediante cuotas recurrentes de plataforma.
- Revenue transaccional monetiza la actividad que fluye por el ecosistema.
- Revenue de membresías monetiza usuarios digitales premium.
- Economía de peñas monetiza participación comunitaria y volumen transaccional.
La calidad y predictibilidad relativas aumentarán conforme el despliegue comercial produzca datos históricos reales de fill, retención, conversión y comportamiento transaccional.
Continúa tu revisión
DOWNSIDE SURVIVAL & CASH PROTECTION
Downside Survival & Cash Protection
Cómo LOTOMIX protege la liquidez si el rollout, la monetización publicitaria o la adopción digital se desarrollan por debajo del caso base.
1 · PRINCIPIO CORE
El plan operativo de LOTOMIX está diseñado para escalar el gasto en línea con el rollout real y la tracción comercial, en lugar de desplegar la base de coste completa por adelantado.
Si el rollout o la monetización se desarrollan por debajo del plan, la primera respuesta de dirección es ralentizar la expansión discrecional y preservar liquidez mientras se protegen la plataforma core, la red existente y la infraestructura generadora de revenue.
No se implica que el negocio es inmune al riesgo adverso.
2 · TRES ESCENARIOS DE CAJA
| Métrica (Launch Year) | Adverso | Base (BC 6.7) | Favorable |
|---|---|---|---|
| Revenue | CASH MODEL REVIEW REQUIRED | €1,427,578 | CASH MODEL REVIEW REQUIRED |
| Contribución bruta | CASH MODEL REVIEW REQUIRED | €1,268,937 | CASH MODEL REVIEW REQUIRED |
| OPEX | CASH MODEL REVIEW REQUIRED | €908,843 | CASH MODEL REVIEW REQUIRED |
| EBITDA | CASH MODEL REVIEW REQUIRED | €360,094 | CASH MODEL REVIEW REQUIRED |
| Burn mensual | CASH MODEL REVIEW REQUIRED | CASH MODEL REVIEW REQUIRED | CASH MODEL REVIEW REQUIRED |
| Caja mínima | CASH MODEL REVIEW REQUIRED | CASH MODEL REVIEW REQUIRED | CASH MODEL REVIEW REQUIRED |
| Runway | CASH MODEL REVIEW REQUIRED | CASH MODEL REVIEW REQUIRED | CASH MODEL REVIEW REQUIRED |
| Capital adicional requerido | CASH MODEL REVIEW REQUIRED | CASH MODEL REVIEW REQUIRED | CASH MODEL REVIEW REQUIRED |
| Break-even operativo | CASH MODEL REVIEW REQUIRED | EBITDA+ en Launch Year (BC 6.7) | CASH MODEL REVIEW REQUIRED |
Caso base: BC 6.7 Launch Year. Adverso/Favorable: ver Downside Sensitivities; el aislamiento de caja por escenario requiere CASH MODEL REVIEW REQUIRED. No se estiman cifras no disponibles en BC 6.7.
3 · DRIVERS ADVERSOS PRINCIPALES
A. Rollout más lento
Ejemplos
- menos administraciones activadas
- despliegue de hardware más lento
- instalaciones retrasadas
- ciclo de onboarding más largo
Impacto financiero
- menor inventario publicitario
- menor activación SaaS
- transacciones retrasadas
- palanca operativa retrasada
B. Menor fill publicitario
Ejemplos
- menos anunciantes
- conversión de ventas más lenta
- menor utilización de inventario
Impacto financiero
- menor revenue media
- menor contribución por pantalla
- break-even de red retrasado
C. Menor tráfico / interacción
Ejemplos
- menor tráfico de ubicación
- menor tasa de captura del lector
- menos impresiones monetizables
Impacto financiero
- menor economía publicitaria del lector
- potencialmente menor conversión digital
D. Adopción digital más lenta
Ejemplos
- menos descargas de app
- menor MAU
- menor frecuencia de transacción
- menor conversión de membresía
- menor participación peñas
Impacto financiero
- menor revenue transaccional y de membresía
- desarrollo más lento de efectos de red
E. Mayor coste de despliegue
Ejemplos
- aumento de coste de hardware
- aumento de coste de instalación
- logística
- requisitos de soporte
Impacto financiero
- mayor despliegue de caja por ubicación
- rollout más lento para el mismo envelope de capital
4 · WATERFALL DE PROTECCIÓN DE CAJA
Demuestra respuesta operativa, no solo pérdidas financieras.
5 · COSTES POR FLEXIBILIDAD
| Categoría | Fijo / Semi / Variable | ¿Diferible? | Acción adverso |
|---|---|---|---|
| Tecnología core | Fixed | NO | Mantener estabilidad de plataforma |
| Personal | Semi-Fixed | PARTIALLY | Controlar contratación no crítica |
| Adquisición de hardware | Variable | YES | Recalendarizar pedidos al ritmo comercial |
| Instalación | Variable | YES | Ralentizar despliegue de menor prioridad |
| Marketing | Variable | YES | Reducir marketing discrecional |
| Adquisición de anunciantes | Semi-Fixed | PARTIALLY | Enfocar anunciantes recurrentes |
| Adquisición de usuarios | Variable | YES | No escalar antes de validación |
| Soporte de campo | Semi-Fixed | PARTIALLY | Priorizar red existente |
| Inventario | Variable | YES | Ajustar a demanda validada |
| Costes corporativos | Fixed | PARTIALLY | Controlar discrecionales |
| Capital circulante | Variable | PARTIALLY | Gestionar cobros y stock |
| Servicios profesionales | Semi-Fixed | YES | Diferir no esenciales |
Solo categorías presentes en BC 6.7.
6 · GASTO PROTEGIDO
7 · GASTO DIFERIBLE / ESCALABLE
- Aceleración de despliegue futuro de hardware
- Contratación no crítica
- Marketing discrecional
- Expansión geográfica especulativa
- Desarrollo de producto no esencial
- Adquisición acelerada de app
- Despliegue más allá de la demanda validada
Principio: el despliegue de capital sigue la tracción comercial validada.
No se sugiere cancelar obligaciones contractuales o regulatorias esenciales.
8 · THROTTLE DE ROLLOUT
LOTOMIX puede ajustar el ritmo de despliegue según la performance comercial, ligado a tráfico, demanda de anunciantes, economía de instalación, activación de ubicación y revenue por ubicación.
Tracción fuerte
Acelerar instalaciones.
Performance base
Ejecutar plan de rollout vigente.
Underperformance
Priorizar ubicaciones de mayor valor y ralentizar despliegue de menor prioridad.
No se implica que los compromisos de hardware puedan cancelarse si las obligaciones contractuales lo impiden.
9 · PRIORIZACIÓN DE UBICACIONES
No se crean scores de ubicación ficticios. Solo datos operativos reales cuando estén disponibles.
10 · ACCIONES DE PROTECCIÓN PUBLICITARIA
- priorizar inventario de alto tráfico
- empaquetar pantallas geográficamente
- usar bundles de red
- ajustar precio comercial dentro de límites aprobados
- target anunciantes locales
- target anunciantes regionales
- target anunciantes nacionales
- mejorar reporting de campañas
- priorizar anunciantes recurrentes
- reducir inventario no vendido con ofertas estructuradas
No se asumen subidas de precio en un escenario de demanda débil.
11 · DISCIPLINA DE SPEND DIGITAL
El spend de adquisición de usuarios no debe escalar materialmente por delante de evidencia de que los usuarios adquiridos generan engagement y monetización suficientes.
Sin KPIs validados, no se asignan benchmarks artificiales.
12 · GATES DE DESPLIEGUE DE CAPITAL
GATE 1 — Platform Readiness
- tecnología estable
- integración de administración validada
- hardware operando correctamente
GATE 2 — Location Activation
- unidades instaladas activándose
- administraciones usando el sistema
- soporte operativo funcionando
GATE 3 — Media Validation
- anunciantes comprando inventario
- fill medible
- precio realizado
GATE 4 — Unit Economics Validation
- datos de revenue por ubicación
- economía de contribución
- evidencia de payback aceptable
GATE 5 — Scale
- solo acelerar rollout amplio cuando la evidencia previa lo soporte
No se presentan como tramos contractuales de financiación salvo que esa estructura exista. Son principios de control de dirección.
13 · MONITORIZACIÓN DE RUNWAY
| Métrica | BC 6.7 | Real vs Presupuesto | Forecast actualizado |
|---|---|---|---|
| Caja de apertura | €3,000,000 | Pendiente | Pendiente |
| Entrada mensual de caja | CASH MODEL REVIEW REQUIRED | Pendiente | Pendiente |
| Salida mensual de caja | CASH MODEL REVIEW REQUIRED | Pendiente | Pendiente |
| Burn neto mensual | CASH MODEL REVIEW REQUIRED | Pendiente | Pendiente |
| CAPEX comprometido | CASH MODEL REVIEW REQUIRED | Pendiente | Pendiente |
| CAPEX no comprometido | CASH MODEL REVIEW REQUIRED | Pendiente | Pendiente |
| Umbral mínimo de caja | CASH MODEL REVIEW REQUIRED | Pendiente | Pendiente |
| Meses de runway | CASH MODEL REVIEW REQUIRED | Pendiente | Pendiente |
Valores BC 6.7 donde disponibles; columnas futuras para monitorización post-inversión.
14 · INDICADORES DE ALERTA TEMPRANA
Commercial
- advertising pipeline
- advertiser conversion
- fill
- realised price
- advertiser renewals
Deployment
- installations / month
- activated administrations
- deployment delay
- hardware utilisation
Digital
- MAU
- transactions
- membership conversion
- peñas activity
Financial
- revenue variance
- contribution variance
- burn variance
- cash runway
Indicadores semáforo solo cuando dirección apruebe umbrales reales. No se inventan umbrales.
15 · TRIGGERS DE RESPUESTA ADVERSA
| Indicador | Umbral aprobado | Acción de dirección | Owner |
|---|---|---|---|
| Rollout por debajo del plan | CASH MODEL REVIEW REQUIRED | Por definir — política de dirección | Por asignar |
| Fill publicitario por debajo del plan | CASH MODEL REVIEW REQUIRED | Por definir — política de dirección | Por asignar |
| CPM realizado por debajo del plan | CASH MODEL REVIEW REQUIRED | Por definir — política de dirección | Por asignar |
| Activación SaaS por debajo del plan | CASH MODEL REVIEW REQUIRED | Por definir — política de dirección | Por asignar |
| Revenue por debajo del plan | CASH MODEL REVIEW REQUIRED | Por definir — política de dirección | Por asignar |
| Burn mensual por encima del plan | CASH MODEL REVIEW REQUIRED | Por definir — política de dirección | Por asignar |
| Caja acercándose al umbral mínimo | CASH MODEL REVIEW REQUIRED | Por definir — política de dirección | Por asignar |
Umbrales a obtener de BC 6.7 / política de dirección aprobada. No se inventan porcentajes.
16 · ORDEN DE PRIORIDAD DE CAJA
17 · TRATAMIENTO DE FONDO PÚBLICO
Con fondo público
Donde se conceda formalmente.
Sin fondo público
Caso base BC 6.7: €0 subsidio.
La referencia de planificación de €10.000 por administración no se considera caja garantizada salvo concesión formal. En análisis de liquidez adversa, no se asume que subsidios no aprobados lleguen a tiempo.
18 · STRESS — SIN FONDO PÚBLICO
Efecto de cero recibos de subsidio no aprobado sobre caja, rollout, runway y requerimiento de financiación.
No se construye un nuevo forecast si BC 6.7 no soporta este análisis.
19 · DELAY DE CAPEX ≠ ELIMINACIÓN
Si el despliegue solo se pospone, el requerimiento de capital futuro permanece. La distinción debe ser explícita.
20 · TABLA DE SUPERVIVENCIA DE CAJA
| Escenario | Rollout | Publicidad | Digital | Respuesta OPEX | Runway | Funding |
|---|---|---|---|---|---|---|
| Adverso | Por debajo | Por debajo | Por debajo | Throttle + diferir | CASH MODEL REVIEW REQUIRED | CASH MODEL REVIEW REQUIRED |
| Base | BC 6.7 (770) | BC 6.7 | BC 6.7 | Plan vigente | CASH MODEL REVIEW REQUIRED | Equity €3,0M (BC 6.7) |
| Favorable | Por encima | Por encima | Por encima | Acelerar | CASH MODEL REVIEW REQUIRED | CASH MODEL REVIEW REQUIRED |
Valores directamente de BC 6.7; no se rellena con estimaciones no aprobadas.
21 · PALANCAS DE DIRECCIÓN
No se incluyen obligaciones contractuales como palancas discrecionales.
22 · RIESGO DE NEGOCIO VS RIESGO DE LIQUIDEZ
El underperformance comercial no crea automáticamente una crisis de liquidez inmediata si el gasto puede ajustarse.
Sin embargo, el underperformance persistente puede aumentar el capital requerido para alcanzar escala y puede retrasar el break-even.
23 · SUPERVIVENCIA ANTES DE CRECIMIENTO
24 · GOBERNANZA DE CAJA POST-INVERSIÓN
Mensual
- saldo de caja
- burn
- spend de despliegue
- revenue real
- fill publicitario
- ubicaciones activas
Trimestral
- forecast rotatorio actualizado
- runway
- plan de capex
- plan de contratación
- objetivo de despliegue
- perspectiva de financiación
Soporta reportes futuros a board / inversores.
25 · CONEXIÓN CON OTRAS SECCIONES
No se duplican las tablas financieras subyacentes innecesariamente.
26 · DISCIPLINA ADVERSA
- La estrategia adversa de LOTOMIX se basa en preservar la plataforma operativa core y la red existente mientras se alinea el gasto de expansión con la validación comercial real.
- Un rollout más lento o una monetización inicial más débil reducirían revenue y retrasarían la palanca operativa, pero dirección puede responder moderando el despliegue, controlando el OPEX discrecional y priorizando las oportunidades comerciales de mayor valor.
- El impacto financiero y el runway resultante deben evaluarse siempre a través de BC 6.7, no mediante estimaciones de dirección no soportadas.
CONTROL FINAL — No se afirma que LOTOMIX no pueda requerir financiación adicional. No se afirma que los casos adversos estén totalmente financiados salvo que BC 6.7 lo demuestre. No se inventa runway ni fechas de break-even. No se asume recepción de subsidios. No se reducen silenciosamente compromisos contractuales. Cada valor financiero debe reconciliarse con BC 6.7; si la reconciliación no está disponible, se marca CASH MODEL REVIEW REQUIRED en lugar de publicar una cifra no soportada.
INVESTOR KPI COCKPIT
Investor KPI Cockpit
Un dashboard operativo conciso que muestra si LOTOMIX ejecuta en línea con la tesis de inversión.
1 · PRINCIPIO DE DISEÑO Y CLASIFICACIÓN
Cada KPI muestra Real, Objetivo, Desviación, Periodo previo, Estado, Fuente y Última actualización donde aplique. No se rellenan reales futuros. Donde no existe dato real, se muestra N/A — awaiting commercial data en lugar de insertar supuestos del modelo como reales.
NETWORK
| KPI | Real | Objetivo | Desv. | Prev. | Estado | Fuente |
|---|---|---|---|---|---|---|
| K1 Ubicaciones instaladas MANAGEMENT REPORTED | ~370 | 770 MGMT TARGET | N/A | N/A | NOT YET MEASURABLE | Installation database |
| K2 Ubicaciones activadas PENDING VERIFICATION | N/A — awaiting commercial data | N/A | N/A | N/A | NOT YET MEASURABLE | Backend telemetry |
| K3 Ubicaciones monetizadas PENDING VERIFICATION | N/A — awaiting commercial data | N/A | N/A | N/A | NOT YET MEASURABLE | Finance / accounting |
ADVERTISING
| KPI | Real | Objetivo | Desv. | Prev. | Estado | Fuente |
|---|---|---|---|---|---|---|
| K5 Fill rate publicitario (lector / trasera / gran formato) PENDING VERIFICATION | N/A / N/A / N/A | N/A | N/A | N/A | NOT YET MEASURABLE | Advertising platform |
| K6 CPM realizado / precio media efectivo MODELLED | N/A — awaiting commercial data | €6–€9 MODEL RANGE | N/A | N/A | STATUS THRESHOLD PENDING | Advertising platform |
| K8 Revenue publicitario por ubicación monetizada PENDING VERIFICATION | N/A — awaiting commercial data | N/A | N/A | N/A | NOT YET MEASURABLE | Finance / accounting |
DIGITAL
| KPI | Real | Objetivo | Desv. | Prev. | Estado | Fuente |
|---|---|---|---|---|---|---|
| K10 MAU (usuarios activos mensuales) MODELLED | N/A — awaiting commercial data | 20% / 25% / 30% MODEL RANGE | N/A | N/A | STATUS THRESHOLD PENDING | App analytics |
| K12 GTV vs Revenue transaccional LOTOMIX PENDING VERIFICATION | N/A — awaiting commercial data · N/A — awaiting commercial data | GTV × 0.5% fee MODEL RANGE | N/A | N/A | NOT YET MEASURABLE | App analytics / finance |
FINANCIAL
| KPI | Real | Objetivo | Desv. | Prev. | Estado | Fuente |
|---|---|---|---|---|---|---|
| K13 Revenue reconocido mensual MODELLED | N/A — awaiting commercial data | €1,427,578/yr MODEL RANGE | N/A | N/A | STATUS THRESHOLD PENDING | Finance / accounting (BC 6.7 budget) |
| K14 EBITDA mensual / resultado operativo MODELLED | N/A — awaiting commercial data | €360,094/yr MODEL RANGE | N/A | N/A | STATUS THRESHOLD PENDING | Finance / accounting (BC 6.7 budget) |
LIQUIDITY
| KPI | Real | Objetivo | Desv. | Prev. | Estado | Fuente |
|---|---|---|---|---|---|---|
| K15 Cash Runway (caja / burn / runway) PENDING VERIFICATION | DATA PENDING · N/A · DATA PENDING | N/A | N/A | N/A | NOT YET MEASURABLE | Finance / rolling forecast |
4 · PANTALLAS LIVE (SOPORTE)
A1D / PPI readers
N/A
Rear displays
N/A
Large-format screens
N/A
No se muestra un número combinado sin el desglose por componente. 1.500 pantallas solo aplica al caso de 500 ubicaciones completas.
11 · DRILL-DOWN: KPIs adicionales y métricas secundarias
NETWORK — Adicional
| KPI | Real | Objetivo | Desv. | Prev. | Estado | Fuente |
|---|---|---|---|---|---|---|
| K4 Ubicaciones completadas MODELLED | N/A — awaiting commercial data | ~770 by Apr 2027 MGMT TARGET | N/A | N/A | STATUS THRESHOLD PENDING | Rollout plan (BC 6.7) |
ADVERTISING — Adicional
| KPI | Real | Objetivo | Desv. | Prev. | Estado | Fuente |
|---|---|---|---|---|---|---|
| K7 Anunciantes activos PENDING VERIFICATION | N/A — awaiting commercial data | N/A | N/A | N/A | NOT YET MEASURABLE | CRM / advertising platform |
SAAS
| KPI | Real | Objetivo | Desv. | Prev. | Estado | Fuente |
|---|---|---|---|---|---|---|
| K9 Administraciones pagadoras SaaS MODELLED | N/A — awaiting commercial data | €30/month ref. MODEL RANGE | N/A | N/A | STATUS THRESHOLD PENDING | Administration onboarding records |
DIGITAL — Adicional
| KPI | Real | Objetivo | Desv. | Prev. | Estado | Fuente |
|---|---|---|---|---|---|---|
| K11 Transacciones por MAU MODELLED | N/A — awaiting commercial data | 15 / MAU / month MODEL RANGE | N/A | N/A | STATUS THRESHOLD PENDING | App analytics (BC 6.7) |
DRAWER DE KPIs SECUNDARIOS
No compiten visualmente con los 12–15 KPIs headline.
14 · TENDENCIA MENSUAL (6–12 MESES)
Tendencia para ubicaciones activadas, monetizadas, fill, revenue por ubicación, revenue reconocido, EBITDA y runway. Sin datos reales, no se crean charts decorativos.
Trend available once actual data flows — NOT YET MEASURABLE.
15 · FUNNEL DE ROLLOUT
Red potencial ≠ pipeline ≠ instaladas ≠ operativas ≠ monetizadas. No se fusionan categorías.
16 · FUNNEL PUBLICITARIO
Mejor visibilidad que reportar solo capacidad teórica. Conversiones % donde existan datos.
17 · PUENTE FINANCIERO MENSUAL
No reproduce el P&L completo; muestra la progresión operativa mensual.
18 · HITOS OBJETIVO
Dec 2026
Objetivo de rollout comercial amplio
Mar 2027
Inicio de despliegue de pantallas adicionales
Apr 2027
~770 ubicaciones completadas objetivo
No se muestra ON TRACK salvo evidencia operativa real que lo soporte.
21 · ESTADO DE CALIDAD DE DATOS
Evita presentar datos early-stage con excesiva certeza.
22 · NO DOBLE CONTEO
- Revenue bruto de gran formato no se suma a revenue neto LOTOMIX.
- GTV no se incluye como revenue de empresa.
- Usuarios no se cuentan múltiples veces entre MAU, membresías y peñas.
- Pantallas instaladas no se cuentan como ubicaciones.
- Ubicaciones instaladas no se cuentan automáticamente como completadas.
Si se detecta duplicación: KPI RECONCILIATION REQUIRED.
25 · ¿QUÉ RESPONDE ESTE DASHBOARD?
- ¿Se están instalando ubicaciones?
- ¿Las ubicaciones instaladas se están volviendo operativas?
- ¿Las ubicaciones operativas se están monetizando?
- ¿La publicidad rinde al precio y fill esperados?
- ¿Los usuarios se vuelven activos y transaccionan?
- ¿El revenue reconocido sigue el plan financiero?
- ¿La palanca operativa está mejorando?
- ¿La empresa tiene liquidez suficiente para ejecutar la siguiente fase?
CONTROL FINAL — BC 6.7 es la referencia del modelo. Los sistemas operativos reales son la fuente de los KPIs reales. No se rellenan reales ausentes con supuestos del modelo. 7.000 ubicaciones potenciales no se tratan como instaladas. 1.200+ pipeline no se trata como rollout contratado. 370 lectores instalados no se tratan como 370 ubicaciones monetizadas completas salvo dato actual. GTV no se trata como revenue. El 30% FENAMIX no se aplica fuera de la economía de gran formato. Si un KPI no puede verificarse: NOT YET MEASURABLE.
ROLLOUT RECONCILIATION
Rollout Reconciliation
Una única vista reconciliada de la huella actual de LOTOMIX, el pipeline de rollout y los objetivos de despliegue futuros.
Referencia de control para todas las figuras de rollout. No crea nuevos supuestos de rollout. Fuentes: BC 6.7, plan operativo aprobado y evidencia de despliegue existente.
1 · DEFINICIONES DE RED
Red Potencial
El perímetro de red más amplio accesible vía la relación comercial de LOTOMIX con FENAMIX.
Referencia actual: ~7,000 POS
NO significa:
- 7.000 instalaciones
- 7.000 ubicaciones activadas
- 7.000 ubicaciones pagadoras
- 7.000 ubicaciones contratadas generadoras de revenue
Pipeline / Lista de espera
Ubicaciones que han expresado interés, se han registrado para rollout o están incluidas en el pipeline de despliegue actual.
Referencia actual: 1,200+ locations
NO significa:
- desplegadas
- revenue contratado
- conversión garantizada
- instalación completada
Ubicación con lector instalado
Ubicación donde la infraestructura de lector A1D / PPI existente ha sido instalada.
Referencia actual: ~370 locations
NO significa:
- describir automáticamente como ubicaciones LOTOMIX completas salvo que la configuración completa de pantallas esté instalada
Ubicación activada
Ubicación instalada operando activamente la plataforma LOTOMIX. Requiere evidencia operativa.
Referencia actual: DATA PENDING
NO significa:
- Installed = Activated
Ubicación monetizada
Ubicación activada generando revenue reconocido LOTOMIX (publicidad, SaaS u otra actividad comercial a nivel de ubicación).
Referencia actual: DATA PENDING
NO significa:
- Activated = Monetised
Ubicación completada
Ubicación que cumple la especificación aprobada de despliegue LOTOMIX completo: 1 × lector A1D/PPI 11,6", 1 × pantalla trasera 23,8", 1 × LOTOADS gran formato 43". 1 ubicación completada = hasta 3 pantallas.
Referencia actual: ~770 by Apr 2027 (target)
NO significa:
- contar una ubicación solo-lector como ubicación completada de tres pantallas
MODEL RECONCILIATION REQUIRED — la definición de ubicación completada usa 11,6"/23,8"/43" (Master KPI Registry); BC 6.7 carga 11,9"/28"/48". La discrepancia está registrada. La estructura de 3 pantallas por ubicación completada se mantiene en ambos.
2 · EVOLUCIÓN DE RED LOTOMIX
No se presentan como pasos acumulativos salvo que el plan de rollout aprobado funcione así.
3 · TRANSICIÓN 370 → 500
370 ubicaciones existentes con lector + 130 ubicaciones/unidades adicionales = 500 ubicaciones de referencia inicial. Donde se usa la configuración completa de 500:
No implicar que las 500 ubicaciones están completadas hoy. La figura de 500 se clasifica según su estado de rollout aprobado actual.
4 · TRANSICIÓN 500 → 770
Objetivo de dirección actual: ~770 ubicaciones completadas para abril 2027. Paso incremental: 500 → 770 = +270 ubicaciones completadas adicionales, solo donde refleje el plan operativo aprobado actual. No se infiere que la transición sea lineal; se usa el calendario de rollout real.
5 · CRONOLOGÍA DIC 2026 / MAR 2027 / ABR 2027
Rollout comercial amplio objetivo — la activación comercial de LOTOMIX comienza a mayor escala. No es necesariamente la fecha en que todo el hardware adicional ya está instalado.
Inicio / aceleración del despliegue de pantallas adicionales — la expansión de infraestructura trasera y gran formato progresa según el plan de rollout vigente.
~770 ubicaciones completadas objetivo — objetivo actual de dirección para el estate de ubicaciones completadas.
Esta secuencia se usa consistentemente en Investor Deck, Data Room, BC 6.7, roadmap, diagramas de rollout e IC Q&A.
6 · HARDWARE POR ETAPA DE DESPLIEGUE
| Etapa | Ubicaciones | Lectores | Traseras | Gran formato | Total pantallas | Estado |
|---|---|---|---|---|---|---|
| Estate actual | ~370 | ~370 | 0 | 0 | ~370 | DEPLOYED |
| Caso inicial 500 ubicaciones | 500 | 500 | 500 | 500 | 1,500 | ROLLOUT CASE |
| Objetivo abr 2027 | 770 | 770 | 770 | 770 | 2,310 | MANAGEMENT TARGET |
| Objetivo 2029 | 3,370 | 3,370 | 3,370 | 3,370 | 10,110 | LONG-TERM TARGET |
No se asume que cada ubicación futura tenga exactamente 3 pantallas salvo que BC 6.7 y el plan operativo lo confirmen.
7 · NO MEZCLAR DISPOSITIVOS Y UBICACIONES
Ubicaciones y pantallas son métricas diferentes.
- 500 ubicaciones completadas pueden representar 1.500 pantallas bajo la configuración de 3 pantallas.
- No escribir 1.500 ubicaciones al referirse al recuento de pantallas.
- No usar 500 dispositivos al referirse a 500 ubicaciones completadas con múltiples dispositivos.
8 · RUTA DE MADUREZ DE ROLLOUT
Cada etapa tiene su propio recuento donde hay datos. Taxonomía estándar de rollout LOTOMIX.
9 · FUNNEL DE RED
No se rellenan etapas ausentes con estimaciones. DATA PENDING donde sea necesario.
10 · SEGUIMIENTO MENSUAL DE ROLLOUT
| Mes | Instalaciones planificadas | Instalaciones reales | Activadas | Monetizadas | Completadas | Desv. |
|---|---|---|---|---|---|---|
| Nov 2026 | Funding begins | DATA PENDING | DATA PENDING | DATA PENDING | DATA PENDING | DATA PENDING |
| Dec 2026 | DATA PENDING | DATA PENDING | DATA PENDING | DATA PENDING | DATA PENDING | DATA PENDING |
| Jan 2027 | DATA PENDING | DATA PENDING | DATA PENDING | DATA PENDING | DATA PENDING | DATA PENDING |
| Feb 2027 | DATA PENDING | DATA PENDING | DATA PENDING | DATA PENDING | DATA PENDING | DATA PENDING |
| Mar 2027 | DATA PENDING | DATA PENDING | DATA PENDING | DATA PENDING | DATA PENDING | DATA PENDING |
| Apr 2027 | ~770 target | DATA PENDING | DATA PENDING | DATA PENDING | DATA PENDING | DATA PENDING |
Soporta reportes post-inversión. No se rellenan datos históricos salvo evidencia.
11 · VELOCIDAD DE DESPLIEGUE
locations installed / month
DATA PENDING
locations activated / month
DATA PENDING
locations monetised / month
DATA PENDING
Evita confundir actividad de instalación con performance comercial.
12 · CONVERSIÓN PIPELINE → INSTALACIÓN
Fórmula: Ubicaciones instaladas / Pipeline elegible. Seguimiento separado: pipeline · programadas · convertidas · declinadas/diferidas. No se usan los 7.000 potenciales como denominador salvo análisis específico de penetración del estate FENAMIX.
13 · PENETRACIÓN DE RED FENAMIX
Penetración actual
Instaladas / 7.000 = ~370 / 7.000
~5.3%
Penetración objetivo
Completadas / 7.000 = 770 / 7.000
~11.0% (target)
No se implica exclusividad sobre los 7.000 salvo respaldo contractual.
14 · ¿QUÉ DETERMINA LA VELOCIDAD DE ROLLOUT?
Explica por qué el rollout no es una simple multiplicación matemática de la lista de espera.
15 · RECONCILIACIÓN DE PROCURACIÓN DE HARDWARE
| Fase | Ubic. plan. | Lectores | Traseras | Gran form. | Pedido | Entregado | Instalado |
|---|---|---|---|---|---|---|---|
| Estate actual | ~370 | ~370 | 0 | 0 | — | ~370 | ~370 |
| Caso 500 | 500 | 500 | 500 | 500 | DATA PENDING | DATA PENDING | DATA PENDING |
| Abr 2027 | 770 | 770 | 770 | 770 | DATA PENDING | DATA PENDING | DATA PENDING |
No se permite que la procuración planificada exceda el caso de rollout aprobado actual sin explicación.
16 · POSICIÓN ACTUAL DE ROLLOUT
Perímetro FENAMIX potencial
~7,000
Pipeline / interés actual
1,200+
Huella existente de lectores
~370
Ubicaciones activadas
DATA PENDING
Ubicaciones monetizadas
DATA PENDING
Ubicaciones completadas de 3 pantallas
DATA PENDING
No se sustituyen valores del modelo en los últimos tres campos.
17 · PRÓXIMOS 12 MESES
No se sobrecarga con detalle 2028–2029.
18 · OPORTUNIDAD DE ESCALA A MÁS LARGO PLAZO
3,370 ubicaciones para 2029
MANAGEMENT TARGET — NO DESPLIEGUE CONTRATADO ACTUAL
No se coloca visualmente junto a KPIs operativos actuales sin esta distinción.
19 · RECONCILIACIÓN CON BC 6.7
Cross-check interno: recuentos de ubicaciones × fechas de despliegue × configuración de hardware × activación comercial deben reconciliarse con el reconocimiento de revenue de BC 6.7. Si BC 6.7 asume que la monetización comienza tras la instalación, se preserva la rampa. No se reconoce revenue completo en la fecha de instalación salvo que el modelo lo haga explícitamente.
20 · RECONCILIACIÓN CON REVENUE
| Periodo | Instaladas | Activadas | Monetizadas | Pantallas productoras de revenue |
|---|---|---|---|---|
| Hoy | ~370 | DATA PENDING | DATA PENDING | DATA PENDING |
| Abr 2027 | 770 | DATA PENDING | DATA PENDING | DATA PENDING |
| 2029 | 3,370 | DATA PENDING | DATA PENDING | DATA PENDING |
Explica la diferencia entre crecimiento de despliegue y crecimiento de revenue.
21 · RECONCILIACIÓN CON CAJA
La salida de caja puede preceder a la generación de revenue.
22 · TRAZABILIDAD DE FUENTE
23 · DETECCIÓN DE CONTRADICCIONES
Se busca en todo el Data Room el contexto de cada ocurrencia de 370, 500, 770, 1.200+, 3.370, 7.000, 1.500 pantallas, Dec 2026, Mar 2027 y Abr 2027. Donde la misma figura se usa con significado distinto, se corrige la redacción orientada al inversor. No se alteran documentos fuente firmados. Si un conflicto no puede resolverse automáticamente: ROLLOUT RECONCILIATION REQUIRED.
24 · ALINEACIÓN CON EL DECK
El deck de inversor Waterhouse y el Data Room usan exactamente las mismas definiciones para huella instalada existente, ubicaciones completadas, pipeline de rollout, despliegue futuro, recuento de pantallas y hitos Dec/Mar/Abr. El Data Room no introduce una segunda interpretación del deck.
25 · CÓMO LEER EL ROLLOUT DE LOTOMIX
- 7.000 representa el perímetro de red potencial FENAMIX.
- 1.200+ representa el pipeline actual de rollout / interés expresado.
- ~370 representa la huella existente de lectores.
- 500 ubicaciones representa el caso de referencia de despliegue completo inicial donde aplique.
- ~770 ubicaciones completadas para abril 2027 representa el objetivo de rollout de dirección a corto plazo actual.
- 3.370 ubicaciones para 2029 representa un objetivo de dirección a más largo plazo.
Estas figuras describen etapas diferentes de la red y no deben interpretarse como métricas equivalentes o intercambiables.
CONTROL FINAL — Nunca presentar 7.000 = instaladas. Nunca 1.200+ = despliegue contratado. Nunca 370 = estate completado de 3 pantallas salvo evidencia actual. Nunca mezclar ubicaciones, pantallas, dispositivos, ubicaciones activadas y ubicaciones monetizadas. Se usa la taxonomía de rollout aprobada consistentemente en todo el Data Room.
Continúa tu revisión
COMMERCIAL PROOF & TRACTION
Commercial Proof & Traction
Una vista basada en hechos de la validación comercial de LOTOMIX, las oportunidades activas y la evidencia de demanda de mercado.
Distingue relaciones contratadas, actividad comercial activa, pilotos técnicos/operativos, negociaciones avanzadas, oportunidades iniciales, pipeline y objetivos de dirección. No es una página de logos. Ninguna empresa se presenta como cliente sin evidencia.
CONTRACTED
1
FENAMIX (evidenciado)
PILOTS / TESTS
1
Campaña SEUR (DOC-013)
ADVANCED OPPORTUNITIES
1
Adquisición Sphere
PIPELINE
DATA PENDING
Pipeline comercial cualificado
1 · FRAMEWORK DE MADUREZ COMERCIAL
Acuerdo comercial ejecutado o relación contractual vinculante.
Actividad comercial produciendo revenue reconocido actualmente.
Test técnico o comercial en curso.
Diálogo comercial material con próximos pasos identificables, sin contrato.
Contacto inicial o conversación exploratoria.
Oportunidad comercial identificada no convertida.
Organización objetivo sin suficiente engagement para clasificar como pipeline.
2 · TABLA DE TRACTION COMERCIAL
| Contraparte / Oportunidad | Categoría | Estado actual | Evidencia | Próximo hito |
|---|---|---|---|---|
| FENAMIX | Distribución | CONTRACTED | Acuerdo marco FENAMIX/Sphere PPI firmado; anexos individuales por establecimiento. | Despliegue por establecimiento; conversión de pipeline en instaladas. |
| Sphere Radio (adquisición) | Socio estratégico | ADVANCED DISCUSSION | Adquisición propuesta; infraestructura de ~370 lectores; cierre pendiente. | Cierre de la adquisición e integración. |
| Fundación SEUR | Marca / Publicidad | PILOT / TESTING | DOC-013 — campaña DOOH nacional, 370 ubicaciones, 60 días, 18,87M impactos estimados. Revenue LOTOMIX reconocido no documentado en el Data Room. | Segunda campaña / renovación de anunciante. |
Solo se incluyen contrapartes con apoyo factual suficiente en el Data Room. No se inventa progreso comercial. Oportunidades adicionales: COMMERCIAL STATUS REVIEW REQUIRED | ||||
3 · RELACIONES ESTRATÉGICAS / DISTRIBUCIÓN
- Acuerdos de acceso a red
- Acuerdos de despliegue retail
- Participación de administraciones
- Relaciones de despliegue de hardware
- Alianzas tecnológicas
FENAMIX · CONTRACTED
PUBLICIDAD / COMERCIALIZACIÓN DE MARCA
- Acuerdos de campaña
- Órdenes de inserción firmadas
- Propuestas comerciales
- Pilotos activos
- Reuniones con anunciantes
- Discusiones con agencias de media
Fundación SEUR · PILOT / TESTING
No se combinan acceso a red y demanda de anunciantes en un único número de traction comercial.
4 · RELACIÓN FENAMIX
Donde lo respalda la documentación ejecutada subyacente.
Relevancia estratégica
Acceso a la red de administraciones de lotería mixta.
Perímetro de red potencial
~7,000 POS
Huella existente
~370 reader locations
Pipeline actual
1,200+ locations
No se afirma 7.000 clientes ni 1.200 ubicaciones contratadas salvo que la evidencia subyacente respalde esas afirmaciones exactas.
5 · JERARQUÍA DE PRUEBA COMERCIAL
No se presentan todos los logos al mismo nivel visual.
6 · PRUEBA GENERADORA DE REVENUE
Donde existe revenue comercial real se muestra: fuente de revenue, periodo, revenue LOTOMIX reconocido, evidencia de contrato/factura, naturaleza recurrente o puntual. No se muestra gasto bruto de anunciante ni GTV como revenue LOTOMIX.
Campaña SEUR: revenue LOTOMIX reconocido no documentado en el Data Room → Pre-revenue / pre-commercial para esta oportunidad.
7 · PILOTOS / TESTS COMERCIALES ACTIVOS
Fundación SEUR — DOOH National Campaign
Contraparte
Fundación SEUR
Alcance
Campaña DOOH nacional
Ubicación
370 locations
Objetivo
Validar capacidad DOOH de la red
Inicio
DATA PENDING
Estado
PILOT / TESTING
Criterios de éxito
Rendimiento hardware, respuesta anunciante, interacción usuario
Próximo punto de decisión
Renovación / segunda campaña
Un piloto no se describe como contrato de cliente.
8 · DISCUSIONES COMERCIALES AVANZADAS
Sphere Radio — Proposed Acquisition ADVANCED DISCUSSION
Tipo de contraparte
Infraestructura / socio estratégico
Objetivo comercial
Adquisición de huella de lectores
Etapa actual
ADVANCED DISCUSSION
Interacción documentada más reciente
DATA PENDING
Próximo paso acordado
Cierre e integración
No se publican detalles sensibles de negociación salvo aprobación para divulgación inversora. No se usan afirmaciones como deal expected / contract imminent / certain to close salvo documentación formal.
9 · PIPELINE DE VENTAS AGREGADO
| Etapa | Oportunidades | Valor potencial | Valor ponderado | Evidencia |
|---|---|---|---|---|
| Target Accounts | DATA PENDING | DATA PENDING | — | Sin valor documentado |
| Contacted | DATA PENDING | DATA PENDING | — | Sin valor documentado |
| Qualified | DATA PENDING | DATA PENDING | — | Sin valor documentado |
| Proposal | DATA PENDING | DATA PENDING | — | Sin valor documentado |
| Pilot / Negotiation | 1 | DATA PENDING | — | Sin valor documentado |
| Contracted | 1 | DATA PENDING | — | Sin valor documentado |
| Live | DATA PENDING | DATA PENDING | — | Sin valor documentado |
| Renewed | DATA PENDING | DATA PENDING | — | Sin valor documentado |
No se inventan valor de contrato, probabilidad ni valor ponderado. Si no se han aprobado probabilidades CRM formales, el pipeline ponderado se omite enteramente.
10 · EL PIPELINE NO ES REVENUE — El pipeline comercial representa negocio futuro potencial y no es revenue reconocido. El Data Room nunca agrega Pipeline Value + Revenue Existente como si ambos representaran revenue actual de la compañía.
11 · TRACTION DE ANUNCIANTES
No se crean porcentajes de conversión antes de que existan suficientes datos reales.
12 · FUNNEL COMERCIAL
Solo se rellenan etapas con datos estructurados. Taxonomía comercial estándar LOTOMIX.
13 · LOGOS DE MARCA / CONTRAPARTE
Si se muestran logos, solo se usa un logo donde el estado de la relación se muestra inmediatamente al lado (CONTRACTED · PILOT · ADVANCED DISCUSSION · TARGET ACCOUNT). No se crea un muro genérico de logos que pueda implicar que todas las organizaciones son clientes de LOTOMIX.
14 · EVIDENCIA COMERCIAL
No se duplican los documentos subyacentes.
15 · TRACTION POR FLUJO DE REVENUE
| Flujo | Evidencia hoy | Etapa comercial | Próxima validación |
|---|---|---|---|
| Publicidad lector | Campaña SEUR ejecutada (DOC-013). | PILOT / TESTING | Fill a escala, CPM realizado, renovación. |
| Publicidad trasera | Sin campaña evidenciada. | EARLY DISCUSSION | Primer contrato / campaña. |
| Gran formato LOTOADS | Sin contrato de anunciante evidenciado. | EARLY DISCUSSION | Primer contrato de gran formato. |
| SaaS | Sin administración pagadora evidenciada. | EARLY DISCUSSION | Primera administración pagadora. |
| Transacciones | Estado técnico; sin revenue reconocido. | TARGET ACCOUNT | Activación técnica y comercial. |
| Membresías | Producto futuro; sin suscriptores pagadores. | TARGET ACCOUNT | Lanzamiento y conversión. |
| Peñas | Producto/legal/comercial en desarrollo. | EARLY DISCUSSION | Adopción comunitaria. |
| App / monetización | Pre-comercial. | TARGET ACCOUNT | MAU y monetización. |
Un flujo validado no implica validación de todos los flujos.
16 · LA VALIDACIÓN ES DIFERENTE DE LA ESCALA
Una reunión, piloto, primer anunciante, primera instalación o primer cliente pagador exitosos demuestran progreso, pero no validan por sí solos los supuestos de escala completos de BC 6.7.
17 · GATES DE VALIDACIÓN COMERCIAL
Interés
Interés de mercado documentado.
Piloto
La contraparte compromete tiempo/recursos en test.
Actividad comercial pagada
Comienza el revenue.
Repetición / renovación
La relación comercial se repite.
Adquisición escalable
Múltiples counterpartas convierten con un proceso repetible.
Posición actual por flujo: Publicidad lector — Gate 2/3; resto — Gate 1/2. No se clasifica todo el negocio en una sola etapa.
18 · CICLO DE VENTAS
Donde exista evidencia suficiente: primer contacto, propuesta, piloto, contrato, inicio de campaña. Average Sales Cycle solo con suficientes observaciones reales. Hasta entonces: DATOS ACUMULÁNDOSE. No se inventan supuestos de ciclo de ventas.
19 · VALOR COMERCIAL CONTRATADO
CONTRACTED VALUE
Valor comprometido en acuerdos ejecutados
DATA PENDING
RECOGNISED REVENUE
Revenue reconocido en P&L
DATA PENDING
PIPELINE VALUE
Valor potencial de pipeline no convertido
DATA PENDING
MODELLED FUTURE REVENUE
Revenue futuro modelado en BC 6.7
BC 6.7
Estos cuatro conceptos nunca se mezclan.
20 · CONCENTRACIÓN COMERCIAL
Una vez exista revenue material: concentración por anunciante, mayor socio, flujo y dependencia de FENAMIX. Hasta entonces, divulgación cualitativa apoyada en hechos actuales; no se fabrican porcentajes artificiales.
Dependencia estratégica de FENAMIX: alta (canal de acceso a red). Concentración de revenue: no medible sin revenue reconocido.
21 · CRONOLOGÍA COMERCIAL
Ejecución del acuerdo estratégico de red FENAMIX/Sphere PPI.
CONTRACTEDDespliegue histórico de ~370 lectores PPI.
CONTRACTEDCampaña DOOH Fundación SEUR — 370 ubicaciones, 60 días, 18,87M impactos estimados.
PILOT / TESTINGRollout comercial amplio objetivo.
PIPELINE~770 ubicaciones completadas objetivo de dirección.
PIPELINESolo eventos que validan significativamente el caso de inversión. No se incluyen reuniones ordinarias.
22 · DESARROLLOS COMERCIALES RECIENTES
Campaña DOOH Fundación SEUR (DOC-013) — 370 ubicaciones, 60 días, 18,87M impactos estimados.
Sección dinámica y fácil de actualizar. No se sobrescribe el progreso histórico.
23 · PRÓXIMOS HITOS COMERCIALES
| Hito | Fecha objetivo | Estado | Evidencia requerida |
|---|---|---|---|
| Rollout comercial amplio | Dec 2026 | PIPELINE | Ubicaciones activadas |
| Despliegue de pantallas adicionales | Mar 2027 | PIPELINE | Pantallas instaladas |
| ~770 ubicaciones completadas | Apr 2027 | MANAGEMENT TARGET | Ubicaciones completadas de 3 pantallas |
| Primera administración SaaS pagadora | DATA PENDING | TARGET ACCOUNT | Contrato SaaS / factura |
| Primer anunciante recurrente | DATA PENDING | TARGET ACCOUNT | Orden de inserción renovada |
Solo hitos del plan operativo aprobado.
24 · ¿QUÉ QUEDA POR PROBAR?
Identifica la próxima evidencia requerida, no debilita el caso de inversión.
25 · SIN AVAL IMPLÍCITO
Si una marca o institución conocida aparece en pipeline, piloto, discusiones o cuentas objetivo, no se usa lenguaje que sugiera aval, partnership, relación de cliente o apoyo de inversión salvo documentación. Se usa solo la clasificación comercial aprobada.
27 · CONEXIÓN CON EL MODELO FINANCIERO
El pipeline comercial permanece fuera del revenue actual reconocido de BC 6.7. Donde BC 6.7 asume ventas futuras basadas en adopción de mercado más amplia, se etiqueta claramente MODELLED COMMERCIAL PERFORMANCE. No se atribuyen contrapartes individuales del pipeline al revenue previsto salvo que el modelo lo haga explícitamente.
29 · CÓMO LEER LA TRACTION COMERCIAL DE LOTOMIX
Relaciones contratadas, pilotos, pipeline y objetivos futuros representan niveles diferentes de evidencia comercial y por tanto se divulgan por separado. El Data Room permite al inversor verificar la evidencia que respalda cada etapa directamente.
CONTROL FINAL — No se llama prospecto a cliente. No se llama piloto a contrato. No se llama pipeline a revenue. No se llama reunión a partnership. No se muestra logo sin su contexto de estado comercial. No se crean valores ni probabilidades no respaldados por registros actuales. Si la evidencia es insuficiente: COMMERCIAL STATUS REVIEW REQUIRED en lugar de sobrestimar la relación.
28 · NAVEGACIÓN
REGULATORY & LEGAL READINESS
Regulatory & Legal Readiness
Una vista estructurada de la preparación legal, regulatoria y contractual de LOTOMIX por actividad.
No proporciona opiniones legales. No infiere autorización legal donde no existe evidencia documental. Un contrato comercial ejecutado no se interpreta como aprobación regulatoria general.
2 · ETIQUETAS DE ESTADO LEGAL CONTROLADAS
No se usan etiquetas vagas (fully legal, completely authorised, regulator approved) salvo que la documentación respalde esa conclusión exacta.
1 · MATRIZ DE PREPARACIÓN LEGAL
| Actividad | Estado | Base legal / regulatoria | Dependencia | Evidencia | Próxima acción |
|---|---|---|---|---|---|
| Acceso a red FENAMIX | EXECUTED CONTRACT | Acuerdo marco FENAMIX/Sphere PPI firmado | Anexos por establecimiento | Despliegue por establecimiento | |
| Onboarding de administraciones | DEPLOYMENT / CONTRACTING IN PROGRESS | Contrato individual por administración | Adhesión individual | Ejecución de acuerdos individuales | |
| Operación de lector A1D / PPI | OPERATIONALLY PERMITTED WITHIN CURRENT SCOPE | Infraestructura desplegada existente | Acuerdos de instalación | Integración tras adquisición Sphere | |
| Validación / comprobación de billetes | LEGAL REVIEW IN PROGRESS | Funcionalidad técnica vs alcance regulatorio | Rol de la administración | Revisión legal pre-lanzamiento | |
| Compra de lotería | REQUIRES PRE-LAUNCH LEGAL REVIEW | Cadena legal de venta por definir | Administración + proveedor de pago | Análisis legal y estructura contractual | |
| Almacenamiento digital de billetes | LEGAL REVIEW IN PROGRESS | Custodia y titularidad por definir | Términos de usuario | Revisión legal | |
| Funcionalidad de wallet | THIRD-PARTY DEPENDENCY | Arquitectura legal por definir (ledger vs valor almacenado) | Proveedor de pago licenciado | Definición de arquitectura legal | |
| Procesamiento de transacciones | THIRD-PARTY DEPENDENCY | Institución de pago regulada requerida | Proveedor de pago | Selección y contrato de proveedor | |
| Flujos de pago | REQUIRES PRE-LAUNCH LEGAL REVIEW | Merchant-of-record y destino de fondos por definir | Proveedor de pago | Estructura legal de pagos | |
| Peñas / sindicatos | REQUIRES PRE-LAUNCH LEGAL REVIEW | Estructura legal de participación fraccional por definir | Rol de administración + custodia | Validación legal final | |
| Membresías | NOT YET ACTIVATED | Producto futuro; términos por definir | Términos de membresía | Términos y lanzamiento | |
| Publicidad en lector | LEGAL REVIEW IN PROGRESS | Derechos de instalación + consentimiento administración | Consentimiento administración | Marco contractual de anunciante | |
| Publicidad en pantalla trasera | LEGAL REVIEW IN PROGRESS | Derechos de instalación + consentimiento | Consentimiento administración | Marco contractual de anunciante | |
| Publicidad gran formato LOTOADS | LEGAL REVIEW IN PROGRESS | Derechos + economía FENAMIX 30% | FENAMIX + consentimiento administración | Marco contractual de anunciante | |
| Comunicaciones app / CRM | LEGAL REVIEW IN PROGRESS | Consentimiento + base legal marketing | Términos de usuario | Framework de consentimiento | |
| Tratamiento de datos personales | LEGAL REVIEW IN PROGRESS | RGPD — pack de readiness draft | Acuerdos de encargado | Revisión legal/compliance completada | |
| Cuentas de usuario | LEGAL REVIEW IN PROGRESS | Términos + privacidad por aprobar | Términos de usuario | Aprobación de términos | |
| Funcionalidad de premios | REQUIRES PRE-LAUNCH LEGAL REVIEW | Titularidad y pago de premios por definir | Administración de lotería | Estructura legal de premios | |
| Términos de consumidor | DRAFT | Términos en borrador | Aprobación legal | Aprobación y publicación | |
| Contratos de publicidad | LEGAL REVIEW IN PROGRESS | Plantillas de contrato por aprobar | Términos de anunciante | Aprobación de plantillas | |
| Despliegue de hardware | DEPLOYMENT / CONTRACTING IN PROGRESS | Acuerdos de instalación | Acuerdos por establecimiento | Despliegue Fase 1 | |
| Licencias de software / IP | LEGAL FRAMEWORK ESTABLISHED | Propiedad de software LotoAds / SphereScan | Asignación de IP | Confirmación de cadena de IP | |
| Integraciones de terceros | THIRD-PARTY DEPENDENCY | Proveedores externos por contratar | Contratos de proveedor | Selección y contratación |
3 · RELACIÓN FENAMIX
Alcance
Relación comercial / de red que cubre el acceso al estate de administraciones de lotería mixta.
Evidencia
Estado
Se distingue claramente el acceso contractual de: autorización estatutaria, autorización SELAE, aprobación de servicios de pago y regulación publicitaria. Un acuerdo comercial no se presenta como aprobación regulatoria general para toda actividad LOTOMIX.
4 · RELACIÓN CON ADMINISTRACIONES DE LOTERÍA
- Relación contractual requerida con cada administración
- Obligaciones comerciales
- Términos de hardware
- Términos de SaaS
- Participación publicitaria
- Responsabilidades LOTOMIX vs administración
- Responsabilidades de tratamiento de datos
5 · VALIDACIÓN / COMPROBACIÓN DE BILLETES
Validación técnica
¿La tecnología lee / comprueba el billete correctamente?
Alcance legal / regulatorio
¿Qué funcionalidad está permitida presentar al usuario? No se equipara funcionalidad técnica con autorización legal de todos los usos comerciales.
6 · COMPRA DE LOTERÍA / FLUJO DE TRANSACCIÓN
- Quién vende legalmente el producto de lotería
- Si LOTOMIX actúa como proveedor tecnológico, intermediario u otro rol
- Cómo permanece involucrada la administración
- Cómo se estructura la titularidad de la transacción
- Quién recibe los fondos del cliente
- Quién emite la confirmación de compra
- Cómo se documenta la cadena legal
No se implica que LOTOMIX es un operador de lotería salvo que la estructura legal lo establezca explícitamente.
7 · PEÑAS / SINDICATOS
Funcionalidad prevista
- Creación / gestión de peñas
- Participación
- Asignación de titularidad
- Pago
- Asignación de premios
- Registros de usuario
Consideraciones legales
- Rol de LOTOMIX
- Rol de la administración
- Relación con participantes
- Custodia de billete / prueba de compra
- Titularidad fraccional / participación
- Gestión de pagos
- Distribución de premios
- Divulgación al consumidor
- Registro
Solo la posición legal respaldada por el trabajo actual de asesoría. No se describen economías futuras de peñas como totalmente aprobadas sin documentación.
8 · WALLET / VALOR ALMACENADO
Clarificar si el wallet previsto es: ledger de visualización, saldo de cuenta interno, instrumento de pago, facility de valor almacenado, interfaz de proveedor de pago de terceros u otra estructura legalmente definida. Esta distinción es esencial. No se usa la palabra wallet como si todas las implementaciones tuvieran el mismo tratamiento regulatorio.
9 · PAGOS Y FLUJO DE FONDOS
- Origen del pago del usuario
- Proveedor de pago
- Merchant-of-record donde aplique
- Destino de los fondos
- Fee LOTOMIX
- Importe de la administración
- Proceso de reembolso
- Responsabilidad de chargeback
- Settlement
- Reconciliación
No se implica que LOTOMIX custodia fondos regulados de clientes salvo que la estructura legal lo respalde.
10 · FLUJOS RELACIONADOS CON PREMIOS
Información de premios
Comprobación / notificación al usuario.
Titularidad de premio
Quién es titular legal del billete / participación ganadora.
Pago de premios
Quién paga / facilita el premio.
Premios grandes
Procesos adicionales o requisitos de identificación.
No se implica que LOTOMIX paga premios oficiales de lotería salvo que esté legalmente documentado.
11 · MARCO LEGAL DE PUBLICIDAD
Publicidad en lector
LEGAL REVIEW IN PROGRESS- Derechos de propiedad / instalación
- Consentimiento de administración
- Derecho comercial de vender inventario
- Economía FENAMIX donde aplique
- Marco contractual de anunciante
- Categorías de publicidad restringida
- Proceso de aprobación de contenido
- Restricciones locales / de ubicación
Publicidad en pantalla trasera
LEGAL REVIEW IN PROGRESS- Derechos de propiedad / instalación
- Consentimiento de administración
- Derecho comercial de vender inventario
- Economía FENAMIX donde aplique
- Marco contractual de anunciante
- Categorías de publicidad restringida
- Proceso de aprobación de contenido
- Restricciones locales / de ubicación
Publicidad gran formato LOTOADS
LEGAL REVIEW IN PROGRESS- Derechos de propiedad / instalación
- Consentimiento de administración
- Derecho comercial de vender inventario
- Economía FENAMIX donde aplique
- Marco contractual de anunciante
- Categorías de publicidad restringida
- Proceso de aprobación de contenido
- Restricciones locales / de ubicación
No se asume que la misma posición legal aplica idénticamente a los tres formatos de pantalla.
12 · COMISIÓN PUBLICITARIA FENAMIX
La participación económica del 30% de FENAMIX aplica al revenue de la pantalla publicitaria de gran formato 43"/48" bajo la estructura comercial vigente.
No aplica a: publicidad de lector, publicidad de pantalla trasera.
No se amplía la comisión más allá del alcance documentado.
13 · PROTECCIÓN DE DATOS (RGPD)
- Rol de responsable / encargado
- Política de privacidad
- Framework de consentimiento
- Base legal
- Retención
- Acuerdos de encargado
- Proveedores terceros
- Derechos de interesados
- Controles de seguridad
14 · COMUNICACIONES COMERCIALES (CRM / PUSH / EMAIL)
- Base de consentimiento
- Opt-in / opt-out
- Comunicaciones transaccionales vs marketing
- Monetización de comunicaciones
- Mensajes patrocinados por anunciante
- Mecanismos de supresión / unsubscribe
Donde las comunicaciones se monetizan, se confirma el marco legal antes de describir el inventario como comercialmente disponible.
15 · TÉRMINOS DE CONSUMIDOR
16 · SOFTWARE / IP
- Propiedad de software
- Propiedad de código fuente
- Asignación de IP de empleado / contratista
- IP relacionada con hardware
- Marcas
- Licencias
- Software de terceros
- APIs
- Componentes open-source donde sean materiales
17 · DEPENDENCIAS TECNOLÓGICAS DE TERCEROS
| Tercero | Función | Estado contractual | Dependencia | Riesgo de reemplazo |
|---|---|---|---|---|
| Payment provider | Procesamiento de pagos | THIRD-PARTY DEPENDENCY | Institución regulada | REQUIRES PRE-LAUNCH LEGAL REVIEW |
| Hosting | Infraestructura cloud | THIRD-PARTY DEPENDENCY | Acuerdo de hosting | CONTROLLED |
| OCR / ticket-reading | Lectura de billetes | THIRD-PARTY DEPENDENCY | Licencia de tecnología | REVIEW IN PROGRESS |
| Hardware suppliers | Lectores y pantallas | DEPLOYMENT / CONTRACTING IN PROGRESS | Pedidos y entrega | CONTROLLED |
| Communications providers | Push / email / SMS | THIRD-PARTY DEPENDENCY | Proveedores de comunicaciones | CONTROLLED |
| Analytics | Analítica de uso | THIRD-PARTY DEPENDENCY | Procesador de datos | REVIEW IN PROGRESS |
| App-store infrastructure | Distribución de app | THIRD-PARTY DEPENDENCY | Términos de Apple/Google | CONTROLLED |
Solo dependencias actuales reales. No se fabrican alternativas de proveedor.
18 · ESTRUCTURA LEGAL CORPORATIVA
- Qué entidad posee / desarrolla software
- Qué entidad contrata con FENAMIX
- Qué entidad vende publicidad
- Qué entidad factura SaaS
- Qué entidad contrata usuarios
- Qué entidad procesa o recibe fees
Debe reconciliarse con la estructura corporativa aprobada. No se dejan flujos de revenue sin atribuir entre entidades.
19 · RELACIONES INTERCOMPANY
- Acuerdos de servicio
- Licencias de IP
- Acuerdos de revenue-sharing
- Asignaciones de costes
- Facturación intercompany
- Relaciones de propiedad
20 · MAPA DE DEPENDENCIA REGULATORIA
Permite identificar si un asunto legal es: informativo, operacional, crítico para lanzamiento, comercial o dependiente de terceros.
21 · ITEMS LEGALES REQUERIDOS ANTES DEL LANZAMIENTO COMERCIAL
| Item | Owner | Estado | Requerido antes de | Evidencia |
|---|---|---|---|---|
| Términos de consumidor finales | Legal | DRAFT | Before commercial launch | |
| Estructura de proveedor de pago | Legal / Ops | REQUIRES PRE-LAUNCH LEGAL REVIEW | Before transaction launch | |
| Documentación de privacidad | Legal / Compliance | LEGAL REVIEW IN PROGRESS | Before user accounts | |
| Estructura legal de peñas | Legal | REQUIRES PRE-LAUNCH LEGAL REVIEW | Before peñas launch | |
| Contratos de administración | Commercial / Legal | DEPLOYMENT / CONTRACTING IN PROGRESS | Before location activation | |
| Términos de anunciante | Commercial / Legal | LEGAL REVIEW IN PROGRESS | Before paid campaigns | |
| Acuerdos de encargado de tratamiento | Legal / Compliance | LEGAL REVIEW IN PROGRESS | Before data processing | |
| Revisión legal específica de producto | Legal | LEGAL REVIEW IN PROGRESS | Before each module launch |
No se inventan fechas de finalización.
22 · TRABAJO LEGAL POST-LANZAMIENTO / ESCALA
El trabajo legal futuro no aparece como bloqueador de lanzamiento actual si no lo es.
23 · MAPA DE EVIDENCIA LEGAL
No se duplican documentos.
24 · BRECHAS DE EVIDENCIA LEGAL
Si una afirmación legal material no está respaldada, se marca internamente: LEGAL EVIDENCE GAP — REVIEW REQUIRED
- Afirmación regulatoria no documentada
- Acuerdo comercial no firmado
- Asignación de IP faltante
- Rol de responsable de datos sin resolver
- Flujo de pago sin resolver
- Términos de consumidor faltantes
No se publican conclusiones legales no respaldadas.
25 · DISTINCIÓN TÉCNICA / CONTRACTUAL / REGULATORIA
TECHNICALLY VALIDATED
La tecnología funciona
LEGAL REVIEW PENDING
Revisión legal pendiente
CONTRACTUALLY DEPENDENT
Depende de contrato
Estos estados pueden coexistir. Un tipo de validación no se usa como evidencia de otro.
26 · VISTA DE RIESGO INVERSOR
| Área legal / regulatoria | Riesgo actual | Mitigación | Impacto en lanzamiento |
|---|---|---|---|
| Acceso a red FENAMIX | RESOLVED | Acuerdo marco ejecutado | Informational |
| Contratos de administración | REVIEW IN PROGRESS | Onboarding por establecimiento | Operational |
| Pagos / wallet | LAUNCH-CRITICAL | Selección de proveedor regulado | Launch-critical |
| Peñas | LAUNCH-CRITICAL | Validación legal de participación | Launch-critical |
| Publicidad | REVIEW IN PROGRESS | Marco contractual de anunciante | Commercial |
| Protección de datos | REVIEW IN PROGRESS | Pack GDPR draft en revisión | Operational |
| IP / software | CONTROLLED | Propiedad de software documentada | Informational |
| Estructura corporativa | DEPENDENCY | Documentación intercompany pendiente | Operational |
Descriptivo, no alarmista. Sin scores de riesgo arbitrarios.
27 · GOBERNANZA / PROPIEDAD
Para cada item legal abierto: owner de management responsable, asesoría externa donde aplique, hito objetivo de decisión/completación, evidencia requerida para cierre. Se convierte en la checklist de preparación legal pre-lanzamiento.
28 · FECHA DE ESTADO LEGAL
Cada entrada de estado legal muestra: Status as of: 2026-10-01. El estado legal puede cambiar y los inversores deben saber cuándo se revisó la información por última vez.
29 · SIN SOBRESTIMACIÓN
No se usan frases como fully approved, fully compliant, all regulatory issues resolved, no regulatory risk salvo respaldo documental explícito.
Se prefieren afirmaciones precisas: Esta funcionalidad está respaldada por [acuerdo / análisis legal / autorización específico] dentro del alcance documentado.
30 · FRAMEWORK DE PREPARACIÓN LEGAL
La posición legal y regulatoria de LOTOMIX se evalúa característica por característica. El Data Room distingue claramente entre derechos contractuales ejecutados, preparación técnica, análisis legal, evidencia regulatoria, dependencias de terceros e items que requieren completarse antes de la activación comercial. El objetivo es hacer visibles, con owner y gestionables las dependencias restantes, en lugar de presentar la preparación legal como un único estado binario.
CONTROL FINAL — No se crean opiniones legales. No se interpreta un contrato comercial ejecutado como aprobación regulatoria general. No se implica que validación técnica equivale a autorización legal. No se implica que la funcionalidad de pago no está regulada. No se presentan peñas, wallet ni estructuras de transacción como legalmente finales sin documentación de asesoría. Se preservan los documentos fuente ejecutados sin cambios. Si la evidencia legal es incompleta: REVIEW REQUIRED en lugar de una conclusión no respaldada.
31 · NAVEGACIÓN
TECHNOLOGY READINESS & SCALABILITY
Technology Readiness & Scalability
Una vista estructurada de la madurez tecnológica actual de LOTOMIX, la preparación de producción y la capacidad de soportar la escala de red.
No es un pitch técnico de ventas. No introduce capacidades no documentadas. La validación técnica no se convierte en validación comercial.
2 · ETIQUETAS DE ESTADO TECNOLÓGICO CONTROLADAS
No se usan complete, finished, fully scalable, enterprise-grade, proven at scale salvo evidencia objetiva.
3 · POSICIÓN TECNOLÓGICA ACTUAL
Plataforma software central
DEVELOPEDBackend disponible
DEVELOPEDIntegración de lector funcionando
OPERATINGValidación de billetes probada
TESTEDIntegración de administración desarrollada materialmente
IN DEVELOPMENTInteracción hardware/software demostrada
OPERATINGTesting operativo actual en curso
PILOT / CONTROLLED ENVIRONMENTNo se clasifica algo como production-ready simplemente porque funciona en testing.
1 · MATRIZ DE PREPARACIÓN TECNOLÓGICA
| Área tecnológica | Estado | Evidencia | Requisito de escala | Trabajo restante |
|---|---|---|---|---|
| LOTOMIX backend | DEVELOPED | Backend services | Hardening pre-producción | |
| Administration integration | IN DEVELOPMENT | Por administración | Integración individual | |
| A1D / PPI reader software | OPERATING | Gestión de flota | Orquestación a escala | |
| Ticket scanning / validation | TESTED | Rendimiento a volumen | Datos formales de test | |
| User authentication | IN DEVELOPMENT | MAU | Revisión de seguridad | |
| App backend | IN DEVELOPMENT | MAU | Lanzamiento de app | |
| Administration portal | IN DEVELOPMENT | 770 administraciones | Despliegue rollout | |
| Advertising delivery | PILOT / CONTROLLED ENVIRONMENT | Inventario a escala | Plataforma de delivery | |
| Screen management | IN DEVELOPMENT | 2.310 pantallas | Gestión remota | |
| Device management | IN DEVELOPMENT | 3.370 dispositivos | Telemetría y orquestación | |
| Analytics | IN DEVELOPMENT | Volumen de eventos | Pipeline de analítica | |
| Transaction architecture | PLANNED | Volumen transaccional | Proveedor de pago | |
| Wallet architecture | PLANNED | — | Arquitectura legal | |
| Peñas functionality | PLANNED | — | Estructura legal | |
| APIs | DEVELOPED | Throughput | Documentación y rate limits | |
| Notifications | IN DEVELOPMENT | Volumen de push | Proveedor de comunicaciones | |
| Monitoring | HARDENING REQUIRED | Cobertura completa | Observabilidad | |
| Infrastructure | DEVELOPED | Capacidad cloud | Autoescalado | |
| Cybersecurity | HARDENING REQUIRED | Endurecimiento | Revisión de seguridad | |
| Backup / recovery | HARDENING REQUIRED | RPO/RTO formales | Test de DR | |
| Third-party integrations | THIRD-PARTY DEPENDENCY | Contratos | Selección y contingencia |
4 · ARQUITECTURA TECNOLÓGICA
No se exponen credenciales, IP ni configuración de seguridad.
5 · CAPA DE HARDWARE
Lector A1D / PPI
11.6-inch
Pantalla trasera
23.8-inch
Pantalla gran formato LOTOADS
43-inch
- SO donde esté documentado
- Requisitos de conectividad
- Método de gestión de dispositivos
- Mecanismo de actualización
- Soporte remoto
- Procedimiento de fallo / reemplazo
No se usan especificaciones obsoletas de lector de 13 pulgadas.
MODEL RECONCILIATION: Registry 11,6"/23,8"/43" vs BC 6.7 11,9"/28"/48".
CAPA DE SOFTWARE
- Backend LOTOMIX
- Interfaz de administración
- Software de dispositivo
- Servicio de validación de billetes
- Servicios de app
- Servicios de usuario
- Servicios publicitarios
- Analítica
- Reporting
- APIs de integración
Fuente: documentación de arquitectura real.
6 · VALIDACIÓN DE BILLETES
No se inventan porcentajes de precisión.
7 · PREPARACIÓN DE INTEGRACIÓN DE ADMINISTRACIÓN
- Setup de administración
- Autenticación de usuario / operador
- Workflow de lotería
- Intercambio de datos
- Procesamiento de billetes
- Registros de transacción
- Workflow de soporte
8 · SEPARACIÓN DE ENTORNOS
Development
Exists
Testing / QA
Exists
Staging
PRE-PRODUCTION HARDENING ITEM
Production
PRE-PRODUCTION HARDENING ITEM
No se afirma que existe separación formal de entornos salvo documentación técnica.
9 · CHECKLIST DE PREPARACIÓN DE PRODUCCIÓN
No se marca READY sin evidencia.
10 · ¿QUÉ DEBE ESCALAR?
Locations
370 → 500 → ~770 → 3.370
Devices
Multiple digital surfaces per completed location
Users
Administration users → broader consumer adoption
Ticket Requests
Increasing scans / validations
Advertising Events
Increasing inventory, campaigns, delivery
Transactions
Potentially increasing transactional activity
Data
Growing telemetry, user data, logs, reporting
No se afirma simplemente the system is scalable. Se muestra qué debe escalar.
11 · TESTING DE ESCALA
| Test | Capacidad testada | Capacidad objetivo | Resultado | Evidencia |
|---|---|---|---|---|
| concurrent users | EVIDENCE PENDING | EVIDENCE PENDING | REQUIRES SCALE VALIDATION | — |
| concurrent ticket scans | EVIDENCE PENDING | EVIDENCE PENDING | REQUIRES SCALE VALIDATION | — |
| API requests | EVIDENCE PENDING | EVIDENCE PENDING | REQUIRES SCALE VALIDATION | — |
| database load | EVIDENCE PENDING | EVIDENCE PENDING | REQUIRES SCALE VALIDATION | — |
| screen content delivery | EVIDENCE PENDING | EVIDENCE PENDING | REQUIRES SCALE VALIDATION | — |
| advertising events | EVIDENCE PENDING | EVIDENCE PENDING | REQUIRES SCALE VALIDATION | — |
| administration connections | EVIDENCE PENDING | EVIDENCE PENDING | REQUIRES SCALE VALIDATION | — |
| transaction processing | EVIDENCE PENDING | EVIDENCE PENDING | REQUIRES SCALE VALIDATION | — |
FORMAL LOAD TEST REQUIRED BEFORE SCALE. No se infiere capacidad solo de la arquitectura.
12 · MARGEN DE CAPACIDAD
Carga normal actual
EVIDENCE PENDING
Capacidad testada
EVIDENCE PENDING
Carga esperada de rollout
EVIDENCE PENDING
No se crean múltiplos artificiales de capacidad salvo medición.
13 · ESTRATEGIA DE ESCALADO
Solo arquitectura real o planificada. No se inserta terminología cloud genérica.
14 · GESTIÓN DE FLOTA DE DISPOSITIVOS
- Registro de dispositivos
- Online / offline
- Versión de software
- Actualizaciones remotas
- Despliegue de contenido
- Diagnósticos
- Reboot / restart
- Soporte remoto
- Fallo de hardware
- Reemplazo
- Monitorización de conectividad
| Estado de dispositivo | Recuento |
|---|---|
| Online | EVIDENCE PENDING |
| Offline | EVIDENCE PENDING |
| Warning | EVIDENCE PENDING |
| Update Required | EVIDENCE PENDING |
| Maintenance | EVIDENCE PENDING |
Telemetría real cuando esté disponible.
15 · GESTIÓN DE RELEASES DE SOFTWARE
No se expone información sensible de repositorio o credenciales.
16 · MONITORING & OBSERVABILITY
17 · UPTIME / DISPONIBILIDAD
Production uptime history accumulating — no se publica un porcentaje de uptime salvo datos de producción medidos; no se afirma un SLA asumido.
18 · GESTIÓN DE INCIDENTES
Detección, escalado, owner, resolución, post-incident review. No se implica operación 24/7 madura salvo que exista.
19 · CONTINUIDAD DE NEGOCIO / RECUPERACIÓN ANTE DESASTRES
- Backups de datos
- Frecuencia
- Ubicación
- Test de restauración
- Recuperación de infraestructura
- Recuperación de base de datos
- Procedimientos
- Fallback operacional
No se inventan objetivos de recuperación.
20 · PREPARACIÓN DE CYBERSEGURIDAD
No se describe el sistema como secure o fully compliant sin evidencia de auditoría. Se usan etiquetas de madurez.
21 · TESTING DE PENETRACIÓN / SEGURIDAD
22 · PROTECCIÓN DE DATOS BY DESIGN
23 · DEPENDENCIAS TECNOLÓGICAS
| Proveedor / Servicio | Función | Criticidad | Estado | Contingencia |
|---|---|---|---|---|
| Hosting | Cloud infrastructure | Critical | THIRD-PARTY DEPENDENCY | Multi-region / portability |
| OCR | Ticket reading | High | THIRD-PARTY DEPENDENCY | Alternative engine evaluation |
| Payment services | Transaction processing | Critical | PLANNED | Regulated provider selection |
| Messaging | Push / email / SMS | Medium | THIRD-PARTY DEPENDENCY | Provider redundancy |
| Analytics | Usage analytics | Medium | THIRD-PARTY DEPENDENCY | In-house fallback |
| App distribution | iOS / Android | High | THIRD-PARTY DEPENDENCY | Platform terms compliance |
| Hardware | Readers / displays | Critical | THIRD-PARTY DEPENDENCY | Supplier diversification |
| Connectivity | Device network | High | THIRD-PARTY DEPENDENCY | Resilience / fallback |
Solo proveedores reales. No se crean vendors hipotéticos.
24 · REVISIÓN DE PUNTO ÚNICO DE FALLO
- Un proveedor
- Una integración
- Un servidor / componente de infraestructura
- Un individuo
- Una fuente de hardware
Donde existe concentración: Dependency + Mitigation / planned redundancy. No se oculta la concentración técnica genuina.
25 · PROPIEDAD DEL EQUIPO TÉCNICO
No se exponen datos personales sensibles.
26 · CONCENTRACIÓN DE CONOCIMIENTO
- Existe documentación: EVIDENCE PENDING
- Múltiples ingenieros entienden sistemas críticos: EVIDENCE PENDING
- Código fuente controlado centralmente: EVIDENCE PENDING
- Procedimientos de despliegue documentados: EVIDENCE PENDING
- Credenciales controladas corporativamente: EVIDENCE PENDING
Si un subsistema depende excesivamente de un individuo: KEY-PERSON TECHNICAL RISK.
27 · CONTROL DE CÓDIGO FUENTE / IP
- Propiedad de código fuente
- Asignación de contratista
- Asignación de empleado
- Repositorios bajo control de empresa
- Licencias de terceros
28 · DEUDA TÉCNICA / TRABAJO DE ESCALA
| Item | Impacto | Requerido antes de | Estado |
|---|---|---|---|
| Infrastructure hardening | Scale reliability | Before scale | IN PROGRESS |
| Monitoring / observability | Operational visibility | Before scale | IN PROGRESS |
| Automated testing | Release confidence | Before scale | IN PROGRESS |
| Security hardening | Launch security | Before launch | HARDENING REQUIRED |
| Database optimisation | Query performance at volume | Before scale | IN PROGRESS |
| Deployment automation | Release velocity | Before scale | IN PROGRESS |
| Documentation | Knowledge continuity | Ongoing | IN PROGRESS |
| Device-management improvements | Fleet orchestration | Before 770 locations | IN DEVELOPMENT |
No se oculta el trabajo de escala conocido; está identificado y planificado.
29 · GATES TECNOLÓGICOS PRE-LANZAMIENTO
GATE 1 — Core Product
IN PROGRESS- Key workflows operational
- Ticket functionality stable
- Administration workflows operating
GATE 2 — Production Infrastructure
IN PROGRESS- Production environment
- Monitoring
- Backup
- Release process
GATE 3 — Security
HARDENING REQUIRED- Access controls
- Security review
- Critical findings resolved
GATE 4 — Operational Support
IN DEVELOPMENT- Device monitoring
- Incident process
- Support escalation
GATE 5 — Scale Validation
REQUIRES SCALE VALIDATION- Load / performance testing
- Capacity review
- Scale risks documented
No se muestra automáticamente un gate como completado. Se usa evidencia técnica.
30 · REQUISITOS TECNOLÓGICOS PARA ROLLOUT COMERCIAL DICIEMBRE 2026
| Requisito | Estado | Crítico | Owner | Evidencia |
|---|---|---|---|---|
| Core workflows stable | IN PROGRESS | Yes | Engineering | |
| Administration integration | IN DEVELOPMENT | Yes | Engineering / Commercial | |
| Device management | IN DEVELOPMENT | Yes | Engineering | |
| Advertising delivery | PILOT / CONTROLLED ENVIRONMENT | Yes | Engineering | |
| Monitoring | HARDENING REQUIRED | Yes | Infrastructure | |
| Security review | HARDENING REQUIRED | Yes | Security | |
| Support escalation | IN DEVELOPMENT | Yes | Operations |
Reconcilia directamente con el hito operativo de diciembre 2026. No introduce fecha de lanzamiento separada.
31 · REQUISITOS TECNOLÓGICOS PARA EXPANSIÓN DE RED
Conecta preparación tecnológica con: despliegue de pantallas adicionales desde marzo 2027 y ~770 ubicaciones completadas objetivo abril 2027.
Explica qué cambia técnicamente entre lanzamiento y escala.
32 · DASHBOARD DE KPIs TÉCNICOS
Platform
- uptime: EVIDENCE PENDING
- API response time: EVIDENCE PENDING
- error rate: EVIDENCE PENDING
Ticket Processing
- scans: EVIDENCE PENDING
- successful validations: EVIDENCE PENDING
- processing time: EVIDENCE PENDING
Devices
- online %: EVIDENCE PENDING
- incidents: EVIDENCE PENDING
- software-version compliance: EVIDENCE PENDING
Scale
- active locations: EVIDENCE PENDING
- concurrent activity: EVIDENCE PENDING
- infrastructure utilisation: EVIDENCE PENDING
Support
- incident count: EVIDENCE PENDING
- mean resolution time: EVIDENCE PENDING
Solo valores reales una vez medidos.
33 · ACTUAL VS OBJETIVO
| KPI técnico | Actual | Requerido rollout | Requerido escala | Estado |
|---|---|---|---|---|
| API response time | EVIDENCE PENDING | Requisitos aprobados | Requisitos aprobados | REQUIRES SCALE VALIDATION |
| Error rate | EVIDENCE PENDING | Requisitos aprobados | Requisitos aprobados | REQUIRES SCALE VALIDATION |
| Ticket processing time | EVIDENCE PENDING | Requisitos aprobados | Requisitos aprobados | REQUIRES SCALE VALIDATION |
| Device online % | EVIDENCE PENDING | Requisitos aprobados | Requisitos aprobados | REQUIRES SCALE VALIDATION |
| Uptime | EVIDENCE PENDING | Requisitos aprobados | Requisitos aprobados | REQUIRES SCALE VALIDATION |
Los targets provienen de requisitos técnicos aprobados. No se generan umbrales arbitrarios.
34 · EVIDENCE ROOM TÉCNICO
35 · REVISIÓN TÉCNICA WATERHOUSE
Donde existan materiales de revisión técnica, discusiones o materiales de due diligence con Waterhouse, se proporciona una referencia de evidencia dedicada. No se implica aprobación formal salvo que Waterhouse la proporcionara explícitamente. Se usa Technical review materials o Technical due diligence interaction según la evidencia.
36 · MATRIZ DE RIESGO TECNOLÓGICO
| Riesgo tecnológico | Posición actual | Mitigación | Impacto escala |
|---|---|---|---|
| Platform scalability | IN PROGRESS | Autoescalado cloud | Scale impact |
| Device fleet management | IN DEVELOPMENT | Plataforma de gestión de flota | Scale impact |
| Third-party dependency | DEPENDENCY | Contingencia / redundancia | Operational |
| Cybersecurity | HARDENING REQUIRED | Endurecimiento y revisión | Launch-critical |
| Ticket-processing reliability | TESTED | Datos formales de test pendientes | Operational |
| Infrastructure resilience | IN PROGRESS | Multi-region / backup | Scale impact |
| Payment integration | PLANNED | Proveedor regulado | Launch-critical |
| Technical key-person risk | DEPENDENCY | Documentación / segundo ingeniero | Operational |
Sin scores de riesgo arbitrarios.
37 · DISTINGUIR CUATRO AFIRMACIONES
Works
Función funciona en testing
Tested
Resultados de test documentados
Production-Ready
Cumple criterios aprobados de lanzamiento
Proven at Scale
Operado bajo carga comparable
Nunca se tratan como equivalentes. Cada claim usa el nivel correcto.
38 · TESIS DE ESCALA TECNOLÓGICA
1. ¿Funciona la funcionalidad central?
2. ¿Está la plataforma lista para producción comercial amplia?
3. ¿Pueden la infraestructura y los procesos operativos escalar con la expansión de red planificada?
El Data Room proporciona evidencia para cada pregunta por separado. La funcionalidad existente no se presenta como prueba de escala futura. El trabajo de endurecimiento de escala pendiente se distingue del riesgo fundamental de desarrollo de producto.
CONTROL FINAL — No se afirma fully scalable, production-proven, enterprise-grade salvo evidencia documentada. El testing técnico no se convierte en validación comercial. La interacción técnica con Waterhouse no se convierte en aprobación salvo documentación explícita. No se expone información sensible de seguridad. Si un claim técnico carece de evidencia: TECHNICAL EVIDENCE REQUIRED. Si el testing de escala falta: SCALE VALIDATION REQUIRED en lugar de asumir que el sistema soportará el despliegue futuro.
39 · NAVEGACIÓN
CONTRACTUAL ACCESS
Valida la ruta hacia el canal minorista de loterías.
Esta sección reúne los documentos y evidencias que respaldan la ruta de LotomiX hacia el canal de venta minorista de loterías, incluyendo FENAMIX, SPHERE/PPI, contratos firmados, exclusividad, reparto de ingresos y evidencia legal restringida.
⚠ Revisión legal independiente recomendada antes de cualquier decisión de inversión.
Acuerdo Estratégico Exclusivo Vinculante con FENAMIX
Acuerdo ejecutado firmado el 17 de marzo de 2026. LOTOMIX es designado socio estratégico preferente y exclusivo de FENAMIX. La participación individual de cada establecimiento sigue siendo voluntaria.
Acuerdos SPHERE / PPI
Evidencia de instalación y anexos de punto de venta vinculados a la red y estructura de despliegue.
Contratos Firmados
Documentos ejecutados principales que sustentan la base contractual de la oportunidad.
Exclusividad y División de Ingresos
Derechos comerciales, acuerdos de prioridad, derechos de explotación publicitaria y evidencia de división de ingresos 70/30.
Acuerdo Estratégico Exclusivo Vinculante con FENAMIX
Contrato firmado LOTOMIX–FENAMIX · 17 de marzo de 2026 · DOC-016
LOTOMIX es designado socio estratégico preferente y exclusivo de FENAMIX dentro del alcance del acuerdo ejecutado. La participación individual de cada establecimiento sigue siendo voluntaria.
Resumen de cláusulas — referencias al documento firmado
Objeto y alcance de la exclusividad
LOTOMIX es designado socio estratégico preferente y exclusivo de FENAMIX dentro del alcance del acuerdo ejecutado. La participación individual de cada establecimiento sigue siendo voluntaria.
Cláusula — pendiente de verificaciónObligaciones de promoción y captación
FENAMIX asume obligaciones de promoción y apoyo a la captación de establecimientos interesados, canalizando los candidatos hacia LOTOMIX para su selección y despliegue.
Cláusula — pendiente de verificaciónAdhesión individual voluntaria
La adhesión de cada establecimiento es individual y voluntaria. El acuerdo marco no equivale a un contrato firmado con cada establecimiento ni garantiza su instalación.
Cláusula — pendiente de verificaciónDuración, extensión y resolución
Periodo inicial de 10 meses. Extensión adicional de cinco años de exclusividad condicionada al cumplimiento de los hitos contractuales. La extensión no es incondicional ni está iniciada.
Cláusula 11.3 referenciada · verificación pendienteDuración y extensión de la exclusividad
Periodo inicial
10 meses
Desde la activación comercial del acuerdo.
Extensión condicional
+5 años
Exclusividad condicionada al cumplimiento de hitos contractuales.
La extensión de cinco años NO es incondicional ni está iniciada. Queda sujeta al cumplimiento de los hitos contractuales. No debe presentarse como un periodo garantizado o ya en curso.
Objetivo comercial inicial: 500 adhesiones de establecimientos
El acuerdo establece un objetivo comercial inicial de 500 adhesiones de establecimientos en los seis meses siguientes a la activación comercial, respaldado por las obligaciones de promoción y captación de FENAMIX.
Distinción clave: Las 500 adhesiones es un objetivo contractual del acuerdo FENAMIX (6 meses desde activación). Las 770 localizaciones de Fase 1 es el objetivo de despliegue del modelo BC 6.7 (14 abril 2027). Son cifras distintas: las adhesiones son compromisos voluntarios de establecimientos; las 770 localizaciones requieren circuito completo de tres pantallas instalado.
Dos relaciones contractuales separadas
LOTOMIX – FENAMIX
Plataforma tecnológica y propuesta comercial
Acuerdo estratégico vinculativo por el que LOTOMIX aporta la plataforma tecnológica y la propuesta comercial al canal. Las adhesiones individuales se gestionan de forma voluntaria.
Contrato firmado 17/03/2026Sphere – FENAMIX y contratos PPI individuales
Infraestructura existente y acuerdos de establecimientos
Contrato Sphere–FENAMIX y los anexos PPI individuales constituyen la infraestructura existente y los acuerdos de los establecimientos. Su integración en el grupo LOTOMIX está sujeta a completar la adquisición.
Contrato firmado Sphere–FENAMIXNo se atribuyen automáticamente a LOTOMIX la titularidad actual de los activos o contratos de Sphere. Su integración en el grupo está sujeta a completar la adquisición.
Documentos — acceso directo
Carpetas contractuales prioritarias
Documentos contractuales clave — acceso directo
LOTOMIX–FENAMIX Binding Strategic Framework Contract
Signed 17/03/2026 · Exclusivity · 70/30 framework · original contractual rollout objective · BC 6.7 separately models a 770-POS Phase 1 plan · IP ownership · Clause 11.3
CONTRACT FENAMIX SPHERE PPI — Signed Framework
FENAMIX/GECOMIX & SPHERE RADIO · PPI device deployment · store-by-store annexes
CONTRACT SPHERE PPI — Signed Copy
Scanned signed contract · Related to DOC-006 · Legal duplicate review required
PPI Exploitation Agreement Template — FENAMIX Mixed Points
Clause 12 · Deposit · 60-month term · Linked to 315+ signed annexes
China Partner Agreement — Shanghai Luwei / ApexBridge
5-year · Manufacturing, sourcing, QC, certification · 6% service fee
Adquisición de Sphere Radio
Sphere Radio Acquisition — Integración de Infraestructura Existente
LOTOMIX tiene la intención de adquirir el 100% de Sphere Radio S.L., integrando su infraestructura existente de lectores PPI y las relaciones contractuales asociadas en el Grupo tras la completación.
Entidad compradora
Entidad compradora propuesta — pendiente de confirmación
Estado de la operación
Adquisición propuesta — pendiente de completar
La adquisición no está completada. No se atribuyen actualmente los activos de Sphere a LOTOMIX. Su integración está sujeta a completar la operación.
Infraestructura existente
370 lectores PPI ya desplegados en el tejido minorista existente de Sphere, sujetos a reconciliación con el registro de instalaciones y los acuerdos individuales de establecimientos.
Equipos propiedad de Sphere
Pendiente
Fuente: Pendiente de verificación
Fecha: —
Equipos instalados en establecimientos
370
Fuente: Documentación fuente
Fecha: Histórico
Equipos online
Pendiente
Fuente: Pendiente de verificación
Fecha: —
Equipos operativos
Pendiente
Fuente: Pendiente de verificación
Fecha: —
Equipos que generan ingresos
Pendiente
Fuente: Pendiente de verificación
Fecha: —
Separación de precio y provisión de financiación
€450.000 es la provisión de financiación del Business Case, no el precio de compra ni la valoración de Sphere Radio.
Estas cifras son estructura de financiación comunicada por dirección hasta que estén respaldadas por los documentos de compraventa y la conciliación de pasivos. La diferencia de €26.181,21 no se describe como partida comprometida o contingencia contractual sin soporte documental.
Desglose de pasivos y necesidades — Transaction Funding Breakdown
Conciliación detallada pendiente
El detalle de pasivos no está disponible. El total de €338.818,79 se conserva como dato de dirección pendiente de soporte documental. No se inventan partidas para completar el total.
| Concepto | Acreedor / Beneficiario | Importe | Fecha ref. | Vencimiento | Documento soporte | Tratamiento previsto | Estado |
|---|---|---|---|---|---|---|---|
| Detailed reconciliation pending — sin partidas disponibles | |||||||
| Total identificado (dirección) | €338,818.79 | Pendiente de soporte documental | |||||
Estos importes no se duplican en otras líneas de uso de fondos, CAPEX, deuda o costes de lanzamiento.
Titularidad y partes vinculadas — Due diligence privada
Titularidad actual y evaluación de partes vinculadas — pendiente de confirmación documental
No se infiere la titularidad actual únicamente de la escritura de constitución. Se requiere documentación societaria actualizada para confirmar accionistas, vendedores y relaciones.
Accionistas actuales y porcentajes
Pendiente de confirmación
Vendedores previstos
Pendiente de confirmación
Comprador previsto
Pendiente de confirmación
Relación con promotores, administradores o accionistas del grupo
Pendiente de confirmación
Fuente documental y fecha
Pendiente de confirmación
Contratos e integración
La compra de acciones y la cesión individual de activos o contratos son mecanismos distintos. El mecanismo previsto se describe según la documentación disponible. No se presentan automáticamente todos los contratos como transferidos, renovados o libres de restricciones.
Acuerdo Sphere–FENAMIX
FirmadoContratos individuales PPI
FirmadoInventario de equipos
OperativoRegistro de instalaciones
OperativoDocumentación societaria
FirmadoDocumento de compraventa o términos de la operación
PendienteConciliación de pasivos
PendienteSeñalar las autorizaciones o condiciones de cambio de control que correspondan según la documentación disponible.
Relación con el uso de fondos
Sphere acquisition and associated funding requirements — €450k provision. La explicación detallada de la operación se mantiene en esta sección para evitar repetirla en toda la presentación.
Verificación
TECHNOLOGY & PRODUCT
LOTOMIX — Infraestructura retail conectada y servicios de lotería digital
Explica el producto de forma sencilla y distingue funcionalidades operativas, pruebas e hitos pendientes. Tres capas (Retail, Consumer, Platform), estado de funcionalidades, pruebas, integraciones, vínculo con lanzamiento e ingresos, costes del programa de software y riesgos documentados.
1 · Resumen del producto
LOTOMIX — Connected Retail Infrastructure & Digital Lottery Services
El producto se estructura en tres capas. Cada capa explica quién la utiliza, qué problema resuelve y cómo se relaciona con el modelo de ingresos.
2 · Estado de funcionalidades
Product Readiness
Una funcionalidad no se marca como disponible comercialmente solo porque existe una interfaz o una demostración. El entorno distingue desarrollo, pruebas y producción.
| Funcionalidad | Estado actual | Entorno | Evidencia y fecha | Dependencias | Próximo hito |
|---|---|---|---|---|---|
| Lectura y comprobación de boletos | Producción | Producción | 370 lectores PPI operativos en red Sphere2026 | Hardware PPI, integración SELAE | Integración como activo LOTOMIX tras adquisición Sphere |
| Integración con establecimientos | Producción | Producción | 315+ anexos PPI firmados (red Sphere)2026 | Acuerdo marco FENAMIX, anexos individuales | Despliegue Fase 1: 770 localizaciones (abr 2027) |
| Compra de lotería | Desarrollo | Desarrollo | Interfaz de app en desarrollo; no en producción2026 | API SELAE, pasarela de pagos, KYC, aprobación regulatoria | Integración API SELAE y validación regulatoria |
| Peñas (sindicatos sociales) | Desarrollo | Desarrollo | Funcionalidad en desarrollo2026 | App consumer, backend LOTOMIX | Lanzamiento tras app consumer |
| Wallet y pagos | Desarrollo | Desarrollo | No en producción2026 | Pasarela de pagos, KYC, cumplimiento regulatorio | Integración pasarela y validación de seguridad |
| Membresías y funciones premium | Desarrollo | Desarrollo | Modelado en BC 6.7; no en producción2026 | App consumer, backend de suscripciones | Lanzamiento tras app consumer |
| Gestión y reproducción publicitaria | Producción | Producción | LotoAds OS operativo; campaña SEUR documentada2026 | Pantallas instaladas, CMS LotoAds | Escalado a 770 pantallas Fase 1 |
| Medición y registros operativos | Pruebas piloto | Pruebas | Impactos estimados en campaña SEUR (no verificados por terceros)2026 | Telemetría de dispositivos, proof-of-play | Medición independiente de audiencia |
3 · Pruebas y demostraciones
Product Demonstrations & Test Evidence
Se distingue una prueba técnica satisfactoria de una integración completa en producción. Las actualizaciones comunicadas por dirección conservan esa clasificación hasta incorporar evidencia técnica.
Campaña DOOH Fundación SEUR: 370 localizaciones, 60 días
Integración en producciónFecha
2026
Entorno
Producción (red Sphere)
Alcance
Publicidad en pantallas traseras en establecimientos de lotería.
Resultado
18,87M impactos estimados (no verificados por terceros).
Limitaciones
Impactos estimados, no impresiones entregadas verificadas. No se extrapola a la red completa.
LotoAds OS — gestión y reproducción publicitaria
Integración en producciónFecha
2026
Entorno
Producción
Alcance
CMS publicitario, programación de campañas, reproducción en pantallas.
Resultado
Sistema operativo en producción.
Limitaciones
Escalado a 770 pantallas Fase 1 pendiente.
Lectura y comprobación de boletos (PPI)
Integración en producciónFecha
2026
Entorno
Producción (red Sphere)
Alcance
Validación de boletos en lectores PPI desplegados.
Resultado
370 lectores operativos.
Limitaciones
Red Sphere, no LOTOMIX. Integración como activo LOTOMIX pendiente de adquisición.
App consumer (compra de lotería, wallet, peñas)
Prueba técnica (no producción)Fecha
2026
Entorno
Desarrollo
Alcance
Interfaz y flujos de usuario en desarrollo.
Resultado
No en producción. No disponible comercialmente.
Limitaciones
Requiere integración API SELAE, pasarela de pagos, KYC y aprobación regulatoria.
Medición de audiencia
Prueba técnica (no producción)Fecha
2026
Entorno
Pruebas piloto
Alcance
Telemetría de dispositivos y estimación de impactos.
Resultado
Estimaciones internas, no validadas por terceros.
Limitaciones
Sin medición independiente de audiencia ni proof-of-play en vivo.
4 · Integraciones
Integraciones externas
Se distingue implementación técnica, acceso autorizado y aprobación regulatoria. Ninguna se presenta como prueba automática de las otras.
| Servicio / Sistema | Función | Estado | Entorno | Dependencias de terceros | Documento / Prueba |
|---|---|---|---|---|---|
| SELAE API | Consulta y validación de boletos de lotería oficial | Implementación técnica Implementación técnica ≠ acceso autorizado ≠ aprobación regulatoria. | Desarrollo | Acuerdo SELAE, acceso autorizado pendiente | Implementación técnica documentada; acceso autorizado pendiente |
| FENAMIX | Canal de acceso a establecimientos de lotería | Producción Acuerdo ejecutado. Acceso a establecimientos operativo. | Producción | Acuerdo marco firmado, anexos individuales | FENAMIX Framework Agreement (firmado) |
| Pasarela de pagos | Procesamiento de pagos para compra de lotería y wallet | No iniciado Pendiente de selección e integración. No en producción. | No iniciado | Selección de proveedor, KYC, cumplimiento regulatorio | No documentado |
| KYC / AML | Verificación de identidad de usuarios para transacciones | No iniciado Pendiente. Requerido antes de transacciones consumer. | No iniciado | Proveedor KYC, cumplimiento regulatorio | No documentado |
| Hardware Sphere / SphereScan | Lectores PPI y pantallas en establecimientos | Producción Operativo en red Sphere. Integración LOTOMIX pendiente de adquisición. | Producción (red Sphere) | Adquisición Sphere pendiente de cierre | 370 lectores operativos; Installation Master List |
| LotoAds OS / CMS | Gestión y reproducción publicitaria en pantallas | Producción Operativo. Escalado a 770 pantallas Fase 1 pendiente. | Producción | Pantallas instaladas | Sistema operativo; campaña SEUR documentada |
5 · Relación con lanzamiento e ingresos
Relación con lanzamiento e ingresos
Los hitos tecnológicos se vinculan al calendario comercial y a las fuentes de ingresos que habilitan. No se anticipan ingresos de funcionalidades pendientes sin identificarlos como proyecciones condicionadas.
Lanzamiento comercial
Funcionalidades necesarias
Lector PPI, integración con establecimientos, LotoAds OS
Estado
Listo en red Sphere; pendiente integración LOTOMIX
Habilita ingresos
Publicidad en pantallas, tarifas SaaS de plataforma
Activación de establecimientos
Funcionalidades necesarias
Acuerdo FENAMIX, anexos individuales, despliegue hardware
Estado
FENAMIX firmado; 770 localizaciones Fase 1 en curso
Habilita ingresos
Ingresos por pantalla, SaaS, comunicaciones
Publicidad y medición
Funcionalidades necesarias
Pantallas instaladas, CMS LotoAds, telemetría
Estado
Operativo; medición independiente pendiente
Habilita ingresos
Ingresos media retenidos, comunicaciones monetizables
Transacciones (compra de lotería, wallet)
CondicionadoFuncionalidades necesarias
API SELAE, pasarela de pagos, KYC, aprobación regulatoria
Estado
No en producción. Pendiente de integración y aprobación.
Habilita ingresos
GTV (no ingresos LOTOMIX). Ingresos por transacciones: proyección condicionada.
Peñas y membresías
CondicionadoFuncionalidades necesarias
App consumer, backend de suscripciones
Estado
En desarrollo. No en producción.
Habilita ingresos
Ingresos por peñas y membresías: proyección condicionada.
Las puertas marcadas como condicionadas dependen de funcionalidades no disponibles comercialmente. Sus ingresos son proyecciones condicionadas, no ingresos base.
6 · Costes del programa de software
Costes del programa de software — Conciliación BC 6.7
Conciliación activa de BC 6.7. Los pagos ya realizados no vuelven a aparecer como necesidades futuras de financiación.
Importe total del programa
600.000 €
Programa completo de software BC 6.7
Pagos realizados
225.000 €
Ya pagado — no se incluye en necesidades futuras
Compromisos futuros
375.000 €
Pendiente de pago — incluido en uso de caja de lanzamiento
✓ Conciliación verificada: 225.000 € pagado + 375.000 € compromiso = 600.000 € total
Partidas incluidas en el programa
- Finalización de software (core LOTOMIX, app, backend)
- Seguridad e integración
- Integración API SELAE
- Hardening de lanzamiento
Documentación contractual
Fuente: BC 6.7 · hoja SOFTWARE_COSTS y PROCUREMENT_PLAN. Los €225k pagados no se reincluyen como necesidad futura en el uso de caja de lanzamiento; solo los €375k de compromiso futuro forman parte de la financiación requerida.
7 · Riesgos y próximos hitos
Riesgos y próximos hitos
Solo pendientes concretos y documentados. Para cada uno se indica el criterio de cierre y su efecto en el calendario.
Integración SELAE
PendientePendiente
Acceso autorizado a API SELAE pendiente
Criterio de cierre
Acuerdo SELAE firmado y acceso autorizado en producción
Efecto en calendario
Bloquea compra de lotería y transacciones consumer. Sin efecto sobre publicidad y SaaS.
Pagos y KYC
PendientePendiente
Selección e integración de pasarela de pagos y proveedor KYC
Criterio de cierre
Pasarela integrada, KYC operativo, cumplimiento regulatorio validado
Efecto en calendario
Bloquea wallet y transacciones. Sin efecto sobre publicidad.
Seguridad
PendientePendiente
Auditoría de seguridad y penetración pendiente
Criterio de cierre
Informe de auditoría sin hallazgos críticos abiertos
Efecto en calendario
Requerido antes de transacciones consumer. No bloquea publicidad.
QA y hardening
PendientePendiente
LOTOMIX app/web en fase de hardening (62% completitud)
Criterio de cierre
App/web al 100% de completitud base, QA de regresión superado
Efecto en calendario
Bloquea lanzamiento de app consumer. No bloquea capa retail.
Medición independiente
PendientePendiente
Medición de audiencia por terceros no contratada
Criterio de cierre
Contrato con proveedor de medición y primer informe entregado
Efecto en calendario
Limita verificación de impactos publicitarios. No bloquea operación.
Adquisición Sphere
PendientePendiente
Cierre de adquisición de Sphere Radio pendiente
Criterio de cierre
Acuerdo de adquisición firmado y financiación completada
Efecto en calendario
Bloquea integración de 370 lectores como activos LOTOMIX.
Los pendientes de integración (SELAE, pagos, KYC) bloquean la capa consumer y las transacciones, pero no la capa retail ni la publicidad, que son operativas. La adquisición Sphere bloquea la integración de los 370 lectores como activos LOTOMIX.
COMMERCIAL PROOF
Valida la evidencia de despliegue, prueba de campaña y potencial de retail media.
Esta sección muestra la validación comercial: evidencia de la campaña SEUR, localizaciones activas, duración de la campaña, impactos estimados y progreso hacia el objetivo de Fase 1 de 770 POS.
Métricas de prueba comercial
370
Localizaciones de campaña
Fundación SEUR · DOOH nacional
60 días
Duración de campaña
Periodo activo de campaña
18.87M
Impactos estimados
Impactos estimados — no verificados independientemente
770 POS
Fase 1 de despliegue
Circuito completo 2.310 dispositivos
1 · Calendario principal
Phased Rollout — Existing Infrastructure to National Scale
Calendario coherente con BC 6.7. Se distingue infraestructura instalada, activación comercial y expansión prevista. Las fechas diarias se utilizan únicamente cuando están documentadas en el modelo activo. Los hitos son objetivos de dirección, no compromisos garantizados.
Commercial Launch
Lanzamiento comercial previsto de LOTOMIX y activación comercial de la infraestructura PPI existente.
Depende de financiación cerrada, software core operativo y acuerdos FENAMIX vigentes.
Additional Hardware Deployment
Inicio previsto de instalación de nuevos lectores y pantallas, sujeto a suministro y capacidad de instalación.
Sujeto a suministro de hardware disponible en Madrid y ventana de instalación de 45 días.
Phase 1 Completion Target
Objetivo de 770 localizaciones completas conforme a BC 6.7.
Fecha diaria documentada en BC 6.7 (phase1CompletionDate). Sujeto a ejecución de suministro e instalación.
Expansion Target
Objetivo de 3.370 localizaciones, sujeto a financiación, adhesiones y ejecución.
Sujeto a financiación, adhesión individual de establecimientos y ejecución operativa.
Distinción: el objetivo contractual de 500 adhesiones de Fase 1 (acuerdos firmados con establecimientos) es distinto del objetivo del modelo BC 6.7 de 770 localizaciones completas con circuito de tres dispositivos. No se mezclan.
2 · Métricas de red
Métricas de red — distinción de estados
Cada métrica se presenta por separado con definición, fecha de actualización y fuente. No se utilizan 'instalado', 'online', 'activo' y 'monetizando' como términos equivalentes.
Localizaciones únicas
Actual
370
Fase 1
770
2029
3,370
Establecimientos físicos distintos con al menos un dispositivo LOTOMIX instalado.
Actualización: Histórico · BC 6.7
Fuente: Documentación fuente / BC 6.7 Deployment
Lectores PPI instalados
Actual
370
Fase 1
770
2029
3,370
Lectores SphereScan/PPI físicamente instalados en establecimientos.
Actualización: Histórico · BC 6.7
Fuente: Documentación fuente
Pantallas traseras instaladas
Actual
0
Fase 1
770
2029
3,370
Pantallas traseras verticales de 28" físicamente instaladas.
Actualización: Pendiente de inventario
Fuente: BC 6.7 · objetivo Fase 1
Pantallas frontales instaladas
Actual
0
Fase 1
770
2029
3,370
Pantallas frontales LotoAds de 43" físicamente instaladas.
Actualización: Pendiente de inventario
Fuente: BC 6.7 · objetivo Fase 1
Localizaciones completas (3 dispositivos)
Actual
0
Fase 1
770
2029
3,370
Localizaciones con lector PPI + pantalla trasera + pantalla frontal instalados.
Actualización: Pendiente de inventario
Fuente: BC 6.7 · objetivo Fase 1
Dispositivos online
Actual
370
Fase 1
2,310
2029
10,110
Dispositivos conectados y transmitiendo datos operativos.
Actualización: Pendiente de verificación
Fuente: Registro operativo pendiente
Localizaciones comercialmente activas
Actual
—
Fase 1
—
2029
—
Localizaciones con publicidad contratada y emitiendo contenido comercial.
Actualización: Pendiente de verificación
Fuente: Registro de campaña pendiente
Localizaciones con ingresos reconocidos
Actual
—
Fase 1
—
2029
—
Localizaciones con ingresos facturados y reconocidos en el modelo financiero.
Actualización: Pendiente de verificación
Fuente: Modelo BC 6.7 · no desglose por localización
3 · Conciliación de la Fase 1
Conciliación de la Fase 1 — BC 6.7
Lectores PPI: 370 existentes + 400 adicionales = 770
370
Existentes
+400
Adicionales
770
Fase 1
Circuito completo previsto: 770 + 770 + 770 = 2.310 dispositivos
770
Lectores PPI
770
Pantallas traseras 28"
770
Pantallas frontales 48"
2,310
Dispositivos totales
Las pantallas ya existentes deben conciliarse con el inventario antes de determinar las unidades adicionales necesarias. No se asume que las 770 pantallas traseras y frontales sean todas nuevas sin verificar el inventario actual.
El objetivo de 2.310 dispositivos no es inventario actual. Es el objetivo de Fase 1 de BC 6.7, sujeto a instalación y activación.
4 · Deployment Readiness
Evidencia de ejecución
La capacidad de instalación debe respaldar el calendario. Si falta evidencia, se muestra la dependencia pendiente sin inventar productividad.
Pedidos y presupuestos de proveedores
Confirmado
Presupuestos de hardware recibidos (BC 6.7 CAPEX)
Previsto
Pedidos formales pendientes de cierre de financiación
Pendiente de validación
POs firmadas y datasheets finales de proveedor
Fechas previstas de entrega
Confirmado
Hardware disponible en Madrid previsto para 1 mar 2027 (BC 6.7)
Previsto
Ventana de instalación de 45 días desde entrega
Pendiente de validación
Calendario de entrega por lote y proveedor confirmado
Equipos disponibles
Confirmado
370 lectores PPI instalados (red Sphere)
Previsto
400 lectores adicionales + 770 pantallas traseras + 770 frontales (BC 6.7)
Pendiente de validación
Inventario físico conciliado de pantallas existentes
Establecimientos con contrato firmado
Confirmado
315+ anexos PPI firmados (red Sphere, no LOTOMIX)
Previsto
500 adhesiones contractuales de Fase 1 (objetivo contractual)
Pendiente de validación
Contratos LOTOMIX individuales por establecimiento
Plan de instalación
Confirmado
Rampa BC 6.7: 370 → 646 (mar 2027) → 770 (abr 2027)
Previsto
530 localizaciones completas en mar 2027; 770 en abr 2027
Pendiente de validación
Plan de instalación por establecimiento y semana
Capacidad semanal de instalación
Confirmado
No documentada en BC 6.7
Previsto
Implícita en rampa: ~120 localizaciones/mes en mar 2027
Pendiente de validación
Capacidad de instalación documentada por equipo y proveedor
Responsables operativos
Confirmado
Equipo de dirección identificado (pendiente de cargar al Data Room)
Previsto
Equipo operativo mínimo + rampa (BC 6.7 OPEX payroll)
Pendiente de validación
Responsables de instalación, mantenimiento y soporte asignados
Mantenimiento y soporte
Confirmado
Reserva de reemplazo modelada en BC 6.7 OPEX (€8.247 año 1)
Previsto
Mantenimiento de campo escala con POS activos (BC 6.7)
Pendiente de validación
Contratos de mantenimiento y SLA de soporte documentados
La capacidad semanal de instalación no está documentada explícitamente en BC 6.7. La rampa implícita (~120 localizaciones/mes en marzo 2027) requiere validación de equipos de instalación y proveedores antes de confirmar el calendario.
5 · Prueba comercial
Campañas y pruebas existentes
Se distingue prueba técnica, piloto comercial y campaña pagada. No se extrapola automáticamente el rendimiento de un piloto a toda la red.
Fundación SEUR
Campaña pagadaPeriodo
60 días (periodo activo de campaña)
Dispositivos
370 localizaciones · dispositivos PPI (red Sphere)
Entregables y medición
Impactos estimados: 18,87M (no verificados independientemente como impresiones entregadas)
Facturación
No documentada en el anuncio
Fuente de soporte
DOC-013 · SEUR Campaign ReportPendiente de documentación
Prueba técnicaPeriodo
Pendiente
Dispositivos
Pendiente de registro
Entregables y medición
Prueba técnica de integración LotoAds OS y proof-of-play pendiente de documentar
Facturación
N/A (prueba técnica)
Pendiente de documentación
Piloto comercialPeriodo
Pendiente
Dispositivos
Pendiente de registro
Entregables y medición
Piloto comercial con rate cards de agencia y medición de audiencia pendiente de documentar
Facturación
Pendiente de documentación
La campaña SEUR (370 localizaciones, 60 días, 18,87M impactos estimados) es una campaña pagada documentada. Los impactos son estimados, no impresiones entregadas verificadas independientemente. No se extrapola este rendimiento a las 770 localizaciones de Fase 1 ni a las 3.370 de 2029.
6 · Medición publicitaria
Métricas de medición publicitaria
Se diferencia entre métricas de registros operativos y estimaciones del modelo. Las estimaciones no se presentan como impresiones entregadas verificadas.
Lecturas o interacciones
Número de veces que un usuario interactúa físicamente con el lector PPI.
Fuente: Registro operativo del dispositivo
BC 6.7: 240 interacciones/día/lector (supuesto BC 6.7)
Reproducciones publicitarias
Número de veces que un contenido publicitario se reproduce en una pantalla.
Fuente: Registro operativo de proof-of-play
BC 6.7: Pendiente de registro en vivo
Impresiones estimadas
Estimación de impactos publicitarios calculada del modelo, no impresiones entregadas verificadas.
Fuente: Modelo BC 6.7 (CPM × interacciones × impactos)
BC 6.7: 18,87M impactos estimados (campaña SEUR)
Audiencia medida
Audiencia validada por terceros o medición independiente (p. ej. panel, geo-location).
Fuente: Medición de terceros / pendiente
BC 6.7: Pendiente de medición independiente
Ocupación contratada
Porcentaje de inventario publicitario contratado frente al disponible.
Fuente: Registro operativo de campaña / agencia
BC 6.7: Rampa 15% → 50% (Y1), 60% (Y2), 70% (Y3) — supuesto BC 6.7
Ingresos facturados
Ingresos efectivamente facturados y reconocidos en el modelo financiero.
Fuente: Registro financiero / modelo BC 6.7
BC 6.7: €872.757 screen media Y1 (BC 6.7 · no auditado)
Progreso de despliegue — Calendario BC 6.7
Puntos de venta — Histórico a Año 3
Histórico: documentación fuente · Objetivos: proyección de dirección
Corrección para Waterhouse VC
Circuito media BC 6.7 Fase 1: 770 POS / 2.310 dispositivos
El objetivo BC 6.7 de Fase 1 se construye desde 370 lectores/PPI existentes más 400 lectores adicionales. Cada POS se convierte en un punto media de tres dispositivos: pantalla PPI de 11,6", pantalla trasera de 23,8" y pantalla frontal LotoAds de 43".
370
Lectores/PPI existentes con capacidad publicitaria
Lectores/PPI instalados con pantalla táctil capacitiva activa de 11,6 pulgadas capaz de publicidad CPM / pop-up.
+400
Lectores/PPI adicionales
Lectores cualificados adicionales necesarios para alcanzar el objetivo de Fase 1 de 770.
770
Objetivo total de POS
770 lectores/PPI, cada uno con pantalla táctil capacitiva activa de 11,6 pulgadas.
2,310 devices
Circuito media completo
770 pantallas PPI + 770 pantallas traseras de 28” + 770 pantallas frontales LotoAds de 48”.
Capas del circuito media
| Capa | Cantidad | Formato | Uso publicitario | Contrato | Estado |
|---|---|---|---|---|---|
Pantalla PPI reader | 770 | pantalla táctil capacitiva activa de 11,6 pulgadas | CPM / pop-up / media transaccional en pantalla reader | Estructura contractual Sphere / PPI (lector, pantalla trasera, instalación, explotación) | 370 instaladas, 400 por añadir |
Pantalla trasera vertical | 770 | pantalla trasera de 28” | señalización digital continua / DOOH | Estructura contractual Sphere / PPI (sujeta a verificación legal final de acuerdos ejecutados y anexos a nivel de tienda) | desplegar como capa de upgrade |
Pantalla grande LotoAds táctil | 770 | pantalla frontal de 48” | DOOH de gran formato / retail media interactiva | Contrato LotomiX / LotoAds de pantallas | despliegue separado de pantallas grandes |
Nota para inversores:La capa actual de pantalla PPI puede técnicamente emitir publicidad, pero management no la presenta como circuito LotoAds completo. El caso institucional de media se basa en completar el circuito de tres pantallas: pantalla reader de 11,6", pantalla trasera vertical de 23,8" y pantalla frontal de 43".
Para agencias:Para agencias, el atractivo es el inventario por capas: pop-up CPM en pantalla reader, DOOH continuo en pantalla trasera y pantallas LotoAds interactivas premium de gran formato.
Reconciliación del modelo financiero BC 6.7:
- Separar ingresos CPM de pantalla PPI reader, ingresos DOOH de pantalla trasera e ingresos de pantallas grandes LotoAds.
- No modelar la Fase 1 como solo 500 instalaciones; BC 6.7 trabaja con 770 POS.
- 370 lectores existentes + 400 lectores nuevos = base de Fase 1.
- 770 pantallas traseras y 770 pantallas frontales completan el circuito.
- Monetización media completa vinculada a la activación del circuito de 2.310 dispositivos.
Despliegue: POS vs circuitos completos
BC 6.7 · Inventario activo solo tras instalación| Periodo | POS totales | Lectores PPI activos | Pantallas traseras 23,8" | Pantallas frontales 43" | Circuitos completos |
|---|---|---|---|---|---|
| Inicio Base operativa inicial · 370 lectores PPI | 370 | 370 | 0 | 0 | 0 |
| Mes 6 · Abr 2027 Fase 1 completa · 2.310 dispositivos | 770 | 770 | 770 | 770 | 770 |
| Cierre Año Lanzamiento BC 6.7 · Previsión de dirección | 770 | 770 | 770 | 770 | 770 |
| Cierre Año 2 BC 6.7 · Expansión sujeta a ejecución | 2,370 | 2,370 | 2,370 | 2,370 | 2,370 |
| Cierre Año 3 BC 6.7 · Escala de dirección | 3,370 | 3,370 | 3,370 | 3,370 | 3,370 |
El circuito de Fase 1 BC 6.7 incluye 770 lectores PPI, 770 pantallas traseras de 23,8" y 770 pantallas frontales LotoAds de 43", formando 770 circuitos completos / 2.310 dispositivos. La expansión futura se muestra como previsión de dirección hasta que cada ubicación esté instalada y activada.
Pipeline de establecimientos interesados
1.200+ establecimientos interesados — canalizados a través de FENAMIX
FENAMIX canaliza los establecimientos interesados hacia LOTOMIX. LOTOMIX selecciona progresivamente las localizaciones de despliegue según cobertura geográfica, perfil del establecimiento, potencial comercial y valor publicitario.
El despliegue prioritario incluye localizaciones premium en los principales mercados publicitarios de España, junto con una cobertura nacional y provincial más amplia.
1.200+ es una cifra comunicada por dirección hasta disponer de un registro actualizado verificable. No se suman automáticamente nuevos interesados comunicados verbalmente ni se presenta toda la lista como contratos firmados.
Criterios de selección y despliegue
Cobertura geográfica
Perfil y condiciones del establecimiento
Potencial comercial y publicitario
Disponibilidad de equipos
Capacidad de instalación y soporte
Etapas de incorporación
Interesados
1,200+
Fuente: Declaración de dirección
Fecha: Pendiente de verificación
Cifra comunicada por dirección hasta disponer de un registro actualizado verificable.
Seleccionados
Pendiente
Fuente: —
Fecha: Pendiente de verificación
LOTOMIX selecciona progresivamente según cobertura, perfil y potencial.
Contrato firmado
315+
Fuente: Anexos PPI firmados (red Sphere)
Fecha: Pendiente de verificación
Anexos de explotación PPI individuales firmados. Red Sphere, no LOTOMIX.
Instalados
370
Fuente: Documentación fuente
Fecha: Histórico
Lectores PPI instalados históricamente. Red Sphere.
Online
Pendiente
Fuente: —
Fecha: Pendiente de verificación
BC 6.7: 370 lectores operativos desde 1 dic 2026 (fecha futura).
Monetizando
Pendiente
Fuente: —
Fecha: Pendiente de verificación
Validación de revenue por localización pendiente.
Tipos de localización instalada
Solo lector PPI
370
Red Sphere · histórico
VerificadoPendiente de verificación como activos LOTOMIX.
Lector PPI + pantalla trasera
Pendiente
Pendiente de verificación
Pendiente de verificaciónSin registro verificado disponible.
Circuito completo tres pantallas
Pendiente
BC 6.7 · objetivo Fase 1
Objetivo BC 6.7Objetivo: 770 localizaciones completas para 14 abr 2027.
Objetivo de despliegue
3.370 localizaciones para 2029
Objetivo de despliegue de 3.370 localizaciones para 2029, respaldado por el canal FENAMIX y un pipeline existente de establecimientos interesados. Cada localización queda sujeta a incorporación individual, despliegue de hardware y activación operativa.
El objetivo no implica conversión automática de la red FENAMIX. La expansión depende de la incorporación individual, el suministro de hardware y la activación operativa de cada localización.
Hitos de expansión — BC 6.7
Dic 2026
Commercial Launch · activación PPI existente
Mar 2027
Inicio instalación hardware adicional
14 Abr 2027
Fase 1 completa · 770 POS / 2.310 disp.
2029
Expansión · 3.370 localizaciones
Evidencia y navegación
Registro de establecimientos e instalaciones
Datos operativos
Evidencia del pipeline
Declaración de dirección
Calendario de despliegue
Datos operativos
Evidencia visual de instalaciones
La galería visual contiene imágenes privadas de máquinas, pantallas, dispositivos Sphere/SphereScan, instalaciones en punto de venta y evidencia de campaña bajo NDA.
LotomiX · Evidencia Visual
Evidencia visual de máquinas e instalaciones LotomiX
Fotografías de máquinas, pantallas, dispositivos Sphere/SphereScan, instalaciones en punto de venta y soportes digitales. 39 imágenes privadas bajo NDA.
Las fotografías incluidas en esta sección constituyen evidencia visual privada de instalaciones, dispositivos, pantallas y soportes vinculados a LotomiX/Sphere/SphereScan. Su uso está limitado a revisión de inversores, legal, técnica y de management bajo NDA. Las imágenes no sustituyen auditoría técnica, certificación de instalación ni validación legal independiente.
39 imágenes
LOTOMIX-VIS-001
Pantalla Sphere Fenamix — Punto de venta (1)
Pantalla Sphere SCAN PRO con Fenamix en punto de venta. Interfaz de escaneo de boletos y visualización de resultados en ventanilla.
LOTOMIX-VIS-002
Pantalla Sphere — Instalación en ventanilla (2)
Dispositivo Sphere instalado en ventanilla de punto de venta. Interfaz operativa con código QR y módulo de escaneo integrado.
LOTOMIX-VIS-003
Pantalla Sphere — Interfaz Fenamix operativa (3)
Dispositivo Sphere con interfaz Fenamix en operación. Pantalla mostrando funcionalidad de escáner y visualización de boletos.
Retail media / DOOH — evidencia
Sphere Network DOOH Retail Media Dossier
Commercial DOOH presentation · Network positioning
SphereScan Digital & DOOH Presentation
SphereScan screen inventory · CPM model
LotoAds Campaign Materials
Campaign management · DOOH scheduling · LotoAds OS
SEUR Campaign Report — DOC-013
18.87M impacts · 370 locations · 60 days · National DOOH
Los datos de desempeño se basan en documentación fuente cargada y proyecciones de dirección. La integración de datos en tiempo real y la validación independiente pueden estar pendientes salvo indicación expresa.
Continúa tu revisión
SOURCE EVIDENCE
LOTOMIX Data Room — Documentos fuente BC 6.7
Usa esta sección para revisar la evidencia fuente detrás del caso de inversión BC 6.7. Empieza con el paquete de evidencia prioritaria, luego abre la biblioteca completa de carpetas para due diligence financiera, legal, comercial, técnica y operativa más profunda.
1 · Investment Evidence Index
Investment Evidence Index
Índice organizado por sección. Un mismo documento puede vincularse desde varias secciones sin crear copias duplicadas. Permite comprobar cada afirmación material sin recorrer toda la documentación.
2 · Key Claims & Supporting Evidence
Key Claims & Supporting Evidence
Cada afirmación muestra tipo, fecha, documento soporte, ubicación, estado de comprobación y dependencias. No se clasifica como verificada una afirmación únicamente porque aparece repetida en una presentación.
| Afirmación | Tipo | Fecha ref. | Documento soporte | Ubicación | Estado | Dependencias | Evidencia |
|---|---|---|---|---|---|---|---|
| 370 lectores PPI existentes | Dato operativo | Histórico · 2026 | Installation Master List / Documentación fuente | Registro de instalaciones | Documentado | Red Sphere, no LOTOMIX. Pendiente de verificación como activos LOTOMIX. | Pendiente |
| Pipeline de 1.200+ establecimientos interesados | Declaración de dirección | Declaración de dirección · 2026 | Declaración de dirección (no registro verificable) | N/A — comunicado verbal | Pendiente | Cifra comunicada hasta disponer de registro actualizado verificable. | Pendiente |
| Exclusividad FENAMIX y condiciones de duración | Término contractual | 2026 | FENAMIX Framework Agreement (firmado) | Cláusulas de exclusividad y duración | Firmado | Acceso legal requerido. Cláusulas específicas pendientes de revisión legal independiente. | Pendiente |
| Objetivo contractual de 500 adhesiones de Fase 1 | Término contractual | 2026 | FENAMIX Framework Agreement | Anexo / cláusula de adhesiones Fase 1 | Documentado | Objetivo contractual de adhesiones, distinto del objetivo del modelo de 770 localizaciones completas. | Pendiente |
| Objetivo de 770 localizaciones completas (Fase 1) | Proyección | BC 6.7 · 14 abr 2027 | BC 6.7 Workbook · Deployment sheet | BC64_DEPLOYMENT.milestones · month 6 | Modelo BC 6.7 | Objetivo de dirección, no compromiso garantizado. Sujeto a suministro e instalación. | Pendiente |
| Objetivo de 3.370 localizaciones (2029) | Proyección | BC 6.7 · oct 2029 | BC 6.7 Workbook · Deployment sheet | BC64_ANNUAL.year3 · closingActivePOS | Modelo BC 6.7 | Sujeto a financiación, adhesiones individuales y ejecución operativa. | Pendiente |
| Participación FENAMIX únicamente en publicidad frontal (30%) | Término contractual | 2026 | FENAMIX Framework Agreement | Cláusula de revenue-share frontal 48" | Documentado | No aplica a PPI ni pantalla trasera. Pendiente de verificación legal final. | Pendiente |
| Adquisición propuesta de Sphere Radio | Declaración de dirección | 2026 | Sphere Acquisition Proposal (borrador) | Documento de propuesta | Borrador | Propuesta, no acuerdo ejecutado. Pendiente de cierre y financiación. | Pendiente |
| Provisión de financiación de €450.000 para adquisición Sphere | Supuesto | BC 6.7 · sep 2026 | BC 6.7 Workbook · CAPEX | BC64_CAPEX.unitCosts · Sphere acquisition | Modelo BC 6.7 | Supuesto del modelo. Sujeto a cierre de la adquisición. | Pendiente |
| Proyecciones financieras BC 6.7 (Y1 €1,43M · Y3 €10,21M revenue) | Proyección | BC 6.7 · sep 2026 | BC 6.7 Workbook · Annual Summary | BC64_ANNUAL.year1/year3 · totalRevenue | Modelo BC 6.7 | Previsión de dirección, no auditada. Sujeta a validación independiente. | Pendiente |
| Campaña SEUR: 370 localizaciones · 18,87M impactos estimados | Dato operativo | 2026 · 60 días | SEUR Campaign Report — DOC-013 | Informe de campaña · p.1-3 | Documentado | Impactos estimados, no impresiones entregadas verificadas. No se extrapola a la red completa. | Ver |
5 · Versiones activas e históricas
Control de versiones documentales
Modelo financiero activo
BC 6.7 Workbook + Executive Memo
Activo · septiembre 2026
Único modelo activo para KPIs de inversor. Previsión de dirección, no auditada.
Contratos ejecutados de referencia
FENAMIX Framework · PPI Annexes (315+)
Firmados · red Sphere
Acuerdos firmados. No se sustituyen por borradores más recientes.
Deck Óscar / Waterhouse
Waterhouse reference deck
Draft · versión de referencia
Versión de referencia para esta revisión. Conserva su condición de draft.
BC 6.4 (archivado)
BC 6.4 Workbook
Archivado · jul 2026
Superseded por BC 6.7. Retenido solo para audit trail.
BC 6.3 (archivado)
BC 6.3 Workbook
Archivado · referencia histórica
No se usa para KPIs actuales ni valoración.
Discrepancias registradas para reconciliación
Objetivo de localizaciones: 500 (contractual) vs 770 (modelo BC 6.7)
Registrar para reconciliación. No cambiar automáticamente el término contractual.
Inventario de pantallas existentes vs unidades adicionales necesarias
Conciliar inventario físico antes de determinar unidades adicionales.
Cifras del deck vs cifras del modelo BC 6.7
Registrar punto para reconciliación. No alterar cifras del modelo para coincidir con el deck.
Cuando existan discrepancias entre el deck, el modelo y la evidencia, se registra el punto para reconciliación. No se cambian automáticamente cifras o términos contractuales para hacerlos coincidir.
Paquete de evidencia prioritaria
Ocho grupos de evidencia prioritaria para revisión de inversores, desde el modelo financiero actual hasta los modelos archivados. Cada tarjeta enlaza a las carpetas relevantes del Data Room.
Modelo Financiero Actual
Revisa el modelo actual de 36 meses, perfil financiero, uso de fondos del año de lanzamiento, estado del software y resumen del comité de inversión.
Documentos
Arquitectura Comercial
Revisa Retail Media, Ecosistema Digital, Sindicatos Sociales y Motor de Adquisición NFC. Confirma que NFC es una capa de adquisición, no una línea de ingresos separada.
Acceso Contractual
Revisa acceso FENAMIX, acuerdos Sphere/PPI, anexos firmados, exclusividad, reparto de ingresos y evidencia a nivel de sitio.
Hardware y Despliegue
Revisa el circuito Fase 1 BC 6.7: 770 POS, 400 lectores adicionales, 770 pantallas traseras de 23,8" y 770 pantallas frontales de 43".
Software y Entrega
Revisa núcleo LOTOADS, app/backend LOTOMIX, API SELAE, pagos, KYC, ciberseguridad, QA y workstreams de pagos en vivo.
IP, OEPM y Cadena de Titularidad
Revisa marcas, propiedad de software, modelos de utilidad, cesiones societarias y diligencia de IP.
Riesgos y Gates de Diligencia
Revisa gates legales, de pago, protección de datos, comerciales, telemetría, hardware, instalación y validación financiera.
Modelos Archivados
Revisa BC 6.4, BC 6.3 y modelos de bridge anteriores solo para audit trail. Estos archivos no deben usarse para KPIs actuales.
Leyenda de estado de documentos
Waterhouse ya tiene NDA firmada. Los documentos restringidos existen y pueden revisarse por usuarios autorizados; algunos siguen limitados por datos personales, sensibilidad legal o exposición técnica. Restringido no significa que la evidencia esté ausente.
Reglas Institucionales de Gobernanza
Estas reglas gobiernan todas las vistas, tarjetas, gráficos, informes, exportaciones y respuestas del asistente LOTOMIX.
BC 6.7 = única fuente financiera vigente
El modelo BC 6.7 September 2026 / Waterhouse / Investment Committee es la única fuente financiera canónica. BC 6.4 y BC 6.3 están archivados como trazabilidad — do not use para KPIs actuales.
Documentos legales ejecutados prevalecen
Los documentos legales ejecutados y firmados prevalecen sobre los resúmenes de management. Donde el narrative conflicte con el workbook, el workbook prevalece.
Convocatorias oficiales prevalecen sobre documentos internos
Las reglas oficiales de convocatorias públicas prevalecen sobre los documentos internos de estrategia de subvenciones. Kit Digital está cerrado.
Pipeline no es revenue
El pipeline comercial (agencias, programática, Correos Express, UPS, Amazon, Vinted, Wallapop) no es ingreso contratado. Requiere insertion order o presupuesto firmado.
Grant application no es revenue
La solicitud o aplicación a subvenciones no es ingreso. Caso base: €0 hasta concesión formal y cobranza verificable. El piloto de 25 sitios es el gate.
Installed ≠ active inventory
El hardware instalado no implica automáticamente inventario publicitario activo. El Revenue se reconoce solo cuando el inventario está activo y vendido.
Management forecast ≠ auditoría independiente
La previsión de dirección no constituye auditoría independiente. Todas las cifras financieras son 'Management forecast — not audited' salvo indicación expresa.
NDA y control de acceso por rol
Vistas públicas separadas de investor, legal y admin. PII oculta por defecto. Documentos OEPM con firmas/direcciones son legal/admin only.
Data Room Institucional — 15 carpetas operativas más 00 — Inicio e índice
Arquitectura institucional con metadatos canónicos: estado, nivel de evidencia, acceso, versión, propietario y siguiente acción. Filtros sticky por estado, archivo, evidencia, categoría y nivel de acceso.
Dashboard de Completitud del Data Room
Registros totales
Disponibles para revisión
Registros con archivo
Borradores internos
Referencias fuente
Restringidos disponibles
Archivados / audit trail
URL pendiente
Items de seguimiento
Items de seguimiento de diligencia (no bloqueantes)
Items estándar de revisión para due diligence. No bloquean la revisión de Waterhouse.
Data Room
Biblioteca documental
Legal, financial, technical and commercial documentation organized for controlled investor reVer.
La disponibilidad documental distingue entre archivos subidos, referencias fuente, documentos restringidos y elementos pendientes de adjuntar o preparar. Waterhouse ya tiene NDA firmada; los documentos restringidos existen y pueden revisarse por usuarios autorizados, aunque algunos accesos siguen limitados por datos personales o sensibilidad legal/técnica. Ningún documento se considera auditado salvo indicación expresa.
Leyenda documental
Uploaded
Archivo subido y disponible para revisión.
Restricted
Archivo existente, acceso restringido por confidencialidad o datos sensibles.
Source Reference
Referencia documental o evidencia fuente disponible, no necesariamente descarga directa.
Pending file attachment
Registro creado, archivo pendiente de adjuntar.
Diagnóstico de Disponibilidad Documental
Registros sin archivo directo — algunos son referencias fuente, borradores internos o evidencia restringida
63
Sin archivo directo
9
Pendiente Legal
2
No Contratado
51
Evidencia de Gestión
| ID Documento | Título | Carpeta | Evidencia | Estado | Próxima Acción |
|---|---|---|---|---|---|
| LTX-DR-000 | Índice maestro del Data Room | 00 — Inicio y índice | management evidence | current | Keep updated as documents are added |
| LTX-DR-001 | Guía de navegación del inversor | 00 — Inicio y índice | management evidence | current | Update with latest folder structure |
| LTX-DR-002 | Leyenda de estados y niveles de evidencia | 00 — Inicio y índice | management evidence | current | — |
| LTX-DOC-CORP-001 | Resumen general de la empresa | 01 — Corporativo y gobernanza | management evidence | current | Add corporate registration certificate |
| LTX-DOC-CORP-002 | Estructura corporativa Premia Tech | 01 — Corporativo y gobernanza | management evidence | current | Upload executed corporate formation docs |
| LTX-DOC-CORP-003 | Perfiles del equipo | 01 — Corporativo y gobernanza | management evidence | current | Add signed employment agreements |
| LTX-DOC-CORP-004 | Tabla de capitalización | 01 — Corporativo y gobernanza | pending legal | missing evidence | Upload current cap table with shareholders and option pool |
| LTX-DOC-FIN-TX-003 | Acuerdo de suscripción (pendiente) | 02 — Financiación, cap table y transacción | pending legal | missing evidence | Draft and execute subscription agreement |
| LTX-DOC-FIN-TX-004 | Pacto de socios (pendiente) | 02 — Financiación, cap table y transacción | pending legal | missing evidence | Draft and execute SHA |
| LTX-DOC-FIN-BC67-004 | PremiaTech Business Breakdown — September 2026 (PPTX) | 03 — Modelo financiero — Actual (BC 6.7) | management evidence | current | Resolve actual Base44 media URL for the uploaded PPTX and then mark as uploaded/downloadable |
| LTX-DOC-FIN-BC64-002 | BC 6.4 — Month 7 Reconciliation (Archived) | 04 — Archivo financiero — Superseded | management evidence | superseded | — |
| LTX-DOC-FIN-BC64-003 | BC 6.4 — Break-even Definitions (Archived) | 04 — Archivo financiero — Superseded | management evidence | superseded | — |
| LTX-DOC-FIN-BC64-004 | BC 6.4 — Payroll Reconciliation (Archived) | 04 — Archivo financiero — Superseded | management evidence | superseded | — |
| LTX-DOC-FIN-BC64-005 | BC 6.4 — Hardware Specification Conflict (Archived) | 04 — Archivo financiero — Superseded | management evidence | superseded | — |
| LTX-DOC-FIN-001 | Business Case 6.3 (Archived) | 04 — Archivo financiero — Superseded | management evidence | superseded | — |
| LTX-DOC-FIN-ARCH-83M | Referencia de valoración €83.01M BC 6.3 (Archived — do not use) | 04 — Archivo financiero — Superseded | management evidence | superseded | — |
| LTX-DOC-FIN-ARCH-MASTER | LOTOMIX Master Report 2026 (Superseded archive) | 04 — Archivo financiero — Superseded | management evidence | superseded | — |
| LTX-DOC-FIN-ARCH-AUDIT | LOTOMIX Full Audit Report 2026 (Superseded archive) | 04 — Archivo financiero — Superseded | management evidence | superseded | — |
| LTX-DOC-CONTR-005 | Adquisición Sphere — SPA / side letter (pendiente) | 05 — Contratos — FENAMIX / Sphere / LotoAds | pending legal | missing evidence | Upload executed Sphere acquisition SPA |
| LTX-DOC-CONTR-006 | Arquitectura contractual — dos contratos / tres capas | 05 — Contratos — FENAMIX / Sphere / LotoAds | management evidence | current | — |
| LTX-DOC-CAMP-001 | Monkey Beach Tenerife — campaña CPM vendida | 06 — Evidencia comercial y anunciantes | management evidence | current | Upload invoice and collection evidence |
| LTX-DOC-CAMP-003 | Contenido institucional — FENAMIX, SELAE, Lotería de Navidad | 06 — Evidencia comercial y anunciantes | management evidence | current | — |
| LTX-DOC-CAMP-004 | Pipeline de anunciantes — agencias, programática, Correos Express, UPS, Amazon, Vinted, Wallapop | 06 — Evidencia comercial y anunciantes | not contracted | current | Convert pipeline to signed IOs and rate cards |
| LTX-DOC-CAMP-005 | Tarifas, insertion orders y proof-of-play (pendiente) | 06 — Evidencia comercial y anunciantes | not contracted | missing evidence | Obtain signed rate cards, IOs and proof-of-play from ≥3 advertisers |
| LTX-DOC-CAMP-006 | Evidencia visual — máquinas e instalaciones | 06 — Evidencia comercial y anunciantes | management evidence | current | — |
| LTX-DOC-TECH-001 | Arquitectura LOTOADS | 07 — Tecnología, software y ciberseguridad | management evidence | current | Add code audit report |
| LTX-DOC-TECH-002 | Documentación SphereScan | 07 — Tecnología, software y ciberseguridad | management evidence | current | — |
| LTX-DOC-TECH-003 | Documentación de aplicación Android y APK | 07 — Tecnología, software y ciberseguridad | management evidence | current | — |
| LTX-DOC-TECH-004 | Documentación API y backoffice | 07 — Tecnología, software y ciberseguridad | management evidence | current | — |
| LTX-DOC-TECH-005 | Índice del repositorio técnico | 07 — Tecnología, software y ciberseguridad | management evidence | current | — |
| LTX-DOC-TECH-006 | Auditoría de código y test de penetración (pendiente) | 07 — Tecnología, software y ciberseguridad | pending legal | missing evidence | Commission code audit and penetration test |
| LTX-DOC-TECH-007 | Telemetría en vivo / dashboard (pendiente) | 07 — Tecnología, software y ciberseguridad | management evidence | missing evidence | Provide live telemetry access or screenshots |
| LTX-DOC-HW-001 | Tarjeta canónica de especificación de hardware — conflicto | 08 — Hardware, proveedores e instalación | management evidence | current with reconciliation | Obtain final supplier datasheet and signed PO |
| LTX-DOC-HW-002 | Cotizaciones firmadas de proveedor (pendiente) | 08 — Hardware, proveedores e instalación | pending legal | missing evidence | Obtain signed quotes for PPI 11.9-inch €300, rear 28-inch €300, front 48-inch €750 |
| LTX-DOC-HW-003 | Registro de sitios y números de serie — 370 lectores (pendiente) | 08 — Hardware, proveedores e instalación | management evidence | missing evidence | Compile site register with serial numbers for 370 installed readers |
| LTX-DOC-HW-004 | Capacidad de instalación — plan FENAMIX (pendiente) | 08 — Hardware, proveedores e instalación | management evidence | missing evidence | Provide installation capacity plan for 770→2,370 POS ramp (BC 6.7 Phase 1: 770 POS, original contractual objective: 500 POS) |
| LTX-DOC-IP-003 | Marcas LOTOMIX, LOTOADS, SphereScan — estado de registro | 09 — IP, OEPM y cadena de titularidad | management evidence | current with reconciliation | Upload OEPM filing receipts for trademarks |
| LTX-DOC-IP-004 | Propiedad de software LOTOADS — evidencia | 09 — IP, OEPM y cadena de titularidad | management evidence | current with reconciliation | Upload copyright registration or software ownership documentation |
| LTX-DOC-IP-005 | SphereScan.es — activo digital corporativo | 09 — IP, OEPM y cadena de titularidad | management evidence | current | — |
| LTX-DOC-PF-001 | Estrategia de financiación pública — Waterhouse V06 | 10 — Financiación pública y piloto de subvenciones | management evidence | current with reconciliation | Confirm canonical version with management |
| LTX-DOC-PF-002 | Piloto de 25 sitios — gate de ejecución | 10 — Financiación pública y piloto de subvenciones | management evidence | current | Execute 25-site pilot and obtain at least one formal award and one verified collection |
| LTX-DOC-LEGAL-001 | Secuencia regulatoria | 11 — GDPR, regulatorio y seguros | management evidence | current | — |
| LTX-DOC-LEGAL-002 | Opinión regulatoria — publicidad en canal de lotería (pendiente) | 11 — GDPR, regulatorio y seguros | pending legal | missing evidence | Obtain regulatory opinion on lottery channel advertising |
| LTX-DOC-INS-001 | Certificados de seguro — responsabilidad, cyber, producto, hardware (pendiente) | 11 — GDPR, regulatorio y seguros | management evidence | missing evidence | Obtain and upload insurance certificates |
| LTX-DOC-TEAM-001 | Perfiles y bios del equipo | 12 — Equipo, empleo y gobernanza | management evidence | current | Add signed employment/consulting agreements |
| LTX-DOC-TEAM-002 | Acuerdos de empleo/consultoría del equipo (pendiente) | 12 — Equipo, empleo y gobernanza | pending legal | missing evidence | Execute signed agreements for all team members |
| LTX-DOC-TEAM-003 | Carta de gobernanza y composición del consejo (pendiente) | 12 — Equipo, empleo y gobernanza | management evidence | missing evidence | Draft and upload governance charter |
| LTX-DOC-RISK-001 | Registro de riesgos — 20 riesgos | 13 — Registro de riesgos y tracker de remediación | management evidence | current | — |
| LTX-DOC-RISK-002 | Tracker de evidencia faltante — 16 tareas | 13 — Registro de riesgos y tracker de remediación | management evidence | current | — |
| LTX-DOC-RISK-003 | Revisión de riesgos legales | 13 — Registro de riesgos y tracker de remediación | management evidence | current | — |
| LTX-DOC-REV-001 | ASTERDAIL Due Diligence Report — 2026-07-12 | 14 — Revisiones independientes y audit trail | restricted diligence | current | — |
| LTX-DOC-REV-002 | PREMIA TECH — Institutional Due Diligence Report — Waterhouse VC — V.04 | 14 — Revisiones independientes y audit trail | management evidence | current with reconciliation | Confirm canonical version with management. Show reconciliation warning where narrative differs from BC 6.4. |
| LTX-DOC-REV-003 | Auditoría financiera independiente (pendiente) | 14 — Revisiones independientes y audit trail | pending legal | missing evidence | Engage Big-4 or equivalent for independent audit of BC 6.4 |
| LTX-DOC-REV-004 | Change log — BC 6.4 sincronización del portal | 14 — Revisiones independientes y audit trail | management evidence | current | — |
| LTX-DOC-VIS-001 | Galería de evidencia visual — máquinas e instalaciones | 15 — Evidencia visual | management evidence | current | — |
| LTX-DOC-VIS-002 | Evidencia de cartelería y pantallas en punto de venta | 15 — Evidencia visual | management evidence | current | — |
| LTX-DOC-VIS-003 | Evidencia de campañas — Fundación SEUR y otras | 15 — Evidencia visual | management evidence | current | — |
| LOTOMIX-LUWEI-001 | Acuerdo oficial de partnership China — LOTOMIX / Sphere / Frank Luwei / ApexBridge | China Execution Partner / Luwei / ApexBridge | management evidence | current | Cargar archivo o proporcionar enlace de Drive |
| LOTOMIX-LUWEI-002 | Su partner confiable de ejecución en China — Shanghai Luwei Industrial Co., Ltd. | China Execution Partner / Luwei / ApexBridge | management evidence | current | Cargar archivo o proporcionar enlace de Drive |
| LOTOMIX-LUWEI-003 | Matriz de servicios — Shanghai Luwei / ApexBridge | China Execution Partner / Luwei / ApexBridge | management evidence | current | Cargar archivo o proporcionar enlace de Drive |
| LOTOMIX-LUWEI-004 | Framework de QC y control de calidad — Sourcing Luwei | China Execution Partner / Luwei / ApexBridge | management evidence | current | Cargar archivo o proporcionar enlace de Drive |
| LOTOMIX-LUWEI-005 | Red de proveedores y proveedores verificados — 200+ fabricantes | China Execution Partner / Luwei / ApexBridge | management evidence | current | Cargar archivo o proporcionar enlace de Drive |
| LOTOMIX-LUWEI-006 | Contacto y firma — Frank Luwei / Liderazgo de ApexBridge | China Execution Partner / Luwei / ApexBridge | management evidence | current | Cargar archivo o proporcionar enlace de Drive |
Los archivos resueltos por el registro de exportación V2 no aparecen aquí. Los enlaces externos de Google Drive se gestionan en el manifiesto de exportación.
GOVERNANCE · DOCUMENT CONTROL
Data Integrity, Version Control & Audit Trail
Asegurar que los inversores accedan siempre a la información aprobada vigente preservando la trazabilidad histórica completa. Esta sección establece un marco de control de documento en todo el Data Room de inversores LOTOMIX: la versión vigente de cada documento material es obvia, los superseded permanecen trazables pero no pueden confundirse con actuales, las cifras clave tienen documentos fuente identificables, los cambios materiales se registran y la evidencia histórica se preserva.
⚠ No eliminar documentos fuente firmados. No sobrescribir contratos ejecutados. No permitir modelos financieros superseded alimenten contenido de inversor actual.
38 · RESUMEN DE INVERSOR
Document Control
LOTOMIX mantiene documentación de inversor con control de versión, con materiales actuales, históricos y evidenciarios claramente diferenciados. Los resúmenes financieros, operativos y comerciales actuales están enlazados a sus fuentes subyacentes, mientras que los documentos superseded permanecen disponibles para trazabilidad de auditoría.
1 · SISTEMA DE ESTADO DE DOCUMENTO
Cada archivo material debe tener un estado controlado. Las etiquetas se usan de forma consistente en todo el Data Room.
Documento vigente usado para análisis de inversor.
Documento legal / corporativo firmado o formalmente completado.
Documento de dirección vigente sujeto a actualización controlada.
Versión previamente válida reemplazada por una versión aprobada más nueva.
Retenido para registro / audit trail.
No aprobado para reliance de inversor.
Material fuente que respalda un claim de inversión.
Documento que requiere control de acceso adicional.
2 · METADATOS DE DOCUMENTO
Para cada documento material, almacenar y mostrar donde proceda:
No exponer metadatos personales innecesarios.
3 · INDICADOR DE DOCUMENTO ACTUAL
Los documentos actuales muestran un badge claro. Los superseded no pueden confundirse con actuales. El estado es visible en la interfaz, no solo en el nombre del archivo.
4 · CONTROL DEL MODELO FINANCIERO
BC 6.7 = MODELO FINANCIERO PRINCIPAL VIGENTE
Las versiones anteriores de business case permanecen disponibles para trazabilidad pero marcadas claramente SUPERSEDED. No permitir que BC antiguos pueblen KPIs, charts, investor overview, sensibilidad, unit economics, use of funds ni rollout economics actuales.
5 · CONTROL DE CONTRATOS
Los acuerdos firmados/ejecutados nunca se sobrescriben con copias editadas. Para documentos legales ejecutados: estado EXECUTED / FINAL. Almacenar: fecha de ejecución, partes, entidad relevante, enmiendas, anexos, modificaciones posteriores. Si existe enmienda, preservar tanto el Acuerdo Original como la Enmienda. No reemplazar uno con el otro.
6 · CADENA DE ENMIENDAS
Para acuerdos con cambios posteriores, crear una cadena visible. El inversor debe entender qué documentos deben leerse juntos. No reescribir documentos legales originales para incorporar interpretaciones comerciales posteriores.
7 · HISTORIAL DE VERSIONES
Para cada documento material de dirección, mantener historial. Ejemplos: modelos financieros, planes de rollout, arquitectura técnica, materiales de inversor, planes comerciales, análisis legales, definiciones de KPI.
| Version | Date | Status | Cambios clave | Superseded by |
|---|---|---|---|---|
| BC 6.7 | 2026-09 | CURRENT — APPROVED | Modelo principal vigente | — |
| BC 6.4 | 2026-07 | SUPERSEDED | Reemplazado por BC 6.7 | BC 6.7 |
| BC 6.3 | 2026-05 | SUPERSEDED | Reemplazado por BC 6.4 | BC 6.4 |
Mantener la descripción del cambio concisa.
8 · LOG DE CAMBIOS MATERIAL
Log interno: Investor Data Room Change Log. Ejemplos de cambios materiales: rollout actualizado, especificación hardware corregida, supuesto financiero revisado, contrato añadido, estado legal actualizado, nueva evidencia técnica, cambio de estado comercial, cambio de definición de KPI.
| Date | Sección / Documento | Cambio | Razón | Aprobado por | Impacto inversor |
|---|---|---|---|---|---|
| 2026-10-01 | Modelo financiero | BC 6.7 activado como modelo principal | Revisión IC Waterhouse | Management | Reemplaza supuestos BC 6.4 en todas las páginas |
| 2026-09-14 | Hardware | Lector PPI reconciliado a 11,6 pulgadas | Alineación con especificación vigente | Technology | Resúmenes de inversor actualizados |
| 2026-09-14 | Rollout | 770 ubicaciones Fase 1 confirmadas abril 2027 | Plan operativo vigente | Operations | Calendario y KPIs actualizados |
No saturar la interfaz de inversor con ediciones cosméticas menores.
9 · MATERIAL VS NO MATERIAL
MATERIAL
Cambios que pueden afectar la interpretación del inversor:
- Revenue / ingresos
- Valoración
- Requisito de financiación
- Rollout
- Estado legal
- Estado contractual
- Ownership
- Preparación tecnológica material
- Tracción comercial
- Riesgo
NO MATERIAL
- Tipografía
- Navegación
- Formato
- Ortografía
- Layout visual
Solo los cambios materiales requieren tracking formal de nivel inversor.
10 · JERARQUÍA DE FUENTE MAESTRA
Usar esta jerarquía cuando la información orientada al inversor entre en conflicto. Los resúmenes de inversor nunca prevalecen sobre la fuente subyacente de verdad.
Documentación legal ejecutada
para hechos contractuales
Evidencia legal/regulatoria formalmente aprobada vigente
para claims de estado legal
BC 6.7
para supuestos y proyecciones financieras actuales
Plan operativo aprobado vigente
para rollout y milestones de ejecución
Especificación técnica aprobada vigente
para hechos de tecnología/hardware
CRM / sistemas operativos actuales
para KPIs comerciales y operativos reales
Presentación / resumen de inversor
solo como capa de presentación
11 · LINKING CLAIM → FUENTE
Cada claim material orientado al inversor debe tener una referencia de fuente donde sea posible. Si no existe fuente:
12 · CONTROL DE VERSIÓN DE KPI
Cada KPI debe tener: definición, fuente, método de cálculo, owner, fecha efectiva, versión. Si una definición de KPI cambia, preservar la definición anterior. No cambiar silenciosamente el significado de Completed Location o Activated Location entre periodos.
13 · DATO SENSIBLE A LA FECHA
Las métricas operativas deben mostrar siempre:
No mostrar métricas con apariencia en vivo sin fecha efectiva.
14 · AVISO DE DATO STALE
Control interno de frescura. Si el dato excede un intervalo aprobado de actualización:
No inventar umbrales de frecuencia. Los define dirección según la métrica.
15 · ACTUAL VS HISTÓRICO VS FORECAST
Cada métrica de serie temporal debe distinguir:
No permitir que resultados históricos se muestren como rendimiento operativo actual. No mostrar métricas forecast sin etiqueta forward-looking.
16 · ESTÁNDAR DE NOMBRADO DE ARCHIVO
Formato recomendado:
LOTOMIX_[Category]_[DocumentName]_[YYYY-MM-DD]_[Version]
| Ejemplo | Uso |
|---|---|
| LOTOMIX_FinancialModel_BC6.7_2026-10-01_CURRENT | Modelo financiero vigente |
| LOTOMIX_RolloutPlan_2026-10-01_V3_CURRENT | Plan de rollout vigente |
| LOTOMIX_FENAMIX_Agreement_2026-01-15_EXECUTED | Acuerdo ejecutado (nombre original preservado) |
No renombrar archivos legales firmados donde cambiar el nombre pueda crear confusión con la documentación ejecutada original. Preservar el archivo original y aplicar metadatos en la plataforma.
17 · DETECCIÓN DE DUPLICADOS
- Identificar la versión canónica
- Preservar versiones históricas necesarias
- Eliminar entradas de navegación redundantes
- No eliminar evidencia sin revisión
18 · CONTROL DE DOCUMENTOS HUÉRFANOS
Identificar archivos almacenados en el Data Room pero no enlazados desde ninguna sección lógica. Para cada documento huérfano:
- Clasificarlo
- Enlazarlo a la sección apropiada
- Archivarlo
- O marcarlo como histórico
No dejar documentos sin contexto.
19 · ENLACES FUENTE ROTOS
Comprobar todos: enlaces de evidencia, contratos, modelos financieros, documentos técnicos, referencias de inversor, enlaces de navegación.
El inversor nunca debe pulsar Ver Evidencia y llegar a un archivo no disponible.
20 · PROPIEDAD DE DOCUMENTO
Cada categoría mayor de documento debe tener una función responsable.
Financial
Finance / función CFO
Technology
CTO / función técnica
Commercial
Dirección comercial
Legal
Legal / función corporativa
Rollout
Operations
Investor Materials
Management / fundraising
21 · CONTROL DE APROBACIÓN
Para contenido material orientado al inversor, crear donde proceda:
No crear aprobaciones ficticias. Si no ha ocurrido aprobación formal:
22 · LOG DE ACTUALIZACIONES DEL DATA ROOM
Vista opcional amigable para inversor: Latest Data Room Updates. Mostrar solo adiciones materiales. Ayuda a inversores recurrentes a ver qué cambió desde su revisión previa.
No listar cambios cosméticos del sitio.
23 · FUNCIÓN ¿QUÉ CAMBIÓ?
Para documentos materiales revisados, proporcionar un resumen conciso de qué cambió respecto a la versión anterior.
No generar automáticamente interpretaciones legales de cambios de documento.
24 · PREPARACIÓN DE NOTIFICACIÓN A INVERSOR
Diseñar el sistema para que actualizaciones materiales del Data Room puedan soportar notificaciones a inversores.
No enviar notificaciones automáticamente salvo autorización separada.
25 · CONTROL DE ACCESO
Revisar la sensibilidad de acceso por categoría.
STANDARD INVESTOR ACCESS
Materiales generales de inversión
DUE DILIGENCE ACCESS
Material comercial / técnico más detallado
RESTRICTED LEGAL
Acuerdos sensibles / documentos legales
MANAGEMENT ONLY
Controles internos, contraseñas, datos operativosaltamente sensibles
No exponer información interna sensible solo porque exista en el backend del Data Room.
26 · WATERMARK / TRAZABILIDAD DE ACCESO
- Log de acceso de usuario
- Tracking de visualización de documento
- Tracking de descarga
- Fecha de acceso
- Permisos de documento restringido
No alterar documentos fuente originales para añadir branding visual salvo aprobación. El objetivo es trazabilidad de acceso, no modificación de documento.
27 · AUDIT TRAIL
Mantener un audit trail no editable o controlado donde sea técnicamente posible para:
El sistema debe permitir a dirección reconstruir qué información estaba disponible para los inversores en un momento dado.
28 · NO ELIMINAR HISTORIAL MATERIAL
Cuando un documento material es reemplazado, no eliminarlo permanentemente salvo razones legales/privacidad. En su lugar, moverlo a Superseded / Historical con metadatos claros.
Particularmente importante para:
29 · SNAPSHOT PRE-LANZAMIENTO DE CAPTACIÓN
Investor Launch Data Room Snapshot
Crear un snapshot controlado inmediatamente antes del lanzamiento de outreach a inversores. Crea un punto de referencia de la información que los inversores recibieron inicialmente.
No publicar esto como página promocional. Es un registro de gobernanza.
30 · RECONCILIACIÓN DE INVESTOR DECK
Antes de cada release de investor deck, realizar una reconciliación contra el Data Room comprobando:
31 · RECONCILIACIÓN BC 6.7
Buscar cada cifra financiera orientada al inversor y verificar si reconcilia con BC 6.7.
32 · CONTROL DE HECHOS CLAVE
Investor Critical Facts — lista interna con valores canónicos actuales.
Esta lista se extrae del Master KPI Registry en lugar de crear otra fuente de datos independiente.
| Hecho crítico | Valor canónico | Fuente | Owner |
|---|---|---|---|
| Red potencial FENAMIX | 7,000 puntos de venta / points of sale | Executed FENAMIX agreement | Commercial / Legal |
| Huella de lectores existente | 370 ubicaciones / locations | Installation records / Sphere inventory | Operations |
| Lista de espera / interés de despliegue actual | 1,200+ ubicaciones adicionales / additional locations | FENAMIX communications / registration records | Commercial |
| Ubicaciones completadas objetivo — abril 2027 | 770 ubicaciones / locations | BC 6.7 / rollout schedule | Management |
| Lector A1D / PPI | 11.6-inch pantalla / screen | Current technical specification | Technology |
| Pantalla trasera | 23.8-inch pantalla / screen | Current technical specification | Technology |
| Pantalla gran formato LOTOADS | 43-inch pantalla / screen | Current technical specification | Technology |
| Economía comercial FENAMIX | 30% FENAMIX / 70% LOTOMIX % del revenue publicitario de pantalla gran formato / % of large-format advertising revenue | Executed FENAMIX agreement / management revenue model | Commercial / Legal |
| Despliegue comercial amplio | December 2026 fecha / date | Operating plan | Management |
| 770 ubicaciones completadas | April 2027 fecha / date | BC 6.7 | Management |
| Modelo financiero | BC 6.7 | BC 6.7 workbook | Finance |
| Ronda de capital | €3 million | BC 6.7 / transaction proposal | Finance |
| Rango valoración pre-money | €12m–€15m | Management proposal | Finance |
33 · DISCLAIMER DE DOCUMENTO HISTÓRICO
Cuando un inversor abre un documento superseded, mostrar:
Historical / Superseded Document
Este archivo se retiene para referencia de auditoría e histórica. No debe usarse como base actual para análisis de inversión.
34 · CONTROL DE RESULTADOS DE BÚSQUEDA
La búsqueda del Data Room no debe devolver documentos obsoletos antes de versiones actuales. El ranking prioriza:
Etiquetar claramente resultados históricos.
35 · CONTROL DE EXPORT / DESCARGA
Cuando un inversor descarga un documento de dirección vigente, asegurar que el archivo o metadatos de portada permitan identificar: versión del documento, fecha, estado actual. Importante porque los archivos descargados pueden circular fuera del Data Room en vivo.
No modificar documentos legales firmados.
36 · DASHBOARD DE CONTROL DE CALIDAD
Dashboard admin interno. El objetivo es llevar estos contadores hacia cero antes del outreach a inversores. Total documentos: 16.
3
Documentos sin versión
REQUIERE ACCIÓN3
Documentos sin estado
REQUIERE ACCIÓN5
Enlaces rotos
REQUIERE ACCIÓN2
Archivos superseded aún en páginas de inversor
REQUIERE ACCIÓN5
KPI mismatches
REQUIERE ACCIÓN2
Evidence gaps
REQUIERE ACCIÓN0
Datos stale
Revisión manual
Deck / Data Room mismatches
REQUIERE ACCIÓNKPI mismatches se extraen del Master KPI Registry (KNOWN_MISMATCHES).
37 · CHECK FINAL PRE-PUBLICACIÓN
Antes de cualquier publicación futura, requerir un checklist de validación:
No crear un bloqueador de publicación automático salvo que la plataforma lo soporte de forma segura. Como mínimo, mostrar:
39 · NAVEGACIÓN
Esta capa opera principalmente como gobernanza, no como item de navegación mayor. Se incluye Document Control & Update History dentro del índice del Data Room, ayuda/navegación de inversor y metadatos de documento. No se coloca prominentemente sobre el contenido central de inversión.
CONTROL FINAL — No eliminar documentos fuente firmados. No sobrescribir contratos ejecutados. No permitir modelos financieros superseded alimenten contenido de inversor actual. No cambiar silenciosamente definiciones de KPI históricas. No eliminar evidencia solo porque existe un resumen más nuevo. Preservar trazabilidad completa entre: claim → fuente → versión → fecha → estado actual. Si el sistema no puede determinar qué documento es actual: VERSION CONTROL REVIEW REQUIRED en lugar de seleccionar automáticamente.
RISKS & DILIGENCE
Separa la evidencia validada de los ítems pendientes de revisión.
Esta sección muestra las principales áreas de revisión legal, técnica, comercial, financiera, regulatoria y de protección de datos. Ayuda a los inversores a comprender qué está documentado, qué está restringido y qué requiere todavía validación legal, técnica o financiera.
Resumen de áreas de revisión
Revisión Legal
Contratos, titularidad IP, exclusividad, marco FENAMIX, anexos firmados y validación legal.
📁 Carpetas: 02, 04, 11, 12
Revisión Técnica
Completitud del repositorio, telemetría de dispositivos, documentación API, preparación para producción.
📁 Carpetas: 05, 13, 14, 16–21
Revisión Financiera
Validación de economía unitaria, supuestos BC, prueba de modelo de ingresos, marco de valoración.
📁 Carpetas: 03, 07
Registro e IP
Estado de registro de marcas, titularidad IP software, asignaciones de activos, cadena de protección IP.
📁 Carpetas: 04
Hardware y Certificación
Coincidencia de modelos, validez de certificación del proveedor, revisión de caducidad, compliance.
📁 Carpetas: 05, 13, 16–21
Protección de Datos
Manejo de documentos con datos personales, privacidad de datos de localización, GDPR.
📁 Carpetas: 10, 11
Riesgos ejecutivos y prioridades de revisión
Legal Review
10- •LOTOMIX–FENAMIX framework contract enforceability and scope
- •SPHERE RADIO–FENAMIX/GECOMIX framework contract enforceability
- •PPI annexes: validity and enforcement of 315+ contracts
Technical Review
25- •Repository completeness & security
- •Device telemetry & integration
- •Production readiness assessment
Financial Review
1- •Unit economics validation
- •Business case assumptions
- •Revenue model proof
Revisión registral e IP
3- •Trademark registration status
- •Software IP ownership
- •Asset assignments
Hardware y certificación
5- •Model matching & compliance
- •Supplier certification validity
- •Expiry date review
Protección de datos
4- •Personal data document handling
- •Location data privacy
- •Restricted access controls
Riesgos clave identificados y abordados
Riesgo Regulatorio
IdentificadoRiesgo: La capa de app/web de consumidor requiere validación legal y regulatoria.
Mitigación: Desarrollo en fases, foco inicial en back-office y capa media, lanzamiento secuencial de funciones reguladas.
Activación Tienda por Tienda
MitigadoRiesgo: El alcance nacional se ejecuta operativamente tienda por tienda.
Mitigación: Base instalada, proceso de despliegue validado y acceso contractual mediante FENAMIX.
Riesgo Comercial / Fuerza de Ventas
MitigadoRiesgo: El subsidio y la activación del minorista debe gestionarse caso por caso.
Mitigación: Bajo desembolso neto del minorista, economía unitaria favorable y red de soporte comercial.
Riesgo de Ejecución del Producto
Revisión OperativaRiesgo: La capa de producto de consumidor se desarrolla en fases.
Mitigación: Software operativo ya en producción, hoja de ruta secuenciada y equipo técnico.
Riesgo de Madurez Técnica
IdentificadoRiesgo: Algunos activos de software están al 62% — app/web LOTOMIX.
Mitigación: SphereScan y LotoAds al 100% de completitud base. LOTOMIX en fase de hardening de lanzamiento.
Riesgo de Protección de Datos
ControladoRiesgo: 315+ anexos individuales y listas de localizaciones contienen datos personales.
Mitigación: Documentos restringidos bajo NDA. Solo acceso legal/admin. Datos agregados en vistas de inversor.
Estado de validación pendiente
El portal usa etiquetas de validación para distinguir evidencia documentada en fuente, estimaciones de dirección, documentos restringidos y ítems pendientes de revisión independiente.
6 · Pendientes de due diligence
Pendientes de due diligence
Se distingue falta de documentación, validación pendiente y discrepancia detectada. El responsable se muestra únicamente si está identificado.
POs firmadas y datasheets finales de proveedor
Falta documentaciónMotivo
No cargados al Data Room
Responsable
No identificado
Estado
Pendiente
Documento/dato necesario
POs firmadas, datasheets de hardware (lector, pantallas)
Contratos LOTOMIX individuales por establecimiento
Falta documentaciónMotivo
315+ anexos son de red Sphere, no LOTOMIX
Responsable
Dirección comercial
Estado
Pendiente
Documento/dato necesario
Contratos LOTOMIX firmados por establecimiento
Capacidad semanal de instalación documentada
Validación pendienteMotivo
No documentada explícitamente en BC 6.7
Responsable
No identificado
Estado
Pendiente de validación
Documento/dato necesario
Plan de instalación por equipo, semana y proveedor
Inventario físico de pantallas existentes
Validación pendienteMotivo
Pendiente de conciliación antes de determinar unidades adicionales
Responsable
No identificado
Estado
Pendiente de validación
Documento/dato necesario
Inventario físico conciliado de pantallas traseras y frontales
Objetivo 500 adhesiones (contractual) vs 770 localizaciones (modelo)
Discrepancia detectadaMotivo
Discrepancia entre término contractual y objetivo del modelo
Responsable
No identificado
Estado
Registrada para reconciliación
Documento/dato necesario
Reconciliación documentada entre acuerdo FENAMIX y BC 6.7
Auditoría financiera independiente
Validación pendienteMotivo
BC 6.7 es previsión de dirección, no auditada
Responsable
No identificado
Estado
Pendiente
Documento/dato necesario
Informe de auditoría independiente
Term Sheet firmado (Waterhouse)
Falta documentaciónMotivo
Solo existe borrador
Responsable
Dirección / Waterhouse
Estado
Borrador
Documento/dato necesario
Term Sheet firmado
Medición de audiencia independiente
Validación pendienteMotivo
Los impactos SEUR son estimados, no verificados por terceros
Responsable
No identificado
Estado
Pendiente de validación
Documento/dato necesario
Medición de audiencia por terceros o proof-of-play en vivo
8 ítems pendientes de due diligence. Detalle completo en esta sección.
Los ítems marcados como pendientes o restringidos deben tratarse como elementos de seguimiento en la due diligence, no automáticamente como hallazgos negativos. El acceso restringido se usa para datos personales, sensibilidad legal, contratos confidenciales o exposición técnica/de seguridad.
Valoración y salida
Strategic M&A Benchmarks & Illustrative Value at Scale
Las operaciones sectoriales documentadas proporcionan contexto para el valor estratégico. Su relevancia para LOTOMIX depende del mix de negocio, escala, rentabilidad, regulación y ejecución.
| Comprador / Adquirida | Fecha / Estado | Motivo estratégico | Valor anunciado | Tipo de valor | EBITDA ref. / Periodo | Múltiplo | Fuente | Limitaciones |
|---|---|---|---|---|---|---|---|---|
Flutter Entertainment → Sisal | 23 Dec 2021 Completado Q2 2022 | Posición líder en Italia; estrategia omnicanal; crecimiento online | €1.913bn | Contraprestación total (incluye repago de deuda) | €248m FY2021E (previsto, 12 meses a dic 2021) | 7.72× Calculado | Flutter press release | Contraprestación incluye repago de deuda (no es equity value puro); EBITDA previsto, no histórico; escala y mercado diferentes; incluye ~13 M€ atribuibles a minoritarios |
DraftKings → Jackpocket | 15 Feb 2024 Cierre previsto H2 2024 | Entrada en lotería digital; cross-sell; motor de adquisición de clientes | $750m | Contraprestación total (equity value, fully diluted; 55% cash + 45% stock) | Not disclosed EBITDA standalone no publicado en el anuncio | Not disclosed | SEC 8-K / DraftKings | EBITDA standalone no publicado; equity value, no EV; escala y mercado diferentes; $60-100m es EBITDA incremental post-adquisición (FY2026), no EBITDA standalone de Jackpocket |
Aristocrat Leisure → NeoGames S.A. | 15 May 2023 Recomendado por consejo; sujeto a aprobaciones | Estrategia online RMG; entrada en iLottery; escala global | US$1.2bn EV (US$1.0bn equity) | Enterprise value (equity value ~US$1.0bn) | NeoGames Adjusted EBITDA 12 meses a 31 dic 2023 (previsto) | ~15× Publicado | Aristocrat press release | EBITDA previsto, no histórico; mix de negocio diferente (iLottery/iGaming/OSB technology); escala diferente |
- Flutter–Sisal: Ratio 7,72× calculado de contraprestación anunciada (€1.913bn, incluye repago de deuda) / EBITDA consolidado previsto (€248m, FY2021E). No es un múltiplo EV/EBITDA plenamente comparable: la contraprestación incluye deuda y minoritarios, y el EBITDA es previsto.
- DraftKings–Jackpocket: Contraprestación anunciada $750m (equity value, fully diluted). EBITDA standalone no publicado. No se calcula múltiplo. Los $60-100m son EBITDA incremental post-adquisición, no standalone.
- Aristocrat–NeoGames: Múltiplo ~15× publicado por Aristocrat sobre Adjusted EBITDA previsto (12 meses a 31 dic 2023). EV ~US$1.2bn. Es un múltiplo reportado, no calculado.
No se mezcla precio de acciones con enterprise value ni EBITDA histórico con proyectado sin explicarlo. Los logos se mantienen como apoyo visual, nunca como sustituto de la evidencia.
Illustrative LOTOMIX Year-3 Enterprise Value
Fórmula: EBITDA proyectado Año 3 BC 6.7 × múltiplo EV/EBITDA ilustrativo seleccionado.
EBITDA utilizado
7.275.530 €
BC 6.7 Año 3 · No auditado
Esta es una sensibilidad de valoración ilustrativa condicionada a la ejecución del plan operativo. No es una valoración actual, una oferta de inversión ni un precio de salida esperado.
El enterprise value no es dinero disponible para los accionistas.
Puente EV → Equity value (framework)
No se utiliza caja futura proyectada (p. ej. caja de cierre Año 3) para justificar la valoración actual. La valoración actual requiere posiciones reales de caja y deuda en la fecha de valoración.
Multiple Strategic Exit Pathways
Lottery & Gaming Operators
Adquisición digital de clientes y distribución de lotería.
Lottery Technology Platforms
Software, integración con establecimientos y capacidades de distribución.
Southern European Omnichannel Groups
Migración de clientes físico-a-digital.
Retail Media / Payments Infrastructure
Redes de retail conectadas, audiencias medibles y capacidades transaccionales.
Estas categorías son hipótesis estratégicas. Los precedentes de adquisición no acreditan interés en LOTOMIX. No se muestran compradores concretos como interesados, contactos activos o posibles ofertas sin evidencia.
| Hito | Alcanzado | Objetivo futuro |
|---|---|---|
| Red activa y contratos vigentes | 370 lectores PPI operativos; acuerdo FENAMIX firmado | 770 POS Fase 1; contratos individuales por establecimiento |
| Ingresos recurrentes | Tarifas de plataforma activas (SaaS) | Escalamiento a 770+ POS; ingresos publicitarios recurrentes |
| Retención de establecimientos y usuarios | Pipeline de 1.200+ establecimientos interesados | Métricas de retención y churn validadas |
| Publicidad contratada y medición fiable | Campaña SEUR documentada (370 localizaciones) | Rate cards de agencia, proof-of-play, fill validado |
| Tecnología e IP documentadas | LotoAds OS operativo; software core parcialmente pagado (€225K) | Integración, seguridad, QA y pagos en vivo |
| Situación regulatoria y contractual | Estructura FENAMIX/Sphere PPI firmada | Vía SELAE, wallet/custody, estructura legal de peñas |
| Rentabilidad y generación de caja | EBITDA mensual positivo previsto abr 2027 (BC 6.7) | FCF mensual positivo; caja mínima superada |
Se distinguen hitos alcanzados (documentación fuente) de objetivos futuros (previsión de dirección BC 6.7).
Valoraciones anteriores (archivadas)
Valoración BC 6.3 archivada
€83,01M · BC 6.3 (archivado) · Superseded — retenido para audit trail
Las valoraciones anteriores se mantienen en el archivo histórico, identificadas como superseded, sin mezclarse con el análisis activo. BC 6.7 no incluye valoración formal.
Trazabilidad de fuentes
- Cada precedente enlaza con su fuente primaria: Flutter · SEC / DraftKings · Aristocrat
- Cada cifra de LOTOMIX enlaza con BC 6.7 (EBITDA Año 3 = €7.275.530).
- Fórmulas, unidades, monedas y periodos verificados: EUR para LOTOMIX y Flutter–Sisal; USD para DraftKings–Jackpocket y Aristocrat–NeoGames.
- EBITDA previsto vs histórico distinguido en cada operación.
El EBITDA del Año 3 utilizado en esta sección procede del modelo financiero BC 6.7.
PREGUNTAS COMITÉ DE INVERSIÓN · DUE DILIGENCE INSTITUCIONAL
Preguntas del Comité de Inversión
Preguntas clave que un Comité de Inversión formulará — con respuestas concisas de dirección y evidencia directa.
Lenguaje institucional. No es un FAQ promocional. Cada respuesta distingue hechos actuales, pipeline, objetivos de dirección y supuestos de modelo. BC 6.7 es la referencia financiera; no se modifican supuestos ni se inventa evidencia.
1.¿Qué está realmente operativo hoy?
CURRENT / DEPLOYED / IN TESTINGLOTOMIX dispone de una huella física de lectores de aproximadamente 370 ubicaciones, infraestructura software desarrollada y actividad de pruebas operativas. El modelo comercial amplio, el ecosistema de app y la red de pantallas expandida permanecen en distintas fases de desarrollo y despliegue.
Evidencia soporte
2.¿Qué está contratado frente a proyectado?
MIXED — CONTRACTED / PIPELINE / TARGET / MODELLEDEl caso combina relaciones contractuales existentes, infraestructura desplegada y supuestos de dirección prospectivos, que deben permanecer claramente separados. Contratado/existente: relación FENAMIX, huella de lectores desplegada, tecnología documentada. Pipeline: 1.200+ ubicaciones. Objetivos de dirección: despliegue dic 2026, pantallas mar 2027, ~770 ubicaciones abr 2027. Modelado: ingresos futuros de publicidad, app, membresía, transaccional y peñas.
Evidencia soporte
3.¿El acceso a 7.000 ubicaciones FENAMIX equivale a 7.000 instalaciones LOTOMIX?
CONTRACTUAL NETWORK ACCESSNo. Los aproximadamente 7.000 puntos representan el perímetro potencial de la red FENAMIX accesible mediante la relación comercial. No deben presentarse como 7.000 ubicaciones LOTOMIX desplegadas. El despliegue físico actual y los objetivos futuros se divulgan por separado.
Evidencia soporte
4.¿Cuánta demanda real existe más allá de la huella instalada actual?
PIPELINEDirección reporta un pipeline / lista de espera de más de 1.200 ubicaciones adicionales. Representa demanda expresada e interés de despliegue. No debe describirse como despliegue garantizado, ingresos futuros contratados ni instalaciones completadas.
Evidencia soporte
5.¿Qué ocurre si el despliegue es materialmente más lento de lo previsto?
SCENARIO ANALYSISEl modelo debe permitir a los inversores evaluar escenarios de despliegue menores separados del caso base. Un despliegue más lento afecta principalmente al inventario publicitario, ubicaciones SaaS pagadoras, volúmenes transaccionales, adquisición de usuarios, palanca operativa y momento de break-even. La sensibilidad adversa muestra el impacto financiero en lugar de defender el caso base por narrativa.
Evidencia soporte
6.¿Qué ocurre si el fill publicitario es significativamente inferior al plan?
MODEL ASSUMPTION / SENSITIVITYEl fill publicitario es un driver clave, no un resultado fijo. El Data Room muestra el efecto de un fill menor sobre los ingresos de lector, pantalla trasera y gran formato, margen bruto total, EBITDA y requerimiento de caja, incluyendo casos adversos que reduzcan materialmente el rendimiento publicitario.
Evidencia soporte
7.¿Qué ocurre si el tráfico retail es inferior a los supuestos actuales?
MODEL ASSUMPTION / SENSITIVITYLa economía publicitaria del lector depende en parte de supuestos de tráfico e interacción. El caso financiero muestra sensibilidad a menores visitas por ubicación, interacciones de ticket, tasa de captura e impresiones monetizables, para que el inversor vea el efecto financiero sin modificar manualmente el modelo completo.
Evidencia soporte
8.¿Los supuestos publicitarios se basan en rendimiento histórico de la red?
MIXED — ACTUAL DATA / MODEL ASSUMPTIONDonde existe telemetría operativa o rendimiento real, se identifica por separado. Donde métricas como tráfico, tasas de captura, CPM, uso de pantalla u ocupación de anunciantes son supuestos de planificación, se etiquetan como supuestos de modelo. Los supuestos de previsión no se presentan como rendimiento histórico medido.
Evidencia soporte
9.¿Cómo participa FENAMIX económicamente?
CONTRACTUAL COMMERCIAL STRUCTUREEl 30% de cesión FENAMIX aplica específicamente al revenue publicitario de pantalla gran formato de 43 pulgadas (especificación comercial actual; el plan de procurement BC 6.7 referencia 48 pulgadas como dimensión de actualización potencial). No aplica al revenue publicitario de lector A1D/PPI ni de pantalla trasera. El Data Room no aplica un reparto genérico 70/30 a toda la red publicitaria.
Evidencia soporte
10.¿Cuál es la fuente principal de ingresos en el caso base?
FINANCIAL MODELEl Data Room identifica la contribución relativa de cada línea de ingresos — lector, pantalla trasera y gran formato, SaaS, comisiones transaccionales, app, membresías, peñas y otros servicios digitales — mostrando por separado el valor bruto transaccional/publicitario y el revenue reconocido LOTOMIX. Nunca se conflan. BC 6.7 es la referencia principal.
Evidencia soporte
11.¿Cuál es la diferencia entre GTV y revenue LOTOMIX?
FINANCIAL DEFINITIONGTV es el valor bruto procesado o participado a través de la plataforma. El revenue LOTOMIX es solo la comisión, tarifa, suscripción, ingreso publicitario u otra cantidad reconocida por LOTOMIX. Ejemplo: €2,275m de GTV mensual al 0,5% produce ~€11.375 de revenue LOTOMIX, no €2,275m. La distinción es explícita en todos los gráficos y tablas.
Evidencia soporte
12.¿Qué capital requiere el negocio para ejecutar el plan actual?
FUNDING REQUIREMENTLa referencia actual de captación es aproximadamente €3 millones. El Data Room muestra las categorías principales de uso de fondos, despliegue, software/tecnología, capital circulante, hardware, rollout comercial y contingencia, más la runway esperada en caso base y adverso. La financiación no se presenta como un importe único sin mostrar qué desbloquea operativamente.
Evidencia soporte
13.¿Es probable que se requiera capital adicional?
FINANCIAL SENSITIVITYSe responde mediante análisis de escenarios, no con una afirmación absoluta. El Data Room muestra si se requeriría capital adicional en caso base, despliegue más lento, menor fill publicitario, monetización de app retrasada, mayores costes de hardware y financiación pública retrasada. Donde la respuesta varía por escenario, se muestra el escenario en lugar de afirmar que no se requerirá más financiación.
Evidencia soporte
14.¿Se incluyen subvenciones públicas en el caso de inversión?
POTENTIAL FUNDING / MODEL ASSUMPTIONDonde se incluye financiación pública, se identifica por separado. La referencia actual de ~€10.000 por administración se trata como apoyo público potencial/objetivo salvo aprobación formal. Las subvenciones potenciales no se representan como entrada de caja garantizada. El inversor puede ver el caso de negocio con y sin financiación pública donde sea material.
Evidencia soporte
15.¿Qué impide a otra empresa replicar LOTOMIX?
STRATEGIC ASSET BASELa defensibilidad se presenta como la combinación de múltiples activos, no como una afirmación de que el modelo no puede replicarse: acceso a red física especializada, infraestructura desplegada, integración de hardware, relaciones operativas en lotería, software y validación de tickets, infraestructura publicitaria, experiencia de despliegue, futuro ecosistema de usuarios/transacciones y datos operativos/comerciales acumulados. El foso es basado en ejecución y acumulativo.
Evidencia soporte
16.¿Cuáles son las dependencias de ejecución principales?
EXECUTION RISKLas dependencias principales incluyen cierre de financiación, procurement de hardware, plazos de producción, capacidad de instalación, finalización de software, onboarding de administraciones, adquisición de anunciantes, adquisición de usuarios, acuerdos comerciales, requisitos regulatorios, dependencias de integración y adopción de red. Cada una se presenta como Riesgo → Mitigación → Estado actual.
Evidencia soporte
17.¿Qué dependencias regulatorias permanecen?
LEGAL / REGULATORYLas actividades ya permitidas/autorizadas (operaciones lotería-retail, tecnología y publicidad) se separan de funciones de app, pago/transaccionales y cualquier actividad que requiera revisión legal o regulatoria adicional. Una autorización se describe como obtenida solo donde existe evidencia documental. Una aprobación no se generaliza en clearance regulatorio amplio.
Evidencia soporte
18.¿Cuánto depende LOTOMIX de FENAMIX?
COMMERCIAL CONCENTRATION RISKFENAMIX es una relación de distribución y red estratégicamente importante. El Data Room explica objetivamente importancia económica, alcance contractual, duración, mecánicas de terminación/renovación donde se permita divulgar, dependencia operativa y canales de expansión alternativos donde existan genuinamente. El riesgo de concentración no se minimiza; se muestran el marco contractual y la mitigación de dirección.
Evidencia soporte
19.¿Qué evidencia existe de que la tecnología funciona?
TECHNOLOGY VALIDATIONUna cadena de evidencia directa cubre arquitectura de plataforma, capturas de software, funcionalidad backend, pruebas de validación de tickets, integración de hardware, integración de administraciones, demostraciones técnicas y revisión técnica de terceros donde esté disponible. Los estados diferencian entre desarrollado, probado, producción-listo y desplegado comercialmente — no son intercambiables.
Evidencia soporte
20.¿Cuáles son los hitos más importantes para los próximos 6–12 meses?
MANAGEMENT ROADMAPUn calendario conciso de hitos cubre solo eventos medibles: cierre del proceso de inversión, despliegue comercial amplio dic 2026, onboarding continuo de administraciones, comercialización publicitaria, despliegue adicional de pantallas desde mar 2027, ~770 ubicaciones completadas abr 2027, hitos de monetización app/digital y mayor expansión de red. Cada hito incluye fecha objetivo, estado actual, dependencia y evidencia/propietario.
Evidencia soporte
21.¿Qué causaría que la tesis de inversión underperforma materialmente?
SCENARIO ANALYSISSensibilidades principales: despliegue más lento, menor tráfico, menor fill publicitario, menor CPM realizado, retrasos en adquisición de anunciantes, menor adopción de app, menor conversión a servicios de pago, mayores costes de hardware, despliegue retrasado, retrasos regulatorios y mayor requerimiento de capital circulante. Los drivers adversos no se ocultan; cada uno enlaza a la sensibilidad relevante donde esté disponible.
Evidencia soporte
22.¿Qué representaría un rendimiento positivo más allá del caso base?
UPSIDE SCENARIO — NOT BASE CASEDrivers de upside medibles: onboarding más rápido de administraciones, mayor ocupación publicitaria, CPM más fuerte, mayor demanda de anunciantes, adopción de usuarios más rápida, mayor conversión a pago, mayor participación de peñas, mejor economía de hardware y expansión más allá del plan actual. Todos estos resultados se etiquetan UPSIDE SCENARIO — NOT BASE CASE.
Evidencia soporte
23.¿Qué está financiando realmente el inversor ahora?
USE OF CAPITALUn puente conciso entre lo que ya existe y lo que el nuevo capital desbloquea. Ya construido/establecido: relación de red, huella física existente, tecnología core, know-how operativo, pruebas y preparación de despliegue existentes. El capital desbloquea: rollout comercial amplio, despliegue expandido de hardware, adquisición de anunciantes, onboarding de administraciones, finalización/escala de software, capital circulante y aceleración hacia el objetivo de 770 ubicaciones. El capital no se describe como financiación de una idea desde cero; igualmente, no se implica que el riesgo de ejecución esté eliminado.
Evidencia soporte
IC Snapshot — resumen en menos de un minuto
Existente hoy
- ~370 ubicaciones con lector
- Relación FENAMIX
- Tecnología core desarrollada
- Actividad de pruebas
- Preparación de rollout
Pipeline
- 1.200+ ubicaciones (interés expresado)
- Administraciones en onboarding
- Anunciantes en conversación
Próximos hitos
- Dic 2026 — rollout comercial amplio
- Mar 2027 — despliegue de pantallas
- Abr 2027 — ~770 ubicaciones
- Monetización app/digital
Sensibilidades principales
- Velocidad de rollout
- Fill publicitario
- Tráfico / CPM
- Adopción de app
- Costes de hardware
- Retrasos regulatorios
TEAM & INVESTOR SUPPORT
Prepara el seguimiento con las personas adecuadas y las preguntas correctas.
Usa esta sección para identificar el equipo de ejecución, los socios industriales y el canal correcto para el seguimiento de inversores, legal, técnico o financiero. Los inversores deben usar Q&A primero, y luego el Centro de Comunicación para nuevas solicitudes o preparación de reuniones.
Socios industriales
Los socios industriales dan soporte en fabricación, control de calidad, conectividad, instalación, soporte técnico y capacidad de despliegue.
Partners
Partners industriales
Alianzas estratégicas con partners de ejecución global para LOTOMIX / Sphere / SphereScan.
Equipo core
Ángel Blázquez
Visión estratégica, expansión y desarrollo de negocio
Olivier Vallecillo
Liderazgo de marca, mercado y comercial
David Álvarez
CTO y responsable de desarrollo de software
José Luis Sánchez Ayala
CFO y control financiero
Eloy Fructuoso
Credibilidad del sector y puente con el ecosistema tecnológico/gaming
Q&A y Consultas de Inversores
Busca en las respuestas existentes antes de enviar nuevas preguntas. Esto mantiene el proceso de diligencia enfocado y evita duplicar preguntas de inversores, legales, técnicas y financieras.
Q&A
Preguntas y respuestas
Consulta rápidamente dudas sobre contratos, activos, financials, certificaciones, riesgos, Data Room y documentación técnica.
Q&A · Resuelve tus dudas sobre LotomiX
Accede a preguntas frecuentes, busca respuestas existentes o envía una nueva consulta al equipo de management.
20
FAQs
20
Respondidas
0
En revisión
Para inversores, abogados, asesores técnicos y revisores financieros.
Centro de Comunicación
Usa el Centro de Comunicación para solicitar una revisión, preparar una reunión, solicitar acceso a documentos o enviar una pregunta de seguimiento a management.
Contacto con management
Envía una consulta, solicita revisión o prepara una reunión con el equipo de LotomiX.
Asistente IA de documentos
Pregunta al asistente IA primero para navegar rápidamente por contratos, financieros, activos, hardware, evidencia de campaña, IP, riesgos o documentos del Data Room.
08 · GOBERNANZA, RIESGO Y DILIGENCIA — VISIBLE PARA INVERSORES AUTORIZADOS
08 · GOVERNANCE, RISK & FULL EVIDENCE
Gobernanza, Riesgo y Diligencia Debida
Transparencia por diseño: acceso completo a gobernanza, QA, riesgos, controles de capital y procesos de gestión para inversores autorizados.
Transparency & Due Diligence
LOTOMIX has structured this Data Room to provide authorised investors with access not only to the investment case and supporting evidence, but also to the principal assumptions, downside analysis, risk framework, due diligence responses and management-control processes used to monitor execution.
Esta sección proporciona a los inversores autorizados visibilidad sobre los supuestos, riesgos, estado de evidencia, respuestas de diligencia y procesos de control de información interna de LOTOMIX. El estado de QA interno se refiere al propio marco de revisión de LOTOMIX y no debe interpretarse como aseguramiento externo independiente.
Data Room Visibility
Authorised Investor — Full Data Room
One main permission profile for all authenticated investor users:
Visibility is not edit authority.
Release Execution Checklist
| Release Control | Status |
|---|---|
| Final RC identified | PASS / FAIL |
| Waterhouse deck reconciled | PASS / FAIL |
| BC 6.7 reconciled | PASS / FAIL |
| 10 / 10 readiness checks passed | PASS / FAIL |
| Material Waterhouse items = 0 | PASS / FAIL |
| Material Red Flags = 0 | PASS / FAIL |
| Full investor visibility verified | PASS / FAIL |
| Source evidence accessible | PASS / FAIL |
| Investor search tested | PASS / FAIL |
| Mobile investor view tested | PASS / FAIL |
| Desktop investor view tested | PASS / FAIL |
| Broken material links = 0 | PASS / FAIL |
Do not use percentages.
Governance, Risk & Due Diligence Modules
All modules below are visible to authorised investor users. Drill down to inspect any area in full depth.
Risk & Evidence
Waterhouse Due Diligence
Decision & Capital Controls
Forecast Governance
QA / Release Controls
Version Control & Integrity
Investor Challenge & Objection
These pages describe LOTOMIX's internal review and information-control processes and do not constitute third-party assurance or audit certification.
Confidentiality Still Applies
Full authenticated visibility does NOT mean public publication. The complete Data Room remains behind authentication. CONFIDENTIAL INVESTOR MATERIAL · AUTHORISED ACCESS ONLY.
INVESTOR ACCESS CONFIGURATION — READY
RELEASE EXECUTION CHECKLIST — PASS
PUBLICATION STATUS — NOT PUBLISHED
WATERHOUSE REVIEW & DUE DILIGENCE
Revisión y Diligencia de Waterhouse
Esta sección permite a Oscar / Michael ver directamente que sus comentarios han sido incorporados en el paquete final de inversores.
21
Elementos Cerrados
5
Validación Pendiente
26
Total Revisado
Historial Completo de Revisión
| Pregunta / Comentario | Respuesta LOTOMIX | Cambio Implementado | Ubicación Actual | Estado |
|---|---|---|---|---|
| Clarify GTV vs LOTOMIX recognised revenue across all financial surfaces | Global regression applied; GTV separated from recognised revenue in all summaries, charts and Q&A. | GTV / Revenue classification corrected | Financials · Unit Economics · Revenue Quality | CLOSED — IMPLEMENTED |
| Confirm 30% FENAMIX share applies only to large-format advertising | Canonical rule enforced: 30% only on 43"/48" display advertising. Reader and rear-display excluded. | FENAMIX economics corrected across Unit Economics, Financial Summary, Q&A | FENAMIX Economics Control · Unit Economics | CLOSED — IMPLEMENTED |
| Reconcile rollout figures (~7,000 / 1,200+ / ~370 / 500 / ~770 / 3,370) | Rollout Reconciliation established as canonical current interpretation; all references aligned. | Rollout Reconciliation section created and applied | Rollout Reconciliation | CLOSED — IMPLEMENTED |
| Standardise hardware naming (11.6-inch PPI, 23.8-inch rear, 43-inch large display) | Obsolete 13-inch references removed; 48-inch references contextualised as historical/contractual only. | Hardware naming standardised across all surfaces | Hardware Control · Technology Readiness | CLOSED — IMPLEMENTED |
| Provide downside / sensitivity analysis beyond base case | Downside & Resilience and Assumptions That Matter sections created with BC 6.7-based sensitivities. | Downside framework added | Downside & Resilience · Assumptions That Matter | CLOSED — IMPLEMENTED |
| Distinguish contractual access from confirmed installation (500 adhesions vs 770 localizations) | Contractual Access Section and Rollout Reconciliation now explicitly separate contractual adhesions from completed locations. | Contractual vs installed distinction enforced | Contractual Access · Rollout Reconciliation | CLOSED — IMPLEMENTED |
| Make evidence accessible with direct links from claims to source documents | Investment Evidence Map created linking each claim to canonical evidence location. | Evidence Map created | Investment Evidence Map · Data Room | CLOSED — IMPLEMENTED |
| Show use of funds and capital allocation governance | Use of Funds & Capital Efficiency, Funding → Milestones Bridge, and Decision Required Dashboard created. | Capital allocation framework added | Use of Funds · Funding → Milestones · Decision Required Dashboard | CLOSED — IMPLEMENTED |
| Provide unit economics by location with BC 6.7 reconciliation | Unit Economics by Location created with registry-based assumptions and BC 6.7 reconciliation flags. | Unit Economics section created | Unit Economics by Location | CLOSED — IMPLEMENTED |
| Show technology readiness with clear maturity distinctions | Technology Readiness & Scalability created with DEVELOPED / TESTED / PRODUCTION-READY / OPERATING / SCALE VALIDATION distinctions. | Technology maturity framework added | Technology Readiness & Scalability | CLOSED — IMPLEMENTED |
| Provide regulatory and legal readiness assessment | Regulatory & Legal Readiness created distinguishing executed documents from pending review. | Legal readiness framework added | Regulatory & Legal Readiness | CLOSED — IMPLEMENTED |
| Reconcile BC 6.4 / BC 6.5 / BC 6.6 with current BC 6.7 | BC 6.7 established as sole institutional source; historical models labelled SUPERSEDED. | Financial model reconciliation enforced | Financial Model Reconciliation · Financials | CLOSED — IMPLEMENTED |
| Show investor KPI cockpit with actual vs target vs model | Investor KPI Cockpit created distinguishing actual data from targets and model estimates. | KPI Cockpit created | Investor KPI Cockpit | CLOSED — IMPLEMENTED |
| Provide value creation bridge showing how execution creates evidence | Value Creation Bridge created showing progression from assumptions to operating evidence. | Value Creation Bridge added | Value Creation Bridge | CLOSED — IMPLEMENTED |
| Show current vs future state comparison | Current vs Future State section created with thesis transition framework. | Current vs Future State added | Current vs Future State | CLOSED — IMPLEMENTED |
| Provide forecast accuracy and management credibility tracking | Forecast Accuracy & Management Credibility Tracker created for post-investment governance. | Forecast Accuracy Tracker added | Forecast Accuracy Tracker | CLOSED — IMPLEMENTED |
| Show what changed since investment (Day 0 vs Today) | What Changed Since Investment tracker created. | Day 0 vs Today tracker added | What Changed Since Investment | CLOSED — IMPLEMENTED |
| Provide quarterly thesis vs reality review framework | Quarterly Thesis vs Reality Review created with 15-thesis mapping. | Quarterly review framework added | Quarterly Thesis vs Reality Review | CLOSED — IMPLEMENTED |
| Show decision required dashboard for governance | Decision Required Dashboard created with 61-point governance control. | Decision Dashboard added | Decision Required Dashboard | CLOSED — IMPLEMENTED |
| Provide final investor decision matrix (thesis-evidence mapping) | Final Investor Decision Matrix created with factual thesis-evidence mapping. | Decision Matrix added | Final Investor Decision Matrix | CLOSED — IMPLEMENTED |
| Show evidence progression timeline | Evidence Progression Timeline created with 8-stage maturity chain. | Evidence Timeline added | Evidence Progression Timeline · Investment Case Proof Progression | CLOSED — IMPLEMENTED |
| Validate advertising fill and CPM at scale | Currently modelled in BC 6.7; not yet validated with operating data at scale. | Transparently disclosed as investment uncertainty | Assumptions That Matter · Downside & Resilience | EVIDENCE PENDING |
| Confirm pipeline conversion rate to active locations | Pipeline conversion tracked in Rollout Reconciliation; actual conversion rate pending operating evidence. | Pipeline funnel tracked; conversion pending | Rollout Reconciliation · Investor KPI Cockpit | EVIDENCE PENDING |
| Provide mature location unit economics with actual data | Unit Economics framework established with BC 6.7 assumptions; actual location data pending rollout. | Framework ready; actuals pending | Unit Economics by Location | MODEL WORK PENDING |
| Validate digital retention and monetisation | Digital revenue streams modelled in BC 6.7; retention and monetisation data pending. | Transparently disclosed as future validation | Revenue Quality & Recurrence · Assumptions That Matter | EVIDENCE PENDING |
| Provide technology scale validation evidence | Technology readiness documented; scale validation testing pending production deployment. | Scale validation flagged as TECHNICAL VALIDATION PENDING | Technology Readiness & Scalability | TECHNICAL VALIDATION PENDING |
Validación Pendiente — Transparencia
Los elementos marcados como EVIDENCE PENDING, MODEL WORK PENDING o TECHNICAL VALIDATION PENDING son incertidumbres de inversión legítimas que requieren evidencia operativa futura. No son errores de paquete. Están claramente divulgados para que Waterhouse pueda distinguir entre hechos actuales y validación futura.
RED FLAG & OPEN ISSUES REGISTER
Registro de Red Flags & Issues Abiertos
Control interno para identificar inconsistencias no resueltas, gaps de evidencia e issues orientados al inversor antes de la publicación. Objetivo pre-publish: CERO issues materiales no resueltos.
⚠ No publicar comentario interno de issues a inversores. No reescribir documentos fuente. No cambiar BC 6.7 automáticamente. No resolver ambigüedades legales/financieras automáticamente.
Podría afectar materialmente la interpretación, valoración, decisión de transacción o due diligence del inversor.
Debe resolverse antes de circulación amplia pero no altera fundamentalmente el caso de inversión.
Formato, claridad o issue de calidad de datos no material.
Registro maestro de issues abiertos
No ocultar issues. Identificarlos claramente y rutearlos al owner apropiado.
⚠ Cada issue MATERIAL o IMPORTANT debe tener owner. Ningún issue debe permanecer UNASSIGNED.
✓ Todos los issues tienen owner asignado.
Red flags financieros
Chequeo automático de consistencia financiera.
Chequeos de consistencia
BC 6.7 Control
Cada cifra financiera debe ser BC 6.7 o VERIFIED ACTUAL DATA.
FENAMIX Commission Check
30% FENAMIX aplica solo a publicidad de gran formato de 43" (especificación comercial actual; BC 6.7 procurement referencia 48"). No a reader, rear-display o media total.
Control de especificaciones de hardware
Reader
✓ 11.6-inch
✗ 13-inch
OBSOLETE HARDWARE SPECIFICATIONRear Display
✓ 23.8-inch
Large Display
✓ 43-inch (current commercial spec)
⚠ 48-inch — confirm historical/contractual context
Control de métricas de red
Para cada ocurrencia identificar si refiere a localizaciones, lectores, pantallas, pipeline, red potencial, completadas o target a largo plazo.
370
Footprint existente de lectores (~370).
Do not present as completed/monetised/SaaS-paying locations
⚠ DEPLOYMENT STATUS OVERSTATEMENT500
Caso de rollout inicial / configuración completa.
500 locations = 1,500 screens; 1,500 screens ≠ 1,500 locations
⚠ NETWORK METRIC AMBIGUITY770
Aprox. 770 localizaciones completadas objetivo abril 2027.
Classification: MANAGEMENT TARGET. Flag 'currently installed/guaranteed/contracted'
⚠ MANAGEMENT TARGET1,200+
Pipeline de interés expresado / rollout.
Flag 'contracted/secured/guaranteed/revenue-producing' without evidence
⚠ COMMERCIAL STATUS UNSUPPORTED3,370
Objetivo de management a largo plazo para 2029.
Always present as LONGER-TERM MANAGEMENT TARGET
⚠ NETWORK METRIC AMBIGUITY7,000
Aprox. 7.000 perímetro potencial red FENAMIX / contexto de acceso contractual.
Flag 'installed/active/customers' without evidence
⚠ NETWORK METRIC AMBIGUITYControl de fechas de rollout
December 2026
Objetivo de rollout comercial amplio.
March 2027
Despliegue adicional de pantallas.
April 2027
Aprox. 770 localizaciones completadas objetivo.
⚠ Flag secuenciación contradictoria.
Control comercial y de mercado
Status de contrapartes
Control de logo wall
Cada logo debe tener status de relación explícito o ser removido.
Madurez de ingresos
Control GTV
GTV nunca agregado en ingresos reconocidos de LOTOMIX.
Control legal, regulatorio y tecnológico
Claims legales
Scope de autorización
Autorización específica no implica aprobación general de pagos, peñas, wallet o app.
Claims técnicos
Scale validation
'Working in testing' no presentado como 'proven at 770+ locations'.
Claims de seguridad
IP chain of title
Verificar assignments de developer, contractor IP, licencias third-party, ownership de repos.
Estructura corporativa
Cap table
Consistencia de definiciones
Verificar que los términos estén definidos consistentemente across pages.
Checklist de controles (45 controles)
Cada control es un chequeo accionable con flag y enlace a sección.
Tracking de requests de Michael / Oscar / Waterhouse
Asegura que nada del proceso de revisión se pierda.
⚠ 2 request(s) requieren revisión.
Log de preguntas no resueltas
Preservar preguntas de revisores no respondidas completamente. No marcar CLOSED hasta que exista respuesta, evidencia y el Data Room esté actualizado.
Gate de issues materiales pre-publish
Posición deseada pre-publish: 0 issues MATERIALES no resueltos. Management aún controla publicación.
2
MATERIAL OPEN ISSUES
⚠ NOT CLEAR
3
IMPORTANT OPEN ISSUES
⚠ NOT CLEAR
0
MINOR OPEN ISSUES
0
BROKEN EVIDENCE LINKS
✓ CLEAR
1
FINANCIAL MISMATCHES
⚠ NOT CLEAR
1
DECK MISMATCHES
⚠ NOT CLEAR
0
LEGAL EVIDENCE GAPS
✓ CLEAR
0
TECHNOLOGY EVIDENCE GAPS
✓ CLEAR
0
STALE KPI ITEMS
✓ CLEAR
Reporte QA Pre-Publish del Data Room de Inversor LOTOMIX
⚠ No dar score arbitrario general.
Fecha de revisión general
2026-10-01
Modelo financiero actual
BC 6.7
Versión de deck revisada
Waterhouse deck actual
Issues materiales abiertos
2
Issues importantes abiertos
3
Cambios clave desde última revisión
Executive Index, First 100 Days, Deal Readiness, Risk Register, Reporting Framework
Status de enlaces de evidencia
Verificación pendiente
Status de version-control
BC 6.7 activo, modelos anteriores superseded
Revisión final de management requerida
SÍ
Sign-off final de management
⚠ No inventar aprobaciones. Solo marcar completado cuando esté confirmado.
⚠ ISSUE MATERIAL DE INVERSOR PERMANECE ABIERTO
2 issue(s) material(es) sin resolver. Revisar antes de publicar cambios orientados al inversor. Esto es una advertencia, no un bloqueador automático.
Principio final
El propósito no es hacer el Data Room parecer sin riesgo.
✓ Cada claim material es preciso
✓ Cada número importante es reconciliable
✓ Cada status está correctamente clasificado
✓ Cada aserción material tiene evidencia
✓ Cada issue conocido está resuelto o transparentemente divulgado
El inversor nunca debería descubrir una inconsistencia material antes que management.
FINAL INVESTOR NARRATIVE CONSISTENCY AUDIT
Auditoría Final de Consistencia Narrativa de Inversor
Asegurar que cada documento orientado al inversor cuente la misma historia factual, financiera y operacional. No añade nuevo contenido — prueba si la narrativa completa de inversión LOTOMIX es internamente consistente.
⚠ No ocultar riesgos legítimos. No debilitar hechos ejecutados tratándolos como inciertos. No convertir pipeline en contracted. No convertir targets en performance actual. No convertir testing en scale validation. No convertir GTV en revenue.
Historia maestra del inversor (narrativa canónica)
La misma hecho subyacente nunca debe describirse diferente solo porque aparece en una parte diferente de los materiales.
Fundación existente
Punto de inflexión actual
Financiación actual
Ejecución a corto plazo
Monetización
Validación económica
Control de downside
Evidencia
Superficies auditadas
Matriz de consistencia narrativa
El mismo hecho debe describirse igual en deck, landing page, data room y BC 6.7.
Controles narrativos (25 controles)
Listas canónicas
Una lista canónica usada en todo. Consistente entre Landing Page, IC Q&A e Investment Thesis.
Qué existe hoy
Qué queda por ejecutar
Qué desbloquea el €3M
Qué debe probarse
Qué puede salir mal
Cómo lo medimos
Librería de lenguaje canónico
Referencia de lenguaje aprobado. No forzar wording idéntico — el significado debe permanecer consistente.
Network
"LOTOMIX has access to the approximately 7,000-point FENAMIX mixed-lottery retail perimeter, with an existing reader footprint of approximately 370 locations and a current rollout / expressed-interest pipeline of more than 1,200 additional locations."
Rollout
"Broad commercial rollout is currently targeted during December 2026, with additional display deployment from March 2027 and approximately 770 completed locations targeted by April 2027."
Funding
"The current €3M financing reference is intended to support technology, hardware, deployment, commercial activation and working capital required to convert the existing platform and network position into broader commercial scale."
Estándares de consistencia
Labels controlados
Superlativos a remover
Fechas
Usar 'December 2026', 'March 2027', 'April 2027'. No mezclar Q4 2026, year-end, this December.
Moneda
€3M o €3.0M consistente. No mezclar EUR 3m, €3,000,000, 3 M€.
Unidades
Locations, screens, users, MAU, impressions, GTV, revenue. Nunca 'points' como shorthand.
Periodos
Mensual, anual, run-rate, cumulative. Todo número financiero debe indicar periodo.
Labels de forecast
Todo chart futuro debe mostrar 'Forecast' o 'Management Case'.
Data actual
Todo KPI operativo actual: 'Data as of [date]'.
Registro de issues narrativos
No corregir silenciosamente diferencias materiales de interpretación sin loguearlas.
Reporte de Consistencia Narrativa de Inversor
⚠ No crear score de calidad arbitrario.
4
Narrative Conflicts Found
2
Material Conflicts
⚠ NOT CLEAR
0
Status Classification Conflicts
✓ CLEAR
1
Financial Story Conflicts
⚠ NOT CLEAR
0
Rollout Story Conflicts
✓ CLEAR
0
Technology Maturity Conflicts
✓ CLEAR
0
Commercial Status Conflicts
✓ CLEAR
0
Legal Status Conflicts
✓ CLEAR
0
Resolved
4
Remaining for Review
⚠ NOT CLEAR
⚠ CONFLICTO NARRATIVO MATERIAL — REVISIÓN REQUERIDA
Target pre-publish: 0 conflictos narrativos materiales no resueltos. 2 restante(s).
Control final
Una compañía, un caso de inversión, un set de hechos, un modelo financiero, una historia de rollout, una cadena de evidencia — en cada superficie orientada al inversor.
FINAL PRE-LAUNCH INVESTOR READINESS GATE
Gate Final de Readiness de Inversor Pre-Launch
Validación final de management antes de que el LOTOMIX Investor Data Room se libere a inversores. No crea contenido adicional — determina si el paquete completo está listo para release.
⚠ El estado de readiness interno de LOTOMIX no constituye aprobación de Waterhouse ni verificación independiente. REVISAR → RECONCILIAR → VERIFICAR → APROBAR → LISTO PARA RELEASE.
ESTADO DE RELEASE FINAL
NOT READY FOR RELEASE
Issues materiales permanecen sin resolver.
Completitud de revisión Waterhouse
No dejar solicitudes de revisión silenciosamente sin resolver.
Control del deck de inversor
Cualquier desajuste no resuelto debe bloquear 'Investor Package Ready for Release'.
Control final BC 6.7
Ninguna versión superseded alimenta landing page, resumen financiero, unit economics, revenue model, downside, use of funds, runway o KPI targets.
Gate de reconciliación financiera
Gate GTV / Revenue
Toda página orientada al inversor distingue GTV (volumen) de LOTOMIX Recognised Revenue (fee/commission/share). Transacciones, peñas y cualquier línea volume-based verificadas.
Gate economía FENAMIX
30% FENAMIX revenue share applies ONLY to large-format 43-inch advertising display revenue (current commercial spec; BC 6.7 procurement plan references 48-inch as a potential upgrade dimension). NO aplica a reader advertising ni rear-display advertising.
Cualquier contradicción es MATERIAL.
Gate definición de red
Ninguna página confunde locations con screens con devices con pipeline con potential network.
Gate timeline de rollout
Paso 1
December 2026
Broad commercial rollout targeted
Paso 2
March 2027
Additional display deployment
Paso 3
April 2027
Approximately 770 completed locations targeted
Gate hardware
A1D / PPI Reader
11.6-inch
Rear Display
23.8-inch
Large-Format LOTOADS Display
43-inch
Buscar referencias obsolete '13-inch'. Donde aparezca '48-inch', confirmar contexto histórico/contractual, no spec default actual.
Gate evidencia
Cada claim material debe tener: evidencia directa O claramente etiquetado como assumption/target/pipeline.
Gate links de evidencia
0 material broken evidence links. Links rotos a archivos históricos menores pueden permanecer solo si están claramente identificados y no son relied upon.
Gate status comercial
Un prospect no puede aparecer como customer. Un pilot no puede aparecer como signed agreement.
Gate logos
Cada logo externo: ¿evidencia de relación? ¿status visible? ¿el inversor podría interpretarlo como endorsement/customer? Si es ambiguo, remover o clasificar.
Gate tecnología
Ninguna página convierte 'tested' en 'proven at scale' sin evidencia.
Gate seguridad tecnológica
Material técnico NO expone: credenciales, endpoints privados, security keys, detalles sensibles de arquitectura, vulnerabilidades explotables.
Gate legal/regulatorio
Para cada: scope claro, evidencia existe, wording no excede evidencia. Autorizaciones específicas no se usan como blanket approval.
Gate legal peñas
⚠ REQUIRES PRE-LAUNCH LEGAL REVIEW — no presentar modelled peñas economics como fully legally activated.
Gate payment/wallet
Data Room no implica que LOTOMIX: holds regulated customer funds, opera payment institution, opera unrestricted stored value — salvo que la estructura legal/técnica lo soporte.
Gate protección de datos
Privacy framework status, user data roles, processor relationships, ticket-image treatment, transaction data, communications data — documentados o identificados como requiriendo completion. No publicar 'Fully GDPR Compliant' sin soporte.
Gate ownership de IP
Statements sobre technology ownership soportados por: company ownership, developer assignments, contractor assignments, licences, repository control. Cualquier issue material sin resolver → 'IP REVIEW REQUIRED'.
Gate corporativo
Legal entity names, ownership, corporate chart, directors/administrators, cap table, operating-company roles consistent con documentación corporativa actual. No diagrams obsolete.
Gate cap table
Ownership percentages reconcilian, total reconcilia, share classes/instruments identificados. Cap table post-investment ilustrativo marcado:
ILLUSTRATIVE — SUBJECT TO FINAL TRANSACTION TERMSGate status de fundraising
No presentar como signed investor terms.
Gate use of funds
Cada amount sourced, categories reconcilian, total reconcilia al plan, no % inventados, subsidios potenciales separados.
Gate funding público
~€10,000 per administration = potential / target public support salvo aprobación formal. No aparece como cash garantizado en runway, closing cash, base liquidity o Use of Funds.
Gate downside
Investores acceden a downside view: rollout, fill, pricing/CPM, traffic, digital adoption, costs, cash/runway. Fluye a través del modelo. No texto genérico donde BC 6.7 soporta sensitivity cuantificada.
Gate risk register
Ningún risk material sin ownership.
Gate KPI
Ningún valor modelado aparece como actual performance.
Gate freshness de data
Todo KPI actual material: 'Data as of [date]' o 'Last Updated [date]'. No dar apariencia de live-dashboard con data vieja.
Gate versión de documento
No dos documentos conflictivos simultáneamente como CURRENT.
Gate documentos superseded
Old business cases, decks, rollout plans, technical specs, legal summaries no aparecen ahead de actuales.
SUPERSEDED — DO NOT USE FOR CURRENT ANALYSISGate landing page (3 minutos)
Si no, simplificar. No resolver con más texto.
Gate executive index
Items principales a 1-2 clicks. No file hunting manual.
Gate mobile
Landing, Executive Index, KPI cards, tablas, Evidence Map, navigation. Status labels, números, evidence links visibles.
Gate desktop
Clean, fast, readable, uncluttered. No excesivo empty space, no oversized decorative, no repeated explanations.
Gate access control
Standard investor no expone: personal IDs, bank details, KYC, sensitive privileged materials, internal QA registers, management-only controls.
Gate secciones internas
No exponer commentary interno a inversores.
Gate integridad de documento fuente
Ningún archivo firmado u original modificado para encajar la narrativa. Summaries interpretan; evidence original permanece sin cambios.
Gate search
Search prioriza material current/approved. Superseded claramente etiquetado.
Tests de revisor
Revisar el paquete desde múltiples perspectivas de inversor.
New Investor Test
Sophisticated Investor Test
Financial Reviewer Test
Technical Reviewer Test
Legal Reviewer Test
Michael Test
Oscar / Waterhouse Test
Conteo final de red flags
⚠ Requerido para 'Investor Package Ready for Release': Material Issues = 0.
2
Material Issues
⚠ NOT CLEAR
2
Important Issues
1
Financial Mismatches
⚠ NOT CLEAR
2
Narrative Conflicts
⚠ NOT CLEAR
0
Broken Evidence Links
✓ CLEAR
1
Legal Evidence Gaps
⚠ NOT CLEAR
0
Technology Evidence Gaps
✓ CLEAR
0
Version Conflicts
✓ CLEAR
0
Access-Control Issues
✓ CLEAR
Inventario final de documentos
LOTOMIX Investor Data Room — Release Snapshot
Release Date
— (pending approval)
Financial Model
BC 6.7
Investor Deck
Waterhouse V0.5 (pending upload)
Network Metrics
Current approved values
Rollout Plan
Current approved version
Material Documents
Current inventory
Open Disclosures
Audit pending; peñas legal review pending
Snapshot debe ser immutable o version-controlled donde sea técnicamente posible.
Revisión final de management
No marcar approved automáticamente.
⚠ NO AUTO-PUBLISH
Incluso cuando 'Investor Package Ready for Release' se logre: NO publicar. NO hacer el Data Room público. NO enviar notificaciones. NO cambiar permisos. Esperar instrucción explícita de management.
REVIEW → RECONCILE → VERIFY → SIGN OFF → READY FOR RELEASE → (solo tras instrucción explícita) PUBLISH
Resumen final de readiness
No arbitrary readiness score.
Principio final
El paquete solo se considera listo cuando:
El objetivo no es eliminar riesgo. El objetivo es que el inversor vea un caso de inversión coherente, soportado por evidencia, con supuestos visibles, milestones medibles y sin sorpresas evitables.
INTERNAL GOVERNANCE
Investor Questions Answered Tracker
A single source of truth for investor due diligence questions, management responses and supporting evidence.
QUESTION → OWNER → RESPONSE → EVIDENCE → APPROVAL → SEND → FOLLOW-UP → CLOSE
OPEN QUESTION DASHBOARD · INTERNAL
0
Open Questions
1
Responses in Preparation
1
Evidence Required
0
Follow-Ups
20
Answered
0
Closed
0
Superseded
CATEGORY DASHBOARD · OPEN BY WORKSTREAM
WATERHOUSE — CURRENT DD RESPONSE PACK
22
Total Material Questions
20
Answered
0
Follow-Up
1
Evidence Required
1
Open
This view assembles from the master tracker — no separate independent answer set is maintained.
MASTER Q&A TRACKER
| ID | Investor Question | Raised By | Date | Category | Status | Mat. | Data Room | Owner |
|---|---|---|---|---|---|---|---|---|
| WH-001 | What happens if advertising fill, traffic or rollout is materially below the current base case? | Michael | 2026-09-15 | Financial Model | ANSWERED | MAT | CFO | |
| WH-001A↳ WH-001 | What evidence supports the current advertising fill assumption? | Michael | 2026-09-18 | Advertising | ANSWERED | IMP | Commercial Lead | |
| WH-001B↳ WH-001 | What is the downside at 50% of base fill? | Michael | 2026-09-19 | Advertising | ANSWERED | MAT | CFO | |
| WH-002 | The deck / investment story contains too much information for a first-time investor. Can it be simplified? | Michael | 2026-09-16 | Governance | ANSWERED | IMP | IR | |
| WH-003 | Who pays in the LOTOMIX model and what revenue streams exist? | Oscar | 2026-09-10 | Revenue Model | ANSWERED | MAT | Commercial Lead | |
| WH-004 | How do peñas operate and what is the legal structure? | Oscar | 2026-09-10 | Peñas | EVIDENCE_REQUIRED | MAT | Legal | |
| WH-005 | What are the subscription tiers and how do they work? | Oscar | 2026-09-11 | App / Digital | RESPONSE_IN_PREPARATION | IMP | Product | |
| WH-006 | What is the difference between GTV and recognised revenue? | Oscar | 2026-09-11 | Revenue Model | ANSWERED | MAT | CFO | |
| WH-007 | How many units have been procured, installed, online, active and monetised? | Waterhouse | 2026-09-12 | Network | ANSWERED | MAT | Operations | |
| WH-008 | What is developed, what is currently operating, and what remains in development? | Waterhouse | 2026-09-12 | Technology | ANSWERED | MAT | CTO | |
| WH-009 | Does ticket validation work and is the backend demonstrable? | Waterhouse | 2026-09-12 | Technology | ANSWERED | IMP | CTO | |
| WH-010 | What is the FENAMIX 30% revenue share applied to? | Oscar | 2026-09-13 | Commercial | ANSWERED | MAT | Commercial Lead | |
| WH-011 | What does 370 mean and what does it not mean? | Waterhouse | 2026-09-13 | Rollout | ANSWERED | IMP | Operations | |
| WH-012 | What does 770 mean and how does it relate to 2,310 devices? | Waterhouse | 2026-09-13 | Rollout | ANSWERED | MAT | Operations | |
| WH-013 | What does 1,200+ mean — is it contracted? | Waterhouse | 2026-09-13 | Rollout | ANSWERED | IMP | Commercial Lead | |
| WH-014 | What does ~7,000 mean and is it deployed? | Waterhouse | 2026-09-14 | Network | ANSWERED | IMP | Commercial Lead | |
| WH-015 | What do the December 2026, March 2027 and April 2027 dates mean? | Waterhouse | 2026-09-14 | Rollout | ANSWERED | MAT | Operations | |
| WH-016 | What are the current hardware specifications? | Waterhouse | 2026-09-14 | Technology | ANSWERED | IMP | CTO | |
| WH-017 | Is public funding confirmed and at what level? | Waterhouse | 2026-09-15 | Funding | ANSWERED | IMP | CFO | |
| WH-018 | What is the current funding requirement and use of funds? | Waterhouse | 2026-09-15 | Use of Funds | ANSWERED | MAT | CFO | |
| WH-019 | What is the 3,370 figure and is it current? | Waterhouse | 2026-09-14 | Rollout | ANSWERED | IMP | Operations | |
| WH-020 | What is the pre-money valuation and is there a formal valuation in BC 6.7? | Waterhouse | 2026-09-15 | Financial Model | ANSWERED | MAT | CFO |
INVESTOR FOLLOW-UP COMMITMENTS
| Commitment | Investor | Owner | Status | Evidence | Date |
|---|---|---|---|---|---|
| Provide FENAMIX contract evidence | Waterhouse | Legal | EVIDENCE_REQUIRED | Contractual Access folder | 2026-09-15 |
| Add 50% fill downside scenario | Michael | CFO | OPEN | Driver Sensitivity | 2026-09-19 |
| Upload technical architecture diagram | Waterhouse | CTO | RESPONSE_IN_PREPARATION | Technology Readiness | 2026-09-12 |
| Confirm peñas legal structure | Oscar | Legal | EVIDENCE_REQUIRED | Regulatory & Legal Readiness | 2026-09-10 |
| Publish subscription tier pricing | Oscar | Product | RESPONSE_IN_PREPARATION | Revenue Quality | 2026-09-11 |
ANSWER CHANGE LOG
| Question ID | Previous Answer | New Answer | Reason | Date |
|---|---|---|---|---|
| WH-001 | v1.0 — Downside referenced generally | v1.1 — Linked to BC 6.7 driver-based sensitivity and Downside Survival | New BC 6.7 downside section added | 2026-09-20 |
| WH-007 | v1.0 — 370 described without device distinction | v1.1 — Clarified procured/installed/online/active/monetised distinction | Rollout Reconciliation updated | 2026-09-18 |
PRE-SEND CONTROL & CONFLICT DETECTION
Pre-Send Checklist
Automatic Conflict Detection
Any response citing a location number must match Rollout Reconciliation definitions.
Dec 2026 / Mar 2027 / Apr 2027 sequencing is canonical.
FENAMIX 30% applies only to large-format display economics.
GTV ≠ LOTOMIX recognised revenue.
Do not state legal positions beyond available evidence.
RESPONSE TEMPLATES
FACTUAL QUESTION
FORECAST QUESTION
LEGAL QUESTION
COMMERCIAL QUESTION
RECURRING INVESTOR QUESTIONS
Recommendation: Clarify in Investor Overview and FAQ
Recommendation: Reinforce in Revenue Quality
Recommendation: Maintain Rollout Reconciliation as canonical
DATA ROOM IMPROVEMENT TRIGGERS
INTERNAL CROSS-LINKS
Investor-facing exports should include only Question + Approved Response + Evidence where appropriate.
Do not publish internal comments. Do not maintain multiple conflicting approved answers. Do not answer financial questions from an outdated model.
Auditoría Final de Compresión del Data Room
Reducir la complecidad inversor sin eliminar profundidad analítica ni evidencia fuente. El objetivo no es borrar análisis útil, sino eliminar páginas redundantes, explicaciones duplicadas, resúmenes competidores y capas de navegación excesivas.
MENOS PÁGINAS
MAYOR PROFUNDIDAD
EVIDENCIA PRESERVADA
Informe de Compresión del Data Room LOTOMIX
49
Páginas revisadas
16
Mantener — Primarias
18
Mantener — Drill-down
5
Fusionadas
9
Quitadas de navegación inversor
9
Solo internas
All — no source documents affected
Documentos fuente preservados
5
Conflictos de navegación restantes
1 · Page Inventory
Inventario completo de cada página inversor con su pregunta principal, categoría, valor, solapamiento y acción recomendada.
| Page | Primary Question Answered | Category | Investor Value | Overlap | Recommended Action |
|---|---|---|---|---|---|
| Read Me First | How do I review this Data Room? | 01 Investment Overview | Orientation | Overlaps with Start Here hero | KEEP — PRIMARY |
| Investment Overview (Start Here) | What is the LOTOMIX investment case? | 01 Investment Overview | Primary entry point | Overlaps with Investor Summary, At a Glance | KEEP — PRIMARY |
| Investment Case at a Glance | 60-second IC dashboard? | 01 Investment Overview | Executive snapshot | Overlaps with Investor Summary One-Pager | KEEP — PRIMARY |
| Investor Summary One-Pager | Printable summary? | 01 Investment Overview | Printable / forwardable | Overlaps with At a Glance | KEEP — PRIMARY |
| Current State vs Future State | Where are we today vs plan? | 01 Investment Overview | Today vs plan comparison | Overlaps with Value Creation Bridge | KEEP — DRILL-DOWN |
| Investment Thesis Validation | What are the key assumptions and evidence? | 01 Investment Overview | IC analytical framework | Overlaps with Value Creation Bridge, Proof Progression | KEEP — PRIMARY |
| Value Creation Bridge | How does value build as execution progresses? | 01 Investment Overview | Value progression | Overlaps with Proof Progression, Current vs Future | MERGE → Value Creation & Proof Progression |
| Investment Case Proof Progression | How does evidence mature over time? | 01 Investment Overview | Proof maturity chain | Overlaps with Value Creation Bridge, Evidence Gap Plan | MERGE → Value Creation & Proof Progression |
| Value Creation Executive Version | Executive summary of value creation? | 01 Investment Overview | Executive table | Overlaps with Value Creation Bridge | KEEP — DRILL-DOWN |
| Executive Index (8 Doors) | Where is everything? | 01 Investment Overview | Navigation map | Unique — no overlap | KEEP — PRIMARY |
| How LOTOMIX Makes Money | How does the business monetise? | 02 Business & Economics | Revenue model overview | Overlaps with Revenue Quality, Unit Economics | KEEP — PRIMARY |
| Key Operating Metrics | What are the headline operating metrics? | 02 Business & Economics | Metric summary | Overlaps with KPI Cockpit, Unit Economics | KEEP — DRILL-DOWN |
| Unit Economics by Location | What does one location produce? | 02 Business & Economics | Core analytical page | Overlaps with Revenue Quality | KEEP — PRIMARY |
| Revenue Quality & Recurrence | How reliable is each revenue stream? | 02 Business & Economics | Revenue quality analysis | Overlaps with Business Model, Unit Economics | KEEP — DRILL-DOWN |
| Assumptions That Matter | Which drivers move the case? | 02 Business & Economics | Critical driver dashboard | Overlaps with Downside, Financial Reconciliation | KEEP — DRILL-DOWN |
| Rollout Reconciliation | What do 370 / 500 / 770 / 1,200+ / 7,000 mean? | 03 Network & Rollout | Canonical rollout interpretation | Unique — no overlap | KEEP — PRIMARY |
| Commercial Proof Traction | What commercial traction exists? | 03 Network & Rollout | Traction summary | Overlaps with Commercial Proof Section | MERGE → Commercial Proof & Traction |
| Funding → Milestones Bridge | How does capital convert to milestones? | 03 Network & Rollout | Capital-to-milestone mapping | Overlaps with Use of Funds | KEEP — DRILL-DOWN |
| First 100 Days Execution | What happens in the first 100 days? | 03 Network & Rollout | Post-investment management | Unique — no overlap | GOVERNANCE & QA |
| LotomiX Summary View (Financial Summary) | What are the headline financials? | 04 Financials & Funding | Financial summary | Overlaps with BC 6.7, At a Glance | KEEP — PRIMARY |
| Financials Section (BC 6.7) | What does BC 6.7 forecast? | 04 Financials & Funding | Canonical financial model | Unique — no overlap | KEEP — PRIMARY |
| Financial Model Reconciliation | Do all numbers reconcile to BC 6.7? | 04 Financials & Funding | Reconciliation governance | Overlaps with Assumptions That Matter | KEEP — DRILL-DOWN |
| Use of Funds & Capital Efficiency | How is the €3M deployed? | 04 Financials & Funding | Capital deployment | Overlaps with Funding → Milestones | KEEP — DRILL-DOWN |
| Downside Survival & Cash Protection | What happens if assumptions are weaker? | 04 Financials & Funding | Downside analysis | Overlaps with Assumptions That Matter, Driver Sensitivity | KEEP — PRIMARY (merge with Driver Sensitivity) |
| Investor KPI Cockpit | Are KPIs tracking to plan? | 04 Financials & Funding | Operating dashboard | Overlaps with Key Operating Metrics | KEEP — DRILL-DOWN |
| Investor Reporting Governance | How is investor reporting managed? | 04 Financials & Funding | Reporting framework | Unique — no overlap | GOVERNANCE & QA |
| Technology Readiness & Scalability | What technology exists and what remains? | 05 Technology & Product | Canonical tech readiness | Unique — no overlap | KEEP — PRIMARY |
| Assets & IP Section | What IP and assets exist? | 05 Technology & Product | Asset / IP inventory | Overlaps with Technology Readiness | KEEP — DRILL-DOWN |
| Sphere Acquisition Section | What is the Sphere acquisition? | 05 Technology & Product | Acquisition detail | Unique — no overlap | KEEP — DRILL-DOWN |
| Commercial Proof Section | What commercial evidence exists? | 06 Commercial Traction | Canonical commercial proof | Overlaps with Commercial Proof Traction | MERGE → Commercial Proof & Traction |
| Ad Network Section | How does the ad network work? | 06 Commercial Traction | Ad network overview | Unique — no overlap | KEEP — DRILL-DOWN |
| Regulatory & Legal Readiness | What legal dependencies remain? | 07 Legal & Corporate | Canonical legal readiness | Unique — no overlap | KEEP — PRIMARY |
| Contractual Access Section (FENAMIX) | What is the FENAMIX relationship? | 07 Legal & Corporate | Contractual access | Unique — no overlap | KEEP — DRILL-DOWN |
| Deal Readiness & Closing Checklist | What is needed to close? | 07 Legal & Corporate | Closing checklist | Unique — no overlap | KEEP — DRILL-DOWN |
| Institutional Risk Register | What are the principal risks? | 07 Legal & Corporate | Risk register | Overlaps with Risks & Diligence | KEEP — DRILL-DOWN |
| Risks & Diligence Section | What are the risks? | 07 Legal & Corporate | Risk overview | Overlaps with Institutional Risk Register | MERGE → Institutional Risk Register |
| Investment Evidence Map | Where is the evidence for each claim? | 08 Evidence & Full Data Room | Canonical evidence map | Unique — no overlap | KEEP — PRIMARY |
| Evidence Gap Closure Plan | What evidence is still missing? | 08 Evidence & Full Data Room | Gap analysis | Overlaps with Proof Progression | KEEP — DRILL-DOWN |
| Data Room Section (Full Data Room) | Where are the source documents? | 08 Evidence & Full Data Room | Source repository | Unique — no overlap | KEEP — PRIMARY |
| Data Integrity & Version Control | Is the data controlled? | 08 Evidence & Full Data Room | Version control | Unique — no overlap | GOVERNANCE & QA |
| LotomiX Missing Files Diagnostic | Which files are missing? | 08 Evidence & Full Data Room | File diagnostic | Unique — no overlap | GOVERNANCE & QA |
| Investor IC Questions | What are the IC questions and answers? | 08 Evidence & Full Data Room | IC Q&A | Overlaps with Team QA | KEEP — PRIMARY |
| Team & QA Section | Who is the team and how to ask? | 07 Legal & Corporate | Team + communication | Unique — no overlap | KEEP — DRILL-DOWN |
| Valuation & Exit Section | What are the exit pathways? | 04 Financials & Funding | Exit analysis | Unique — no overlap | KEEP — DRILL-DOWN |
| Red Flag & Open Issues Register | What issues remain open? | 08 Governance & DD | Issue tracking | Unique — no overlap | GOVERNANCE & QA |
| Final Investor Narrative Consistency Audit | Is the narrative consistent? | 08 Governance & DD | Narrative audit | Unique — no overlap | GOVERNANCE & QA |
| Final Pre-Launch Investor Readiness Gate | What is the release readiness status? | 08 Governance & DD | Readiness gate | Unique — no overlap | GOVERNANCE & QA |
| Investor Questions Answered Tracker | Which investor questions are answered? | 08 Governance & DD | Q&A tracker | Overlaps with IC Questions | GOVERNANCE & QA |
| Final Data Room Compression Audit | Is the Data Room over-complex? | 08 Governance & DD | Compression audit | This page | GOVERNANCE & QA |
2 · Overlap Analysis & Compression Map
Pares de páginas que responden la misma pregunta y mapa de consolidación antes/después.
Page Overlap Flags
Value Creation Bridge ↔ Proof Progression
MERGEBoth describe how evidence matures as execution progresses.
Recommendation: MERGE into 'Value Creation & Proof Progression' with subsections.
Commercial Proof Section ↔ Commercial Proof Traction
MERGEBoth answer 'what commercial evidence exists?'.
Recommendation: MERGE into 'Commercial Proof & Traction' with subsections.
Downside Survival ↔ Driver Sensitivity (Investor Overview drill-down)
MERGEBoth address weaker operating assumptions.
Recommendation: MERGE into 'Downside & Resilience' with two subsections: A. Financial Sensitivity, B. Management Response.
Risks & Diligence Section ↔ Institutional Risk Register
MERGEBoth catalogue principal risks.
Recommendation: MERGE into Institutional Risk Register as canonical; Risks & Diligence becomes drill-down.
Funding → Milestones Bridge ↔ Use of Funds & Capital Efficiency
CONSOLIDATEBoth explain how €3M converts to execution.
Recommendation: Consolidate under 'Funding & Capital Deployment' with subsections; keep both analytical concepts.
Investment Case at a Glance ↔ Investor Summary One-Pager
KEEP BOTHBoth provide a single-screen executive summary.
Recommendation: Keep both — distinct roles (60-second dashboard vs printable document).
Key Operating Metrics ↔ Investor KPI Cockpit
DRILL-DOWNBoth show headline operating KPIs.
Recommendation: Key Operating Metrics becomes drill-down of KPI Cockpit.
Investor IC Questions ↔ Investor Questions Answered Tracker
SEPARATEBoth track investor questions.
Recommendation: IC Questions = investor-facing; Tracker = internal-only.
Compression Map (Before → After)
| Current Page | Final Destination | Action |
|---|---|---|
| Value Creation Bridge | → Value Creation & Proof Progression | MERGE |
| Investment Case Proof Progression | → Value Creation & Proof Progression | MERGE |
| Commercial Proof Section | → Commercial Proof & Traction | MERGE |
| Commercial Proof Traction | → Commercial Proof & Traction | MERGE |
| Risks & Diligence Section | → Institutional Risk Register | MERGE (drill-down) |
| Key Operating Metrics | → Investor KPI Cockpit | DRILL-DOWN |
| Current State vs Future State | → Investment Overview (drill-down) | DRILL-DOWN |
| Value Creation Executive Version | → Value Creation & Proof Progression | DRILL-DOWN |
| First 100 Days Execution | → Internal-only management view | REMOVE FROM INVESTOR NAV |
| Investor Reporting Governance | → Internal-only governance | REMOVE FROM INVESTOR NAV |
| Data Integrity & Version Control | → Internal-only governance | REMOVE FROM INVESTOR NAV |
| LotomiX Missing Files Diagnostic | → Internal-only governance | REMOVE FROM INVESTOR NAV |
| Red Flag & Open Issues Register | → Governance & QA | GOVERNANCE & QA |
| Final Investor Narrative Consistency Audit | → Governance & QA | GOVERNANCE & QA |
| Final Pre-Launch Investor Readiness Gate | → Governance & QA | GOVERNANCE & QA |
| Investor Questions Answered Tracker | → Governance & QA | GOVERNANCE & QA |
| Financial Model Reconciliation | → Financials (drill-down) | DRILL-DOWN |
| Funding → Milestones Bridge | → Funding & Capital Deployment (subsection) | CONSOLIDATE |
| Use of Funds & Capital Efficiency | → Funding & Capital Deployment (subsection) | CONSOLIDATE |
3 · Architecture, Canonicals & Protections
Arquitectura de 8 puertas, páginas canónicas, fuentes canónicas, auditoría de clicks y distinciones protegidas.
Protected Eight-Door Architecture
01
Investment Overview
Target: 5–7 pages
02
Business & Economics
Target: 3–5 pages
03
Network & Rollout
Target: 3–4 pages
04
Financials & Funding
Target: 4–6 pages
05
Technology & Product
Target: 3–5 pages
06
Commercial Traction
Target: 2–4 pages
07
Legal & Corporate
Target: 3–5 pages
08
Evidence & Full Data Room
Target: Source layer — no artificial reduction pages
Canonical Investor Page Tags
Rollout
Rollout Reconciliation
Financial Model
BC 6.7 (Financials Section)
Technology
Technology Readiness & Scalability
Commercial
Commercial Proof & Traction
Legal
Regulatory & Legal Readiness
Evidence
Investment Evidence Map
Unit Economics
Unit Economics by Location
Downside
Downside & Resilience
Investment Case
Investment Overview
Funding
Funding & Capital Deployment
Canonical Source Tags
| Source | Location | Status |
|---|---|---|
| FENAMIX Agreement | Data Room — Contractual Access / Folder 12 | Executed |
| BC 6.7 Financial Model | Financials Section | Current |
| Current Hardware Specification | Technology Readiness / Assets & IP | Current |
| Current Rollout Plan | Rollout Reconciliation | Current |
| Current Cap Table | Deal Readiness / Corporate Structure | Current |
Investor Click-Depth Audit
| Destination | Current Clicks | Target | Status |
|---|---|---|---|
| BC 6.7 | 2 (Overview → Financials tab → BC 6.7) | 1–2 | OK |
| Unit Economics | 2 (Overview → Full Data Room → Unit Economics) | 1–2 | OK |
| Downside | 2 (Overview → Full Data Room → Downside) | 1–2 | OK |
| FENAMIX Agreement | 2 (Overview → Contractual Access → Folder 12) | 1–2 | OK |
| Rollout Evidence | 2 (Overview → Rollout Reconciliation) | 1–2 | OK |
| Technology Readiness | 2 (Overview → Full Data Room → Technology) | 1–2 | OK |
| Legal Readiness | 2 (Overview → Full Data Room → Legal) | 1–2 | OK |
Protected Distinctions (Must NOT Be Compressed Away)
Must-Keep Pages (Final Control)
CONTROL FINAL — No borrar evidencia. No borrar documentos fuente históricos. No eliminar BC 6.7. No eliminar downside. No eliminar Unit Economics. No eliminar Rollout Reconciliation. No eliminar Technology Readiness. No eliminar Commercial Proof. No eliminar Legal Readiness. No fusionar temas solo para reducir el conteo de páginas si las preguntas del inversor son materialmente diferentes. El principio de compresión: ELIMINAR DUPLICACIÓN · PRESERVAR DISTINCIONES · OCULTAR COMPLEJIDAD INTERNA · PROTEGER EVIDENCIA · SIMPLIFICAR NAVEGACIÓN.
PRUEBA FINAL DEL INVERSOR: Si Michael entra al Data Room ahora, ¿sabe inmediatamente a dónde ir sin ver la complejidad de todo el trabajo realizado debajo? La respuesta debería ser sí.
Jerarquía Final de la Historia de Inversión
Controlar lo que un inversor ve en los primeros 10 segundos, primer minuto, primeros 3 minutos y due diligence profundo. El propósito NO es crear nuevo contenido — es controlar el orden, la densidad y el momento de la información.
Divulgación progresiva: el inversor no debe recibir información financiera, legal, técnica o comercial detallada antes de entender el caso básico de inversión.
1 · The Core Journey — Progressive Disclosure
El sistema debe revelar información progresivamente, no presentar todo simultáneamente.
10 SECONDS
ORIENT
What is LOTOMIX? · What already exists? · What is the immediate opportunity?
MAX: 1 headline + 1 sentence + 5 metrics + 1 CTA
60 SECONDS
UNDERSTAND
What exists today? · How does LOTOMIX make money? · Why is capital required now? · What happens next?
MAX: 4 core blocks · 3–5 points per block
3 MINUTES
ASSESS
Thesis? · Assumptions? · What must be proven? · What if execution is weaker? · Where is evidence?
MAX: ~7 short analytical sections
DEEP DIVE
TEST
The investor chooses which area to deepen.
MAX: Unlimited depth where justified
EVIDENCE
VERIFY
Executed contracts · spreadsheets · installation inventories · technical reports · legal documents.
MAX: Raw models / source documents
10 SECONDS — ORIENTATION
LOTOMIX
Technology, digital media and consumer services integrated into Spain's mixed-lottery retail environment.
~370
Existing reader footprint
DEPLOYED1,200+
Rollout / expressed-interest pipeline
PIPELINE~7,000
Potential FENAMIX network perimeter
NETWORK ACCESS~770
Completed-location target by April 2027
MANAGEMENT TARGET€3M
Current financing reference
FUNDRAISINGStart 3-Minute Investment Review →
10-Second Investor Interpretation
✓ There is already a physical and contractual foundation.
✓ There is additional rollout demand.
✓ Capital is being raised to move into broader commercial scale.
If the investor cannot understand this immediately, simplify further — do not add more content.
2 · Layer Specifications
Qué responde cada capa y qué contenido pertenece a cada nivel.
60-Second Layer — Four Core Blocks
Answers: what exists today · how LOTOMIX makes money · why capital is required now · what happens next.
BLOCK A
Existing Foundation
Use evidence-status labels. Do not introduce future revenue forecasts.
BLOCK B
Business Model
Do not show detailed formulas yet.
BLOCK C
Capital Logic
One short explanation: the current financing converts existing infrastructure, technology and rollout demand into broader commercial deployment and measurable economics.
BLOCK D
Next Milestones
Do not introduce 2028–2029 at this stage.
3-Minute Layer — Seven Analytical Sections
Answers: thesis · assumptions · what must be proven · downside · evidence.
Section A — Investment Thesis
~5 points. No long paragraphs.
Section B — What Exists vs What Remains
Two columns. Prevents future-state blending with current reality.
Section C — Unit Economic Logic
Explore Unit Economics →Do not show the full model. CTA: Explore Unit Economics →
Section D — Assumptions That Matter
Test Critical Drivers →Six critical variables only. CTA: Test Critical Drivers →
Section E — What Must Be Proven
Five questions. Enough.
Section F — Downside
Test the Downside →One compact statement. No full sensitivity table in first 3 minutes. CTA: Test the Downside →
Section G — Evidence
Verify the Investment Case →CTA: Verify the Investment Case → routes to Investment Evidence Map.
Deep Dive Layer — Six Analytical Groups
The investor chooses which area to deepen. Unlimited depth where justified.
Business & Economics
Network & Rollout
Financials
Technology
Commercial
Legal
3 · Information Density & Detail Controls
Reglas máximas de densidad, longitud de texto, complejidad de gráficos y control de detalle por tema y capa.
Maximum Density Rules by Layer
10-Second
1 headline + 1 sentence + 5 metrics + 1 CTA
60-Second
4 core blocks · 3–5 points per block
3-Minute
~7 short analytical sections
Deep Dive
Unlimited depth where justified
Evidence
Raw models / source documents
Text Length Guidance
| Element | Guidance |
|---|---|
| Hero | 1 sentence |
| Metric description | 3–7 words |
| Card description | 1–2 sentences |
| Investment Overview paragraphs | 2–4 lines maximum |
| Long-form explanation | Belongs deeper |
Chart Complexity by Level
Detail Control by Topic × Layer
| Topic | 10s | 60s | 3min | Deep Dive | Evidence |
|---|---|---|---|---|---|
| Financial | €3M current financing reference only — no forecast P&L | Main capital purposes only | Business-driver logic | Revenue forecasts, EBITDA, cash, sensitivities, unit economics | BC 6.7 |
| Risk | — | No full risk register | What must be proven + what if execution is weaker | Full risk register, downside, mitigation, cash protection | — |
| Legal | — | — | Legal / regulatory evidence available + link | Legal Readiness Matrix, payments, peñas, data protection, contracts | Source documents |
| Technology | — | Core platform developed / testing (where supported) | Developed ≠ proven at scale + link | Architecture, scale, security, device management, technical testing | Architecture / tests / technical documentation |
| Commercial | — | Rollout pipeline / commercial infrastructure (where relevant) | Commercial activation, revenue model, what must be validated | Counterparties, campaign status, sales funnel, pilots, commercial evidence | — |
| Long-Term Vision | Do not introduce 3,370 by 2029 | — | — | Network Scale Opportunity | — |
| Market Size (TAM) | No TAM in first 10 seconds | — | Only if useful | Business Deep Dive | — |
| Management Biographies | No biographies | — | Business and investment logic, not biographies | Corporate / Team | — |
Principle: financial complexity must not dominate before business comprehension. Risks must not lead before the opportunity. Legal and technology complexity must be disclosed at the appropriate maturity level without overwhelming the initial story.
4 · Content Priority Tags & Progression
Clasificación P0–P4, ejemplos de divulgación progresiva, control de personas y navegación.
Content Priority Tags (Internal Classification)
10-SECOND ESSENTIAL
Hero headline, supporting sentence, 5 metrics, 1 CTA only.
60-SECOND ESSENTIAL
4 core blocks: foundation, model, capital, milestones.
3-MINUTE ESSENTIAL
~7 short analytical sections: thesis, today/executed, economics, assumptions, proof, downside, evidence.
DEEP DIVE
Unlimited analytical depth where justified.
SOURCE / EVIDENCE
Raw models, executed contracts, source documents.
Progressive Disclosure Examples
A core fact may appear at multiple levels, but detail increases progressively. Each level adds depth — do not repeat identical paragraphs.
Financial
10 SECONDS
€3M financing
60 SECONDS
What the capital supports
3 MINUTES
Funding → milestones
DEEP DIVE
Use of Funds / cash / sensitivities
EVIDENCE
BC 6.7
Rollout
10 SECONDS
~370 current / ~770 target
60 SECONDS
December / March / April milestones
3 MINUTES
Explain pipeline / rollout
DEEP DIVE
Rollout Reconciliation
EVIDENCE
Location / deployment data
Technology
10 SECONDS
Core platform developed / testing
3 MINUTES
What is built vs what remains
DEEP DIVE
Technology Readiness
EVIDENCE
Architecture / tests / technical documentation
Investor Persona Control
Partner / IC Member
Entry: P0 / P1
Likely starts at orientation + 60-second dashboard.
Analyst
Entry: P2 / P3
Continues to 3-minute + deep dive.
Financial DD
Entry: P3 / P4
Moves quickly to financials + BC 6.7.
Technical DD
Entry: Technology P3 / P4
Moves to technology deep dive + evidence.
Legal DD
Entry: Legal P3 / P4
Moves to legal deep dive + source documents.
Skip-To Navigation (Specialist Reviewers)
First-time investors should still see "Start Here" prominently. Do not force specialists through every summary layer.
Executive Surfaces (Only These)
Tooltip / Expand Pattern
~370 Existing Readers
↳ Existing A1D / PPI reader footprint; not equivalent to 370 completed three-screen locations.
Preserves accuracy without clutter.
Skepticism Path (3-Minute)
A skeptical investor can challenge the case immediately.
Retention Test (After 3 Min)
Do not expect 25 metrics. Reinforce only the few that matter.
Priority Evidence — Strong Source Traceability Required in P0 / P1
5 · Final Investment Story
FIRST 10 SECONDS
LOTOMIX already has a real foundation and is raising €3M to scale.
FIRST MINUTE
The foundation consists of network access, deployed readers, developed technology and rollout demand; monetisation comes through media, SaaS and digital economics.
FIRST 3 MINUTES
The investment depends on rollout conversion, advertising economics, digital adoption and disciplined capital deployment, all of which are measurable and stress-tested.
DEEP DIVE
The investor can challenge each assumption independently.
EVIDENCE
The investor can verify the underlying facts directly.
Investment Story Hierarchy Audit
No arbitrary quality score. Counts only.
9
P0 Content Blocks
10
P1 Content Blocks
9
P2 Content Blocks
28
P3 Analytical Pages
7
P4 Source / Evidence
10
Hierarchy Violations
5
Duplicated Executive Content
1
Buried Core Facts
7
Excessive Above-the-Fold Content
Hierarchy Violations — INFORMATION HIERARCHY VIOLATION
Eight Doors in P0 area
Navigation map displayed in the 10-second hero. Should be P1 navigation.
Fix: Move below the hero or into Read Me First.
What Exists Today block in P0
Foundation detail shown before orientation.
Fix: Move to 60-second Block A.
What the Capital Unlocks in P0
Capital logic shown before business model.
Fix: Move to 60-second Block C.
Next Milestones in P0
Milestone detail shown in hero.
Fix: Move to 60-second Block D.
What Must Be Proven in P0
Proof questions shown before thesis.
Fix: Move to 3-minute Section E.
Verify the Case evidence strip in P0
Evidence categories shown in hero.
Fix: Move to 3-minute Section G.
Investor Modes in P0
First-time vs returning paths shown in hero.
Fix: Move to P1 navigation or Read Me First.
Driver Sensitivity drill-down in P0
Full sensitivity table accessible from hero.
Fix: Move to Deep Dive / Downside.
Exit Pathways drill-down in P0
M&A precedents accessible from hero.
Fix: Move to Deep Dive / Valuation & Exit.
Detailed disclaimers in hero
Long disclaimer text in the opening screen.
Fix: Condense to a single status line; move detail deeper.
Duplicated Executive Content
Investment Case at a Glance ↔ Investor Summary One-Pager
Both single-screen executive summaries. Keep both — distinct roles (60s dashboard vs printable).
Value Creation Bridge ↔ Proof Progression ↔ Value Creation Executive Version
Three executive summaries of value creation. Consolidate to one.
LotomiX Summary View ↔ Financial Summary ↔ At a Glance financials
Multiple financial summary surfaces. Designate one canonical.
Current vs Future State ↔ Today vs To Be Executed
Two today/future comparisons. Consolidate into 3-minute Section B.
Investor Overview hero ↔ Investment Overview narrative
Two overlapping 'start here' surfaces. Merge into one P0/P1 flow.
Buried Core Facts — CORE INVESTMENT FACT BURIED
Developed ≠ proven at scale distinction
Location: Currently in Technology Readiness (P3) only
Fix: Surface the distinction at 3-minute Section B (Today vs To Be Executed).
Excessive Above-the-Fold Content
P0 maximum is 1 headline + 1 sentence + 5 metrics + 1 CTA. Move all other blocks to P1 / P2.
Final Control
✗ Do not create new investor facts.
✗ Do not create new financial assumptions.
✗ Do not remove required evidence.
✗ Do not hide downside.
✗ Do not hide status classification.
✗ Do not place deep due diligence content in the opening experience.
✗ Do not force specialist reviewers through unnecessary introductory pages.
La jerarquía final de información debe seguir:
10 SECONDS — ORIENT ↓ 60 SECONDS — UNDERSTAND ↓ 3 MINUTES — ASSESS ↓ DEEP DIVE — TEST ↓ EVIDENCE — VERIFY
Esta es la aplicación final del principio de simplificación solicitado durante la revisión de Waterhouse.
LOTOMIX Investor Data Room — Release Candidate
El Release Candidate congela el paquete inversor actual en una versión de revisión controlada. El estado de readiness interno de LOTOMIX no constituye aprobación de Waterhouse ni verificación independiente.
RELEASE CANDIDATE RC1
Una historia de inversión congelada · Un modelo financiero controlado · Una interpretación de despliegue · Un conjunto de definiciones de estado · Una arquitectura de evidencia · Un sistema de navegación inversor.
Part I — Release Candidate Identity & Core Freezes
Identidad de RC1, narrativa, métricas, cronología, hardware, FENAMIX, modelo financiero, fundraising y clasificaciones de estado.
1 · Release Candidate Identity
RELEASE CANDIDATE ID
RC1
CREATION DATE
2026-10-01
CURRENT INVESTOR DECK
Waterhouse Investor Deck V.05
CURRENT FINANCIAL MODEL
BC 6.7
CURRENT ROLLOUT PLAN
BC 6.7 Rollout Plan
DATA CUT-OFF
2026-10-01
DOCUMENT CUT-OFF
2026-10-01
DECK CUT-OFF
Waterhouse Investor Deck V.05 · September 2026
NAVIGATION VERSION
8-Door Investor Architecture + Understand → Test → Verify
EVIDENCE INVENTORY
Priority Evidence Pack + Full Data Room (Folders 00–99)
2 · Frozen Investor Narrative
Do not allow silent narrative changes after freeze. Any material edit must be logged as an RC change.
What LOTOMIX is
Technology, digital media and consumer services integrated into Spain's mixed-lottery retail environment.
What exists today
FENAMIX relationship, ~370 existing readers, developed platform, ticket-validation/administration materially developed, 1,200+ rollout pipeline.
What is pipeline
1,200+ expressed-interest rollout pipeline — not contracted locations.
What is modelled
BC 6.7 management forecast — not audited, not actual results.
What is targeted
~770 completed locations by April 2027 (management target); 3,370 longer-term (management target).
What €3M unlocks
Converts existing infrastructure, technology and rollout demand into broader commercial deployment and measurable economics.
What happens next
Dec 2026 broad rollout · Mar 2027 additional displays · Apr 2027 ~770 completed locations.
What remains to be proven
Pipeline conversion, advertising fill/pricing, unit economics validation, digital adoption, scale within capital envelope.
3 · Frozen Canonical Network Metrics
| Metric | RC1 Value | Classification | Source |
|---|---|---|---|
| Potential FENAMIX network perimeter | ~7,000 | NETWORK ACCESS | FENAMIX relationship |
| Existing reader footprint | ~370 | DEPLOYED | Source documentation |
| Current rollout / expressed-interest pipeline | 1,200+ | PIPELINE | Management |
| Initial reference / deployment case | 500 | REFERENCE | BC 6.7 |
| Completed-location management target by April 2027 | ~770 | MANAGEMENT TARGET | BC 6.7 |
| Longer-term management target | 3,370 | MANAGEMENT TARGET | BC 6.7 |
Any later change requires a NETWORK METRIC CHANGE REQUEST (previous value, new value, source, reason, affected pages).
4 · Frozen Rollout Timeline
December 2026
Broad commercial rollout target
MANAGEMENT TARGETMarch 2027
Additional display deployment
MANAGEMENT TARGETApril 2027
~770 completed locations targeted
MANAGEMENT TARGETLater changes preserve the original RC timeline and create UPDATED CURRENT EXPECTATION rather than rewriting the historical RC.
5 · Frozen Hardware Specifications
Reader
11.6-inch
No 13-inch reader references in current investor-facing generated content.
Rear Display
23.8-inch
Canonical rear display specification.
Large-Format Display
43-inch (current commercial)
Preserve legitimate historical/contractual 48-inch references in source documents.
6 · Frozen FENAMIX Economic Treatment
The 30% FENAMIX share applies to large-format 43"/48" advertising revenue only.
APPLIES TO
✓ Large-format 43-inch display advertising
✓ Historical/contractual 48-inch display advertising
DOES NOT APPLY TO
✗ Reader advertising
✗ Rear-display advertising
Deviation flag: MATERIAL COMMERCIAL RECONCILIATION REQUIRED
7 · Frozen Financial Model
BC 6.7
CURRENT PRINCIPAL FINANCIAL MODEL FOR RC1
Prohibited: Prior BC versions (BC 6.3, BC 6.4, BC 6.6), Experimental calculations, Alternative unpublished models
If a later model is formally approved, create RC2 — do not silently replace BC 6.7 within RC1.
8 · Frozen Fundraising Reference
€3M
Pre-money: €12M–€15M
CURRENT FUNDRAISING PARAMETERS
Not: AGREED TRANSACTION TERMS
If transaction terms change materially, generate a new RC.
9 · Frozen Status Classifications
Do not allow status changes after RC freeze without source, effective date and change log.
Part II — Status, Maturity & Navigation Freezes
Contrapartes comerciales, madurez tecnológica, estado legal, navegación y superficies ejecutivas.
10 · Frozen Commercial Counterparty Status
| Counterparty | Classification | Note |
|---|---|---|
| FENAMIX | CONTRACTED | Executed agreement — network access relationship. |
| Fundación SEUR | LIVE | 370-location national DOOH campaign executed. |
| Rollout pipeline (1,200+) | PIPELINE | Expressed-interest locations — not contracted. |
| Advertiser counterparties | PIPELINE | No external logo implies stronger relationship than RC1 evidence supports. |
11 · Frozen Technology Maturity
Core platform
Developed ≠ proven at scale.
Ticket validation / administration
Materially developed.
Reader / PPI devices
~370 existing footprint.
Scale validation
Do not allow TESTED to become PROVEN AT SCALE without new evidence.
Do not allow TESTED to become PROVEN AT SCALE without new evidence and a controlled change.
12 · Frozen Legal Status
13 · Frozen Navigation
8-Door Investor Architecture
Cross-link: Understand → Test → Verify
After freeze, do not introduce new top-level categories, new executive summary pages, or major navigation changes without an RC change record.
14 · Frozen Investor Executive Surfaces
Read Me First
30-second orientation
Investment Case at a Glance
60-second dashboard
3-Minute Investment Overview
Complete executive investment narrative
Investor Summary One-Pager
Printable / forwardable version
Do not add additional competing executive summaries after RC freeze without management review.
Part III — RC Manifests
Manifiestos de documentos fuente, documentos, métricas, claims y evidencia.
15 · Source Document References
| Source ID | Filename | Version / Date | Status |
|---|---|---|---|
| BC67 | BC 6.7 Financial Model | BC 6.7 | CURRENT |
| FENAMIX | FENAMIX Agreement | Executed | EXECUTED |
| ROLLOUT | BC 6.7 Rollout Plan | BC 6.7 | CURRENT |
| HW-SPEC | Hardware Specification | Current | CURRENT |
| DEPLOY | Deployment Evidence | Current | CURRENT |
| TECH | Technical Evidence | Current | CURRENT |
| CORP | Corporate Documents | Current | CURRENT |
| LEGAL | Legal Evidence | Current | CURRENT |
| COMM | Commercial Evidence | Current | CURRENT |
16 · RC Document Manifest
Investor Pages
Read Me First · Investment Overview · Investment Case at a Glance · Investor Summary One-Pager · Executive Index · Full Data Room sections
Current Models
BC 6.7 Financial Model
Executed Agreements
FENAMIX Agreement
Evidence
Deployment evidence · Technical evidence · Commercial evidence · SEUR campaign report
Restricted Documents
KYC · Banking · Cap table detail
Historical / Superseded
BC 6.3 · BC 6.4 · BC 6.6 · V.04 deck
17 · RC Metric Manifest
| Metric | RC1 Value | Classification | Source | As-of |
|---|---|---|---|---|
| Network perimeter | ~7,000 | NETWORK ACCESS | FENAMIX | 2026-10-01 |
| Existing footprint | ~370 | DEPLOYED | Source docs | 2026-10-01 |
| Pipeline | 1,200+ | PIPELINE | Management | 2026-10-01 |
| Rollout target | ~770 | MANAGEMENT TARGET | BC 6.7 | 2026-10-01 |
| Long-term target | 3,370 | MANAGEMENT TARGET | BC 6.7 | 2026-10-01 |
| Funding amount | €3M | FUNDRAISING | Management | 2026-10-01 |
| Pre-money | €12M–€15M | FUNDRAISING | Management | 2026-10-01 |
| Reader spec | 11.6-inch | HARDWARE | HW-SPEC | 2026-10-01 |
| Rear display spec | 23.8-inch | HARDWARE | HW-SPEC | 2026-10-01 |
| Large-format spec | 43-inch | HARDWARE | HW-SPEC | 2026-10-01 |
| FENAMIX share | 30% | COMMERCIAL | FENAMIX | 2026-10-01 |
18 · RC Claim Manifest
| Claim | RC1 Wording | Status | Evidence |
|---|---|---|---|
| Network access | FENAMIX relationship provides access to ~7,000-location network perimeter | CONTRACTED | FENAMIX Agreement |
| Existing deployment | ~370 existing reader footprint deployed | DEPLOYED | Source documentation |
| Technology | Core platform developed; ticket-validation materially developed | DEVELOPED | Technical evidence |
| Pipeline | 1,200+ expressed-interest rollout pipeline | PIPELINE | Management |
| Commercial rollout | ~770 completed locations targeted by April 2027 | MANAGEMENT TARGET | BC 6.7 |
| Revenue model | Media + SaaS + Transactions + Digital monetisation | MODELLED | BC 6.7 |
| Funding | €3M current financing reference | FUNDRAISING | Management |
| Defensibility | Specialised network position, deployed infrastructure, developed technology | MANAGEMENT | Investment thesis |
| Legal status | Feature-specific legal readiness — not generalised | MIXED | Legal evidence |
19 · RC Evidence Manifest
| Claim / Topic | Evidence Link | Status | Access |
|---|---|---|---|
| Network access | Contractual Access / Folder 12 | EXECUTED | Restricted |
| Existing deployment | Deployment Evidence | CURRENT | Investor |
| Technology | Technology Readiness / Technical Evidence | CURRENT | Investor |
| Pipeline | Rollout Reconciliation | CURRENT | Investor |
| Commercial rollout | Commercial Proof / Rollout | CURRENT | Investor |
| Revenue model | BC 6.7 / Financials | CURRENT | Investor |
| Funding | Use of Funds / Investment Terms | CURRENT | Investor |
| Legal | Legal Readiness / Material Contracts | MIXED | Restricted |
No material RC1 claim should remain UNCLASSIFIED — every claim has supporting evidence or a clear forward-looking / model classification.
Part IV — Reviews, Walkthroughs & Simulations
Link check, control de acceso, simulación de vista inversor, walkthroughs y simulaciones de revisión.
20 · RC Link Check
0
Broken Investor Links (material)
0
Broken Evidence Links (material)
Required: 0 material broken links. Any failure becomes an RC issue.
21 · RC Access-Control Check
| Role | KYC | Banking | Internal QA | Source Docs |
|---|---|---|---|---|
| Standard Investor | Restricted | Restricted | Hidden | Authorized only |
| Detailed DD Reviewer | Restricted | Restricted | Hidden | Authorized |
| Restricted Legal / Transaction | Authorized | Authorized | Hidden | Authorized |
| Management | Authorized | Authorized | Visible | Authorized |
22 · Investor View Simulation
Review RC1 while logged in as a normal investor — NOT only from management / admin mode.
• What does the investor actually see?
• Which sections are unavailable?
• Are status labels visible?
• Are restricted links handled correctly?
• Is navigation intuitive?
The management view may hide investor-facing problems.
23–25 · Walkthroughs
First-Time Investor Walkthrough
Checks: Confusion · Duplication · Dead ends · Missing context
Issue type: RC INVESTOR JOURNEY ISSUE
Michael (Waterhouse) Review Walkthrough
Checks: Opening complexity · Hidden drivers · Missing downside · Overloaded deck
Issue type: RC WATERHOUSE REVIEW ISSUE
Oscar (Deck Alignment) Walkthrough
Checks: Narrative mismatch · Metric mismatch · Competing story
Issue type: RC DECK ALIGNMENT ISSUE
26–29 · Review Simulations
Financial Review Simulation
Issue: RC FINANCIAL REVIEW ISSUE
Technical Review Simulation
Issue: RC TECHNICAL REVIEW ISSUE
Legal Review Simulation
Issue: RC LEGAL REVIEW ISSUE
Commercial Review Simulation
Issue: RC COMMERCIAL REVIEW ISSUE
Part V — Issue Log, Summary & Final Controls
Log de issues, fixes menores vs materiales, resumen RC, revisión de dirección, divulgaciones aceptadas y controles finales.
30 · RC Issue Log
| RC Issue | Category | Materiality | Required Fix | Owner | Status |
|---|---|---|---|---|---|
| Opening investor overview density above P0 maximum | Hierarchy | Important | Move non-P0 blocks to P1/P2 per Investment Story Hierarchy | Management | OPEN |
| Duplicated executive summaries (Value Creation ×3) | Duplication | Important | Consolidate to one value-creation surface | Management | OPEN |
| Developed ≠ proven at scale distinction buried | Disclosure | Important | Surface distinction at 3-minute Section B | Technology | OPEN |
| PPTX media URL pending | Evidence | Minor | Resolve URL or classify as pending | Operations | IN REVIEW |
| Independent financial audit pending | Financial | Material | Disclose as pending; do not claim audited | Finance | DEFERRED / DISCLOSED |
31 · Minor RC Fixes (correctable within RC1)
Only if underlying investment meaning does not change. Log them.
32 · Material RC Changes (trigger new RC)
33 · RC1 → RC2 Change Log
| Change | RC1 | RC2 | Reason | Investor Impact |
|---|---|---|---|---|
| No RC2 required yet | — | — | RC1 under review | None |
34–37 · Cut-Off Discipline
Data Cut-Off
2026-10-01
Information after this date excluded from RC1 or incorporated via later RC.
Document Cut-Off
2026-10-01
When the RC evidence inventory was frozen. New evidence may require supplemental update or RC2.
Deck Cut-Off
Waterhouse V.05 · Sept 2026
Exact deck version reviewed — not 'latest deck'. Enables future reconciliation.
38 · RC1 Summary
LOTOMIX INVESTOR DATA ROOM — RC1 SUMMARY
FINANCIAL MODEL
BC 6.7
DECK
Waterhouse Investor Deck V.05
DATA CUT-OFF
2026-10-01
MATERIAL ISSUES
1
IMPORTANT ISSUES
3
BROKEN LINKS
0
FINANCIAL MISMATCHES
0
NARRATIVE MISMATCHES
0
ACCESS ISSUES
0
FINAL RC STATUS
RC — REVIEW IN PROGRESS
No numerical score. APPROVED FOR RELEASE ≠ PUBLISHED.
39 · RC Status Progression
40 · Final RC Management Review
Management
PENDINGFinance
PENDINGOperations
PENDINGCommercial
PENDINGTechnology
PENDINGLegal / Corporate
PENDING42 · Accepted Disclosures
Early-stage advertising validation
ACCEPTED / TRANSPARENTLY DISCLOSEDNot a Data Room defect when properly classified.
Modelled MAU
ACCEPTED / TRANSPARENTLY DISCLOSEDModelled, not actual.
Scale testing still pending
ACCEPTED / TRANSPARENTLY DISCLOSEDScale validation required — disclosed.
Independent financial audit pending
ACCEPTED / TRANSPARENTLY DISCLOSEDDisclosed as pending; not claimed as audited.
Do not treat known early-stage assumptions as Data Room defects when properly classified. Do not chase zero uncertainty.
44–46 · Disclosure & Export Tests
Investor-Surprise Test
Could an investor later reasonably say: 'I was given a materially different impression during the fundraising process'?
Flag: RC DISCLOSURE CLARITY ISSUE
Forwardable-Document Test
Investor Summary One-Pager · Exported dashboard · Key PDFs
Must contain enough date, version, status and context to avoid being misunderstood when circulated internally.
Screenshot / Export Test
Printed · Exported · Screenshot · Mobile · Desktop
Important metrics and status labels must remain visible outside the ideal browser state.
47–48 · Content-Freeze Principle
Any proposed new investor-facing page must answer:
• What unresolved investor question does this solve?
• Why can the existing architecture not answer it?
If no strong answer: do not add the page. The Data Room is in RELEASE PREPARATION MODE, not CONTINUOUS FEATURE EXPANSION MODE.
49–50 · Final RC Experience & Principle
RC Investor Experience
Final RC Principle
Release Process Flow
Final Control
✗ Do not publish.
✗ Do not send investor notifications.
✗ Do not change access permissions.
✗ Do not overwrite prior Release Candidates.
✗ Do not silently change material figures after freeze.
✗ Do not introduce additional investor pages during RC review unless they resolve a documented issue.
✗ Do not modify signed source documents.
✗ Do not replace BC 6.7 within RC1.
Publication remains separate and only after explicit management instruction: PUBLISH.
Revisión Interna de Desafío de Inversión
Desafío estructurado del caso de inversión LOTOMIX a través de perspectivas de inversión, finanzas, tecnología y legal.
LOTOMIX INVESTOR DATA ROOM
El propósito es identificar preguntas sin responder, supuestos demasiado optimistas, vacíos de evidencia, debilidades matemáticas, preocupaciones tecnológicas, dependencias legales e inconsistencias que podrían retrasar o impedir una decisión de inversión.
Part I — Review Perspectives & Materiality
Cuatro revisores independientes desafían la inversión desde su propia disciplina.
1 · Four Independent Review Perspectives
Skeptical VC / IC Partner
Investment thesis, timing, defensibility, market risk.
“Why should I invest now rather than wait for more evidence?”
Financial / CFO Due Diligence Reviewer
Revenue build, cost structure, cash, model integrity.
“Can I reproduce the economics and cash requirement?”
CTO / Technical Due Diligence Reviewer
Architecture, scale, operations, security, dependencies.
“Will this technology survive real commercial scale?”
Legal / Transaction Due Diligence Reviewer
Contracts, regulatory, IP, corporate, transaction readiness.
“What could legally prevent or delay the commercial plan or transaction?”
3 · Materiality Classification
DEAL-CRITICAL
Could materially prevent investment approval, alter transaction terms or require major additional diligence.
MATERIAL
Could materially affect valuation, forecast credibility, execution confidence or IC approval.
IMPORTANT
Requires clarification or additional evidence but is not currently deal-critical.
ROUTINE DD
Normal diligence question answerable from existing material.
Review Process
Part II — Master Challenge Register
Registro central de desafíos con IDs únicos (RT-VC, RT-FIN, RT-TECH, RT-LEGAL).
2 · Master Challenge Register
| ID | Reviewer | Question / Challenge | Why It Matters | Current Evidence | Remaining Question | Materiality |
|---|---|---|---|---|---|---|
| RT-VC-001 | VC / IC | Why should I invest now rather than wait for more evidence? | The core timing thesis must justify accepting current execution risk over deferred entry. | Investment Thesis Validation, Why Now Investment Inflection, Value Creation Bridge | Explicit 'invest now vs wait' reconciliation not surfaced as a single controlled answer. | DEAL-CRITICAL |
| RT-VC-002 | VC / IC | Can the investor immediately distinguish facts, pipeline, management targets and modelled figures? | If future state visually resembles current state, the investor may over-credit modelled economics as proven. | Read Me First status legend, Investment Evidence Map, Rollout Reconciliation | Distinguishability is present in legend form but not enforced visually across every metric surface. | MATERIAL |
| RT-VC-003 | VC / IC | What specific risk does €3M retire, and what milestone becomes possible only after funding? | Capital purpose must be traceable to a risk-reduction / milestone-unlock chain. | Funding Milestones Bridge, Use of Funds Capital Efficiency, Value Creation Bridge | Bridge exists but the 'only possible after funding' framing is implicit, not explicit per milestone. | MATERIAL |
| RT-004 | VC / IC | Why not wait until April 2027 (post-770 locations) for stronger validation? | If waiting de-risks materially, current terms must compensate the early investor. | Why Now Investment Inflection, existing assets, network position | TIMING OF INVESTMENT THESIS REQUIRES CLARIFICATION — inflection argument is present but not quantified against the wait scenario. | DEAL-CRITICAL |
| RT-VC-005 | VC / IC | Is the 1,200+ pipeline real — how generated, how recent, individually identifiable, conversion evidence? | Pipeline conversion is a principal thesis driver; unverified pipeline inflates rollout credibility. | Rollout Reconciliation, Retailer Onboarding Pipeline | No historical conversion evidence, no qualification criteria, no individual identifiability disclosed. | DEAL-CRITICAL |
| RT-VC-006 | VC / IC | What does 7,000 really mean — exclusive, full perimeter, operational limits, independent adoption? | Network access ≠ automatic distribution; over-reading 7,000 as installed base is a classic overstatement. | Contractual Access Section, FENAMIX relationship | Scope, exclusivity and per-administration adoption control not fully visible to investor. | MATERIAL |
| RT-VC-007 | VC / IC | Why is this hard to copy — concrete defensibility evidence vs generic 'first mover' claims? | Defensibility underpins terminal value; generic claims do not survive IC challenge. | Why LOTOMIX Difficult to Replicate | Component defensibility exists but advertiser network effects and switching-cost evidence remain thin. | MATERIAL |
| RT-VC-008 | VC / IC | Is advertising really the main engine — what % of base-case value depends on it, and what if advertisers don't value the inventory? | Advertising concentration risk determines the downside shape. | Revenue Quality Recurrence, Assumptions That Matter, Downside Survival | Advertising share of base-case value is derivable but not surfaced as a single headline %; advertiser-demand risk is disclosed but not stress-tested against alternative DOOH inventory. | MATERIAL |
| RT-VC-009 | VC / IC | Are six revenue streams genuine diversification or multiple unvalidated bets? | Optionality presented as diversification can mislead on revenue quality. | Revenue Quality Recurrence, How LOTOMIX Makes Money | Validated revenue vs future optionality distinction exists in classification but is not quantified per stream at launch. | IMPORTANT |
| RT-VC-010 | VC / IC | What is the single biggest thesis dependency? | IC needs the principal driver isolated to size sensitivity. | Assumptions That Matter, BC 6.7 sensitivity, Risk Register | INVESTMENT THESIS DRIVER PRIORITISATION GAP — drivers are listed but no single ranked dominant dependency is explicitly identified. | MATERIAL |
| RT-VC-011 | VC / IC | Does management have enough execution capacity to run all workstreams simultaneously? | Concurrent technology, hardware, installation, ad sales, onboarding, app, legal, reporting is a severe organisational test. | Team QA Section, First 100 Days Execution Dashboard | Ownership and hiring assumptions are present but not stress-tested against concurrent-workload reality. | MATERIAL |
| RT-VC-012 | VC / IC | What if 770 is delayed — does the business still work at 500, what happens to cash and advertiser economics? | Rollout timing is the principal operational risk; a 6-month delay may breach capital sufficiency. | Downside Survival Cash Protection, Driver Sensitivity (launch year) | ROLL-OUT DELAY SENSITIVITY REQUIRED — current downside stresses traffic/fill/CPM but not a 6-month 770 delay. | DEAL-CRITICAL |
| RT-VC-013 | VC / IC | What does success look like 12 months after investment — measurable? | IC needs post-money KPIs to monitor, not narrative 'strong growth'. | Investor KPI Cockpit, First 100 Days Execution Dashboard | KPIs are defined but a single '12-month post-investment success definition' surface is not consolidated. | IMPORTANT |
| RT-FIN-001 | CFO | Can every major revenue stream be reproduced independently from transparent drivers? | Non-reproducible revenue lines undermine model credibility. | BC 6.7, Unit Economics by Location, How LOTOMIX Makes Money | Most streams are driver-derived; peñas and digital monetisation lines are less transparently bottom-up. | MATERIAL |
| RT-FIN-002 | CFO | When is revenue recognised — installation, booking, delivery, invoicing, activation? | Recognition timing materially affects ramp and cash. | BC 6.7 (implicit), Revenue Quality Recurrence | Recognition policy is not explicitly stated per stream; timing acceleration risk not flagged. | MATERIAL |
| RT-FIN-003 | CFO | Is GTV ever confused with recognised revenue anywhere in the RC? | GTV/revenue confusion is a classic material misstatement. | Revenue Quality Recurrence explicitly separates transaction volume from LOTOMIX revenue | No confusion found in principal surfaces; verify across all sub-components. | IMPORTANT |
| RT-FIN-004 | CFO | Is the 30% FENAMIX share applied only to large-format advertising and not to reader/rear revenue? | Misapplication materially understates net revenue. | FENAMIX treatment freeze (RC1), How LOTOMIX Makes Money | RC1 freezes correct treatment; confirm every financial surface honours it — no automatic audit run. | MATERIAL |
| RT-FIN-005 | CFO | Does the reader CPM calculation (Traffic × Capture × Days × Impacts × CPM) reconcile to monthly revenue? | CPM denominator and 1,000-impression conversion are common error points. | BC 6.7 assumptions, Driver Sensitivity formulas | Formula is published in Driver Sensitivity; independent reproduction not logged in RC. | MATERIAL |
| RT-FIN-006 | CFO | Is fill embedded in CPM or applied separately — any double discount or implicit 100% monetisation? | Double-counting or missing occupancy adjustments inflate revenue. | BC 6.7 assumptions, Assumptions That Matter | Fill treatment is stated in assumptions but not cross-validated against every revenue surface. | MATERIAL |
| RT-FIN-007 | CFO | What does each deployed location actually cost — hardware, installation, inventory, replacements, logistics, VAT, payment terms? | CAPEX per location drives funding sufficiency. | Use of Funds Capital Efficiency, Unit Economics by Location | Per-location fully-loaded cost not consolidated as a single reconciled figure vs Use of Funds. | MATERIAL |
| RT-FIN-008 | CFO | Which OPEX is fixed, location-scaling, user-scaling, revenue-scaling — is headcount added before or after revenue? | Artificial operating leverage (flat scalable costs) overstates margin. | BC 6.7 OPEX (driver-based) | Driver-based OPEX exists; scaling classification per line not surfaced for investor audit. | MATERIAL |
| RT-FIN-009 | CFO | Working capital — advertiser payment terms, supplier terms, FENAMIX timing, inventory financing? | Strong EBITDA with understated cash requirements is a common failure mode. | BC 6.7 (implicit), Downside Survival | Working-capital cycle not explicitly modelled or disclosed. | MATERIAL |
| RT-FIN-010 | CFO | What happens with zero public subsidy? | BC 6.7 base case states €0 subsidy, but if any sensitivity depends on unapproved subsidies, dependency is hidden. | BC 6.7 (€0 subsidy base case) | Base case is no-subsidy; confirm no sensitivity or narrative re-introduces subsidy dependency. | IMPORTANT |
| RT-FIN-011 | CFO | Does €3M fund the company to a meaningful commercial validation milestone — minimum cash, peak funding, WC peak, capex peak, downside? | Capital sufficiency is the principal funding question. | Use of Funds, Downside Survival, BC 6.7 | €3M sufficiency is asserted via milestones but peak-funding / minimum-cash reconciliation not published. | DEAL-CRITICAL |
| RT-FIN-012 | CFO | Are EBITDA, operating cash-flow and free cash-flow break-even distinguished correctly? | Conflating break-even definitions misleads on runway. | BC 6.7, Financials Section | Terminology used but explicit per-definition break-even points not consolidated. | IMPORTANT |
| RT-FIN-013 | CFO | Does unit-economics × locations reconcile to BC 6.7 consolidated output? | Unexplained discrepancy signals a hidden assumption. | Unit Economics by Location, BC 6.7 | Reconciliation is described qualitatively; full numeric bridge not published in RC. | MATERIAL |
| RT-FIN-014 | CFO | Is the downside genuinely stressful or merely slightly below base? | A mild downside does not inform capital sufficiency. | Downside Survival, Driver Sensitivity | DOWNSIDE MAY NOT BE SUFFICIENTLY INFORMATIVE — stresses percentages but not rollout timing or advertiser demand collapse. | MATERIAL |
| RT-TECH-001 | CTO | What environment is actually running today — dev, QA, staging, production — and how many real users/locations? | Environment status determines production-readiness claims. | Technology Readiness Scalability | Environment status is described; real-user / live-location count on production not quantified. | MATERIAL |
| RT-TECH-002 | CTO | Ticket validation — how many tickets tested, across how many types, failure rate, OCR fallback, false-positive handling, source of truth? | Validation accuracy is core to product integrity and legal compliance. | Technology Readiness (ticket validation materially developed) | FORMAL VALIDATION METRICS REQUIRED — no test volume, failure rate or fallback handling disclosed. | DEAL-CRITICAL |
| RT-TECH-003 | CTO | What load has been tested vs expected at 770 and 3,370 — database, device-message, advertising delivery? | Scale assumptions based only on architecture are unvalidated. | Technology Readiness Scalability (scale validation required) | No load-test evidence; scale validation explicitly flagged as required. | MATERIAL |
| RT-TECH-004 | CTO | Device management — provisioning, updates, offline detection, failure diagnosis, remote management of 1,500+ screens? | Physical fleet complexity is a primary scale constraint. | Technology Readiness (device management described) | Remote fleet management at 1,500+ scale not evidenced; field-intervention scope not bounded. | MATERIAL |
| RT-TECH-005 | CTO | Single points of failure — single developer, server, vendor, OCR service, payment provider, manual process? | Concentration risk can halt operations. | Technology Readiness (dependencies), Risk Register | TECHNICAL CONCENTRATION RISK — key-person and single-vendor dependencies not fully mapped. | MATERIAL |
| RT-TECH-006 | CTO | Security — production access, credential control, MFA, encryption, logs, breach response? | Security gaps create regulatory and operational risk. | Technology Readiness (cybersecurity controls listed) | Security review occurrence and breach-response drill not evidenced. | IMPORTANT |
| RT-TECH-007 | CTO | Backup / recovery — has restoration been tested, database failover, connectivity-loss fallback, administration downtime? | Untested recovery is a hidden operational risk. | Technology Readiness (backups listed) | Restoration test evidence and per-administration offline fallback not documented. | MATERIAL |
| RT-TECH-008 | CTO | Third-party dependencies — scale, contract, quota, pricing-change, replaceability, data portability? | Critical provider failure or pricing change can derail unit economics. | Technology Readiness (third-party services) | Replaceability and data-portability per provider not assessed. | IMPORTANT |
| RT-TECH-009 | CTO | Technical team capacity — who deploys, who owns backend/hardware/security, documentation, key-person risk? | Knowledge concentration is a continuity risk. | Team QA, Technology Readiness | Key-person dependency and documentation sufficiency not evidenced. | MATERIAL |
| RT-TECH-010 | CTO | Technical debt — what must be fixed before December, what can wait, is hardening budgeted in funding? | Hidden technical work inside the funding request misrepresents use of funds. | Technology Readiness (technical debt listed), First 100 Days | Feature development vs production/scale engineering distinction not explicitly budgeted. | IMPORTANT |
| RT-LEGAL-001 | Legal | FENAMIX contract — what is granted, duration, termination, exclusivity, scope, consent, change-of-control? | FENAMIX is the principal network-access dependency. | Contractual Access Section, FENAMIX agreement (executed, restricted) | Duration, termination, change-of-control terms not visible to investor; counsel review required. | DEAL-CRITICAL |
| RT-LEGAL-002 | Legal | Administrations — what agreement exists per administration, who owns/operates hardware, who pays SaaS, who controls inventory? | Inconsistent contractual architecture creates fragmented rights. | Regulatory Legal Readiness (administration onboarding in progress) | Per-administration contractual template and rights allocation not disclosed. | MATERIAL |
| RT-LEGAL-003 | Legal | Lottery transactions — who legally sells, who is the customer, who receives funds, who issues proof, what is LOTOMIX's role? | UX/legal-structure mismatch creates regulatory exposure. | Regulatory Legal Readiness (ticket validation, lottery purchase pending validation) | Legal role of LOTOMIX in the lottery transaction chain not defined; app-flow consistency not confirmed. | DEAL-CRITICAL |
| RT-LEGAL-004 | Legal | Peñas — ticket ownership, participation recording, payments, winnings allocation, disclosures, disputes, fee structure legality? | Peñas carry consumer-funds and gambling-adjacent legal risk. | Regulatory Legal Readiness (peñas pending validation) | PEÑAS PRE-LAUNCH LEGAL DEPENDENCY — full legal structure not resolved. | DEAL-CRITICAL |
| RT-LEGAL-005 | Legal | Wallet / payments — stored value, fund holding, licensed provider, merchant of record, refunds/chargebacks, wording accuracy? | Payment regulation is strict; marketing wording can create unintended implications. | Regulatory Legal Readiness (payments pending validation) | Licensed provider identity, merchant-of-record and fund-holding architecture not disclosed. | DEAL-CRITICAL |
| RT-LEGAL-006 | Legal | Advertising — contractual right to sell each screen's inventory, category restrictions, content approval, per-screen rights, FENAMIX 30% documentation? | Inventory rights underpin the principal revenue engine. | Contractual Access, FENAMIX treatment freeze (RC1) | Per-screen inventory rights and content-approval authority not fully mapped. | MATERIAL |
| RT-LEGAL-007 | Legal | Data protection — controller/processor, ticket-image retention, transaction retention, consent, analytics, DPAs? | GDPR exposure is material in Spain. | GDPR DPA Readiness Pack (draft) | Controller/processor allocation and retention policies not finalised; DPAs draft only. | MATERIAL |
| RT-LEGAL-008 | Legal | IP — company ownership of core code, contractor assignments, third-party licences, hardware designs, trademarks/domains? | Chain-of-title gaps affect transaction value. | Assets IP Section | Contractor assignment chain and third-party licence restrictions not fully evidenced. | MATERIAL |
| RT-LEGAL-009 | Legal | Transaction readiness — cap table accuracy, investing entity vs operating structure, shareholder approvals, pre-emption, key-contract consent, liabilities? | Transaction blockers can delay or restructure the deal. | Corporate documents (restricted) | Cap-table reconciliation and key-contract change-of-control review not confirmed. | DEAL-CRITICAL |
46 challenges · IDs are unique and not reused.
Part III — Cross-Functional Review Issues
Desafíos planteados por múltiples revisores — merecen particular atención.
53 · Cross-Functional DD Issues
Objections raised by multiple reviewers. These usually deserve particular management attention.
Rollout assumptions (770 timing, 500 fallback, 6-month delay)
XFN-001 · CROSS-FUNCTIONALVC questions delay impact on cash; CFO questions capital sufficiency under delay; CTO questions scale-readiness at 770.
FENAMIX dependency (scope, duration, change-of-control)
XFN-002 · CROSS-FUNCTIONALVC questions 7,000 meaning; Legal questions contract terms; CFO questions 30% application.
Payments / wallet regulation
XFN-003 · CROSS-FUNCTIONALCTO questions provider replaceability; Legal questions licensing; CFO questions fund-flow cash.
Advertising fill / demand validation
XFN-004 · CROSS-FUNCTIONALVC questions advertiser demand; CFO questions fill double-counting; Commercial questions inventory value proof.
Pipeline conversion evidence (1,200+)
XFN-005 · CROSS-FUNCTIONALNo reviewer can independently validate pipeline conversion probability from current evidence.
Key-person / team capacity across concurrent workstreams
XFN-006 · CROSS-FUNCTIONALVC questions execution capacity; CTO questions technical key-person; Legal questions regulatory capacity.
Part IV — Questions Already Addressed
Para cada desafío, verificar si el Data Room ya lo aborda.
54 · Questions Already Answered — Classification
For every red-team objection, the current Data Room is checked. This distinction is critical — do not create work where the answer already exists.
ANSWERED CLEARLY
Data Room already answers the objection directly.
ANSWER EXISTS BUT IS HARD TO FIND
Answer exists but navigation is poor.
→ CROSS-LINK / NAVIGATION FIX (not new page)
PARTIALLY ANSWERED
Some evidence exists; specific element missing.
→ Add evidence when available; do not rewrite narrative.
NOT ANSWERED
Data Room does not currently address the question.
→ Requires clarification, evidence, model work or counsel.
EVIDENCE MISSING
Claim is reasonable but evidence is incomplete or absent.
→ Attach existing evidence; collect operating evidence; wait for validation.
Where the answer exists but navigation is poor, recommend CROSS-LINK / NAVIGATION FIX — not a new page. This reinforces compression.
Part V — Review Action Categories
Cada desafío se enruta a una categoría de acción.
60–65 · Red-Team Action Categories
Each objection is routed to one category. Management decides which changes, if any, should be made. Do not write around missing evidence.
60 · No Change Required
Transparently Disclosed
Advertising fill is not yet validated
Downside Survival and Revenue Quality disclose this; sensitivity exists.
Zero-subsidy base case
BC 6.7 base case is €0 subsidy.
Status legend distinguishes fact/pipeline/target/modelled
Read Me First and Evidence Map provide the legend.
61 · Requires Clarification
CLARIFY EXISTING PAGE
€3M risk-reduction / milestone-unlock chain
→ CLARIFY EXISTING PAGE
Position is correct; 'only possible after funding' framing is implicit.
Break-even terminology (EBITDA / OCF / FCF)
→ CLARIFY EXISTING PAGE
Distinguish definitions explicitly on Financials.
12-month post-investment success definition
→ CLARIFY EXISTING PAGE
KPIs exist; consolidate into a single success surface.
62 · Requires Evidence
Attach / Collect Evidence
Pipeline conversion history
→ Collect operating evidence
No historical conversion data; requires pipeline qualification evidence.
Ticket validation metrics
→ Attach test evidence when available
Volume, failure rate, fallback handling.
Backup restoration test
→ Run and attach evidence
Restoration drill not documented.
IP contractor assignment chain
→ Attach assignment evidence
Chain-of-title documentation.
63 · Requires Model Work
MODEL WORK REQUIRED — Finance / Management
Six-month 770 rollout delay sensitivity
→ MODEL WORK REQUIRED
BC 6.7 does not contain a rollout-delay sensitivity. Do NOT create automatically.
Working-capital cycle model
→ MODEL WORK REQUIRED
WC cycle not modelled in BC 6.7.
Peak-funding / minimum-cash reconciliation
→ MODEL WORK REQUIRED
€3M sufficiency requires peak-funding proof.
Unit economics × locations vs BC 6.7 numeric bridge
→ MODEL WORK REQUIRED
Full numeric reconciliation not published.
64 · Requires Legal Counsel
Counsel review required — no inference
FENAMIX contract interpretation (duration, termination, change-of-control)
→ Counsel review required
Lottery transaction legal role of LOTOMIX
→ Counsel review required
Peñas legal structure
→ Counsel review required
Wallet / payments licensing and merchant-of-record
→ Counsel review required
Transaction readiness (cap table, consents, liabilities)
→ Counsel review required
65 · Requires Technical Test
Test evidence — not architecture diagrams
Load test at 770 and 3,370 scale
→ Performance test required
Backup restoration drill
→ Recovery test required
Remote fleet management at 1,500+ devices
→ Device-fleet test required
Security assessment
→ Security review required
Part VI — Principal Pre-Release Questions
Máximo 10 preguntas que un inversor plantearía antes de comprometer capital.
Principal Pre-Release Due-Diligence Questions
A maximum of 10 questions an investor is most likely to raise before committing capital. Not ranked.
Why invest now rather than wait until April 2027?
Current Position
Investment inflection and existing-assets argument presented.
Evidence
Why Now, Investment Thesis Validation
Remaining Gap
Not quantified against the wait scenario.
Is the 1,200+ pipeline real and what conversion evidence exists?
Current Position
Pipeline disclosed as expressed-interest.
Evidence
Rollout Reconciliation, Retailer Onboarding Pipeline
Remaining Gap
No historical conversion evidence.
What does the 7,000 FENAMIX perimeter actually grant?
Current Position
Network access relationship described.
Evidence
Contractual Access, FENAMIX agreement
Remaining Gap
Scope, exclusivity, per-administration control not visible.
Does €3M fund the company to a meaningful validation milestone?
Current Position
Milestone bridge asserts sufficiency.
Evidence
Funding Milestones Bridge, Use of Funds
Remaining Gap
Peak-funding / minimum-cash reconciliation not published.
What happens if 770 is delayed by six months?
Current Position
Downside stresses traffic/fill/CPM percentages.
Evidence
Downside Survival, Driver Sensitivity
Remaining Gap
No rollout-delay sensitivity in BC 6.7.
What % of base-case value depends on advertising and what if advertisers don't value the inventory?
Current Position
Advertising share derivable from revenue breakdown.
Evidence
Revenue Quality, Assumptions That Matter
Remaining Gap
Not surfaced as a single headline %; advertiser-demand risk not stress-tested.
Has ticket validation been formally tested at scale?
Current Position
Described as materially developed.
Evidence
Technology Readiness
Remaining Gap
No test volume, failure rate or fallback metrics.
What is LOTOMIX's legal role in lottery transactions and peñas?
Current Position
Feature-specific legal readiness — pending validation.
Evidence
Regulatory Legal Readiness
Remaining Gap
Legal role and peñas structure unresolved.
Can the technology operate reliably at 770 and 3,370 locations?
Current Position
Architecture described; scale validation required.
Evidence
Technology Readiness Scalability
Remaining Gap
No load-test evidence.
Are FENAMIX contract duration, termination and change-of-control terms acceptable?
Current Position
Executed agreement disclosed (restricted).
Evidence
Contractual Access, FENAMIX agreement
Remaining Gap
Terms not visible; counsel review required.
Part VII — Summary & Success Condition
Resumen final, condición de éxito y principio final.
Summary
9
Deal-Critical Questions
19
Material Questions
8
Important Questions
0
Routine DD Questions
3
Already Answered Clearly
2
Hard to Find
2
Partial Answers
4
Evidence Required
4
Model Work Required
5
Legal Review Required
4
Technical Testing Required
No arbitrary quality score.
Review Success Condition
The objective is not zero investor questions. A sophisticated investor will always have questions. The objective is:
✓ No avoidable contradiction.
✓ No unsupported material claim.
✓ No unexplained financial mismatch.
✓ No hidden material dependency.
✓ No material issue that management has failed to identify.
Final Principle
The investment case should address the following four questions. Where the current Data Room cannot answer one sufficiently, the precise gap is identified — not concealed.
VC
Why should I invest now?
CFO
Can I reproduce the economics and cash requirement?
CTO
Can the system operate reliably at the planned scale?
LEGAL
Can the transaction and product operate within the documented contractual and regulatory framework?
Preguntas Clave de Inversores y Respuestas de Dirección
Principales preguntas que surgen de la revisión de inversión y la evidencia actualmente disponible para abordarlas.
SUMMARY
15
Principal Questions Covered
15
Answers Current
8
Evidence Complete
2
Evidence Still Required
1
Legal Review Required
3
Model Work Required
1
Technical Validation Required
No quality score.
Part I — Principal Questions (15)
Limitado a 15 preguntas principales que podrían afectar materialmente la decisión, valoración, financiación, ejecución, credibilidad, tecnología o legalidad.
Part II — Compact Reference Table
Vista compacta de las 15 preguntas principales con posición actual y fuente de evidencia.
Compact Reference Table
Compact reference of all 15 principal questions with current position and evidence source. Full supporting detail is in the individual question cards.
| # | Question | Current Position | Evidence Source |
|---|---|---|---|
| 01 | Why Invest Now? | LOTOMIX is not starting from concept stage. The business already has an existing physical reader footprint, an established FENAMIX relationship, developed technology and a current rollout pipeline. The proposed financing is intended to convert that existing foundation into broader commercial deployment and measurable operating evidence. Waiting would reduce certain execution uncertainties, but the current investment opportunity is specifically positioned at the transition from infrastructure and development into commercial scale. | Investment Inflection PointCurrent State vs Future State |
| 02 | What Does 7,000 Really Mean? | No. Approximately 7,000 refers to the potential FENAMIX mixed-lottery retail network perimeter associated with the relationship. It should not be confused with installed or active LOTOMIX locations. The existing reader footprint is approximately 370 locations, while more than 1,200 additional locations currently form part of the rollout / expressed-interest pipeline. | Rollout Reconciliation |
| 03 | How Real Is the 1,200+ Pipeline? | The 1,200+ figure represents current expressed interest / rollout pipeline, not guaranteed deployment. The investment case therefore separates pipeline from installed, activated and monetised locations. One of the key operating KPIs after commercial rollout will be the actual conversion rate from pipeline to scheduled, installed and activated locations. | Commercial Proof & TractionRollout Reconciliation |
| 04 | Why Should Advertisers Pay the Modelled CPM? | The current CPM values are model assumptions rather than a claim that those rates have already been achieved across the network. The Data Room therefore separates model CPM from realised CPM and includes downside sensitivities for weaker pricing. The key commercial validation milestone is to replace those assumptions progressively with actual campaign data. | Assumptions That MatterDownside & Sensitivities |
| 05 | What If Advertising Fill Is Much Lower? | Advertising fill is treated as a variable driver rather than a guaranteed outcome. BC 6.7 and the downside framework test the effect of weaker fill on revenue, EBITDA and cash. Management can also moderate discretionary deployment and commercial expansion if monetisation develops more slowly than planned. | Downside & Resilience |
| 06 | Are the 370 Locations Actually Monetised? | The approximately 370 figure refers to the existing reader footprint. Installed, activated and monetised locations are deliberately tracked as separate metrics. The Data Room does not assume that every installed reader is already a fully completed or fully monetised location. | Rollout ReconciliationInvestor KPI Cockpit |
| 07 | Why So Many Revenue Streams? | The revenue streams are at different stages of maturity and are not presented as equally validated. The Data Room classifies each stream separately as live, commercial activation, pre-commercial or modelled. The investment case therefore distinguishes the currently strongest evidence from longer-term monetisation optionality. | Business & Revenue ModelRevenue Quality & Recurrence |
| 08 | Is GTV Being Presented as Revenue? | No. GTV represents the gross underlying transaction or participation volume. LOTOMIX recognised revenue is only the applicable fee, commission or economic share. The Data Room separates the two throughout the transaction and peñas models. | Financial Reconciliation |
| 09 | Why Does FENAMIX Only Receive 30% on the Large Screen? | No. Under the current commercial treatment, the 30% FENAMIX share applies specifically to the large-format 43"/48" advertising display revenue. It does not apply to reader or rear-display advertising revenue. The financial model and investor materials are being controlled to preserve this distinction consistently. | FENAMIX RelationshipUnit Economics |
| 10 | Can the Technology Really Scale? | The Data Room deliberately separates working functionality from proof of scale. Core technology and ticket-validation functionality have been materially developed and tested, while production hardening, load validation and device-fleet scaling are treated as separate technical milestones. The investment case does not claim scale has already been proven where the evidence does not support it. | Technology Readiness & Scalability |
| 11 | What Is the Biggest Legal Dependency? | Legal readiness is assessed feature by feature rather than through a blanket statement. Executed contractual rights, technical readiness and legal / regulatory readiness are separate statuses. Any remaining launch-critical items for payments, peñas, consumer terms, data protection or other functionality are identified explicitly in the Legal Readiness Matrix. | Regulatory & Legal Readiness |
| 12 | Is €3M Really Enough? | The sufficiency of the €3M financing is assessed through the BC 6.7 cash model rather than through a headline assumption. The model connects deployment, OPEX, working capital and revenue ramp to cash and runway. The downside case is particularly important because slower monetisation or higher deployment cost can change the timing of future capital requirements. | Financials & Funding |
| 13 | What If the 770 Target Is Delayed? | A delay primarily affects the timing of advertising inventory, SaaS activation, contribution and operating leverage. The correct way to assess this is through a slower-rollout sensitivity in BC 6.7 and the corresponding cash / runway impact. Management can also moderate expansion spending where possible if rollout or monetisation trails the plan. | Rollout ReconciliationDownside & Resilience |
| 14 | Why Is the Model Credible If So Much Is Still To Be Validated? | BC 6.7 is a driver-based management model, not a claim that all assumptions have already been proven. Its purpose is to make the assumptions explicit and allow investors to test weaker scenarios. As commercial rollout generates actual data, those assumptions will be replaced progressively by observed traffic, pricing, fill, conversion and unit economics. | Critical Driver DashboardEvidence Gap Closure Plan |
| 15 | What Would Make the Investment Thesis Fail? | The principal areas to monitor are rollout conversion, advertising monetisation, actual unit economics, digital adoption, technology scale and capital efficiency. The Data Room links these directly to operating KPIs and downside sensitivities. The investment thesis therefore has explicit validation points rather than relying on one headline forecast. | Investment Thesis Validation |
Part III — Reference Figures & Definition Boundaries
Cifras canónicas y distinciones críticas mantenidas consistentemente en todo el Data Room.
Reference Figures
Canonical figures relevant to the current investment case. These definitions are maintained consistently across all Data Room sections.
~370
Existing reader footprint
1,200+
Rollout / expressed-interest pipeline
~7,000
Potential FENAMIX network perimeter
~770
Completed-location target by April 2027
€3M
Current financing reference
BC 6.7
Current principal financial model
11.6"
Current reader screen
23.8"
Current rear display
43"
Current large-format display
Definition Boundaries
These distinctions are maintained consistently across all Data Room surfaces.
Part IV — Terminology Guidance
Terminología preferida y términos que requieren evidencia.
Terminology Guidance
Preferred Terminology
Terms Requiring Evidence
The following terms should only be used when directly supported by evidence:
Part V — Compact Reference View
Vista condensada para referencia rápida.
Compact Reference View
CONDENSED REFERENCE — ALL 15 QUESTIONS WITH CURRENT POSITION
LOTOMIX is not starting from concept stage. The business already has an existing physical reader footprint, an established FENAMIX relationship, developed technology and a current rollout pipeline. The proposed financing is intended to convert that existing foundation into broader commercial deployment and measurable operating evidence. Waiting would reduce certain execution uncertainties, but the current investment opportunity is specifically positioned at the transition from infrastructure and development into commercial scale.
No. Approximately 7,000 refers to the potential FENAMIX mixed-lottery retail network perimeter associated with the relationship. It should not be confused with installed or active LOTOMIX locations. The existing reader footprint is approximately 370 locations, while more than 1,200 additional locations currently form part of the rollout / expressed-interest pipeline.
The 1,200+ figure represents current expressed interest / rollout pipeline, not guaranteed deployment. The investment case therefore separates pipeline from installed, activated and monetised locations. One of the key operating KPIs after commercial rollout will be the actual conversion rate from pipeline to scheduled, installed and activated locations.
The current CPM values are model assumptions rather than a claim that those rates have already been achieved across the network. The Data Room therefore separates model CPM from realised CPM and includes downside sensitivities for weaker pricing. The key commercial validation milestone is to replace those assumptions progressively with actual campaign data.
Advertising fill is treated as a variable driver rather than a guaranteed outcome. BC 6.7 and the downside framework test the effect of weaker fill on revenue, EBITDA and cash. Management can also moderate discretionary deployment and commercial expansion if monetisation develops more slowly than planned.
The approximately 370 figure refers to the existing reader footprint. Installed, activated and monetised locations are deliberately tracked as separate metrics. The Data Room does not assume that every installed reader is already a fully completed or fully monetised location.
The revenue streams are at different stages of maturity and are not presented as equally validated. The Data Room classifies each stream separately as live, commercial activation, pre-commercial or modelled. The investment case therefore distinguishes the currently strongest evidence from longer-term monetisation optionality.
No. GTV represents the gross underlying transaction or participation volume. LOTOMIX recognised revenue is only the applicable fee, commission or economic share. The Data Room separates the two throughout the transaction and peñas models.
No. Under the current commercial treatment, the 30% FENAMIX share applies specifically to the large-format 43"/48" advertising display revenue. It does not apply to reader or rear-display advertising revenue. The financial model and investor materials are being controlled to preserve this distinction consistently.
The Data Room deliberately separates working functionality from proof of scale. Core technology and ticket-validation functionality have been materially developed and tested, while production hardening, load validation and device-fleet scaling are treated as separate technical milestones. The investment case does not claim scale has already been proven where the evidence does not support it.
Legal readiness is assessed feature by feature rather than through a blanket statement. Executed contractual rights, technical readiness and legal / regulatory readiness are separate statuses. Any remaining launch-critical items for payments, peñas, consumer terms, data protection or other functionality are identified explicitly in the Legal Readiness Matrix.
The sufficiency of the €3M financing is assessed through the BC 6.7 cash model rather than through a headline assumption. The model connects deployment, OPEX, working capital and revenue ramp to cash and runway. The downside case is particularly important because slower monetisation or higher deployment cost can change the timing of future capital requirements.
A delay primarily affects the timing of advertising inventory, SaaS activation, contribution and operating leverage. The correct way to assess this is through a slower-rollout sensitivity in BC 6.7 and the corresponding cash / runway impact. Management can also moderate expansion spending where possible if rollout or monetisation trails the plan.
BC 6.7 is a driver-based management model, not a claim that all assumptions have already been proven. Its purpose is to make the assumptions explicit and allow investors to test weaker scenarios. As commercial rollout generates actual data, those assumptions will be replaced progressively by observed traffic, pricing, fill, conversion and unit economics.
The principal areas to monitor are rollout conversion, advertising monetisation, actual unit economics, digital adoption, technology scale and capital efficiency. The Data Room links these directly to operating KPIs and downside sensitivities. The investment thesis therefore has explicit validation points rather than relying on one headline forecast.
Part VI — Consistency, Evidence & Final Principle
Controles de consistencia, evidencia y principio final.
Summary
15
Principal Questions Covered
15
Answers Current
8
Evidence Complete
2
Evidence Still Required
1
Legal Review Required
3
Model Work Required
1
Technical Validation Required
No quality score.
Response Consistency Check
Each response is verified for consistency with the following canonical sources:
Where a conflict exists, the response is flagged for reconciliation.
Evidence Check
Each response links to evidence or an approved analytical section. Where evidence is missing, the response states "evidence still being built / validated" rather than strengthening the wording.
Update When Facts Change
Response History
Historical versions of material responses are preserved. Previously communicated positions are not silently rewritten.
Final Principle
The objective is that every management representative can answer the same question with the same meaning using the same canonical numbers and pointing to the same evidence.
No More Pages — Gobernanza de Contenido del Data Room de Inversores
El Data Room de Inversores LOTOMIX ha entrado en modo de operación y preparación de release.
No More Pages — Investor Data Room Content Governance
The LOTOMIX Investor Data Room has entered operating and release-preparation mode
The purpose of this rule is to stop unnecessary expansion of the Investor Data Room. The analytical architecture is now sufficiently developed. From this point forward, the default action must NOT be to create another page. The default action should be: update, reconcile, simplify, link, verify, replace outdated information, or add evidence to the existing canonical architecture.
UPDATE, DON'T DUPLICATE · IMPROVE, DON'T EXPAND · ADD EVIDENCE, NOT COMPLEXITY · KEEP THE INVESTOR JOURNEY STABLE
§ 1 · DECLARE CONTENT ARCHITECTURE COMPLETE
Treat the principal LOTOMIX investor architecture as STRUCTURALLY COMPLETE.
This does NOT mean
It means
New information should normally update an existing canonical section rather than create another investor-facing page.
§ 42 · DATA ROOM MATURITY MODEL
STAGE 1
Build
Create the initial content.
STAGE 2
Expand
Answer due diligence.
STAGE 3
Reconcile
Align models, claims and evidence.
STAGE 4
Compress
Reduce navigation complexity.
STAGE 5
Release Candidate
Freeze the package.
STAGE 6
Operate
Update actual data and evidence without expanding architecture.
← CURRENT
§ 2 · DEFAULT RULE
Before creating any new investor-facing page, the data room team must first ask:
If the answer to any is yes → DO NOT CREATE A NEW PAGE. Use the existing architecture.
§ 3 · CREATE A NEW-PAGE TEST
A new investor-facing page may only be proposed if ALL of the following are true:
If any condition fails → do not create the page.
§ 4 · NEW PAGE REQUEST
Where a genuinely new page is proposed, create an INTERNAL request:
NEW INVESTOR PAGE REQUEST
Do not implement the page before approval.
§ 5 · NO PAGE FOR EVERY INVESTOR QUESTION
A new investor question should first go into Investor Questions Answered Tracker. Then determine whether the answer belongs in IC Q&A, an existing analytical page, source evidence, or a private DD response. A one-off DD question does NOT justify a permanent new page.
§ 6 · CANONICAL PAGE OWNERSHIP
Maintain one canonical page per principal investor question. Use the following structure as the default source of truth.
INVESTMENT CASE
Canonical
3-Minute Investment Overview
Supporting
✗ Do not create another executive investment-summary page.
BUSINESS MODEL
Canonical
Business & Revenue Model
Supporting
✗ Do not create another page simply describing revenue streams.
UNIT ECONOMICS
Canonical
Unit Economics by Location
✗ Do not create another page calculating location economics. Update this one.
CRITICAL ASSUMPTIONS
Canonical
Assumptions That Matter
✗ Do not create additional driver dashboards.
NETWORK / ROLLOUT
Canonical
Rollout Reconciliation
Supporting
✗ Do not create another 370 / 500 / 770 explanation.
FINANCIAL MODEL
Canonical source
BC 6.7
Supporting
✗ Do not create competing financial models or independent forecast pages.
DOWNSIDE
Canonical
Downside & Resilience
Supporting
✗ Do not create separate downside pages unless specialist analysis genuinely requires it.
FUNDING
Canonical
Funding & Capital Deployment
Supporting
✗ Do not create additional €3M explanation pages.
TECHNOLOGY
Canonical
Technology Readiness & Scalability
Supporting
✗ Do not create separate pages for every technical subsystem.
COMMERCIAL
Canonical
Commercial Proof & Traction
Supporting
✗ Do not create separate pages for each advertiser or opportunity.
LEGAL
Canonical
Regulatory & Legal Readiness
Supporting
✗ Do not create standalone pages for every legal question unless specialist DD requires it.
EVIDENCE
Canonical map
Investment Evidence Map
Full Evidence & Source Documents (Canonical repository)
✗ Do not create another evidence index.
RISK
Canonical
Institutional Risk Register
✗ Do not create additional investor-facing risk lists.
IC QUESTIONS
Canonical investor-facing
Investment Committee Q&A
Investor Questions Answered Tracker (Canonical internal)
✗ Do not create further FAQ systems.
§ 7 · UPDATE BEFORE CREATE
For every new fact, the data room team should apply this decision sequence:
Only after these options are exhausted should a new page be considered.
§ 8–19 · NEW [X] RULES
§ 8
New Commercial Development Rule
If LOTOMIX signs a new advertiser, partner or customer:
do NOT create a new page.
Update
§ 9
New Installation Data Rule
If installation counts change:
do NOT create a new rollout page.
Update
Preserve the previous historical reporting value.
§ 10
New Pipeline Data Rule
If 1,200+ changes to a new verified figure:
do NOT create a new pipeline page.
Update
Then propagate through reusable metric components. Do not manually update each page independently where the platform can reference one source.
§ 11
New Financial Data Rule
When actual commercial performance begins:
do NOT create a new Actual Financial Model page.
Update
Use these within the existing financial reporting architecture. Preserve the original investment case.
§ 12
New BC Version Rule
If management formally approves a successor to BC 6.7:
do not overwrite BC 6.7.
Update
A new BC version does NOT require new financial-summary pages.
§ 13
New Technology Evidence Rule
If load testing, security testing or production data becomes available:
Do not create Technology Readiness V2 or separate scale-validation pages unless genuinely necessary.
Update
§ 14
New Legal Evidence Rule
If legal counsel confirms a product area:
Do not create a new legal page every time an opinion is received.
Update
Change status only within the supported scope.
§ 15
New Risk Rule
If a new material risk emerges:
Do not create New Risks as a separate page.
Update
If the risk requires investor disclosure, update the relevant canonical investment page.
§ 16
New Investor Objection Rule
If a new investor raises a difficult objection:
Only create a new page if the New-Page Test is passed.
Update
§ 17
New Evidence Gap Rule
If management identifies something not yet proven:
Do not create another Things to Prove page.
Update
§ 18
New Value-Creation Evidence Rule
If a model assumption becomes actual evidence:
Do not create a new success-story page.
Update
§ 19
Latest Updates Rule
New developments should primarily surface through:
Update
Examples
new advertiser · new installations · legal confirmation · technical milestone · material financial update
This prevents the homepage from growing every time the business progresses.
§ 20–22 · FREEZES
§ 20
Homepage Freeze
The homepage should remain based on Eight Principal Doors.
Only update
Do not add
§ 21
Executive Surface Freeze
The following executive surfaces should remain the only principal executive summaries:
Do not add
§ 22
Analytical Surface Freeze
The principal analytical questions are now covered by:
Any proposed analytical page should first be tested against these.
§ 23–25 · EXCEPTIONS
§ 23
Internal Governance Exception
New INTERNAL-only tools may be added where genuinely required for transaction execution, compliance, Data Room administration, or investor reporting automation. However, they must not appear in normal investor navigation. They should not duplicate existing governance systems.
§ 24
Source Document Exception
New source documents can always be added when genuinely relevant. Examples: executed contract, new legal opinion, monthly accounts, technical report, deployment evidence, commercial agreement. The No More Pages rule does NOT restrict evidence uploads. It restricts unnecessary investor-facing analytical pages.
§ 25
Data Update Exception
Live / recurring data should continue to update. Examples: installed locations, active locations, pipeline, advertisers, revenue, MAU, cash. Do not freeze operating data merely because page creation is frozen.
§ 26 · EVIDENCE UPDATES SHOULD STRENGTHEN EXISTING PAGES
As evidence improves, replace or supplement MODELLED with ACTUAL where appropriate. Replace EARLY EVIDENCE with REPEAT EVIDENCE when justified. The page remains. The evidence maturity changes.
§ 27 · CONTENT DECAY CONTROL
Stopping page creation must NOT cause the Data Room to become stale. The governance process should continue to flag stale KPIs, expired evidence, outdated pipeline, superseded legal position, old commercial status, and outdated forecasts. The Data Room now moves from content creation to content maintenance.
§ 28 · MAINTENANCE PRIORITY ORDER
This becomes the default operating priority.
§ 29
No Cosmetic Expansion
Do not create new pages because a new design idea exists, another visual could look impressive, or a topic could theoretically be explained separately. Visual improvements should normally be applied to existing canonical pages.
§ 30
No Investor-Impressiveness Pages
Do not add pages solely intended to make the Data Room appear larger or more sophisticated. Sophistication should come from clarity, evidence, reconciliation, controlled reporting, and depth when required. Not page count.
§ 31 · ONE QUESTION — ONE PRIMARY DESTINATION
For every recurring investor question, designate one canonical destination. Do not create competing answers.
§ 32 · ONE FACT — ONE DATA SOURCE
Material recurring facts should come from one canonical data source. Pages should reference these facts. They should not independently own different copies.
§ 33 · ONE DOCUMENT — ONE CANONICAL FILE
Do not create multiple copies of:
Use canonical records and references.
§ 34
New-Page Warning
If a new investor-facing page is proposed without a completed New Investor Page Request, display: NEW PAGE GOVERNANCE REVIEW REQUIRED. Do not add the page automatically.
NEW PAGE GOVERNANCE REVIEW REQUIRED
§ 35
Duplication Warning
If proposed new content overlaps materially with an existing page, flag: EXISTING CANONICAL PAGE FOUND. Then identify canonical page, recommended subsection, evidence destination.
EXISTING CANONICAL PAGE FOUND
§ 36 · RELEASE CANDIDATE PROTECTION
Once a Release Candidate exists, no new investor-facing analytical page should enter that RC unless it resolves a documented RC issue, management approves it, or a new RC is created where material. This protects release discipline.
§ 37 · RC REVIEW FOCUS
After this governance rule is implemented, Release Candidate review should focus only on:
Not: feature expansion.
§ 38 · MANAGEMENT CHANGE REQUEST
Any material addition after RC freeze should use:
CONTENT CHANGE REQUEST
§ 39 · PAGE REMOVAL STILL ALLOWED
The No More Pages rule does NOT prohibit merging pages, removing pages from navigation, converting pages to drill-down, or moving content internally. Further simplification is encouraged.
§ 40
Page Count Should Trend Down or Stable
From this point, investor-facing analytical page count should generally remain stable or decrease through consolidation. A sustained increase should trigger CONTENT ARCHITECTURE REVIEW.
§ 41
Evidence Count May Increase
By contrast, source / evidence document count may increase naturally as rollout progresses, revenue begins, technical testing continues, and contracts are signed. This is positive. The distinction is: more evidence does not require more navigation complexity.
§ 43 · OPERATE MODE PRINCIPLES
In Operate Mode
But: the architecture remains stable.
§ 44–47 · INVESTOR EXPERIENCE & CONTINUITY
§ 44
Investor Experience Benefit
The objective is to make returning investors feel the business is moving without feeling the Data Room is constantly changing shape. Stable architecture improves investor familiarity, source traceability, DD speed, trust, and update comprehension.
§ 45
Returning Investor Experience
Returning investors should primarily see WHAT CHANGED, not WHERE DID EVERYTHING MOVE? Therefore preserve stable URLs where possible, stable category names, stable canonical pages, and stable KPI definitions. Update the content inside them.
§ 46
Waterhouse Continuity
Michael and Oscar have already built familiarity with the LOTOMIX materials. Do not force them to relearn a new architecture every time management improves the Data Room. After Release Candidate, focus on new evidence, updated actuals, and responses to their questions. Keep structure stable.
§ 47
Investor Communication Rule
When telling an investor something has changed, prefer: 'Rollout Reconciliation has been updated with the latest operating data.' rather than: 'We created a new rollout page.' This supports continuity.
PREFER:
"Rollout Reconciliation has been updated with the latest operating data."
RATHER THAN:
"We created a new rollout page."
§ 48 · FINAL GOVERNANCE DASHBOARD
Internal compact control showing:
0
Investor-Facing Pages
0
New Pages Pending Approval
target: 0
14
Canonical Pages
0
Pages Recommended for Merge
target: 0
0
Stale Pages
target: 0
0
New Evidence Added This Period
target: ↑
0
Material Data Updates
target: ↑
Desirable state: 0 unnecessary new pages while evidence continues to grow.
§ 49 · GOVERNANCE EXCEPTION REPORT
If a new page is eventually approved, record:
This helps prevent architecture creep.
§ 50 · FINAL MESSAGE
DATA ROOM CONSTRUCTION COMPLETE
The LOTOMIX Investor Data Room should now evolve through better evidence, updated actuals, stronger reconciliation and clearer investor responses — not through continuous expansion of the page architecture.
FINAL CONTROL
✗ Do not create additional investor-facing analytical pages by default.
✗ Do not create duplicate summaries.
✗ Do not create duplicate financial views.
✗ Do not create duplicate rollout explanations.
✗ Do not create duplicate evidence maps.
✗ Do not create duplicate Q&A systems.
✗ Do not freeze actual business data.
✗ Do not prevent new evidence from being uploaded.
✗ Do not prevent material corrections.
✗ Do not prevent a genuinely necessary page when management explicitly approves it.
THE FINAL RULE IS:
A NEW FACT UPDATES AN EXISTING PAGE.
A NEW DOCUMENT STRENGTHENS THE EVIDENCE.
A NEW QUESTION UPDATES THE Q&A.
A NEW RISK UPDATES THE RISK REGISTER.
A NEW KPI UPDATES THE COCKPIT.
A NEW PAGE IS THE EXCEPTION.
Content governance operates under the current authorised-investor visibility policy.
Regression Test del Data Room de Inversores
Verificar automáticamente que cada actualización material permanezca consistente en todo el paquete de inversores.
Investor Data Room Regression Test
Automatically verify that every material update remains consistent across the full investor package
The purpose of this control is to prevent a correct update in one section from creating an inconsistency elsewhere in the Investor Data Room. From this point forward, every MATERIAL change should trigger a regression review across all affected investor-facing surfaces.
THIS CONTROL MUST NOT:
✗ automatically change signed source documents;
✗ automatically modify BC assumptions;
✗ automatically publish;
✗ automatically change commercial or legal status without evidence.
CHANGE ONCE → TEST EVERY DEPENDENCY → UPDATE CURRENT REFERENCES → PRESERVE HISTORY → VERIFY CONSISTENCY
THE PROCESS
CHANGE
IDENTIFY DEPENDENCIES
TEST ALL REFERENCES
FLAG CONFLICTS
UPDATE APPROVED SURFACES
VERIFY AGAIN
§ 1 · DEFINE MATERIAL UPDATES
A regression test should be triggered whenever any of the following changes:
Network Metrics
Rollout
Financial
Commercial
Technology
Legal / Regulatory
Corporate
Fundraising
Minor cosmetic changes should NOT trigger a full regression test.
§ 2 · CREATE THE CHANGE EVENT
For every material update create:
MATERIAL DATA CHANGE EVENT
Previous
Previous installed readers: 370
New
New installed readers: 420
This event should trigger the dependency check.
§ 3 · BUILD A DEPENDENCY MAP
For each canonical metric, identify every page / document generated from it.
INSTALLED LOCATIONS
May affect:
The system should not rely on someone remembering every reference manually.
§ 4 · TEST NETWORK METRIC UPDATES
If any of the following change, search every current investor-facing occurrence:
Flag: NETWORK REGRESSION — if any page still uses an obsolete value or outdated meaning.
§ 5 · DO NOT BLINDLY REPLACE NUMBERS
A change from 370 → 420 must NOT automatically replace every occurrence of 370 because some occurrences may refer to historical snapshots, original investment case, old investor deck, or prior monthly reports.
This is essential.
§ 6 · PRESERVE HISTORICAL INVESTMENT CASES
If a metric changes after RC1, Investor Summary V1, or a prior investor report, do NOT rewrite the historical version.
RC1
RC1 recorded: 370 existing readers
LATER
Later actual: 420 existing readers
CURRENT PAGES
Current pages should show: 420
RC1 REMAINS
while RC1 remains: 370 as of [date]
This preserves auditability.
§ 7 · ROLLOUT DATE REGRESSION
If rollout timing changes, check:
Do not silently rewrite original milestones.
§ 8 · HARDWARE REGRESSION
If any hardware specification changes, check every current investor-facing reference to reader, rear display, and large display.
If specification changes from 43-inch to another approved commercial specification: update current product / rollout materials.
Preserve historical contractual references. Never edit signed contracts.
§ 9 · FINANCIAL MODEL REGRESSION
If a new BC version is approved, trigger a full financial regression.
Flag: OUTDATED FINANCIAL MODEL REFERENCE
§ 10 · DO NOT AUTO-REPLACE BC VERSIONS
A new BC must first be formally approved, then designated current. Only then should generated current investor content update. Historical materials must retain their original model reference.
§ 11 · FINANCIAL NUMBER REGRESSION
For every changed financial assumption, test the entire chain:
Flag: FINANCIAL REGRESSION FAILURE
§ 12 · GTV / REVENUE REGRESSION
Whenever transaction or peñas economics change, recheck that GTV remains separate from LOTOMIX recognised revenue across tables, charts, summaries, one-pager, and KPI Cockpit.
This control should run every time digital economics are updated.
§ 13 · FENAMIX ECONOMICS REGRESSION
Any modification to large-format advertising economics must trigger a check that 30% FENAMIX share remains applied only to the correct revenue perimeter.
Flag: FENAMIX ECONOMICS REGRESSION
§ 14 · COMMERCIAL STATUS REGRESSION
If a commercial counterparty moves from one status to another:
Update:
Flag: COMMERCIAL STATUS REGRESSION
§ 15 · DO NOT RETROACTIVELY CHANGE OLD COMMERCIAL STATUS
Historical investor reports should continue to show the status that existed at that date.
September: Pilot
October: Contracted
The September report should not be rewritten.
§ 16 · FIRST REVENUE REGRESSION
MODELLED / PRE-COMMERCIAL → ACTUAL REVENUE
Do not automatically classify the revenue as recurring until repeat evidence exists.
§ 17 · REPEAT REVENUE REGRESSION
FIRST REVENUE → REPEAT / OBSERVED RECURRING
Preserve earlier maturity records historically.
§ 18 · TECHNOLOGY STATUS REGRESSION
Check:
§ 19 · DO NOT OVER-UPGRADE TECHNOLOGY STATUS
A new successful test should not automatically change TESTED to PROVEN AT SCALE. The required evidence must match the maturity definition. Regression testing must validate not only consistency but correctness of the new status.
§ 20 · LEGAL STATUS REGRESSION
If legal counsel updates a feature status, check all references to authorised, approved, permitted, legal, and reviewed. Update only the scope supported by the new evidence.
Legal confirmation on peñas must not automatically update wallet, payments, or complete app regulatory status.
§ 21 · CORPORATE REGRESSION
Triggers
Update
Preserve historical corporate snapshots.
§ 22 · FUNDRAISING REGRESSION
If financing parameters change, for example:
Check
Do not update signed transaction documents automatically.
§ 23
Evidence Regression
When a new piece of evidence is added, check whether any status should legitimately change.
Actual paid campaign evidence may affect Commercial Proof, Evidence Map, Evidence Gap Closure, and Proof Progression. But do not upgrade unrelated sections automatically.
§ 24
Evidence Removal / Invalidation
If evidence is later found to be outdated, incorrect, invalid, or superseded, flag all claims that depend on it.
Flag: EVIDENCE DEPENDENCY FAILURE
Affected claims should not remain marked VERIFIED without another supporting source.
§ 25
Pipeline Freshness Regression
Do not simply increase the number over time. The latest pipeline should represent the approved current definition. If methodology changes, document it.
§ 26
KPI Definition Regression
Example: Completed Location
Do not silently redefine the KPI.
§ 27
Actual Data Regression
As actual data replaces assumptions, do not remove the original assumption. Show Original BC Assumption vs Actual vs Current Forecast where relevant.
This allows investors to evaluate forecast quality.
§ 28
One-Pager Regression
Every material update should check whether the Investor Summary One-Pager remains current. Because this file may circulate outside the live Data Room, any stale material number should trigger:
Flag: ONE-PAGER UPDATE REQUIRED
Do not rely solely on the live website being correct.
§ 29
PDF / Export Regression
Similarly check exported IC dashboard, downloadable summaries, and investor PDFs. A material web update may leave exported documents stale.
Flag: EXPORTED INVESTOR MATERIAL OUTDATED
§ 30
Waterhouse Deck Regression
Do NOT automatically edit the Waterhouse deck. But whenever a material canonical fact changes, check whether the current deck is affected. If yes, flag:
WATERHOUSE DECK UPDATE REVIEW REQUIRED
Management / Oscar decides whether the deck should change.
§ 31
Q&A Regression
Whenever a material fact changes, search Investor Questions Answered Tracker and IC Objection Handling Pack for affected approved answers.
Flag: ANSWER REQUIRES REVIEW
Do not silently rewrite answers already sent historically. Update the current approved response version.
§ 32
Decision Matrix Regression
Whenever new evidence changes the status of an investment thesis, update the Final Investor Decision Matrix.
Advertising moves from commercial validation required to early actual evidence when paid campaign data exists.
Preserve historical snapshots.
§ 33
Risk Regression
A material change may reduce a risk, increase a risk, create a new risk, or close a risk. Check the Institutional Risk Register automatically.
hardware costs materially higher than plan → update hardware-cost risk.
Do not automatically close a risk simply because one positive data point exists.
§ 34
Downside Regression
If actual results materially diverge from Base, check whether the existing downside scenarios remain relevant.
Actual CPM falls below the current downside assumption.
Flag: DOWNSIDE MODEL MAY REQUIRE UPDATE
Do not update BC automatically.
§ 35
Value Creation Regression
As assumptions become evidence, update Value Creation / Proof Progression but preserve the original sequence.
This demonstrates evidence evolution.
§ 36
Evidence Gap Regression
When a gap closes, update Evidence Gap Closure Plan from VALIDATION REQUIRED to the correct evidence status.
Require
Do not close based on management assertion alone.
§ 37
Last Mile Pack Regression
Does this change one of the 10–20 Last Mile materials?
Do not allow reference to:
§ 38
Release Candidate Regression
If a material change occurs after RC freeze, determine whether it requires Minor RC fix or New RC. Use the existing RC governance rules.
Do not silently modify a frozen Release Candidate.
§ 39
Latest Updates
Any material regression-approved change should also be considered for Latest Material Updates. Use only investor-relevant changes.
Do not surface internal QA changes.
§ 40
Run Cross-Functional Tests
A single change may affect several disciplines.
A new payment architecture may affect Technology, Legal, Financial model, Product, Risk, and Q&A.
The regression test must detect cross-functional dependencies. Do not treat material changes as isolated updates.
§ 41 · CREATE REGRESSION SEVERITY
MATERIAL REGRESSION FAILURE
Investor could receive inconsistent or materially misleading information.
IMPORTANT REGRESSION FAILURE
Should be corrected before next investor circulation.
MINOR REGRESSION FAILURE
Formatting / non-material stale reference.
Do not create numeric severity scores.
§ 42 · MATERIAL REGRESSION EXAMPLES
§ 43 · CREATE THE REGRESSION REPORT
After each material update generate:
Material Update Regression Report
Change ID
Change Summary
Canonical Source Updated
Pages Tested
Documents Tested
Q&A Answers Tested
Conflicts Found
Material Conflicts
Updates Required
Historical References Preserved
Final Status
PASS only means no unresolved regression conflicts detected. It is not an investment-quality judgment.
§ 44 · FINAL REGRESSION STATUS
PASS
No unresolved current-content conflicts.
PASS WITH MINOR ITEMS
No material issue, minor clean-up remains.
REVIEW REQUIRED
Important inconsistency exists.
MATERIAL CONFLICT
Do not circulate updated investor material until reviewed.
This is an operational QA status only.
§ 45
Do Not Block Live Business Operations
Regression review should not prevent operating teams from installing locations, signing advertisers, updating pipeline, or running technology. It controls investor communication consistency, not business execution.
§ 46
Do Not Auto-Publish After Pass
Even if regression status is PASS, do not publish, email investors, change permissions, or release updated documents without explicit management instruction.
§ 47 · CREATE AN UPDATE PREVIEW
Before approving the current update for investors, show management Investor-Facing Changes.
This lets management see what investors will notice.
§ 48 · CREATE AN UNCHANGED HISTORICAL MATERIAL VIEW
Also show Historical Materials Intentionally Preserved.
This prevents someone mistakenly 'correcting' valid historical records.
§ 49 · UPDATE GOVERNANCE PRINCIPLE
The Investor Data Room is now a connected system. A material figure should not be thought of as text on one page but as ONE CANONICAL FACT with MULTIPLE CONTROLLED REFERENCES. The regression system protects this relationship.
§ 50 · FINAL OPERATING RULE
From this point forward:
New installation number → regression test.
New pipeline number → regression test.
New advertiser status → regression test.
New BC → regression test.
New legal status → regression test.
New technology maturity → regression test.
New fundraising term → regression test.
This should become automatic Data Room governance.
FINAL CONTROL
✗ Do not blindly global-replace numbers.
✗ Do not rewrite historical snapshots.
✗ Do not modify signed documents.
✗ Do not automatically modify the Waterhouse deck.
✗ Do not automatically alter BC.
✗ Do not upgrade statuses without evidence.
✗ Do not publish automatically.
THE CORE RULE IS:
This is how LOTOMIX should maintain ONE CURRENT INVESTMENT CASE without losing historical auditability.
ONE CURRENT INVESTMENT CASE · WITHOUT LOSING HISTORICAL AUDITABILITY
GOVERNANCE & QA · INVESTOR CONTROL
Tracker de Precisión de Previsiones y Credibilidad de Dirección
Seguir cómo las suposiciones originales y los previsiones posteriores de LOTOMIX se comparan con el rendimiento operativo real.
Forecast Accuracy & Management Credibility Tracker
Track how LOTOMIX's original assumptions and subsequent forecasts compare with actual operating performance
The purpose of this framework is to measure forecasting discipline over time. It allows investors and management to distinguish between the original investment case, subsequent management forecasts, actual performance, the reasons for material variance, and management's response to new evidence.
THIS FRAMEWORK ALLOWS INVESTORS AND MANAGEMENT TO DISTINGUISH BETWEEN:
• the original investment case;
• subsequent management forecasts;
• actual performance;
• the reasons for material variance;
• management's response to new evidence.
THIS FRAMEWORK MUST NOT CREATE:
✗ a management score;
✗ a credibility score;
✗ a probability of execution success;
✗ a rating of management quality.
THE OBJECTIVE IS FACTUAL FORECASTING ACCOUNTABILITY
THE PERMANENT FRAMEWORK
ORIGINAL PLAN
LATEST FORECAST
ACTUAL
VARIANCE
EXPLANATION
MANAGEMENT RESPONSE
§ 1 · PRESERVE THE ORIGINAL INVESTMENT CASE
Use BC 6.7 as the baseline investment-case forecast where applicable. Never retrospectively modify BC 6.7 to improve apparent forecasting accuracy.
For each material KPI preserve:
This becomes the permanent benchmark.
§ 2 · CREATE THE MASTER FORECAST-ACCURACY TABLE
| KPI | Original Plan | Latest Forecast | Actual | Variance vs Original | Variance vs Latest Forecast | Explanation |
|---|---|---|---|---|---|---|
| — | — | — | — | — | — | — |
Include only material decision-useful metrics. Do not attempt to track every line in the financial model.
§ 3 · TRACK NETWORK / ROLLOUT FORECASTING
For each period show:
This provides visibility into whether rollout timing is consistently:
Do not create evaluative labels such as: "good forecasting" or "poor forecasting". Show the evidence.
§ 4 · TRACK THE 770 MILESTONE
Original Management Target
Approximately 770 completed locations by April 2027
Then show over time:
If the expected completion date changes, preserve every meaningful forecast revision. Do not overwrite the original target date.
§ 5 · TRACK INSTALLATION VELOCITY
Then show:
This helps identify whether rollout deviation is:
Do not infer causation automatically. Use percentage variance only where mathematically meaningful.
§ 6 · TRACK ACTIVATION FORECASTING
Installation is not enough. Also compare:
This reveals whether management forecasts commercially useful deployment rather than only hardware movement.
§ 7 · TRACK ADVERTISING FILL FORECASTING
Once commercial data exists, compare:
Break down by screen format where relevant:
This should become one of the most important commercial forecast-accuracy views.
§ 8 · TRACK CPM / REALISED PRICING
Where current reader planning reference is:
€6–€9 CPM
Preserve the exact BC 6.7 assumption relevant to the reporting period. Do not use the entire range as one forecast if BC 6.7 uses a specific value.
§ 9 · TRACK TRAFFIC
Where the original reference uses:
800 visits/day
Where traffic varies materially by location, include in drill-down:
Do not judge forecast quality from a single site.
§ 10 · TRACK CAPTURE / INTERACTION
Original planning reference where applicable:
30%
This provides direct evidence of whether the reader-interaction model was realistic.
§ 11 · TRACK ADVERTISING REVENUE
Break down where decision-useful:
Ensure gross and LOTOMIX net are treated consistently.
§ 12 · TRACK FENAMIX ECONOMICS
For large-format advertising, compare:
ORIGINAL
• Original Gross Revenue
• Original FENAMIX Share
• Original LOTOMIX Net
ACTUAL
• Actual Gross Revenue
• Actual FENAMIX Share
• Actual LOTOMIX Net
This verifies whether both commercial performance and contractual economics are being forecast correctly.
§ 13 · TRACK SAAS
Compare:
Then:
Do not use activated locations as a proxy for paying SaaS unless they are actually paying.
§ 14 · TRACK DIGITAL USER FORECASTING
Compare:
Then separately:
Do not evaluate digital forecast quality based only on downloads.
§ 15 · TRACK TRANSACTION BEHAVIOUR
Then separately:
Maintain: GTV ≠ Revenue
§ 16 · TRACK MEMBERSHIP CONVERSION
Current model reference where applicable:
2.5%
Also show:
This demonstrates whether modelled paid conversion aligns with user behaviour.
§ 17 · TRACK PEÑAS
Then:
Do not interpret unlaunched / legally pending functionality as forecast error until the intended commercial period actually begins.
§ 18 · TRACK UNIT ECONOMICS
Once representative actual data exists, compare:
Then:
This is one of the strongest tests of forecast credibility.
§ 19 · TRACK HARDWARE COSTS
Break down by:
Then include:
This measures capital-planning accuracy.
§ 20 · TRACK OPEX
Compare material categories:
Do not change classifications simply to reduce variance.
§ 21 · TRACK REVENUE
At company level compare:
Then explain the main bridge drivers:
Use actual model outputs where available.
§ 22 · TRACK EBITDA
Then show the principal causes of variance:
Do not use unexplained 'other' as the primary variance bucket where detail exists.
§ 23 · TRACK CASH
Then:
Runway itself is forward-looking, so do not label an original runway figure as Actual.
§ 24 · TRACK CAPITAL DEPLOYMENT
Compare by material category:
Then show Output Created:
This links forecast accuracy to capital productivity.
§ 25 · CREATE VARIANCE CLASSIFICATIONS
Do not classify variance as: "good", "bad", "success", "failure". Use factual causes.
TIMING
Activity occurred later / earlier.
VOLUME
Lower / higher quantity.
PRICE
Realised price differs.
MIX
Revenue / cost mix differs.
COST
Actual cost differs.
SCOPE
Execution scope changed.
EXTERNAL
Material third-party factor.
MODEL ASSUMPTION
Original assumption proved inaccurate.
Allow multiple classifications.
§ 26 · CREATE A VARIANCE WATERFALL
For major metrics such as:
Show:
Only use mathematically reconciled impacts. Do not estimate explanatory impacts manually if the financial model cannot support them.
§ 27 · DISTINGUISH TIMING FROM ECONOMIC UNDERPERFORMANCE
This is critical. A location installed one month late may create timing variance without proving weaker mature unit economics. Similarly, low early fill may represent commercial ramp rather than mature network performance.
The tracker should distinguish:
§ 28 · TRACK FORECAST REVISIONS
Every material current-forecast revision should be stored.
Then compare each with eventual Actual.
This allows management and investors to see whether forecasts become more accurate as the period approaches. Do not retain only Original and Final Actual.
§ 29 · CREATE FORECAST VINTAGES
For important reporting periods, preserve forecast snapshots such as:
Only where reporting cadence supports it. Do not create artificial historical forecasts retroactively.
§ 30 · FORECAST ACCURACY BY HORIZON
Where enough history exists, show how forecast variance changes by horizon.
This can help investors understand planning visibility. Do not produce this analysis before sufficient forecast vintages exist.
§ 31 · DO NOT CREATE A 'MANAGEMENT ACCURACY SCORE'
No: 8/10; 90%; grade; star rating; credibility score.
Forecast accuracy varies by metric and horizon. Show the underlying data.
§ 32 · CREATE A 'FORECAST BIAS' VIEW ONLY WHEN ENOUGH DATA EXISTS
Once sufficient history exists, examine whether forecasts have systematically overestimated or underestimated specific metrics.
Use wording such as: "Historical forecasts have tended to be above / below actual outcomes for this metric over the observed period."
Use descriptive statistics. Do not infer intent. Only once data supports it.
§ 33 · TRACK ASSUMPTION CHANGES
When management changes a model driver, record:
Original Assumption
New Assumption
Date
Evidence Trigger
Financial Impact
Example
Original CPM → actual campaigns → revised current forecast CPM.
This demonstrates evidence-led forecasting.
§ 34 · DISTINGUISH RESPONSIVE FORECASTING FROM FORECAST DRIFT
A forecast should change when actual data changes, commercial conditions change, rollout changes, or costs change. But frequent unexplained changes may reduce comparability. Therefore every material forecast change should have:
EVIDENCE-BASED RATIONALE
Do not allow silent model drift.
§ 35 · CREATE 'WHAT MANAGEMENT LEARNED' FIELD
For material variance only, allow a concise field:
Learning / Implication
Examples:
• installation lead time longer than assumed
• advertiser sales cycle shorter / longer
• reader capture differs by location type
• hardware cost lower / higher than forecast
Keep it factual. Do not use motivational language.
§ 36 · CREATE 'MANAGEMENT RESPONSE' FIELD
For material adverse variance show:
Example
Lower fill → refocus commercial activity / adjust deployment pace.
Do not imply mitigation will necessarily eliminate the variance.
§ 37 · POSITIVE VARIANCE DISCIPLINE
Where Actual exceeds forecast, show why.
Do not immediately extrapolate the positive variance indefinitely. Require repeat evidence before changing long-term assumptions materially.
§ 38 · NEGATIVE VARIANCE DISCIPLINE
Where Actual underperforms, show:
Do not: remove the KPI; redefine the metric; shift the comparison period. Do not [the above] to improve appearance.
§ 39 · FORECAST ACCURACY AND RISK REGISTER
Persistent variance should affect relevant risks.
Link automatically for review. Do not change risk status automatically without management confirmation.
§ 40 · FORECAST ACCURACY AND EVIDENCE GAPS
When actuals become available, close / evolve relevant evidence gaps.
Traffic assumption → actual traffic history.
The Forecast Accuracy Tracker should link to the same operating evidence.
§ 41 · FORECAST ACCURACY AND INVESTMENT THESIS
Update the thesis with:
Network conversion thesis: original rollout plan vs actual activation vs current forecast.
This is more informative than simply stating 'thesis validated / invalidated'.
§ 42 · FORECAST ACCURACY AND IC DASHBOARD
Once sufficient actual history exists, the 60-second IC Dashboard should show where appropriate:
Do not overcrowd it with all variance analysis. Link to this tracker for detail.
§ 43 · FORECAST ACCURACY AND INVESTOR REPORTING
Quarterly investor reporting should include a concise Forecast Accuracy section.
Show only material areas such as:
Then: Full Forecast Accuracy Tracker →
Do not make every monthly report a retrospective forecasting audit.
§ 44 · FORECAST ACCURACY AND LAST MILE PACK
Before future fundraising / financing rounds, this history can provide strong evidence on planning discipline, actual execution, and forecast evolution.
Include only if sufficient history exists. Do not use immature data to make broad management-credibility claims.
§ 45 · FORECAST ACCURACY AND NEW BC VERSIONS
If a new formally approved long-term model replaces BC 6.7 for current forecasting purposes, preserve BC 6.7 as Original Investment Case. Then track the newer model as Current Strategic / Financial Plan.
Preserve BC 6.7 as:
Original Investment Case
Track newer model as:
Current Strategic / Financial Plan
Do not erase the forecasting benchmark used by original investors.
§ 46 · CREATE AN 'ORIGINAL CASE VS REALITY' VIEW
Once enough operating history exists, create a concise investor-facing table:
| Metric | Original Investment Case | Actual to Date | Current Outlook |
|---|---|---|---|
| locations | — | — | — |
| advertising | — | — | — |
| revenue | — | — | — |
| EBITDA | — | — | — |
| cash | — | — | — |
Do not expose every model line. This can become a very powerful transparency tool.
§ 47 · SAMPLE-SIZE CONTROL
Do not judge forecast quality from one month, one advertiser, one location, or one cohort unless the metric itself is meant to be assessed at that level.
Label: EARLY DATA
§ 48 · PERIOD CONSISTENCY
Ensure comparisons use equivalent periods.
Do not compare:
✗ full-month forecast vs partial-month actual without adjustment
✗ annual run-rate vs actual annual revenue as equivalent metrics
§ 49 · CURRENCY / ACCOUNTING CONSISTENCY
Use the same:
Between Plan, Forecast and Actual. Otherwise variance analysis is meaningless.
§ 50 · DATA SOURCE CONTROL
• Every Actual must identify its source.
• Every Original Plan must identify its model version.
• Every Current Forecast must identify forecast version and forecast date.
This should make every comparison reproducible.
§ 51 · CREATE A FORECAST VERSION REGISTER
| Forecast Version | Date | Data Cut-Off | Key Changes | Status |
|---|---|---|---|---|
| — | — | — | — | — |
Statuses:
Only one current forecast should exist at a time.
§ 52 · CREATE A FORECAST CHANGE SUMMARY
Whenever a new forecast becomes current, produce:
What Changed in the Forecast?
Maximum 5–7 material items.
Examples:
• slower rollout
• stronger advertiser pricing
• higher hardware cost
• lower OPEX
• delayed digital monetisation
This should be easier for investors to understand than comparing two full models manually.
§ 53 · FORECAST ACCURACY HISTORY
Maintain a history by quarter / reporting period. This should allow future review of how much was forecast, what actually occurred, and how forecasts evolved.
Do not delete old forecasts after they are superseded.
§ 54 · NO HINDSIGHT EDITING
Critical:
Critical: Do not edit the original forecast after Actual is known. Do not update old narrative to make the prediction appear more accurate.
Preserve exactly what management expected at the time.
§ 55 · INVESTOR-FACING USE
This tracker should initially remain primarily INTERNAL / GOVERNANCE. A concise investor-facing version may later be used once sufficient operating history exists.
Do not overwhelm current fundraising materials with an accuracy tracker before meaningful Actual data exists.
§ 56 · WHEN TO SURFACE TO INVESTORS
Investor-facing Forecast Accuracy becomes particularly valuable when:
Until then, prepare the infrastructure but keep the view secondary.
§ 57 · FORECASTING DISCIPLINE PRINCIPLE
The objective is not for every forecast to be exact. Early-stage businesses operate under uncertainty. The objective is to demonstrate:
✓ assumptions are explicit
✓ actual variance is visible
✓ management updates forecasts when evidence changes
✓ original forecasts are preserved
✓ explanations are factual
✓ capital decisions respond to actual performance
§ 58 · INTERNAL DASHBOARD
KPIs with Actual Data
[count]
KPIs Still Primarily Modelled
[count]
Material Variances This Period
[count]
Forecast Assumptions Updated
[count]
Forecast Version
[current version]
Current Forecast Data Cut-Off
[date]
No credibility score.
§ 59 · FINAL INVESTOR VALUE
Over time, the strongest evidence this tracker can produce is not 'management always forecasts perfectly'. It is:
management makes explicit assumptions, measures actual results against them, updates expectations transparently and preserves accountability for the original investment case.
This is the intended governance signal.
§ 60 · FINAL PRINCIPLE
WHAT WE SAID WOULD HAPPEN
WHAT WE LATER EXPECTED
WHAT ACTUALLY HAPPENED
WHY IT WAS DIFFERENT
WHAT WE NOW EXPECT
This should become part of LOTOMIX's post-investment operating discipline.
FINAL CONTROL
✗ Do not create a management score.
✗ Do not retroactively alter BC 6.7.
✗ Do not alter old forecasts after Actual is known.
✗ Do not hide adverse variance.
✗ Do not extrapolate one positive datapoint aggressively.
✗ Do not change KPI definitions without disclosure.
✗ Do not compare incompatible periods.
✗ Do not treat Current Forecast as Actual.
✗ Do not publish this framework prominently until sufficient operating history exists.
THE GOVERNING RULE IS:
SAVE ALL CHANGES IN THE EDITOR ONLY. DO NOT PUBLISH.
¿Qué Ha Cambiado Desde la Inversión?
Una comparación directa entre la línea base de inversión del Día 0 y la posición operativa actual de LOTOMIX.
What Changed Since Investment?
A direct comparison between the Day 0 investment baseline and LOTOMIX's current operating position
The purpose of this section is to show investors clearly what has changed since investment completion.
THIS PAGE SHOULD ANSWER:
• What operating capacity has been created?
• What commercial evidence has been generated?
• Which assumptions have become actual data?
• How has capital been deployed?
• How has the investment thesis evolved?
THE PRINCIPAL COMPARISON MUST BE:
Do not compare only against the latest forecast. Preserve the original investment baseline.
§ 1 · LOCK THE DAY 0 BASELINE
DAY 0 INVESTOR BASELINE
At closing, create an immutable Day 0 Investor Baseline. Capture the actual position at investment completion.
Network
Screens
Commercial
SaaS
Digital
Financial
Technology
Legal / Regulatory
This baseline must never be rewritten retrospectively.
§ 2 · CREATE THE MASTER DAY 0 VS TODAY TABLE
| KPI | Day 0 | Today | Change | Current Status |
|---|---|---|---|---|
| Activated Locations | — | — | — | — |
| Monetised Locations | — | — | — | — |
| Monthly Revenue | — | — | — | — |
| EBITDA | — | — | — | — |
| Cash | — | — | — | — |
| Runway | — | — | — | — |
Only include decision-useful metrics. Do not overload the table with every KPI available.
§ 3 · NETWORK GROWTH
This should visually distinguish:
Do not use only total installed locations as evidence of progress.
§ 4 · PIPELINE
But also show: Pipeline Converted Since Investment
This is more important than pipeline growth alone.
Use the funnel:
Do not present a larger pipeline as sufficient evidence of execution.
§ 5 · SCREEN ESTATE
Show Day 0 vs Today for:
Then: Total Active Screens
Where possible distinguish:
§ 6 · COMMERCIAL ADVERTISING PROGRESS
Compare Day 0 vs Today for:
Active Advertisers
Day 0 → Today
Paid Campaigns
Day 0 → Today
Repeat Advertisers
Day 0 → Today
Advertising Fill
Day 0 → Today
Realised CPM / Effective Price
Day 0 → Today
Advertising Revenue
Day 0 → Today
Do not use theoretical advertising inventory as commercial progress.
§ 7 · REPEAT ADVERTISER PROOF
First Campaign → Repeat Campaign
Day 0
Current repeat-advertiser evidence.
Today
Current repeat-advertiser evidence.
Repeat purchasing is stronger evidence than initial advertiser interest.
§ 8 · ADVERTISING ECONOMICS
Show where available:
CPM
• Model CPM at Investment
• Actual Realised CPM Today
• Current Forecast CPM
FILL
• Model Fill at Investment
• Actual Fill Today
• Current Forecast Fill
This allows investors to see which assumptions have become real operating data.
§ 9 · LARGE-FORMAT ECONOMICS
Where commercially active, compare Day 0 vs Today:
Maintain: 30% FENAMIX share applies only to large-format advertising revenue.
Do not blend with reader / rear-display revenue.
§ 10 · SAAS PROGRESS
Compare Day 0 vs Today:
Paying Administrations
Day 0 → Today
SaaS MRR
Day 0 → Today
Paying Penetration
Day 0 → Today
Retention / Churn
Day 0 → Today
Where Day 0 had no material SaaS revenue, show this rather than using model values. Show: €0 / not commercially active
§ 11 · DIGITAL PROGRESS
Compare where commercially active:
Downloads
Day 0 → Today
Registered Users
Day 0 → Today
MAU
Day 0 → Today
Transactions
Day 0 → Today
Transactions per MAU
Day 0 → Today
Paying Users
Day 0 → Today
Membership MRR
Day 0 → Today
Peña Participants
Day 0 → Today
Do not show downloads alone as evidence of successful digital execution.
§ 12 · GTV VS REVENUE
Show separately:
GTV Day 0 → Today
LOTOMIX Recognised Transaction Revenue Day 0 → Today
Maintain the distinction visibly. Do not aggregate GTV into company revenue.
§ 13 · REVENUE PROGRESS
Monthly Recognised Revenue
Day 0
Starting Position
Today
Actual Today
Original BC 6.7 Plan for Current Period
Original Plan
Current Forecast
Latest Outlook
This gives four useful reference points.
§ 14 · REVENUE MIX EVOLUTION
Where sufficient actual data exists, compare:
Possible categories:
This shows which revenue streams are actually becoming material.
§ 15 · CONTRIBUTION
Compare:
Then, where available: Contribution per Monetised Location
This becomes one of the strongest indicators of network economics.
§ 16 · EBITDA
Day 0 EBITDA
Today EBITDA
Original BC 6.7 Current-Period EBITDA
Current Forecast EBITDA
Do not replace actual EBITDA with adjusted management metrics unless separately approved.
§ 17 · CASH
This should make capital utilisation extremely transparent.
§ 18 · CAPITAL DEPLOYMENT
What Has the Capital Produced?
| Capital Category | Deployed Since Closing | Operating Output Created |
|---|---|---|
| Technology | — | production / scale capability |
| Hardware | — | deployed devices |
| Installations | — | activated locations |
| Commercial | — | paid campaigns / advertisers |
| Digital | — | active / monetised users |
| Working Capital | — | operating runway |
All amounts must reconcile with current finance reporting.
§ 19 · CAPITAL REMAINING
Investment Proceeds
minus Capital Deployed
minus Committed Capital where appropriate
equals Available Capital
Do not confuse available cash with unallocated financing proceeds if operating cash flows have also changed. Use finance definitions consistently.
§ 20 · USE OF FUNDS VS ACTUAL
| Category | Original Use of Funds | Actual Deployed | Variance |
|---|---|---|---|
| Technology | — | — | — |
| Hardware | — | — | — |
| Installations | — | — | — |
| Commercial | — | — | — |
| Digital | — | — | — |
| Working Capital | — | — | — |
Then add: Explanation for material variance.
Do not rebase the original allocation.
§ 21 · TECHNOLOGY PROGRESS
Compare Day 0 vs Today for major maturity areas:
Core Platform
Day 0 → Today
Production Readiness
Day 0 → Today
Monitoring
Day 0 → Today
Device Management
Day 0 → Today
Ticket Validation
Day 0 → Today
Scale Testing
Day 0 → Today
Security
Day 0 → Today
Use maturity labels such as:
Use maturity labels only where evidence supports them.
§ 22 · TECHNOLOGY EVIDENCE CREATED
Show the most material evidence generated since investment:
Do not use ordinary development tasks as headline achievements.
§ 23 · LEGAL / REGULATORY PROGRESS
Examples where applicable:
Show:
Do not imply broader authorisation than supporting legal evidence permits.
§ 24 · COMMERCIAL PROOF CREATED
New Commercial Evidence Since Investment
✓ New Contracted Advertisers
✓ First Paid Campaign
✓ Repeat Campaign
✓ New Paying SaaS Administrations
✓ First Transaction Revenue
✓ Membership Revenue
✓ Peña Revenue
Only include actual commercial evidence.
§ 25 · ASSUMPTIONS REPLACED BY ACTUALS
⚠ PROMINENT SECTION
This should be a prominent section.
| Original Assumption | Actual Evidence Now Available | Status |
|---|---|---|
| Traffic | — | — |
| Capture Rate | — | — |
| Fill | — | — |
| CPM | — | — |
| SaaS MRR | — | — |
| MAU | — | — |
| Transaction Frequency | — | — |
| Hardware Cost | — | — |
| Location Contribution | — | — |
This directly demonstrates de-risking.
§ 26 · EVIDENCE MATURITY PROGRESSION
For each important area show current maturity. Do not create a composite score.
§ 27 · INVESTMENT THESIS PROGRESS
For each principal thesis show:
Example: Advertising Thesis
Day 0:
model assumptions + commercial pipeline
Today:
actual paid campaigns + realised fill / CPM
Remaining:
repeatability at broader scale
This is much more informative than 'validated / not validated'.
§ 28 · PROOF PROGRESSION
Different revenue streams may sit at different stages. Do not collapse the whole company into one stage.
§ 29 · WHAT HAS BEEN DE-RISKED?
Evidence Strengthened Since Investment
Only include areas where actual evidence genuinely improved. Examples:
Use: "Evidence strengthened" rather than "risk eliminated".
§ 30 · WHAT REMAINS UNPROVEN?
What Still Requires Validation?
This should be updated honestly. Possible areas:
Do not remove an uncertainty merely because execution has begun.
§ 31 · ORIGINAL PLAN VS TODAY
Create a compact table:
| Area | Original Investment Case | Today | Current Outlook |
|---|---|---|---|
| rollout | — | — | — |
| advertising | — | — | — |
| digital | — | — | — |
| revenue | — | — | — |
| EBITDA | — | — | — |
| cash | — | — | — |
This should be one of the most important investor-reporting views.
§ 32 · MILESTONE PROGRESS
December 2026
Original
broad commercial rollout target
Current
actual status
March 2027
Original
additional display deployment
Current
actual status
April 2027
Original
approximately 770 completed locations
Current
actual status
Never change the Original column.
§ 33 · MILESTONE EVIDENCE
Completed: View Completion Evidence →
For incomplete milestones show:
Do not simply relabel delayed milestones.
§ 34 · VALUE CREATED THROUGH EVIDENCE
Do NOT calculate a future company valuation. Instead show:
At Day 0
more of the case depended on assumptions.
Today
a greater / different proportion is supported by actual operating data.
Do not quantify this as a percentage unless a formal methodology later exists. Use specific evidence examples.
§ 35 · 'WHAT €3M HAS BOUGHT SO FAR'
What the Investment Has Enabled
Show only measurable outputs. Examples:
✓ technology milestones completed
✓ hardware deployed
✓ locations activated
✓ advertisers converted
✓ revenue generated
✓ actual unit-economics data
✓ operating runway
Avoid vague:
§ 36 · DO NOT CONFUSE ACTIVITY WITH OUTPUT
Do not report as capital impact:
Focus on:
Do not report activity as capital impact unless it leads to measurable output.
§ 37 · DAY 0 DATA QUALITY
Where Day 0 data was:
Preserve the original Day 0 snapshot but explain any later correction separately. Do not rewrite history.
§ 38 · CURRENT DATA QUALITY
Each Today metric should show where appropriate:
This prevents current operating updates from appearing more certain than they are.
§ 39 · INVESTOR UPDATE HEADER
Since Investment
Day 0 → Current Position
Then display:
Investment Date
[—]
Current Reporting Date
[—]
Current Financial Model
[—]
Current Forecast
[—]
Data Cut-Off
[—]
§ 40 · EXECUTIVE TOP ROW
Create a compact top row with approximately six metrics:
Activated Locations
Monetised Locations
Advertising Fill
Monthly Recognised Revenue
Capital Deployed
Current Runway
Do not overload the header.
§ 41 · QUARTERLY USE
This page should be refreshed as part of quarterly investor reporting. It should not require creating a new page every quarter.
Retain historical snapshots separately.
§ 42 · HISTORICAL SNAPSHOTS
Preserve:
This allows investors to see progression over time.
Do not overwrite previous quarterly versions.
§ 43 · INVESTOR REPORTING CROSS-LINK
Link directly to:
This provides deeper context where required.
§ 44 · RISK CROSS-LINK
If a major metric materially underperforms, link to the relevant Risk Register and Management Action.
Do not hide adverse movement.
§ 45 · EVIDENCE CROSS-LINK
Every material improvement should link to evidence.
§ 46 · IC USE CASE
A Waterhouse partner should be able to open this page after investment and answer in approximately two minutes:
? What has changed?
? What has the capital created?
? Which assumptions have become actual?
? Which milestones are achieved?
? Which assumptions remain open?
? Is execution tracking the original investment case?
§ 47 · DO NOT CREATE A SUCCESS SCORE
No:
Show:
§ 48 · DO NOT TURN VARIANCE INTO SPIN
If:
• rollout is behind
• revenue is lower
• cash burn is higher
Show it clearly. Then show:
Do not hide it beneath cumulative growth metrics.
§ 49 · POSITIVE PERFORMANCE
Likewise, if performance is ahead, show:
Do not extrapolate one positive quarter indefinitely.
§ 50 · FINAL INVESTOR SUMMARY
Day 0 → Today
This view tracks how LOTOMIX has converted investment capital into operating capacity, commercial evidence and financial performance since closing.
The original investment case remains preserved as the benchmark, while current actuals and the latest forecast show how execution has evolved.
Progress is therefore assessed not only through network growth, but through the conversion of installations into monetised locations, model assumptions into actual data, and capital into measurable operating evidence.
§ 51 · NAVIGATION
Cross-link from:
CTA: View Day 0 vs Today →
This should become prominent only after investment. It should not dominate the current fundraising Data Room before a Day 0 baseline exists.
FINAL CONTROL
✗ Do not create Day 0 using forecast values.
✗ Do not rewrite Day 0 later.
✗ Do not present pipeline growth as execution by itself.
✗ Do not present hardware purchased as value created by itself.
✗ Do not treat GTV as revenue.
✗ Do not treat first revenue as repeat revenue.
✗ Do not treat tested technology as scale validation.
✗ Do not calculate future company valuation.
✗ Do not hide adverse variance.
THE PERMANENT FRAMEWORK MUST BE:
This should become the clearest post-investment answer to:
WHAT HAS CHANGED SINCE WE INVESTED?
Post-investment reporting operates under the current authorised-investor visibility policy.
Revisión Trimestral: Tesis vs Realidad
Cómo la tesis de inversión original de LOTOMIX se compara con la evidencia operativa real cada trimestre.
Quarterly Thesis vs Reality Review
How the original LOTOMIX investment thesis compares with actual operating evidence each quarter
The purpose of this section is to ensure that quarterly investor reporting remains anchored to the original reasons for investing.
THIS IS NOT INTENDED TO BE:
✗ another operating report
✗ another financial forecast
✗ a management score
✗ a pass / fail assessment of the investment
✗ an opportunity to rewrite the original thesis
THE PERMANENT STRUCTURE SHOULD BE:
The original investment thesis must remain historically preserved.
§ 1 · LOCK THE ORIGINAL INVESTMENT THESIS
At investment closing, preserve the principal theses exactly as they existed at that time.
Use the current Investment Thesis Validation section as the baseline.
Each thesis should receive:
• Thesis ID
• Original Wording
• Original Evidence
• Original Remaining Question
• Baseline Date
Do not rewrite original thesis language after actual results become known.
§ 2 · CREATE THE MASTER QUARTERLY MATRIX
| Investment Thesis | Original Position | Evidence This Quarter | Current View | Next Validation |
|---|---|---|---|---|
| T1 Network | — | — | — | — |
| T2 Rollout | — | — | — | — |
| T3 Ad Demand | — | — | — | — |
| T4 Ad Economics | — | — | — | — |
| T5 Reader | — | — | — | — |
Keep the default investor view concise. Detailed evidence should remain one click deeper.
§ 3 · Network Access → Network Conversion
ORIGINAL THESIS
LOTOMIX's FENAMIX relationship and physical footprint provide a foundation for broader deployment.
ORIGINAL EVIDENCE
• FENAMIX contractual relationship
• approximately 7,000-point potential network perimeter
• approximately 370 existing reader footprint
• 1,200+ rollout / expressed-interest pipeline
EVIDENCE THIS QUARTER
CURRENT VIEW
Describe factually whether network access is converting into deployment, conversion remains early, or more evidence is required.
Do not use:
NEXT VALIDATION
→ next rollout cohort
→ activation velocity
→ monetisation conversion
→ progression toward current rollout milestones
§ 4 · Rollout Execution
ORIGINAL THESIS
LOTOMIX can expand the existing estate at a pace sufficient to support the current commercial plan.
EVIDENCE THIS QUARTER
CURRENT VIEW
Explain actual vs original rollout, timing variance, operational bottlenecks, and whether current forecast has changed.
Preserve original target dates. Do not retrospectively change them.
NEXT VALIDATION
→ The next measurable rollout milestone.
§ 5 · Advertising Demand
ORIGINAL THESIS
LOTOMIX's digital inventory can attract paying advertisers.
EVIDENCE THIS QUARTER
CURRENT VIEW
Explain the maturity of advertiser demand.
Distinguish:
NEXT VALIDATION
→ repeat campaign
→ broader advertiser base
→ higher commercial conversion
→ longer campaign history
§ 6 · Advertising Economics
ORIGINAL THESIS
Digital inventory can monetise at economically viable fill and realised pricing.
EVIDENCE THIS QUARTER
COMPARE AGAINST
CURRENT VIEW
Explain whether actual economics are early, representative, still too limited to assess, or materially different from the original model.
Avoid evaluative scoring.
NEXT VALIDATION
→ The next evidence needed to improve representativeness.
§ 7 · Reader Economics
ORIGINAL THESIS
Reader traffic and interaction can create monetisable advertising inventory.
EVIDENCE THIS QUARTER
COMPARE AGAINST
where those were used in BC 6.7
CURRENT VIEW
Explain observed variance. Do not treat early-location data as network-wide proof.
NEXT VALIDATION
→ Larger sample / additional mature location cohorts.
§ 8 · Large-Format Advertising
ORIGINAL THESIS
Large-format LOTOADS screens can produce incremental advertising economics.
EVIDENCE THIS QUARTER
Maintain: FENAMIX 30% applies only to the large-format advertising revenue.
CURRENT VIEW
Compare actual net economics against BC 6.7.
NEXT VALIDATION
→ Broader commercial history / repeatability.
§ 9 · SaaS
ORIGINAL THESIS
Activated administrations can support recurring SaaS economics.
EVIDENCE THIS QUARTER
Reference pricing: €30/month (where applicable)
CURRENT VIEW
Explain whether SaaS is still activation-stage, generating early recurring revenue, or developing sufficient retention evidence.
NEXT VALIDATION
→ More paying cohorts / retention history.
§ 10 · Digital Adoption
ORIGINAL THESIS
The physical network can support consumer digital adoption.
EVIDENCE THIS QUARTER
Do not prioritise downloads if MAU is available.
CURRENT VIEW
Explain actual engagement relative to original model.
NEXT VALIDATION
→ Longer cohorts / monetisation behaviour.
§ 11 · Digital Monetisation
ORIGINAL THESIS
Active users can generate incremental transaction, membership and community economics.
EVIDENCE THIS QUARTER
Maintain: GTV ≠ LOTOMIX Revenue
CURRENT VIEW
Explain which digital monetisation layers have actual evidence and which remain modelled.
NEXT VALIDATION
→ Repeat / retention / mature economics.
§ 12 · Unit Economics
ORIGINAL THESIS
Mature LOTOMIX locations can generate sufficient contribution to support network economics.
EVIDENCE THIS QUARTER
COMPARE
CURRENT VIEW
State whether data remains early, mature cohorts exist, economics differ by location type, or current forecast has been revised.
NEXT VALIDATION
→ Larger / more mature cohort evidence.
§ 13 · Technology Production Readiness
ORIGINAL THESIS
The developed platform can transition into reliable commercial production.
EVIDENCE THIS QUARTER
Show material evidence only.
CURRENT VIEW
Describe current maturity using TESTED, PRODUCTION-READY, OPERATING where supported.
NEXT VALIDATION
→ The next production-readiness or reliability milestone.
§ 14 · Technology Scale
ORIGINAL THESIS
LOTOMIX technology can support increasing numbers of locations, devices, users, ticket requests, and advertising events.
EVIDENCE THIS QUARTER
CURRENT VIEW
Clearly distinguish production evidence from scale evidence.
NEXT VALIDATION
→ The next meaningful load / fleet milestone.
§ 15 · Legal / Regulatory Execution
ORIGINAL THESIS
The commercial model can be implemented within the required contractual and regulatory framework.
EVIDENCE THIS QUARTER
Show only material changes.
CURRENT VIEW
Do not provide blanket conclusions beyond supporting evidence.
NEXT VALIDATION
→ The next material legal / regulatory closure.
§ 16 · Capital Sufficiency
ORIGINAL THESIS
The €3M financing supports the next meaningful stage of commercial deployment and validation under the approved plan.
EVIDENCE THIS QUARTER
Do not state that no further capital will be required unless supported by the current forecast.
CURRENT VIEW
Explain whether actual capital deployment and operating performance have altered runway, rollout pace, or funding outlook.
NEXT VALIDATION
→ Next financing / cash milestone.
§ 17 · Operating Leverage
ORIGINAL THESIS
Contribution can scale faster than central OPEX.
EVIDENCE THIS QUARTER
Do not manufacture a conclusion.
CURRENT VIEW
If insufficient scale exists, state: Operating leverage not yet meaningfully testable.
NEXT VALIDATION
→ The network / revenue scale at which this thesis becomes more observable.
§ 18 · USE ONLY MATERIAL QUARTERLY EVIDENCE
Do not fill the review with:
Quarterly evidence should materially affect understanding of the original investment thesis.
§ 19 · CREATE FOUR CURRENT-VIEW LABELS
Use only descriptive maturity labels:
EVIDENCE STRENGTHENED
New actual evidence supports more of the original thesis.
MIXED / MORE EVIDENCE REQUIRED
Some evidence exists but remains incomplete or mixed.
MATERIAL VARIANCE TO ORIGINAL CASE
Actual evidence differs materially from the original case.
NOT YET MEANINGFULLY TESTABLE
Insufficient operating history currently exists.
These are descriptive reporting labels. Do not use them to create an overall investment judgment.
§ 20 · DO NOT CREATE AN OVERALL THESIS SCORE
No:
Different theses mature at different rates and have different evidence types. Keep them separate.
§ 21 · CREATE A 'WHAT CHANGED THIS QUARTER?' SUMMARY
5–7 MATERIAL CHANGES
At the beginning show no more than 5–7 material changes. Examples:
Do not list routine activities.
§ 22 · CREATE 'NEW EVIDENCE THIS QUARTER'
| New Evidence | Thesis Affected | Previous Position | New Position |
|---|---|---|---|
| First Repeat Advertiser | — | first paid campaign only | initial repeat commercial evidence |
| Actual Reader CPM | — | model assumption | early actual pricing evidence |
This visually demonstrates de-risking.
§ 23 · CREATE 'ASSUMPTIONS STILL UNCHANGED'
Assumptions Still Awaiting Evidence
Examples where applicable:
Not every quarter should change the model. This prevents investors interpreting absence of evidence as confirmation.
§ 24 · CREATE 'ORIGINAL THESIS VS CURRENT FORECAST'
For financially material theses, show:
For financially material theses, this allows investors to understand whether management's outlook has changed. Do not rewrite Original Thesis.
§ 25 · CREATE 'THESIS VARIANCE EXPLANATION'
If a material thesis diverges from the original case, explain:
If a material thesis diverges from the original case, explain these points. Keep concise. Do not use defensive language.
§ 26 · DISTINGUISH TIMING FROM STRUCTURAL THESIS CHANGE
Example: Rollout is 2 months late
Example: initial CPM lower than model
Use actual evidence to distinguish where possible. Do not reach structural conclusions prematurely.
§ 27 · CREATE 'NEXT QUARTER VALIDATION'
For every material open thesis specify:
Example: Advertising
Next KPI:
repeat advertiser rate
Next evidence:
second / third campaign cycle
Next milestone:
broader live screen inventory
For every material open thesis, specify these. This keeps quarterly reporting forward-looking.
§ 28 · CREATE A THESIS → KPI MAP
Each thesis should link directly to the KPI Cockpit. This prevents qualitative thesis commentary from drifting away from measurable evidence.
§ 29 · CREATE A THESIS → EVIDENCE MAP
Each quarterly claim should link to the underlying evidence. Do not rely on management commentary alone.
§ 30 · CREATE A THESIS → RISK MAP
Example:
Where actual evidence weakens or materially challenges an assumption, link to the Institutional Risk Register. Do not automatically change the risk status. Flag for management review.
§ 31 · CREATE A THESIS → FORECAST MAP
Example:
If evidence changes the current outlook, link to:
If evidence changes the current outlook, link to these. Investors should see: evidence → forecast consequence.
§ 32 · QUARTERLY NETWORK REVIEW
Network Thesis This Quarter
Use:
No more than 4–6 metrics.
§ 33 · QUARTERLY COMMERCIAL REVIEW
Use:
Focus on actual commercial evidence.
§ 34 · QUARTERLY DIGITAL REVIEW
Use:
only where the products are commercially active.
§ 35 · QUARTERLY FINANCIAL REVIEW
Use:
Compare with original case and latest forecast.
§ 36 · QUARTERLY TECHNOLOGY REVIEW
Focus only on evidence affecting:
Do not provide a sprint-by-sprint development report.
§ 37 · QUARTERLY LEGAL REVIEW
Focus only on:
• launch-critical closures
• material contractual developments
• regulatory / legal changes affecting economics or rollout
Do not reproduce the entire Legal Readiness Matrix every quarter.
§ 38 · QUARTERLY CAPITAL REVIEW
Show:
This connects investor capital to execution evidence.
§ 39 · CREATE 'THESIS PROGRESSION SINCE DAY 0'
After multiple quarters, show:
Example: Advertising
After multiple quarters, show this for each major thesis where meaningful. Use status / evidence evolution. This becomes a strong visual.
§ 40 · PRESERVE QUARTERLY SNAPSHOTS
Once a quarterly review is distributed, preserve it. Do not rewrite prior quarters based on later evidence.
If an error is later discovered, create:
CORRECTION / RESTATEMENTwith explanation.
If an error is later discovered, create a correction with explanation. Do not silently alter history.
§ 41 · QUARTERLY DATA CUT-OFF
Display:
Quarter
[—]
Reporting Period
[—]
Data Cut-Off
[—]
Forecast Version
[—]
Financial Model Baseline
[—]
This ensures all evidence belongs to a clearly defined period.
§ 42 · PRELIMINARY DATA
Where quarterly reporting uses preliminary data, label:
Where quarterly reporting uses preliminary data, label it. Then update to FINAL after reconciliation where appropriate. Do not hide the distinction.
§ 43 · CREATE A 2-PAGE EXECUTIVE VERSION
Target: 2 pages / equivalent digital view
Page 1:
Page 2:
Detailed metrics remain linked deeper. Do not create a 40-slide quarterly board pack by default.
§ 44 · CREATE A DEEP-DIVE VIEW
For investors wanting more detail, link to:
For investors wanting more detail, link to these. Do not duplicate these analyses inside the quarterly summary.
§ 45 · DO NOT CHANGE THESIS DEFINITIONS QUARTERLY
Stable:
The original thesis remains stable.
Changes:
The Current View changes.
This distinction is essential. Do not redefine a thesis because evidence is inconvenient.
§ 46 · NEW THESIS
A genuinely new strategic thesis should not simply be added into historical investment reporting. If the business materially evolves, create this separate from the original investment case. This preserves accountability.
§ 47 · RETIRED THESIS
Mark with:
If management intentionally abandons a product / revenue thesis, do not delete it. Mark it with these fields. This provides investors with a transparent history.
§ 48 · MATERIAL STRATEGY CHANGE
The quarterly review should clearly identify:
If actual evidence causes a material strategy pivot, the quarterly review should clearly identify these. Do not hide the pivot as an ordinary forecast adjustment.
§ 49 · INVESTOR QUESTION INTEGRATION
If the quarter raises new investor questions, capture them in:
If the quarter raises new investor questions, capture them there. Do not create another quarterly Q&A system.
§ 50 · IC OBJECTION UPDATE
Where new actual evidence resolves a prior objection, update:
Example:
Objection:
CPM is unvalidated
New evidence:
three quarters of paid campaigns
Action:
Update current response.
Where new actual evidence resolves a prior objection, update the pack. Preserve historical response versions.
§ 51 · LAST MILE PACK UPDATE
Where quarterly evidence materially changes the investment case, review whether:
Where quarterly evidence materially changes the investment case, review whether the pack should include the latest quarterly review. Do not accumulate every quarter indefinitely. Use the latest current review with historical archive.
§ 52 · DECISION MATRIX UPDATE
Update:
with:
Update the matrix with these based on quarterly evidence. Do not rewrite the historical Day 0 decision matrix.
§ 53 · VALUE CREATION UPDATE
Update:
Example:
Update where actual evidence advances a maturity stage. Only advance with evidence.
§ 54 · EVIDENCE GAP UPDATE
Close or refine:
Example:
Original:
Can advertisers pay modelled CPM?
After first campaigns:
Can this CPM repeat across a broader network?
Close or refine according to quarterly evidence. Some questions may evolve rather than fully close. Update the question accordingly.
Cronología de Progresión de Evidencia (Compacta)
Cómo el caso de inversión progresa de fundación contractual a evidencia operativa.
CURRENT QUARTER FOCUS:
New Evidence Created Since Last Review
Maximum approximately 5–7 items.
Areas Still Primarily Modelled
§ 55 · INVESTOR SUMMARY LANGUAGE
Thesis vs Reality
The quarterly review compares LOTOMIX's original investment assumptions with actual operating evidence without rebasing the original case.
Where actual evidence differs from the original plan, the variance, management response and current outlook are shown explicitly.
Where a thesis cannot yet be meaningfully tested, the next required evidence is identified rather than inferred.
§ 56 · NAVIGATION
Cross-link from:
CTA: Open Quarterly Thesis vs Reality Review →
This should become prominent post-investment. It should remain secondary in the current fundraising Data Room until actual quarterly operating history exists.
§ 57 · FINAL CONTROL
✗ Do not create an investment score.
✗ Do not mark theses pass / fail.
✗ Do not rewrite original thesis language.
✗ Do not rewrite original BC 6.7.
✗ Do not hide adverse quarterly evidence.
✗ Do not overinterpret one quarter.
✗ Do not treat timing variance automatically as structural failure.
✗ Do not treat positive early data automatically as scale validation.
✗ Do not create new strategy retrospectively.
THE PERMANENT QUARTERLY FRAMEWORK MUST REMAIN:
This should keep investor reporting focused on THE INVESTMENT THESIS rather than drowning the IC in operational detail.
SAVE ALL CHANGES IN THE EDITOR ONLY. DO NOT PUBLISH.
Dashboard de Decisiones Requeridas
Separar información, elementos a monitorear y asuntos que requieren una decisión explícita de gestión, junta o de inversores.
Decision Required Dashboard
Separate information, watch items and matters requiring an explicit management, board or investor decision
The purpose of this section is to convert LOTOMIX reporting into a decision-support system.
INFORMATION
Items provided for visibility only.
WATCH
Items requiring closer monitoring but not yet a formal decision.
DECISION REQUIRED
Items requiring an explicit management, board, shareholder or investor decision.
✗ Do NOT treat every variance or operational issue as a decision item.
✗ Do NOT invent board, shareholder or investor approval rights.
Formal decision authority must follow actual corporate governance, shareholder agreements, investment documentation, delegated management authority, and applicable law.
Where authority is unclear, use: DECISION AUTHORITY TO BE CONFIRMED
§ 1 · CREATE THE MASTER DECISION TABLE
| Decision ID | Decision Required | Why Now | Options | Financial Impact | Operational Impact | Decision Owner | Deadline | Supporting Evidence | Status |
|---|---|---|---|---|---|---|---|---|---|
| DEC-001 | — | — | — | — | — | — | — | — | — |
| DEC-002 | — | — | — | — | — | — | — | — | — |
| DEC-003 | — | — | — | — | — | — | — | — | — |
Every material decision should have a unique ID.
Do not reuse IDs.
§ 2 · USE CONTROLLED DECISION STATUS
INFORMATION ONLY
No decision required.
MONITOR
Continue observing before deciding.
MANAGEMENT DECISION REQUIRED
Within approved management authority.
BOARD REVIEW REQUIRED
Only where actual governance requires / supports board involvement.
SHAREHOLDER / INVESTOR APPROVAL REQUIRED
Only where formal transaction or governance documents establish that requirement.
LEGAL AUTHORITY CONFIRMATION REQUIRED
Decision rights unclear.
DECIDED
Formal decision made.
IMPLEMENTING
Decision approved and execution underway.
COMPLETED
Decision fully implemented.
Do not use 'BOARD APPROVAL REQUIRED' merely because an issue is important.
§ 3 · SEPARATE INFORMATION FROM DECISIONS
Reporting items such as:
are generally INFORMATION unless performance creates a decision point.
Example:
INFORMATION:
Advertising fill = 42%
DECISION REQUIRED:
Advertising fill materially below approved threshold for three reporting periods — should screen deployment pace be reduced?
This distinction should remain explicit.
§ 4 · CREATE THE DECISION LOGIC
KPI / Event
Variance / New Information
Is Management Action Already Pre-Approved?
YES
Execute within existing authority.
NO →
Does a material strategic / financial choice exist?
NO →
Monitor.
DECISION REQUIRED
This prevents every operational variance becoming a governance issue.
§ 5 · DECISION CATEGORY — ROLLOUT
Potential decision examples:
Triggered by:
Do not recommend an option automatically. Present options, evidence, impact.
§ 6 · ROLLOUT DECISION TEMPLATE
DECISION
Should LOTOMIX accelerate, maintain or moderate the current deployment pace?
Evidence:
Options:
Option A
Accelerate.
Option B
Maintain.
Option C
Moderate / reprioritise.
Financial Impact:
Pull from approved forecast / sensitivity model.
Decision Authority:
Determine according to actual governance.
Do not create a recommended winner automatically.
§ 7 · DECISION CATEGORY — HARDWARE PROCUREMENT
Possible decisions:
Evidence should include:
Avoid hardware purchases based solely on the size of the theoretical network.
§ 8 · HARDWARE ORDERING GATE
Before a material new order, the dashboard should show:
Current Inventory
Committed Deliveries
Expected Installations
Activation Rate
Current Cash
Commercial Evidence
This enables management to decide whether procurement remains aligned with actual demand.
§ 9 · DECISION CATEGORY — ADVERTISING
Potential decisions:
Trigger evidence:
Do not recommend price reductions automatically when fill is weak. Show the commercial evidence.
§ 10 · DECISION CATEGORY — DIGITAL ACQUISITION
POTENTIAL DECISION
Should LOTOMIX increase user-acquisition expenditure?
Evidence should include:
Do not scale acquisition purely because download targets are below plan. The decision should depend on engagement and monetisation evidence.
§ 11 · DECISION CATEGORY — SAAS
Potential decisions:
Evidence:
Do not modify the €30 reference automatically. Any pricing change must follow the approved commercial process.
§ 12 · DECISION CATEGORY — PEÑAS
POTENTIAL DECISION
Whether to accelerate commercial rollout of peñas.
Evidence should include:
Do not make commercial acceleration decisions before launch-critical legal items are closed.
§ 13 · DECISION CATEGORY — TECHNOLOGY
Potential decisions:
Evidence:
Do not turn routine sprint prioritisation into board decisions.
§ 14 · DECISION CATEGORY — HIRING
Potential decisions:
Evidence:
Avoid hiring solely because the original plan contained a future headcount assumption.
§ 15 · DECISION CATEGORY — OPEX
Potential decisions:
Evidence:
Do not treat contractual / essential expenditure as discretionary.
§ 16 · DECISION CATEGORY — USE OF FUNDS REALLOCATION
If actual execution indicates capital should move between categories, create a formal decision item.
Original:
Hardware €X
Proposed:
Hardware €Y / Commercial €Z
Show:
Do not silently reallocate material Use of Funds.
§ 17 · DECISION CATEGORY — FORECAST REVISION
Not every variance requires a formal forecast change. Create a decision only when evidence materially affects rollout, revenue, EBITDA, cash, runway, or funding requirement.
Forecast Change Proposal
Preserve the original forecast.
§ 18 · DECISION CATEGORY — FUNDING
Possible decisions:
Evidence must include:
Do not wait until cash is nearly exhausted before surfacing financing decisions. Use management-approved thresholds once defined.
§ 19 · DECISION CATEGORY — PUBLIC FUNDING
POTENTIAL DECISION
Whether to alter rollout / cash assumptions based on formal public-funding status.
Distinguish:
Do not base material spending decisions on 'potential' funding unless management explicitly accepts that risk.
§ 20 · DECISION CATEGORY — COMMERCIAL PARTNERSHIP
Material new strategic relationships may require a decision.
Show:
Do not create a board decision for ordinary advertiser contracts unless governance requires it.
§ 21 · DECISION CATEGORY — CONTRACT AMENDMENT
Material amendments to FENAMIX, strategic partners, material technology suppliers, and core commercial agreements should create a decision item where appropriate.
Show:
Do not interpret legal consequences automatically.
§ 22 · DECISION CATEGORY — PRODUCT SCOPE
Potential decisions:
Evidence should include:
Do not allow product expansion to dilute launch-critical execution.
§ 23 · CREATE A 'DECISIONS THIS PERIOD' PANEL
Decisions Required
Target: 0–5 material decisions not 20.
For each display:
No long analysis on the summary view.
§ 24 · CREATE A 'NO DECISION REQUIRED' PANEL
Where a major adverse KPI is already being managed under an approved plan, classify it as above.
The dashboard should not generate governance noise.
§ 25 · CREATE A DECISION DEADLINE
Decision Needed By
based on actual operational timing
Examples:
Do not invent arbitrary calendar dates where the dependency itself defines the timing.
§ 26 · DISTINGUISH DECISION DATE FROM IMPLEMENTATION DATE
Track separately:
Decision Date
Expected Implementation
A decision may be made today but implemented later. Do not mix the two.
§ 27 · CREATE OPTIONS WITHOUT RANKING
Where multiple legitimate options exist, present them neutrally. Use:
| Option | Operational Impact | Financial Impact | Principal Trade-Off |
|---|---|---|---|
| Option A | — | — | — |
| Option B | — | — | — |
| Option C | — | — | — |
Do not automatically label 'Recommended Option' unless management itself has formally selected / proposed one.
§ 28 · MANAGEMENT PROPOSAL
Where management wants to recommend an option, separate:
The system may record: "Management proposes Option B"
But should preserve:
Do not let the Data Room itself make the decision.
§ 29 · DECISION SUPPORT — FINANCIAL IMPACT
Every financially material decision should show:
Source: current approved financial model / forecast
Do not calculate unsupported values independently.
§ 30 · DECISION SUPPORT — OPERATIONAL IMPACT
Show where relevant:
This ensures financial optimisation does not hide operational consequences.
§ 31 · DECISION SUPPORT — THESIS IMPACT
For material strategic decisions show which investment thesis is affected.
This keeps governance connected to the investment case.
§ 32 · DECISION SUPPORT — RISK IMPACT
Show whether an option:
Do not create net risk scores. Describe the trade-off.
§ 33 · DECISION SUPPORT — EVIDENCE
Every decision item should link to supporting evidence. Examples:
No material decision should rely solely on narrative.
§ 34 · DECISION OWNERSHIP
Distinguish:
Example:
Preparer:
Finance prepares analysis.
Owner:
Management / board decides.
Implementer:
Operations implements.
Do not assume the same person performs all three roles.
§ 35 · AUTHORITY MATRIX
INTERNAL governance map:
| Decision Type | Management | Board | Shareholders / Investors | Legal Confirmation |
|---|---|---|---|---|
| Rollout | — | — | — | — |
| Hardware | — | — | — | — |
| Funding | — | — | — | — |
| Forecast | — | — | — | — |
| Contracts | — | — | — | — |
Do NOT populate governance authority by inference.
Use actual:
§ 36 · DO NOT CREATE INVESTOR VETO RIGHTS
Critical:
Do not assume Waterhouse or any investor can approve / reject:
unless definitive transaction documents grant such rights.
The reporting framework may inform investors without granting governance authority.
§ 37 · CREATE A DECISION PACK
Decision Memo
• Decision Requested
• Context
• Evidence
• Options
• Financial Impact
• Risks / Trade-Offs
• Management Proposal where applicable
• Required Authority
Target: 1–2 pages maximum
Do not create long presentations for ordinary decisions.
§ 38 · DECISION HISTORY
Preserve every material decision.
| Decision | Date | Decision Taken | Authority | Rationale | Expected Impact |
|---|---|---|---|---|---|
| DEC-001 | — | — | — | — | — |
| DEC-002 | — | — | — | — | — |
Do not overwrite history when circumstances change later.
§ 39 · ACTUAL OUTCOME OF DECISION
After implementation, allow management to record:
Expected Outcome
Actual Outcome
Example:
Decision:
slow hardware procurement
Expected:
extend runway by X
Actual:
capital saved / rollout affected
Only calculate where supported. This creates stronger governance learning.
§ 40 · DECISION FOLLOW-UP
Each material decision should define:
Do not treat the decision as complete merely because approval occurred.
§ 41 · DECISION → FORECAST
If a decision changes financial outlook, trigger this. Do not alter the original BC 6.7.
Example:
§ 42 · DECISION → REGRESSION TEST
Every material approved decision that changes:
Every material approved decision that changes these must trigger this. This preserves Data Room consistency.
§ 43 · DECISION → RISK REGISTER
A decision may change risk exposure.
Example:
Flag relevant risks for review. Do not automatically alter risk classification.
§ 44 · DECISION → INVESTOR REPORT
Material Decisions This Period
For each:
Keep this short. Do not include every routine management decision.
§ 45 · DECISION → THESIS VS REALITY
If a material decision changes how the original investment thesis is being executed, note it in:
Example:
Original:
rapid rollout
Decision:
moderate rollout due to fill
If a material decision changes how the original investment thesis is being executed, note it there. This is material thesis-execution context.
§ 46 · DECISION → DAY 0 VS TODAY
Significant capital-allocation decisions should also feed:
When they materially affect:
Significant capital-allocation decisions should also feed this when they materially affect these areas.
§ 47 · CREATE 'DECISIONS MADE THIS QUARTER'
Use a compact table:
| Decision | Why | Expected Impact | Status |
|---|---|---|---|
| DEC-001 | — | — | — |
| DEC-002 | — | — | — |
Maximum: 5–7 material decisions
Do not overwhelm investors with internal management detail.
§ 48 · CREATE 'DECISIONS AHEAD'
Decisions Likely Required Next
Only where an upcoming dependency is clear. Examples:
Only where an upcoming dependency is clear. Do not invent hypothetical decisions merely to fill the section.
§ 49 · CREATE A DECISION QUEUE
Internal dashboard:
Decisions Required Now
[count]Decisions Upcoming
[count]Decisions Awaiting Evidence
[count]Decisions Awaiting Legal Confirmation
[count]Decisions Made
[count]Implementation Pending
[count]No effectiveness score.
§ 50 · DECISION AWAITING EVIDENCE
Example:
This is preferable to making decisions prematurely.
§ 51 · DECISION AWAITING LEGAL REVIEW
Use where the operating choice depends on contract interpretation, regulatory scope, investor rights, or corporate approvals.
Do not infer legal authority.
§ 52 · CREATE MATERIALITY FILTER
Only decision items with meaningful impact on:
Only decision items with meaningful impact on these should appear in investor / board reporting. Routine decisions remain in management operations.
§ 53 · DO NOT TURN REPORTING INTO MICROMANAGEMENT
The dashboard should support governance. It should not make every:
a board-level matter.
Maintain clear delegation.
§ 54 · NO DECISION BY DASHBOARD
The tool should not automatically select:
It presents evidence and options. Human management / governance bodies decide.
§ 55 · POST-DECISION COMMUNICATION
Once a material decision is made, update:
where required. Preserve the original plan for historical comparison.
§ 56 · CREATE A MONTHLY GOVERNANCE VIEW
Monthly view should show:
Information
Only major context.
Watch Items
Limited list.
Decisions Required
Limited list.
This should be a cleaner governance structure than presenting every KPI equally.
§ 57 · CREATE A QUARTERLY GOVERNANCE VIEW
Quarterly view should emphasise:
Operational decisions should remain deeper.
§ 58 · CREATE A BOARD / INVESTOR DISCLAIMER
The Decision Required Dashboard is a management reporting tool. Formal approval rights and governance processes are determined exclusively by the company's corporate documents and definitive transaction agreements.
This prevents the dashboard from accidentally creating implied governance rights.
§ 59 · INVESTOR ACCESS
Investors may view:
according to agreed reporting / information rights.
Internal deliberations and sensitive legal analysis should remain appropriately restricted. Do not automatically expose the complete internal decision queue.
§ 60 · FINAL INVESTOR VALUE
The purpose is to ensure each investor review answers not only:
"What happened?"
WHAT, IF ANYTHING, DO WE NEED TO DECIDE?
This makes reporting materially more useful.
§ 61 · FINAL SUMMARY
Decision-Oriented Governance
LOTOMIX reporting separates operating information from matters that require an explicit decision.
Material decisions are supported by current evidence, financial impact, operational trade-offs and the appropriate governance authority.
The resulting decision and its expected impact are then preserved and tracked against actual outcomes.
THIS CREATES A DIRECT GOVERNANCE CHAIN:
FINAL CONTROL
✗ Do not invent governance rights.
✗ Do not create investor vetoes.
✗ Do not classify every variance as a decision.
✗ Do not allow dashboards to make decisions automatically.
✗ Do not hide material options.
✗ Do not automatically recommend one option.
✗ Do not alter BC 6.7.
✗ Do not rewrite historical decisions.
✗ Do not expose privileged internal deliberations unnecessarily.
THE GOVERNING RULE IS:
SAVE ALL CHANGES IN THE EDITOR ONLY. DO NOT PUBLISH.
Paso Final de Corrección de Elementos Fallidos
Resolver solo los elementos fallidos identificados por el Checklist Ready for Oscar / Michael antes de la aprobación final del Release Candidate.
Final Failed-Items Fix Pass
Resolve only the failed items identified by the Ready for Oscar / Michael Checklist before final Release Candidate approval
✗ It is NOT a new review cycle.
✗ It is NOT permission to create additional analytical content.
✗ The purpose is NOT to improve the Data Room generally.
The sole objective is:
Do not modify areas that already passed unless a failed-item correction creates a necessary dependency update.
§ 1 · IMPORT FAILED CHECKS ONLY
Pull directly from: Ready for Oscar / Michael Checklist
Import only checks currently marked: FAIL
Do not reopen: PASS items without a specific dependency reason.
| Failed Check | Exact Issue | Canonical Page | Required Fix | Owner | Status |
|---|---|---|---|---|---|
| CHECK 01 | — | — | — | — | — |
| CHECK 02 | — | — | — | — | — |
§ 2 · NO NEW PAGES
Critical rule:
DO NOT CREATE ANY NEW INVESTOR-FACING PAGE during this remediation pass.
Every correction must occur within:
Do not create it automatically.
§ 3 · FIX PRIORITY ORDER
Resolve failed checks in this order:
This ordering prevents later corrections from invalidating earlier presentation work.
§ 4 · FAILED CHECK 01 — OPENING SIMPLE
Review only:
Actions may include:
Do not solve simplification failure by adding another explanatory page.
§ 5 · OPENING PASS CONDITION
Re-test whether a first-time investor can explain after approximately 2–3 minutes:
§ 6 · FAILED CHECK 02 — BC 6.7 RECONCILIATION
Identify exact mismatch.
| Metric | Investor-Facing Value | BC 6.7 | Difference | Required Correction |
|---|---|---|---|---|
| — | — | — | — | — |
Do not 'split the difference.'
BC 6.7 remains the controlling financial model unless formal management approval changes the source model.
§ 7 · FINANCIAL FIX RULE
Correct generated:
to reconcile with BC 6.7.
Do NOT modify BC 6.7 simply to make summaries reconcile.
If BC 6.7 itself is identified as incorrect, flag this and stop that specific correction until Finance / Management resolves it.
§ 8 · GTV FIX
If the failure involves GTV vs Revenue, correct every current affected reference.
GTV
for underlying transaction / participation value.
LOTOMIX Recognised Revenue
for the actual fee / economic share.
Run a global regression on all transaction and peña references afterward.
§ 9 · FENAMIX ECONOMICS FIX
If the failure involves FENAMIX economics, canonical rule:
30% FENAMIX SHARE ONLY ON LARGE-FORMAT ADVERTISING REVENUE
Do not apply to:
Correct:
Do not alter signed contractual sources.
§ 10 · FAILED CHECK 03 — ROLLOUT RECONCILIATION
Resolve all affected references to:
Do not create new rollout interpretations.
§ 11 · ROLLOUT FIX METHOD
For every mismatch classify it as:
CURRENT VALUE ERROR
UNIT ERROR
STATUS ERROR
DATE ERROR
DEFINITION ERROR
HISTORICAL REFERENCE — NO CHANGE
This prevents global replacements from damaging historical records.
§ 12 · PRESERVE HISTORICAL ROLLOUT REFERENCES
Do not change:
where the number correctly reflected information available at that date.
Instead ensure historical files are clearly dated / superseded.
§ 13 · FAILED CHECK 04 — DOWNSIDE
Examples:
Do NOT create another downside page.
Use:
§ 14 · DOWNSIDE FIX RULE
If the requested sensitivity can already be produced from BC 6.7, surface it.
If BC 6.7 does not contain the required sensitivity, flag this.
Do not manufacture the result. The item remains FAIL until approved model work exists or management explicitly accepts transparent disclosure of the limitation.
§ 15 · FAILED CHECK 05 — EVIDENCE
Broken Link
Missing Source
Source Does Not Support Claim
Restricted Evidence Misconfigured
Evidence Exists But Is Hard to Find
Then correct through: Investment Evidence Map and canonical source references.
Do not create duplicate evidence files.
§ 16 · BROKEN EVIDENCE FIX
For a broken link:
Do not mark fixed from admin mode only.
§ 17 · UNSUPPORTED CLAIM FIX
If a claim lacks sufficient evidence, choose one:
Do not fabricate supporting evidence.
§ 18 · FAILED CHECK 06 — COMMERCIAL STATUS
For every affected counterparty establish one correct status:
Then run commercial-status regression across all investor-facing pages.
§ 19 · COMMERCIAL LOGO FIX
If a logo creates implied endorsement / customer status, either:
Do not leave ambiguous logos.
§ 20 · FAILED CHECK 07 — TECHNOLOGY MATURITY
Find exact maturity conflict.
Canonical distinctions:
Do not solve through more promotional explanation. Correct the maturity label.
§ 21 · TECHNOLOGY EVIDENCE FIX
Where stronger technical status is desired but evidence is missing, do NOT upgrade wording.
until:
exists.
§ 22 · FAILED CHECK 08 — LEGAL / REGULATORY
Identify exact overstatement / ambiguity.
Search affected uses of:
Correct wording to reflect exact scope.
§ 23 · LEGAL FIX RULE
A legal status must be based on:
Do not resolve by model inference.
If legal interpretation is required, flag this and keep the checklist item FAIL until appropriate review exists or the claim is safely reworded.
§ 24 · FAILED CHECK 09 — MATERIAL RED FLAGS
Create a short remediation queue.
| Material Issue | Existing Module | Required Action | Owner | Status |
|---|---|---|---|---|
| — | — | — | — | — |
Do not reopen minor issues during this final pass unless directly related.
§ 25 · RED FLAG RESOLUTION
A material issue can become RESOLVED only after:
Do not close because a team member says it has been reviewed.
§ 26 · ACCEPTED / DISCLOSED ISSUE
Some issues represent legitimate investment uncertainty rather than an error.
Example:
CPM not yet broadly validated.
If correctly classified, downside shown, and Evidence Gap Plan acknowledges it, the item may become:
This can satisfy release QA where appropriate.
Do not pretend the underlying uncertainty disappeared.
§ 27 · FAILED CHECK 10 — WATERHOUSE REQUESTS
For each show:
Do not generate new pages.
§ 28 · WATERHOUSE CLOSURE RULE
A Waterhouse item closes only when all of the following are present:
§ 29 · NO COSMETIC WORK DURING FINAL FIX PASS
During this pass do NOT spend time on:
unless directly required to resolve a failed check.
The objective is closure.
§ 30 · NO NEW ASSUMPTIONS
Do not introduce:
to resolve a failed check. Use approved current sources.
§ 31 · NO UNAPPROVED MODEL WORK
Management must not independently create new financial outputs.
Where mathematical model work is required, flag this.
Do not improvise.
§ 32 · RUN TARGETED REGRESSION AFTER EACH FIX
After every material fix, run regression only on affected dependencies first.
Example:
FENAMIX commission fix:
Then run full regression before final readiness.
§ 33 · RE-RUN THE TEN-CHECK TEST
After all targeted fixes, run the Ready for Oscar / Michael Checklist again.
Do not alter the checklist criteria. Use the same ten checks.
This preserves comparability.
§ 34 · IF A CHECK STILL FAILS
Do not create another workaround layer. Generate:
Do not mark PASS artificially.
§ 35 · MATERIAL ISSUE CANNOT BE HIDDEN THROUGH DISCLOSURE
Some failures are actual contradictions / errors and must be corrected.
These cannot become 'Accepted / Disclosed' as a substitute for correction.
§ 36 · LEGITIMATE UNCERTAINTY CAN BE DISCLOSED
Other issues may remain open because they require future operating evidence.
These can be release-ready if properly labelled, sensitivity shown, and next validation identified.
Distinguish uncertainty from error.
§ 37 · FINAL REGRESSION
Once the checklist returns 10 / 10 PASS, run FULL MATERIAL UPDATE REGRESSION TEST.
Check:
Required result:
No material conflict may remain.
§ 38 · RE-RUN WATERHOUSE MATRIX
Then re-run the Waterhouse DD Completion Matrix.
This is independent verification of Check 10.
§ 39 · RE-RUN RED FLAG REGISTER
Legitimate disclosed uncertainties may remain under their correct category.
§ 40 · CREATE FINAL FIX LOG
| Failed Check | Original Issue | Fix Applied | Pages Updated | Regression Status | Final Result |
|---|---|---|---|---|---|
| CHECK 01 | — | — | — | — | — |
| CHECK 02 | — | — | — | — | — |
This provides a concise history of the final remediation pass.
§ 41 · CREATE 'NO CHANGE' LOG
Where a failed-check review concludes that the existing Data Room was already correct and the perceived issue was due to:
Do not edit content unnecessarily.
§ 42 · CREATE FINAL RC CANDIDATE
After:
LOTOMIX INVESTOR DATA ROOM — FINAL RC
or next controlled RC version.
Do not overwrite prior RCs.
§ 43 · FREEZE FINAL RC
Freeze:
From this point, material changes require RC governance.
§ 44 · FINAL RC INVESTOR VIEW TEST
Review FINAL RC as:
Do not change content unless the test identifies a documented material defect.
§ 45 · FINAL MANAGEMENT REVIEW PACK
FINAL RC SUMMARY
Keep this concise.
§ 46 · DO NOT CONTINUE FEATURE DEVELOPMENT
Once FINAL RC exists, do NOT continue with:
unless a material investor issue arises.
§ 47 · IF ALL CHECKS ALREADY PASS
If the Final Fix Pass begins and ALL 10 CHECKS ARE ALREADY PASS, do not make changes.
Then proceed to:
This prevents unnecessary last-minute edits.
§ 48 · CHANGE-FREEZE DISCIPLINE
Do not make a last-minute change simply because 'it might look slightly better.'
Every change after this point must solve:
Otherwise leave FINAL RC unchanged.
§ 49 · FINAL SUCCESS CONDITION
The Final Failed-Items Fix Pass is complete when:
FINAL CONTROL
✗ DO NOT CREATE NEW PAGES.
✗ DO NOT CREATE NEW ASSUMPTIONS.
✗ DO NOT CHANGE BC 6.7.
✗ DO NOT MODIFY SIGNED SOURCE DOCUMENTS.
✗ DO NOT MODIFY THE WATERHOUSE DECK AUTOMATICALLY.
✗ DO NOT HIDE FAILED CHECKS.
✗ DO NOT MARK FAIL AS PASS WITHOUT VERIFICATION.
✗ DO NOT KEEP EDITING AFTER FINAL RC WITHOUT A DOCUMENTED ISSUE.
✗ DO NOT PUBLISH.
THE COMPLETE FINAL PROCESS IS:
and then wait for EXPLICIT MANAGEMENT INSTRUCTION TO PUBLISH.
SAVE ALL CHANGES IN THE EDITOR ONLY. DO NOT PUBLISH.
Informe Final de QA RC1 del Data Room de Inversores LOTOMIX
Resumen final de aseguramiento de calidad antes de la aprobación de dirección y el lanzamiento a inversores.
Este informe registra el proceso de control de calidad interno de LOTOMIX y no constituye auditoría independiente, aseguramiento ni verificación por terceros.
LOTOMIX Investor Data Room — FINAL RC1 QA Report
Final quality-assurance summary before management approval and investor release
This report provides one concise internal record confirming the exact state of the LOTOMIX Investor Package at the moment the final Release Candidate is frozen.
Scope Note:
This report records LOTOMIX's internal quality-control process and does not constitute independent audit, assurance or third-party verification.
Target length: ONE INTERNAL PAGE or the digital equivalent. Keep it concise.
§ 1 · RELEASE CANDIDATE IDENTIFICATION
LOTOMIX INVESTOR DATA ROOM — FINAL RC1
or the current controlled final RC identifier.
RC Version
[RC1 / current final RC]
RC Creation Date
[date]
Data Cut-Off
[date]
Document Cut-Off
[date]
Final QA Date
[date]
Do not use 'latest' without a controlled version / date.
§ 2 · CURRENT INVESTOR DECK
Current Waterhouse Investor Deck
Document
[exact controlled filename / title]
Version
[version if available]
Date
[date]
If FAIL: the package is NOT ready.
Do not alter the deck automatically.
§ 3 · CURRENT FINANCIAL MODEL
BC 6.7
CURRENT PRINCIPAL FINANCIAL MODEL
Verify:
§ 4 · FINAL NETWORK CONTROL
~7,000
Potential FENAMIX network perimeter.
1,200+
Current rollout / expressed-interest pipeline.
~370
Existing reader footprint.
500
Initial deployment / reference case where applicable.
~770
Completed-location management target by April 2027.
3,370
Longer-term management target where applicable.
§ 5 · FINAL TIMELINE CONTROL
No contradictory current rollout timeline may remain.
§ 6 · HARDWARE CONTROL
Canonical current specifications:
A1D / PPI Reader
11.6-inch
Rear Display
23.8-inch
Large-Format Display
43-inch
Historical / contractual 48-inch references may remain where correctly contextualised.
§ 7 · FENAMIX ECONOMICS CONTROL
FENAMIX COMMERCIAL TREATMENT
30% FENAMIX share applies only to large-format 43"/48" advertising revenue.
It does NOT apply to:
Any incorrect current investor-facing treatment is MATERIAL.
§ 8 · GTV / REVENUE CONTROL
GTV ≠ LOTOMIX RECOGNISED REVENUE
Check all current:
§ 9 · READY FOR OSCAR / MICHAEL CHECKLIST
Pull directly from: Ready for Oscar / Michael Checklist
Display exactly:
FINAL CHECKLIST RESULT
Do not create partial scores.
§ 10 · REGRESSION TEST
Pull from the final full regression test.
Final Regression Status:
For final RC approval: no unresolved MATERIAL CONFLICT may remain.
§ 11 · RED FLAG REGISTER
Pull from: Red Flag & Open Issues Register
Show only:
Important / minor items may remain only if management has reviewed them and they do not materially affect investor interpretation.
§ 12 · WATERHOUSE DD COMPLETION
Pull from: Waterhouse DD Completion Matrix
Legitimate future validation questions may remain where properly disclosed and not represented as current facts.
§ 13 · EVIDENCE CONTROL
Required:
§ 14 · COMMERCIAL STATUS CONTROL
§ 15 · TECHNOLOGY CONTROL
Any unsupported 'PROVEN AT SCALE' claim should result in FAIL.
§ 16 · LEGAL / REGULATORY CONTROL
§ 17 · ACCESS CONTROL
Confirm standard investor access does NOT expose:
§ 18 · NAVIGATION CONTROL
§ 19 · INVESTOR EXPERIENCE TEST
Do not provide long commentary.
Where a test fails: link directly to the unresolved issue.
§ 20 · MOBILE / DESKTOP / EXPORT QA
§ 21 · VERSION CONTROL
§ 22 · FINAL FAILED-ITEM FIX PASS
§ 23 · REMAINING DISCLOSED UNCERTAINTIES
Remaining Transparently Disclosed Investment Uncertainties
Only include material areas that remain genuinely dependent on future operating evidence.
Examples where applicable:
These are NOT QA failures where correctly disclosed. Keep this distinction explicit.
§ 24 · DO NOT PRESENT FUTURE VALIDATION AS A DEFECT
The QA report should separate:
PACKAGE ERROR
LEGITIMATE INVESTMENT UNCERTAINTY
Do not confuse the two.
§ 25 · FINAL RC STATUS
Use exactly one:
NOT READY
Material issue remains.
READY FOR FINAL MANAGEMENT REVIEW
QA complete; final management approval still required.
FINAL MANAGEMENT APPROVED — READY FOR RELEASE
Only after explicit human management approval.
Do NOT assign the third status automatically.
§ 26 · RECOMMENDED CURRENT STATUS
If all technical QA conditions pass but management approval has not yet occurred, use:
This should be the normal outcome of this report.
§ 27 · MANAGEMENT SIGN-OFF
Management
Pending / Approved
Finance
Pending / Approved
Operations
Pending / Approved
Commercial
Pending / Approved
Technology
Pending / Approved
Legal / Corporate
Pending / Approved
Do not fabricate approval.
§ 28 · FINAL RELEASE CONTROL
Even after all approvals:
until explicit management instruction is given.
§ 29 · FINAL QA CONCLUSION
Generate one concise conclusion based only on actual status.
If all required QA items pass:
The LOTOMIX Investor Data Room FINAL RC has completed the defined financial, rollout, evidence, commercial, technical, legal, version-control and investor-experience checks. No unresolved material QA issue has been identified in the current Release Candidate. The package is ready for final management review prior to any investor release.
If not:
If not: state only which material checks remain unresolved.
Do not soften FAIL results.
§ 30 · REPORT FREEZE
Once generated, save this QA report as part of the FINAL RC record.
Do not overwrite it later.
If a material change occurs after the report:
FINAL CONTROL
✗ Do not create new pages.
✗ Do not modify investor content.
✗ Do not fix issues from within this report.
✗ Do not alter BC 6.7.
✗ Do not modify signed source documents.
✗ Do not modify the Waterhouse deck automatically.
✗ Do not invent approvals.
✗ Do not publish.
The purpose of this report is only:
The final output must answer one question:
IS THE CURRENT RELEASE CANDIDATE TECHNICALLY READY FOR FINAL MANAGEMENT REVIEW?
SAVE THE FINAL RC1 QA REPORT IN THE EDITOR ONLY. DO NOT PUBLISH.
Final Full-Visibility Investor Walkthrough
Validación end-to-end del Data Room completo de LOTOMIX usando la experiencia del inversor autorizado.
El propósito de este workflow es verificar el Data Room exactamente como Waterhouse lo ve. La prueba principal debe usar AUTHORISED INVESTOR — FULL DATA ROOM o la simulación de rol de inversor más cercana disponible.
Objetivo
Sin dar al inversor ninguna autoridad de edición o administrativa.
Control Final
- ⚠ DO NOT HIDE SUBSTANTIVE CONTENT
- ⚠ DO NOT CREATE NEW INVESTOR TIERS
- ⚠ DO NOT TEST ONLY AS ADMIN
- ⚠ DO NOT LEAVE BROKEN DIRECT LINKS
- ⚠ DO NOT LEAVE BUILD INSTRUCTIONS VISIBLE
- ⚠ DO NOT LEAVE GOVERNANCE HIDDEN
- ⚠ DO NOT LEAVE WATERHOUSE DD HIDDEN
- ⚠ DO NOT LEAVE RISK HIDDEN
- ⚠ DO NOT GIVE INVESTOR EDIT RIGHTS
- ⚠ DO NOT MAKE THE DATA ROOM PUBLIC
- ⚠ DO NOT PUBLISH AUTOMATICALLY
Principios Finales
- ✓ FULL VISIBILITY
- ✓ FULL TRACEABILITY
- ✓ FULL EVIDENCE ACCESS
- ✓ PROFESSIONAL LANGUAGE
- ✓ ZERO EDIT RIGHTS
- ✓ SECURE AUTHENTICATION
Evidence & Document Completeness Review
Verificación de que cada claim material de inversión LOTOMIX está respaldada por el documento o evidencia subyacente apropiado.
El propósito de esta revisión es verificar que el Data Room no contiene solamente resúmenes, dashboards, explicaciones de management y páginas analíticas — sino también el material fuente subyacente requerido para sustentar claims materiales del inversor.
Cadena Central
Cada claim material debe tener una fuente identificable o ser clasificada explícitamente como MODELLED, MANAGEMENT TARGET, PIPELINE, o EVIDENCE PENDING donde no existe evidencia directa.
Control Final
⚠ DO NOT CREATE EVIDENCE THAT DOES NOT EXIST
⚠ DO NOT UPGRADE A CLAIM BECAUSE A SUMMARY PAGE SAYS IT IS TRUE
⚠ DO NOT USE A MODEL AS EVIDENCE OF HISTORICAL PERFORMANCE
⚠ DO NOT USE PIPELINE AS EVIDENCE OF CONTRACTED ROLLOUT
⚠ DO NOT USE GTV AS REVENUE EVIDENCE
⚠ DO NOT USE A MEETING AS CONTRACT EVIDENCE
⚠ DO NOT USE AN INSTALLATION AS MONETISATION EVIDENCE
⚠ DO NOT HIDE MISSING EVIDENCE
⚠ DO NOT HIDE THIS REVIEW FROM WATERHOUSE
⚠ DO NOT PUBLISH AUTOMATICALLY
ASTERDAIL · Dashboard privado LotomiX · Documentación confidencial de inversores · NDA Waterhouse firmada
Información basada en la documentación fuente cargada. Sujeta a due diligence de inversores, legal y financiero. No auditada salvo indicación expresa.