(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]