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:

  1. Datasets and derived products

  • heatmap.png (or equivalent)

  • binary_matrix.csv (0/1 after thresholding)

  • bitstream.txt (serialized bits with explicit read order)

  1. 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)

  1. Run metadata

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

  1. 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)

  1. Load heatmap.png

  2. Convert to grayscale; normalize if preregistered

  3. Threshold (Otsu or fixed threshold; preregistered)

  4. Output binary_matrix.csv

  5. Serialize to bitstream.txt using declared read order

  6. Search for preamble and SYNC using declared matching criteria

  7. Parse LEN and validate bounds

  8. Extract payload bits

  9. Decode payload to text (if applicable) using published mapping

  10. 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:

  1. Datos y productos derivados

  • heatmap.png

  • binary_matrix.csv

  • bitstream.txt

  1. 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

  1. Metadatos

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

  1. 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)

  1. Cargar heatmap.png

  2. Grises + normalización preregistrada

  3. Umbral (Otsu o fijo)

  4. binary_matrix.csv

  5. bitstream.txt con orden declarado

  6. Buscar preambulo y SYNC con criterio declarado

  7. Parsear LEN y validar

  8. Extraer payload

  9. Decodificar a texto (si aplica)

  10. 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:

  1. normalization of values to a common intensity range (0–255) for grayscale rendering;

  2. temporal segmentation into contiguous windows and within-window aggregation (typically averaging);

  3. spatial encoding where each sensor channel maps to a fixed row/column while time windows map to the orthogonal axis;

  4. 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:

  1. structural coherence;

  2. reproducibility under identical parameters;

  3. sensitivity to parameter variation (outputs disappear when parameters are perturbed);

  4. 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:

  1. normalización de valores a una escala común (0–255) para renderizado en grises;

  2. segmentación temporal en ventanas contiguas y agregación (habitualmente promedio);

  3. codificación espacial asignando cada canal de sensor a una fila/columna fija y las ventanas temporales al eje ortogonal;

  4. 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:

  1. coherencia estructural;

  2. reproducibilidad con los mismos parámetros;

  3. sensibilidad a variaciones de parámetros (desaparece al perturbarlos);

  4. 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.

jueves, 22 de enero de 2026

What if the “future” doesn’t exist as a finished place waiting for us to arrive? by JSBClabs

 



What if the “future” doesn’t exist as a finished place waiting for us to arrive?

What if what we call the future is simply the world updating itself—moment by moment, branch by branch—less like a straight road and more like a tree that keeps splitting? A reality that isn’t “there” in full, but becomes fixed only as each instant resolves.

This is where the uncomfortable (and fascinating) part enters: consciousness.

In quantum physics, before a measurement we talk in terms of probabilities, superpositions, and amplitudes. Not because the universe is mystical, but because the best model we have describes multiple possible outcomes until a concrete interaction forces one outcome to become the one we can record. And while “consciousness” and “measurement” are not the same thing, it’s hard to avoid the question:

What if consciousness is, at the very least, a marker—an act of attention that turns a cloud of possibilities into a stable, documented state?

I’m not saying “mind controls matter.” That’s the easy headline. The seductive one. The one that requires the least discipline.

What I am saying is simpler and harder:

What if consciousness doesn’t create reality, but it selects what becomes stable—what becomes communicable, measurable, traceable?

This is the philosophical core behind my new project, TORUS.

TORUS is not about receiving a message from “the future” as if time were a straight line. In this framework, TORUS becomes something else: a way to test whether a prepared observer—an intentional act of attention—can correlate with the emergence of coherence in a system that otherwise behaves like noise.

Not a miracle. A signature.

And that’s why TORUS is built to be boring in the right way: strict, traceable, auditable.

My “beacon” is not a metaphor. It is a mechanism:

  • sessions recorded raw, without interpretation,

  • artifacts sealed with logs and integrity checks,

  • a decoding method with limited degrees of freedom,

  • and a single brutal rule: if it can’t be verified and repeated, it doesn’t count.

Because if reality is assembled moment by moment, the real question isn’t “can a message arrive?”

The real question is whether the world leaves a fingerprint when you fix the process with rules—when you prepare the receiver, when you define the channel, when you refuse to let narrative replace data.

In that sense, consciousness wouldn’t be a magician.

It would be a switch: it doesn’t invent the light, but it may decide when the circuit closes—and when the event becomes a recorded fact.

That is what TORUS is looking for.

Not a letter.

A signature.

El Blog de JSBAenacock

Divulgador