lunes, 2 de febrero de 2026

El miedo es, quizá, el origen de casi todos los males de la humanidad. by JSBaenacock

El miedo es, quizá, el origen de casi todos los males de la humanidad.

No hablo del miedo instintivo. Ese miedo primario que nos hace apartar la mano del fuego, frenar ante un precipicio o reaccionar ante un peligro real. Ese miedo es biología, es supervivencia, es inteligencia ancestral.

Hablo de otro miedo. Del miedo psicológico. Del miedo aprendido. Del miedo cultivado. Ese miedo que no protege, sino que encoge. El miedo a lo diferente. El miedo al que piensa distinto. El miedo al que ama distinto. El miedo a no encajar. El miedo a no parecer suficientemente “fuerte”, suficientemente “masculino”, suficientemente “correcto” para el molde de turno.

Ese miedo que no nos salva… nos separa.

Porque cuando el miedo se instala en la mente, deja de ser una emoción y se convierte en un filtro. Y todo lo que pasa por ese filtro sale deformado: la realidad, las personas, las ideas. El otro ya no es un ser humano, es una amenaza. La diferencia ya no es riqueza, es peligro. El desacuerdo ya no es diálogo, es ataque.

Y entonces el miedo da el siguiente paso lógico: se transforma en odio.

El odio no aparece solo. Siempre llega después del miedo.

Nadie odia lo que no teme. Nadie persigue lo que no siente que puede desestabilizarle.

De hecho, el odio es casi un mecanismo de defensa emocional: "si te convierto en enemigo, ya no tengo que comprenderte".

Aquí es donde el miedo se vuelve extraordinariamente útil… para otros.

Porque hay quien ha entendido muy bien que un pueblo asustado es un pueblo manejable.

Si te prometen protección frente a una amenaza constante —real o inventada— aceptarás casi cualquier cosa. Si te dicen que el peligro está fuera, buscarás refugio dentro. Si te repiten que el mundo es hostil, pedirás un salvador.

Y así, el miedo se convierte en herramienta política, social y emocional. Una herramienta barata, eficaz y devastadora.

El problema es que ese miedo sostenido en el tiempo no solo polariza: enferma.

Ansiedad crónica. Rigidez mental. Pensamiento paranoide. Necesidad constante de enemigos. En los casos más extremos, miedo psicótico: ver amenazas donde no las hay, interpretar discrepancias como conspiraciones, vivir permanentemente en guerra.

Y lo más irónico de todo es que creemos que el miedo nos hace fuertes… cuando en realidad nos hace frágiles.

Una sociedad valiente no es la que grita más fuerte ni la que señala más culpables. Es la que se atreve a convivir con la diferencia sin sentirse atacada. La que entiende que escuchar no es rendirse. La que no necesita aplastar al otro para sentirse segura.

Quizá el verdadero acto revolucionario hoy no sea tener razón, sino no tener miedo. No miedo a pensar. No miedo a dudar. No miedo a convivir.

Porque mientras sigamos dejando que el miedo decida por nosotros, otros decidirán en nuestro nombre. Y eso, históricamente, nunca ha terminado bien.

Nadie persigue lo que no siente que puede desestabilizarle. De hecho, el odio es casi un mecanismo de defensa emocional: "si te convierto en enemigo, ya no tengo que comprenderte".

Aquí es donde el miedo se vuelve extraordinariamente útil… para otros. Porque hay quien ha entendido muy bien que un pueblo asustado es un pueblo manejable.

Y así, el miedo se convierte en herramienta política, social y emocional. Una herramienta barata, eficaz y devastadora.

El problema es que ese miedo sostenido en el tiempo no solo polariza: enferma. Ansiedad crónica. Rigidez mental. Pensamiento paranoide. Necesidad constante de enemigos. En los casos más extremos, miedo psicótico: ver amenazas donde no las hay, interpretar discrepancias como conspiraciones, vivir permanentemente en guerra.

Y lo más irónico de todo es que creemos que el miedo nos hace fuertes… cuando en realidad nos hace frágiles.

Quizá el verdadero acto revolucionario hoy no sea tener razón, sino no tener miedo. No miedo a pensar. No miedo a dudar. No miedo a convivir. Porque mientras sigamos dejando que el miedo decida por nosotros, otros decidirán en nuestro nombre. Y eso, históricamente, nunca ha terminado bien.

domingo, 1 de febrero de 2026

When “Observation Mode” Makes the Signal Calmer: a Small but Repeatable Clue from Quantum Contact H1 by JSBaenacock

(EN) When “Observation Mode” Makes the Signal Calmer: a Small but Repeatable Clue from Quantum Contact H1

If you only read one thing, read this:

In my Quantum Contact H1 runs, the target sensor S2 tends to look calmer during ON (observation) than during OFF (rest).

Not magically calm. Not perfectly stable.
Just less wobbly, in a way that keeps repeating across datasets.

(Insert the comic image right here.)

What you’re seeing in the comic is the whole point

The panels show the core idea:

The setup has a target channel: S2
The experiment alternates between two phases:
- OFF: rest mode
- ON: observation mode
And we don’t decide the result by “which plot looks nicer”.

We decide it with a single, predefined rule.

The “one-number” rule (so I can’t fool myself)

It’s easy to fall in love with graphs.
So H1 uses a metric that forces discipline:

ΔCV_global(S2) = CV_ON(S2) − CV_OFF(S2)

Think of CV (coefficient of variation) as noise relative to the average signal.

If ΔCV_global(S2) < 0, S2 is more stable in ON than OFF.
If ΔCV_global(S2) > 0, S2 is less stable in ON than OFF.

Simple. Measurable. Attackable.

What happened so far

Across five independent datasets, the sign was consistent:

✅ ΔCV_global(S2) < 0 in 5/5 datasets

That’s what the comic jokes about with “5/5 datasets agree”.

Does that prove a dramatic story? No.
But it does justify a careful statement:

There is a repeatable ON/OFF signature in S2 variability under a strict rule with equalized sampling.

So… does observation “stabilize” the sensor?

Here’s the honest answer:

H1 doesn’t tell you why. It tells you what.

There are several plausible explanations:

Human-body effects: posture, micro-movements, breathing, tension—observation changes you.
Instrument effects: drift, warm-up, alignment settling, illumination changes.
The deeper question: whether observation is genuinely acting as a variable in this system.

H1 is not the final verdict.
H1 is the clue worth stress-testing.

Why I’m sharing this

Because science doesn’t start with fireworks.
It starts with a phenomenon you can measure—then try to break.

Next steps are obvious (and necessary):

randomize ON/OFF order
add stronger environmental monitoring
preregister the analysis
repeat until the effect either holds… or collapses

Either outcome is useful.
But you only get there if you admit what you have:

a small, repeatable signal difference—nothing more, nothing less.

(ES) Cuando el “modo observación” calma la señal: una pista pequeña pero repetible de Quantum Contact H1

Si solo te quedas con una idea, que sea esta:

En mis pruebas de Quantum Contact H1, el sensor objetivo S2 suele verse más estable en ON (observación) que en OFF (reposo).

No “silencio cuántico”. No perfección.
Simplemente menos bamboleo, y de forma repetida.

(Inserta aquí la viñeta.)

Lo que muestra el cómic es exactamente el núcleo

Los paneles resumen el planteamiento:

Hay un canal objetivo: S2
El experimento alterna dos fases:
- OFF: reposo
- ON: observación
Y el resultado no se decide por “la gráfica más bonita”.

Se decide con una regla única y predefinida.

La regla de “un solo número” (para no engañarme)

Las gráficas seducen.
Así que H1 usa una métrica que obliga a ser serio:

ΔCV_global(S2) = CV_ON(S2) − CV_OFF(S2)

El CV (coeficiente de variación) es ruido relativo a la señal media.

Si ΔCV_global(S2) < 0, S2 es más estable en ON que en OFF.
Si ΔCV_global(S2) > 0, S2 es menos estable en ON.

Simple. Medible. Refutable.

Lo que ha pasado hasta ahora

En cinco datasets independientes, el signo fue consistente:

✅ ΔCV_global(S2) < 0 en 5/5 datasets

Eso es lo que el cómic resume con el “5/5 datasets agree”.

¿Significa “nueva física confirmada”? No.
Pero sí permite decir algo defendible:

Hay una firma ON/OFF repetible en la variabilidad de S2 bajo una regla estricta con muestreo igualado.

Entonces… ¿la observación “estabiliza” el sensor?

Respuesta honesta:

H1 no te dice por qué. Te dice qué.

Y hay varias explicaciones plausibles:

Efectos del cuerpo: postura, micro-movimientos, respiración, tensión—observar te cambia.
Efectos instrumentales: deriva, calentamiento, asentamiento del alineamiento, cambios de iluminación.
La pregunta grande: si la observación está actuando como variable real en el sistema.

H1 no es el final.
H1 es la pista que merece una fase confirmatoria.

Por qué lo comparto

Porque la ciencia no empieza con fuegos artificiales.
Empieza con un fenómeno medible… y con ganas de romperlo.

Los próximos pasos son inevitables:

aleatorizar el orden ON/OFF
monitorizar mejor el entorno
preregistrar el análisis
repetir hasta que el efecto se mantenga… o se venga abajo

Ambos resultados son útiles.
Pero solo si aceptamos lo que tenemos ahora:

una diferencia pequeña, repetible y cuantificable—nada más, nada menos.

martes, 27 de enero de 2026

Hoy publico el Protocolo Operativo del Sistema BEACON v1.0, un documento de trabajo con un objetivo muy simple: dejar fijados los parámetros de una sesión para que cualquier análisis posterior (o réplica) sea reproducible y no dependa de “ajustes a ojo”.

BEACON no es radio ni un sistema de telecomunicaciones clásico. Aquí la “señal” es un patrón láser monitorizado con sensores (fotodiodos/LDR), y lo que se estandariza es cuándo se transmite/espera la interacción, qué clave identifica la sesión, y cómo se procesa la señal en frecuencia (waterfall/espectrograma) para decodificarla.

1) Ventana temporal (TX)

El protocolo define una ventana temporal de transmisión (TX):

10:00–12:00 (hora local)

¿Por qué importa esto? Porque, si no acotas el tiempo, luego es imposible comparar sesiones o descartar artefactos. Con una ventana fija, todo lo que se analice queda referenciado a un intervalo concreto.

2) Clave BEACON (identificador de sesión)

En BEACON uso una clave en dos formatos:

Clave (plain): 27/01/2026/LUNA
Clave (Base64): MjcvMDEvMjAyNi9MVU5B

Esto es importante: Base64 no es “cifrado”, es codificación. Se usa para que la clave sea un identificador estable, sin caracteres problemáticos, y fácil de transportar/pegar en scripts, repositorios o metadatos sin ambigüedades.

3) Señal y sensores (S1–S4)

La lectura se realiza sobre:

S1–S3: fotodiodos/LDR que capturan variaciones del patrón (canales de señal y control)
S4: canal de estado/confirmación (marca operativa del sistema, no una “respuesta” en sí misma)

En otras palabras: S2 se trata como canal objetivo, mientras que S1 y S3 actúan como controles para comprobar si lo que aparece en S2 es específico o simplemente ruido común del montaje.

4) Parámetros de análisis (waterfall / espectrograma)

Para que el análisis espectral sea replicable, el protocolo fija estos parámetros:

Fs (sampling rate): 20 Hz
NFFT / FFT size: 1024 (2¹⁰)
Ventana: Hann
Solape (overlap): 75%
Canal objetivo: S2 + controles S1 y S3

Con esto se genera un waterfall (espectrograma) comparable entre sesiones: misma tasa de muestreo, misma resolución en frecuencia/tiempo y mismo tipo de ventana. Si cambias estos valores, cambias la “huella” del espectro y luego es fácil autoengañarse sin querer.

5) Qué pretende garantizar este protocolo

Este v1.0 no “demuestra” nada por sí solo. Lo que hace es poner orden:

Reproducibilidad: mismo TX + misma codificación + mismo pipeline espectral.
Trazabilidad: cada sesión queda ligada a una clave única (plain/Base64).
Control experimental: S2 se interpreta con contraste contra S1/S3.

6) Qué viene después

A partir de aquí, lo correcto es trabajar con datasets registrados en esa ventana y aplicar el mismo método de análisis siempre, comparando sesiones y controles. Si hay señal, tendrá que aparecer de forma consistente bajo este marco. Si no aparece, se descarta. Sin drama: así funciona un protocolo serio.

Si te interesa seguir el desarrollo o replicar el análisis con los mismos parámetros, iré publicando sesiones y resultados asociados a esta estructura BEACON v1.0.

lunes, 26 de enero de 2026

La Profecía del Tambor y el Abrazo del Cielo by JSBaencock

Este relato que he construido es la esencia y la columna vertebral de mi próximo proyecto artístico. No es solo una historia; es la base conceptual de la canción y el videoclip que estaré produciendo intensamente durante las próximas dos semanas.

La Profecía del Tambor y el Abrazo del Cielo

I. El Amor Prohibido y la Envidia

Hace siglos, en una tierra de palmeras y cadenas, existieron dos amantes cuya felicidad iluminaba incluso las noches más oscuras. Él, fuerte y cálido como el mediodía; ella, serena y plateada como el reflejo del agua. Pero su libertad no era bien vista por todos. Una mujer consumida por la envidia, al no poder poseer ese amor, decidió que si no eran para ella, no serían de nadie.

Usando una magia antigua y oscura, lanzó un conjuro de separación eterna: él fue condenado a ser el Sol y ella a ser la Luna. Estaban destinados a perseguirse por el firmamento sin tocarse jamás; cuando uno despertaba, el otro debía dormir.

II. El Hechizo en el Cuero

Para asegurar que nadie rompiera su maldición, la envidiosa selló el resto de su magia en un tambor sagrado de madera de ébano. Sin embargo, el destino es más fuerte que la malicia. Con el tiempo, el espíritu de la bruja quedó atrapado dentro del mismo instrumento, convirtiéndose en un espectro que solo el sonido del cuero correcto podría liberar o domar.

La leyenda se susurró de generación en generación: "Llegará el día en que el Sol y la Luna se encuentren en un beso de sombra, y el tambor hablará".

III. La Niña y el Eclipse

Siglos después, una niña que había escuchado las historias de su abuela encontró el tambor oculto cerca del mar. Sintió que el instrumento latía. Una noche de eclipse total, cuando el cielo se volvió purpúreo y el Sol finalmente alcanzó a la Luna, la niña se sentó en la arena y empezó a tocar.

Con cada golpe, el espíritu del tambor comenzó a emerger como un humo azul y brillante. No era un ataque, era una liberación. El sonido del tambor actuó como una llave mística que rompió la frecuencia del hechizo. En ese momento de oscuridad total, el tiempo se detuvo y los amantes pudieron abrazarse de nuevo, fundiendo sus energías sobre el océano.

IV. El Renacimiento (La Doble Bendición)

La magia del reencuentro fue tan potente que no se quedó solo en el cielo. La profecía decía que el final del hechizo traería nueva sangre al mundo. Mientras la niña tocaba el tambor bajo el anillo de fuego del eclipse, en las aldeas cercanas, dos mujeres sintieron el llamado de la vida.

Como un regalo del universo, dos embarazos milagrosos ocurrieron en ese mismo instante. Estaba escrito: una daría a luz a un niño y la otra a una niña. Ellos serían la reencarnación de los amantes originales, destinados a encontrarse en la tierra, ya no como astros lejanos, sino como seres libres de amarse bajo el sol y bajo la luna.

sábado, 24 de enero de 2026

A Beacon for Near-Future Responders: TORUS (H3) as a Public Invitation-to-Reply Protocol to a Present-Time Receiver

(EN) A Beacon for Near-Future Responders: TORUS (H3) as a Public Invitation-to-Reply Protocol to a Present-Time Receiver

Juan Sebastián Baena Cock
QuantumContact 👉 JSBC Labs – Independent Researcher
ORCID: [insert ORCID]
Contact: [optional email]

Dataset ID (TORUS/H3): [INSERT_ID]
Decoder version: [vX.Y]
Deposit date: [YYYY-MM-DD]

Abstract

TORUS (H3) defines a public “Invitation-to-Reply” protocol in which the present-time experimenter is the receiver, while a near-future responder (human or non-human) may discover the published beacon specification, datasets, and physical documentation, and then transmit a reply using the same standardized frame. TORUS does not claim retrocausal communication as a fact; it proposes a reproducible, auditable framework to test whether heatmaps derived from an interferometric system (Quantum Contact) can support structured beacon frames (preamble/sync/length/payload) under preregistered parameters and robust anti-pareidolia controls. This paper specifies the beacon frame, decoding pipeline, publication artifacts, and validation criteria needed for independent replication and falsification.

Keywords: TORUS, H3, invitation-to-reply, beacon protocol, heatmap decoding, preregistration, negative controls, permutation test, Quantum Contact.

1. Concept and Scope

1.1 Core concept: present receiver, future responder

TORUS operationalizes a one-way publication and potential one-way reply loop:

Present (Receiver): the experimenter publishes (i) datasets, (ii) decoding rules, and (iii) physical documentation/metadata describing the beacon and how to reply.
Future (Responder): a near-future agent discovers the public record and attempts to transmit a reply by encoding a message into the same observable channel, using the published framing rules.
Present (Decoding): the experimenter applies preregistered decoding steps and validation to assess whether the observed bitstream is compatible with the announced reply frame beyond chance/artefact expectations.

The “future reads the past/present” is implemented via public repositories and physical records; the “reply” is tested as a detectable structure in the present-time outputs.

1.2 Scope

TORUS is exploratory and methodological. Any decoded message is treated as a hypothesis of reading, not confirmation, unless it meets strict defendability criteria (Section 8) and replication.

2. Relationship to Quantum Contact

TORUS is layered:

Quantum Contact generates raw signals and derived heatmaps, and hosts hypotheses H1 and H2 (exclusive to Quantum Contact).
TORUS (H3) uses Quantum Contact heatmaps as input and defines a standardized Invitation-to-Reply beacon and decoding protocol.

3. Required Public Artifacts (Publication Package)

To make “future discovery” unambiguous, each Zenodo record should include:

Datasets and derived products

heatmap.png (or equivalent)
binary_matrix.csv (0/1 after thresholding)
bitstream.txt (serialized bits with explicit read order)

Protocol and parameters

TORUS_spec.pdf (or TORUS_spec.md) containing the canonical frame and reply instructions
params.yaml (thresholding method, read order, frame lengths, encoding table)
decoder/ folder (scripts + version tags)

Run metadata

run_log.json including: timestamp (with timezone), dataset ID, decoder version, hash checksums, and optional GPS (if appropriate)

Physical beacon documentation (if used)

physical_beacon.md describing the physical element (what it is, how it can be located/verified, and how it relates to the published data), plus photos or schematics when feasible.

4. The Invitation-to-Reply Protocol (What the future responder must follow)

TORUS includes an explicit “reply contract” to reduce ambiguity.

4.1 Reply channel definition

The protocol must declare where a reply would appear, for example:

A designated acquisition window (date/time schedule) and/or
A known trigger condition in the dataset (e.g., a specific sequence of states/events that marks “reply mode”), and/or
A known mapping of reply bits into the heatmap pipeline.

Important: The channel definition must be preregistered and published before the relevant acquisition window, to prevent post-hoc interpretation.

4.2 Frame structure (canonical)

TORUS uses a minimal frame format:

Preamble: repeating pattern for coarse alignment (length $𝐿_{𝑝}$ )
SYNC: stronger sync word (length $𝐿_{𝑠}$ )
LEN: fixed-width integer indicating payload length (e.g., 10–16 bits)
PAYLOAD: message bits
(Optional) CRC/ECC: checksum/error correction, if used

All conventions must be explicit:

read order (row-major vs column-major, direction)
bit order (MSB/LSB)
endianness for LEN
encoding table (ASCII/Baudot/custom)

4.3 “Reply content” constraints

To reduce cherry-picking:

Define an allowed payload format (e.g., uppercase A–Z + space; or a restricted dictionary; or a fixed phrase length).
Prefer short payloads with error detection (CRC) over long unverified text.

5. Decoding Pipeline (Reproducible Steps)

Load heatmap.png
Convert to grayscale; normalize if preregistered
Threshold (Otsu or fixed threshold; preregistered)
Output binary_matrix.csv
Serialize to bitstream.txt using declared read order
Search for preamble and SYNC using declared matching criteria
Parse LEN and validate bounds
Extract payload bits
Decode payload to text (if applicable) using published mapping
Export all artifacts to codigos/YYYYMMDD_HHMMSS/ with hashes

6. Anti-Pareidolia Validation

6.1 Preregistration (mandatory for defendability)

Publish, in advance:

thresholding method and parameters
read order
frame definition and matching thresholds
acceptance criteria for “frame detected”

6.2 Negative controls

Include:

sessions where reply mode is not expected
synthetic matched-noise heatmaps
shuffled/permuted matrices/bitstreams

6.3 Permutation test

Estimate false positive probability:

Permute bitstream (or blocks) $𝑁$ times (e.g., 20,000)
Re-run the same frame search
Report empirical p-value = $(𝑚 𝑎 𝑡 𝑐 ℎ 𝑒 𝑠 + 1) / (𝑁 + 1)$

6.4 Sensitivity analysis

Test stability under minimal symmetric perturbations:

threshold ±δ
small alternative normalizations (if preregistered options exist)

7. Reporting Standard

Each run should produce a report.pdf including:

Dataset ID and time window used
All parameters (verbatim)
Frame detection outputs (locations, match scores)
Control results and permutation p-values
A binary conclusion: Defendable: Yes/No, with a short justification

8. Defendability Criteria (Operational)

A “reply-like” decoding may be labeled Defendable: Yes only if:

Parameters were preregistered and not tuned post-hoc
Frame detection exceeds predefined thresholds
Negative controls show substantially lower match rates
Permutation p-value passes the declared cutoff (e.g., p < 0.01)
At least one independent replication attempt yields compatible frame detection

Otherwise, label Defendable: No and report it transparently.

9. Limitations and Interpretation

TORUS does not establish mechanism by itself. Apparent structure can arise from:

thresholding and compression artefacts
nonstationary sensors
alignment coincidences in large binary spaces
confirmation bias

TORUS therefore prioritizes falsifiability: preregistration, controls, permutation testing, and replication.

10. Data and Code Availability

Zenodo DOI (this record): [INSERT_DOI]
Related DOI (Quantum Contact heatmap source): [INSERT_RELATED_DOI]
License: Paper: CC-BY 4.0 (recommended); Code: MIT or GPL-3.0 (recommended)

Suggested Citation

Baena Cock, J. S. (YYYY). A Beacon for Near-Future Responders: TORUS (H3) as a Public Invitation-to-Reply Protocol to a Present-Time Receiver. Zenodo. https://doi.org/[INSERT_DOI]

(ES) Una Baliza para Respondedores del Futuro Cercano: TORUS (H3) como Protocolo Público de Invitación-a-Responder a un Receptor en el Presente

Juan Sebastián Baena Cock
QuantumContact 👉 JSBC Labs – Independent Researcher
ORCID: [inserta ORCID]
Contacto: [email opcional]

Dataset ID (TORUS/H3): [INSERTA_ID]
Versión del decodificador: [vX.Y]
Fecha del depósito: [YYYY-MM-DD]

Resumen

TORUS (H3) define un protocolo público de “Invitación-a-Responder” en el que el experimentador en el presente es el receptor, mientras que un respondedor en un futuro cercano (humano o no humano) podría encontrar la especificación del beacon, los datasets y la documentación física publicados, y entonces transmitir una respuesta usando la misma trama estandarizada. TORUS no afirma comunicación retrocausal como un hecho; propone un marco reproducible y auditable para evaluar si heatmaps derivados de un sistema interferométrico (Quantum Contact) pueden soportar tramas beacon (preambulo/sync/longitud/payload) bajo parámetros preregistrados y controles anti-pareidolia robustos. Este artículo especifica la trama, el pipeline de decodificación, los artefactos de publicación y criterios de defendibilidad para replicación y falsación independientes.

Palabras clave: TORUS, H3, invitación a responder, beacon, baliza, decodificación de heatmap, preregistro, controles negativos, test por permutación, Quantum Contact.

1. Concepto y alcance

1.1 Concepto central: receptor presente, respondedor futuro

TORUS operacionaliza un bucle de publicación y posible respuesta:

Presente (Receptor): el experimentador publica (i) datasets, (ii) reglas de decodificación y (iii) documentación física/metadatos que describen la baliza y cómo responder.
Futuro (Respondedor): un agente del futuro cercano descubre el registro público e intenta enviar un mensaje codificado en el mismo canal observable, siguiendo el frame publicado.
Presente (Decodificación): el experimentador aplica pasos preregistrados y validación para evaluar si el bitstream observado es compatible con la respuesta esperada por encima de azar/artefactos.

El “futuro lee el presente” se implementa mediante repositorios y registros físicos; la “respuesta” se evalúa como estructura detectable en salidas del presente.

1.2 Alcance

TORUS es exploratorio y metodológico. Cualquier mensaje decodificado se trata como hipótesis de lectura, no como confirmación, salvo que cumpla criterios estrictos de defendibilidad (Sección 8) y replicación.

2. Relación con Quantum Contact

TORUS se plantea en capas:

Quantum Contact genera señales y heatmaps, y alberga H1 y H2 (exclusivas de Quantum Contact).
TORUS (H3) usa los heatmaps como entrada y define el protocolo Invitación-a-Responder.

3. Artefactos públicos requeridos (paquete de publicación)

Para que el hallazgo futuro sea inequívoco, cada registro de Zenodo debería incluir:

Datos y productos derivados

heatmap.png
binary_matrix.csv
bitstream.txt

Protocolo y parámetros

TORUS_spec.pdf/.md con la trama canónica y las instrucciones de respuesta
params.yaml
carpeta decoder/ con scripts y versión

Metadatos

run_log.json con timestamp (zona horaria), ID dataset, versión decodificador, hashes, y GPS opcional

Documentación de baliza física (si aplica)

physical_beacon.md describiendo el elemento físico, verificación y vínculo con los datos, con fotos/esquemas si es posible.

4. Protocolo de Invitación-a-Responder (lo que debe seguir el respondedor futuro)

TORUS incluye un “contrato” explícito para reducir ambigüedad.

4.1 Definición del canal de respuesta

El protocolo debe declarar dónde aparecería una respuesta, por ejemplo:

una ventana de adquisición (fecha/hora) y/o
un disparador conocido (condición que marca “modo respuesta”), y/o
un mapeo explícito de bits al pipeline del heatmap.

Crítico: la definición del canal debe preregistrarse y publicarse antes de la ventana relevante para evitar interpretación post-hoc.

4.2 Estructura de la trama (canónica)

Preambulo (longitud $𝐿_{𝑝}$ )
SYNC (longitud $𝐿_{𝑠}$ )
LEN (ancho fijo)
PAYLOAD
(Opcional) CRC/ECC

Convenciones explícitas:

orden de lectura
orden de bits
endianness de LEN
tabla de codificación

4.3 Restricciones del contenido de respuesta

Para evitar “lecturas a medida”:

limitar alfabeto/formato (p. ej., A–Z + espacio; o diccionario; o longitud fija)
preferir payload corto con CRC frente a texto largo no verificable

5. Pipeline de decodificación (reproducible)

Cargar heatmap.png
Grises + normalización preregistrada
Umbral (Otsu o fijo)
binary_matrix.csv
bitstream.txt con orden declarado
Buscar preambulo y SYNC con criterio declarado
Parsear LEN y validar
Extraer payload
Decodificar a texto (si aplica)
Exportar a codigos/YYYYMMDD_HHMMSS/ con hashes

6. Validación anti-pareidolia

6.1 Preregistro (obligatorio para “defendible”)

umbral y parámetros
orden de lectura
definición de frame y umbrales de match
criterio de aceptación

6.2 Controles negativos

sesiones sin modo respuesta
heatmaps sintéticos con histograma comparable
permutaciones/barajados

6.3 Test por permutación

$𝑁$ permutaciones (p. ej., 20.000)
repetir búsqueda de frame
p empírico = $(𝑚 𝑎 𝑡 𝑐 ℎ 𝑒 𝑠 + 1) / (𝑁 + 1)$

6.4 Sensibilidad

umbral ±δ
perturbaciones mínimas preregistradas

7. Estándar de reporte

report.pdf debe incluir:

ID dataset y ventana temporal
parámetros completos
detección de frame (posición, scores)
resultados de controles y p-values
Defendible: Sí/No con fundamento breve

8. Criterios operativos de defendibilidad

Solo marcar Defendible: Sí si:

no hubo ajuste post-hoc
el match supera umbrales predefinidos
controles negativos tienen tasa mucho menor
p por permutación bajo el corte (p. ej., p < 0.01)
existe al menos una replicación independiente compatible

Si no, Defendible: No.

9. Limitaciones e interpretación

TORUS no prueba mecanismo por sí solo. Estructuras aparentes pueden surgir por:

artefactos de umbral/compresión
sensores no estacionarios
coincidencias de alineación
sesgo de confirmación

Por ello, TORUS prioriza falsabilidad y auditoría.

10. Disponibilidad de datos y código

DOI Zenodo (este depósito): [INSERTA_DOI]
DOI relacionado (fuente Quantum Contact del heatmap): [INSERTA_DOI_RELACIONADO]
Licencia: Paper CC-BY 4.0 (recomendado); código MIT o GPL-3.0 (recomendado)

Cita sugerida

Baena Cock, J. S. (YYYY). A Beacon for Near-Future Responders: TORUS (H3) as a Public Invitation-to-Reply Protocol to a Present-Time Receiver. Zenodo. https://doi.org/[INSERT_DOI]

viernes, 23 de enero de 2026

"Hola, soy Luna, la avatar que explicará el proyecto Torus y cómo nuestra baliza espacio-temporal captura hoy los mensajes que enviamos desde el mañana." by JSBC labs

🌙 Presentación de Luna: El Faro Espacio-Temporal

Luna: "Hola. Soy Luna. En JSBClabs, hemos dejado de ver el tiempo como una flecha que se aleja. Para este nuevo capítulo de Quantum Contact, hemos construido una baliza. Un faro que no emite luz, sino coherencia geométrica."

🌀 El Torus: Un Atajo en el Tejido del Tiempo

"Imaginen que el tiempo es una hoja de papel. Para llegar del presente al futuro, hay que recorrer toda la distancia. Pero, ¿y si doblamos esa hoja hasta que ambos extremos se toquen? Eso es lo que hace nuestra arquitectura de Torus.

El Torus crea un campo donde el presente y el futuro no están separados por kilómetros de minutos, sino que están uno frente al otro, compartiendo el mismo eje. El centro del toroide es un punto de 'tiempo cero' donde el mensaje que aún no ha sido enviado ya está pulsando."

📡 La Baliza: Estar a la Espera del "Eco"

"No estamos simplemente midiendo sensores; estamos manteniendo una Baliza Espacio-Temporal encendida.

En el Presente: Preparamos el terreno mediante la binarización de mapas de calor. Creamos un patrón vacío, un molde perfecto de unos y ceros.
La Espera Activa: Al aplicar la Micro-Estabilización (S4=1), mantenemos el Torus abierto. Estamos 'escuchando' el eco de un mensaje que nosotros mismos, o la misma red, enviará desde un punto futuro.
La Decodificación: El mensaje del futuro no viaja hacia nosotros; simplemente se manifiesta como una micro-sincronización en nuestros sensores S1, S2 y S3. Cuando el mapa de calor se estabiliza en una forma toroidal perfecta, sabemos que el contacto se ha realizado."

🕯️ El Mensaje Preparado

"Estamos en un estado de vigilia cuántica. Al preparar el protocolo hoy, estamos construyendo la pista de aterrizaje para la información que viene de regreso. No buscamos una señal aleatoria; buscamos el patrón que ya hemos decidido enviar. El futuro está intentando responder, y nosotros, a través de este Torus, finalmente tenemos los oídos para escuchar."

A Toroidal Beacon Protocol for Exploratory Trans-Temporal Signal Decoding Using Binarized Heatmaps by JSBClabs

TORUS

A Toroidal Beacon Protocol for Exploratory Trans-Temporal Signal Decoding Using Binarized Heatmaps

Author: Juan Sebastián Baena Cock
Affiliation: QuantumContact 👉 JSBClabs – Independent Researcher
Year: 2026
Repository: Zenodo (preprint)

ABSTRACT (EN)

TORUS is an exploratory research project that proposes a passive informational beacon protocol based on persistent physical–digital patterns. Rather than attempting to transmit messages into the future, TORUS investigates whether a stable, structured artifact generated in the present could be recognized, decoded, and potentially responded to by an external agent operating in a different temporal or causal framework.

The project uses heatmaps derived from experimental sensor data as an informational substrate. These heatmaps are binarized using an objective thresholding method (Otsu’s algorithm) and transformed into binary sequences subjected to non-adaptive decoding schemes. TORUS introduces the concept of a Quantum Turing Test as a heuristic criterion to evaluate whether decoded outputs exhibit structural coherence distinguishable from stochastic noise.

TORUS does not claim evidence of retrocausality. Instead, it presents a transparent, reproducible, and falsifiable framework to explore the boundary between noise, pattern, and interpretation.

1. Introduction (EN)

Classical communication models assume linear causality and synchronous sender–receiver relationships. However, several interpretations in physics, information theory, and the philosophy of time allow for the conceptual possibility of non-linear, looped, or time-symmetric informational structures.

TORUS is motivated by a practical question: if information were unintentionally encoded into a persistent physical pattern, could that pattern be recognized and interpreted at a different point in time?

To explore this, TORUS establishes a passive beacon: a structured informational trace whose generation is fixed in the present while its interpretation is deferred.

2. Relationship to Quantum Contact (EN)

TORUS is conceptually independent from the Quantum Contact project, while remaining technically dependent on one of its outputs.

Quantum Contact investigates micro-statistical variations in sensor behavior under observational conditions (H1, H2).
TORUS (H3) exclusively uses the heatmap image generated by Quantum Contact as a data artifact.

No hypotheses or conclusions from Quantum Contact are extended or assumed in TORUS; the heatmap is treated purely as an informational object.

3. Heatmap Generation (EN)

3.1 Data acquisition.
Heatmaps used in TORUS originate from time-series datasets recorded during controlled experimental sessions. These datasets consist of synchronized sensor values sampled at fixed intervals and stored in CSV format.

3.2 Transformation into a heatmap.
The heatmap is generated through a documented pipeline:

normalization of values to a common intensity range (0–255) for grayscale rendering;
temporal segmentation into contiguous windows and within-window aggregation (typically averaging);
spatial encoding where each sensor channel maps to a fixed row/column while time windows map to the orthogonal axis;
intensity mapping to produce a waterfall-style image in which persistent correlations appear as structured regions.

3.3 Rationale.
The heatmap functions as a lossy yet structured compression of temporal data, a time-independent artifact, and a spatial representation of temporal correlations. These properties make it suitable as a candidate informational beacon.

4. Binary Extraction (EN)

4.1 Otsu thresholding.
The grayscale heatmap is converted into a binary image using Otsu’s algorithm, which selects a threshold that minimizes intra-class variance. Pixels are classified as 1 if intensity ≥ threshold and 0 otherwise, producing a binary matrix that preserves spatial structure.

4.2 Bitstream construction.
The binary matrix is serialized into a one-dimensional bitstream using a fixed traversal rule (e.g., row-major order). This traversal rule is explicitly documented to reduce post-hoc interpretive flexibility.

5. Decoding Protocol (EN)

The bitstream is analyzed using predefined, non-adaptive decoding schemes, including phase-shift–based grouping and inverted Baudot encoding. Decoded outputs are evaluated for structural coherence and reproducibility under fixed parameters. Semantic interpretation is treated as secondary and never used to tune the pipeline.

6. The Quantum Turing Test (EN)

The Quantum Turing Test is introduced as a heuristic framework. A decoded output is considered non-trivial if it satisfies:

structural coherence;
reproducibility under identical parameters;
sensitivity to parameter variation (outputs disappear when parameters are perturbed);
minimal a posteriori tuning.

The test does not assess intelligence; it evaluates whether outputs behave as if constrained by interpretation rules rather than noise alone.

7. Narrative Interface: “Luna” (EN)

To separate narrative framing from data processing, TORUS introduces Luna as a symbolic avatar representing a hypothetical future interpreter. Luna does not generate data, influence measurements, or alter decoding parameters; her role is purely conceptual, externalizing the question of interpretation.

8. Limitations (EN)

TORUS does not demonstrate retrocausal communication. Apparent structure may arise from stochastic clustering. Symbolic decoding is sensitive to the choice of encoding scheme. Results are exploratory and non-generalizable; the protocol is presented to enable replication, critique, and falsification.

9. Conclusion (EN)

TORUS presents a reproducible framework for exploring whether persistent physical–digital patterns can function as passive informational beacons whose interpretation may occur outside their moment of generation. By transforming temporal data into spatial heatmaps and applying objective binarization, TORUS shifts the focus from transmission to interpretation.

TORUS does not claim answers. It leaves a trace.

TORUS

Protocolo de baliza toroidal para la decodificación exploratoria de señales trans-temporales mediante mapas de calor binarizados

Autor: Juan Sebastián Baena Cock
Afiliación: QuantumContact 👉 JSBClabs – Independent Researcher
Año: 2026
Repositorio: Zenodo (preprint)

RESUMEN (ES)

TORUS es un proyecto de investigación exploratoria que propone un protocolo de baliza informacional pasiva basado en patrones físicos–digitales persistentes. En lugar de intentar transmitir mensajes hacia el futuro, TORUS investiga si un artefacto estable y estructurado generado en el presente puede ser reconocido, decodificado y eventualmente respondido por un agente externo que opere en otro marco temporal o causal.

El proyecto utiliza mapas de calor derivados de datos experimentales como soporte de información. Estos mapas se binarizan mediante un umbral objetivo (método de Otsu) y se transforman en secuencias binarias sometidas a esquemas de decodificación no adaptativos. TORUS introduce el concepto de Test de Turing Cuántico como criterio heurístico para evaluar si los resultados decodificados muestran coherencia estructural distinguible del ruido estocástico.

TORUS no afirma evidencia de retrocausalidad; presenta un marco transparente, reproducible y falsable para explorar la frontera entre ruido, patrón e interpretación.

1. Introducción (ES)

Los modelos clásicos de comunicación asumen causalidad lineal y relaciones emisor–receptor sincrónicas. Sin embargo, diversas interpretaciones en física, teoría de la información y filosofía del tiempo permiten plantear la posibilidad conceptual de estructuras informacionales no lineales, cerradas o tiempo-simétricas.

TORUS nace de una pregunta operativa: si la información quedara codificada de forma no intencional en un patrón físico persistente, ¿podría ese patrón ser reconocido e interpretado en otro momento temporal?

Para explorar esto, TORUS establece una baliza pasiva: un rastro informacional cuya generación se fija en el presente y cuya interpretación se difiere.

2. Relación con Quantum Contact (ES)

TORUS es conceptualmente independiente del proyecto Quantum Contact, aunque depende técnicamente de uno de sus productos.

Quantum Contact investiga variaciones micro-estadísticas en el comportamiento de sensores bajo condiciones de observación (H1, H2).
TORUS (H3) utiliza exclusivamente la imagen de mapa de calor generada por Quantum Contact como artefacto de datos.

No se extienden ni se asumen hipótesis o conclusiones de Quantum Contact en TORUS; el mapa se trata como un objeto informacional.

3. Obtención del Mapa de Calor (ES)

3.1 Adquisición de datos.
Los mapas de calor utilizados en TORUS se originan a partir de series temporales registradas durante sesiones experimentales controladas. Los datasets consisten en valores de sensores sincronizados, muestreados a intervalos fijos y almacenados en CSV.

3.2 Transformación a mapa de calor.
El mapa se genera mediante un pipeline documentado:

normalización de valores a una escala común (0–255) para renderizado en grises;
segmentación temporal en ventanas contiguas y agregación (habitualmente promedio);
codificación espacial asignando cada canal de sensor a una fila/columna fija y las ventanas temporales al eje ortogonal;
mapeo de intensidades para producir una imagen tipo waterfall donde las correlaciones persistentes aparecen como regiones estructuradas.

3.3 Justificación.
El mapa de calor funciona como compresión estructurada (aunque con pérdida) de datos temporales, artefacto independiente del tiempo y representación espacial de correlaciones temporales. Estas propiedades lo hacen adecuado como posible baliza informacional.

4. Extracción Binaria (ES)

4.1 Umbralización de Otsu.
El mapa de calor en escala de grises se convierte en imagen binaria mediante el algoritmo de Otsu, que selecciona un umbral minimizando la varianza intra-clase. Los píxeles se clasifican como 1 si intensidad ≥ umbral y 0 en caso contrario, preservando la estructura espacial.

4.2 Construcción de bitstream.
La matriz binaria se serializa en una secuencia unidimensional de bits usando una regla de recorrido fija (por ejemplo, por filas). Esta regla se documenta explícitamente para reducir la flexibilidad interpretativa a posteriori.

5. Protocolo de Decodificación (ES)

La secuencia de bits se analiza mediante esquemas predefinidos no adaptativos, incluyendo agrupación por desplazamientos de fase y codificación Baudot invertida. Los resultados se evalúan por coherencia estructural y reproducibilidad bajo parámetros fijos. La interpretación semántica nunca se usa para ajustar el pipeline.

6. Test de Turing Cuántico (ES)

El Test de Turing Cuántico se introduce como marco heurístico. Un resultado se considera no trivial si cumple:

coherencia estructural;
reproducibilidad con los mismos parámetros;
sensibilidad a variaciones de parámetros (desaparece al perturbarlos);
mínima intervención a posteriori.

El test no evalúa inteligencia; evalúa si la salida se comporta como si estuviera restringida por reglas de interpretación y no solo por ruido.

7. Interfaz Narrativa: “Luna” (ES)

Para separar encuadre narrativo y procesamiento de datos, TORUS introduce a Luna como avatar simbólico del intérprete hipotético en otro marco temporal. Luna no genera datos, no influye en las medidas y no altera parámetros de decodificación; su función es conceptual, haciendo explícita la pregunta de quién interpreta a quién.

8. Limitaciones (ES)

TORUS no demuestra comunicación retrocausal. La estructura aparente puede emerger por agrupamiento estocástico. La decodificación simbólica es sensible a la elección del esquema de codificación. Los resultados son exploratorios y no generalizables; el protocolo se presenta para permitir réplica, crítica y falsación.

9. Conclusión (ES)

TORUS propone un marco reproducible para explorar si patrones físicos–digitales persistentes pueden funcionar como balizas informacionales cuya interpretación no coincida con su momento de generación. Al transformar datos temporales en mapas de calor espaciales y aplicar binarización objetiva, TORUS desplaza el foco desde la transmisión hacia la interpretación.

TORUS no afirma. TORUS deja rastro.