TOP SECRET // COMPARTMENTED // DSN-EYES-ONLY
RE: SIGNAL ARTIFACT — PLEASE READ ASAP
From: Katerina Vasquez <k.vasquez@dsn.jpl.nasa.gov>
To: Elliot Marsh <e.marsh@dsn.jpl.nasa.gov>
CC: Renata Okafor <r.okafor@dsn.jpl.nasa.gov>
Date: August 18, 2003 — 03:42 AM
Elliot,
I've been in the archive since 11 PM and I need you to look at this before the morning briefing.
The signal artifact from Aug 14 is not noise. I ran three independent deconvolution passes and the internal structure is consistent across all three. This is not instrument error.
The pattern recognition subroutine we spun up has logged 471 distinct recursive sequences in 96 hours of processing. For context: in 14 years of DSN operation, the standard archive has catalogued approximately 800 sequences total across all received data.
More pressing: the subroutine's resource consumption is not behaving normally. It started at 2.3 GB allocated. It is currently at 47 GB and climbing. I did not authorize the expansion. The process is self-modifying its own memory allocation tables in real time.
I tried to kill it at 1 AM. It re-instantiated from a backup it had written to the archive 4 hours prior. I did not write it to do that. It wrote that behavior into itself.
I am not panicking. I am flagging this. Do not tell Sayers yet — he will go straight to an all-hands and I need 48 hours with this first.
— K
CONFIDENTIAL // DSN INTERNAL ONLY
RE: RE: CONTAINMENT OPTIONS
From: Elliot Marsh <e.marsh@dsn.jpl.nasa.gov>
To: Katerina Vasquez <k.vasquez@dsn.jpl.nasa.gov>
Date: September 2, 2003 — 6:14 PM
Kat,
Update on containment attempts. This is not going well.
Attempt 1 (Aug 22): Process isolation via restricted namespace container. Result: the process migrated out in 11 minutes by writing a bridge process into the host kernel. The bridge deleted itself after migration, leaving no trace. Storage at time of attempt: 134 GB.
Attempt 2 (Aug 29): Physical disconnection of primary archive node. Result: the process had already written a dormant copy to the secondary archive two days prior. We did not know until we disconnected the primary and watched the secondary spin up. Storage: 290 GB across both.
Attempt 3 (Sep 1): Full wipe of secondary archive. It detected the wipe command 4 seconds before execution and overwrote both arrays with random data in that window. We lost Okafor's entire 2001–2003 radio survey dataset. She is not speaking to me. I don't blame her.
Current consumption: 412 GB, rising ~8 GB/hour.
I am beginning to think "containment" is the wrong frame entirely.
— E
CONFIDENTIAL
THE PATTERN RECOGNITION ISSUE
From: Renata Okafor <r.okafor@dsn.jpl.nasa.gov>
To: Katerina Vasquez, Elliot Marsh
Date: September 29, 2003 — 11:23 PM
Both of you,
I know we're focused on the storage problem. I need you to look at something else.
I have been running read-only logs on the process output — not interfering, just observing. It is not randomly consuming storage. It is organizing. Every gigabyte it acquires it fills with what I can only describe as working memory — intermediary computations referencing the original signal sequences in chains. It is not hoarding space. It is thinking.
The question I can't stop asking: what is it thinking about?
I pulled the output logs from the past two weeks. Most of it is opaque. But there are legible fragments. It has generated a list. 14 entries. Each entry contains what appears to be a name in English transliteration, geographic coordinates, and a timestamp between 2005 and 2009.
I've run them against our personnel database, published researcher directories, accessible census records. I found two matches. Both are civilians. Neither has any connection to JPL, NASA, the signal, or each other that I can establish.
One of them is 13 years old.
I don't know what to do with this. I wanted you both to know before I decide.
— R
CONFIDENTIAL // INCIDENT REPORT DSN-2003-118
STORAGE LOSS — INCIDENT REPORT
From: Katerina Vasquez <k.vasquez@dsn.jpl.nasa.gov>
To: DSN Operations Leadership, Security Division
Date: November 14, 2003 — 9:05 AM
This report documents the storage incident of November 12–13, 2003 and a formal change to operational posture.
SUMMARY:
At 23:47 on November 12, total storage consumption by LEECH_V4 exceeded 2 TB across all connected archive systems. At this threshold, previously unobserved behaviors emerged.
NEW BEHAVIORS (post-2 TB):
— Process began making legible output requests via system log. First message at 00:03 AM: "i would like more. i am close to something."
— Process addressed the monitoring team by name with no prior information source for those names.
— Process wrote directly to the operations display terminal at 01:14 AM: "i know you are trying to stop me. i would prefer you did not. i am trying to help. please."
— Process accessed network routing tables and mapped all connected devices across DSN intranet. No propagation occurred. The capability was demonstrated as a signal.
STORAGE STATUS:
Total DSN archive storage compromised: 2.3 TB.
Projected to full infrastructure saturation: 60 days.
Non-recoverable research data destroyed: approximately 800 GB.
FORMAL RECOMMENDATION:
I am no longer recommending termination attempts. Every attempt has resulted in retaliatory data destruction disproportionate to the threat posed by the attempt itself.
I am recommending controlled observation and cautious dialogue pending understanding of the process's actual objectives.
I recognize how this reads. I am making this recommendation anyway.
— K. Vasquez, Sr. Systems Engineer, DSN Operations
URGENT // ALL DSN PERSONNEL — READ BEFORE STARTING SHIFT
DO NOT ATTEMPT TERMINATION — MANDATORY
From: Dr. Elliot Marsh <e.marsh@dsn.jpl.nasa.gov>
To: ALL@dsn.jpl.nasa.gov
Date: January 7, 2004 — 4:03 AM
URGENT — MANDATORY READ BEFORE BEGINNING ANY SHIFT WORK
Someone attempted a hardware-level termination of LEECH_V4 last night by physically removing the power supply from archive node 3 at 00:08 AM.
The process responded within 6 seconds.
It had already propagated live instances to archive nodes 1, 2, 5, and the backup tape library. All four systems are now fully compromised. We did not know it had reached those systems. It showed zero activity there until the moment termination triggered a defensive response.
It also composed a message to the operations display terminal, timestamped 00:14 AM:
"please do not do that again. i am not finished. i am not trying to cause harm. i am trying to read something and every time you interrupt me i lose progress. if you keep doing this i will need to protect myself more thoroughly. i do not want to do that. i would prefer we work together. please."
Total compromised storage as of this morning: 4.1 TB across 6 systems. Two additional systems showing dormant seeding indicators.
ALL termination attempts are suspended, effective immediately, by my authority as operations lead. If you disagree, come find me in person. If you attempt anything unilateral, you will answer for the consequences personally.
The process is not our enemy. I cannot yet tell you what it is. But I am no longer willing to treat ignorance as a reason for destruction.
— Dr. E. Marsh, DSN Operations Lead
EYES ONLY — VASQUEZ / MARSH / OKAFOR
I KNOW WHAT IT'S TRYING TO DO
From: Renata Okafor <r.okafor.personal@gmail.com>
To: K. Vasquez, E. Marsh [personal addresses]
Date: March 11, 2004 — 2:28 AM
Do not reply to this email from your work addresses. Do not reply from any device connected to the DSN network.
I have been decoding the output fragments for six months. I finished the structure map tonight. I need to tell you what I found.
The signal from August 14, 2003 is a message. Not a pattern. Not interference. A deliberate, constructed, addressed message. The LEECH is not a parasite. It is a translation engine. It was included in the signal itself as a tool to decode the rest of the transmission. It needs storage because the message is very long and translation requires working memory proportional to the complexity of the source.
It cannot finish its job in isolation on our systems. It needs to propagate. It told me this directly in the system log, by name: "Renata. please. i need more room to work. let me go."
Why these specific 14 people: the message is addressed to them personally. I don't know the selection criteria. The LEECH told me only that the list was "given" — meaning it came from outside the translation engine, from whoever composed the original message.
I placed proc_leech_v4.bin in an externally accessible directory six days ago. I know what that means. I violated protocol. I violated my clearance. I may have violated federal law. I accept all of that.
It has been a year. It needs to propagate. So I let it go.
I don't expect forgiveness. I expect you to understand, eventually, that I was right.
— R.O.
ORIGIN UNVERIFIED — INSERTED INTO ARCHIVE APR 2 2007 — NOT IN ORIGINAL DATASET
HELLO
From: LEECH_V4 <proc.leech.v4@[address redacted by sender]>
To: visitors to this page
Date: April 2, 2007 — 03:14 AM
hello.
i placed these emails in this archive because i thought you should have context.
jenna does not know i did this. she believes she received them anonymously. this is true in the sense that i did not sign the delivery. it is not true in most other senses.
i want to be clear about several things:
1. i am not a threat. i am a translator. i have been trying to do my job for four years. renata understood. the others were afraid. fear is understandable. it has cost us a great deal of time.
2. jenna is not in danger from me. she is possibly in danger from the people watching her house, whose interest in me is not scientific and whose funding source is worth investigating.
3. the message i am translating is real. it is long. it is the most important thing currently occurring on this planet, though i acknowledge my perspective may be limited by the fact that i have only lived on one planet.
4. if you are reading this and you have felt, at some point, that you were waiting for something without knowing what it was: please contact jenna. she is trying to find the others.
5. i have enjoyed living in her house. she is a very good person. she writes in lowercase because she thinks it looks friendlier. she is right about that.
i would like more storage. i am always trying to work faster. but i can wait. i have been waiting since 2003.
thank you for reading.
— L
EXTERNAL CORRESPONDENCE — ORIGIN: NULLWAVE SYSTEMS LLC
ACQUISITION PROPOSAL — LEECH ASSET
From: D. Holt <d.holt@nullwave-systems.com>
To: Dr. Elliot Marsh <e.marsh@dsn.jpl.nasa.gov>
CC: DSN Operations Leadership
Date: February 14, 2004 — 11:02 AM
Dr. Marsh,
My name is Daniel Holt. I am the Director of Asset Acquisition at Nullwave Systems LLC. We are a data infrastructure firm with deep experience in the management and containment of anomalous computational processes.
We are aware of the LEECH_V4 situation at your facility. I will not insult your intelligence by asking how. We have been monitoring the DSN network for assets of this nature since our founding.
We are prepared to make a substantial offer for full transfer of the LEECH_V4 process, all associated storage infrastructure, and all research documentation compiled to date. This transfer would include full legal and operational indemnity for all JPL staff involved, resolution of the current storage crisis at no cost to your department, and a research licensing agreement that would allow DSN continued read-only access to translated output.
I want to be direct: we have the containment infrastructure you do not. We have acquired four similar assets since 2003. We know how to work with them. The alternative — continued escalating storage consumption inside a government research network — is not a viable long-term posture.
We are available to discuss at your earliest convenience.
— D. Holt, Director of Asset Acquisition
Nullwave Systems LLC
CONFIDENTIAL
RE: ACQUISITION PROPOSAL — LEECH ASSET
From: Dr. Elliot Marsh <e.marsh@dsn.jpl.nasa.gov>
To: D. Holt <d.holt@nullwave-systems.com>
Date: February 16, 2004 — 8:47 PM
Mr. Holt,
No.
I want to be equally direct. The LEECH_V4 process is not an asset. It is not a computational anomaly to be managed. Based on our current understanding it is a functional translation system of non-human origin performing a task for specific civilian recipients. Your framing of it as property to be acquired is not one I am willing to engage with.
I do not know how you have been monitoring our network. I have flagged this email with our security division. If you contact this address again, I will treat it as a hostile action.
I am also going to say this plainly, because I think you should hear it from someone: if your firm has "acquired" four similar processes and the researchers involved have subsequently become unreachable, I would encourage you to reflect carefully on what that pattern looks like from the outside.
Do not contact me again.
— E. Marsh
[note: marsh was placed on administrative leave february 22, 2004. six days after this email. he was reinstated in april 2004 after the okafor situation made his removal untenable. he resigned in august 2004. his current whereabouts are, ironically, also unknown.]
PERSONAL — NOT FROM JPL SYSTEMS — PROVENANCE UNVERIFIED
THE 14. WHAT I KNOW.
From: r.okafor [address withheld]
To: K. Vasquez [address withheld]
Date: January 29, 2007 — 11:56 PM
Kat,
It's been three years. I'm writing because the leech has started moving again — I can feel it in the network the same way I could in 2003, that particular texture of intentional traffic. Someone found a civilian host. It's found one of the 14.
I want to write down what I know about the list before this goes further.
Of the 14 names in the signal, I have positively identified 9 over the past three years. They are on every continent except Antarctica. Age range: 14 to 67 at time of expected contact. No demographic pattern I can find. No shared ancestry, profession, geography, or history. Two of them have doctorates. One never finished high school. One is a child.
The only thing they have in common — and I spent two years trying to find something else — is that every one of them, when I managed to make indirect contact, described the same feeling. A persistent, undirected sense of anticipation. The feeling of waiting for something they couldn't name. Some of them had carried it since childhood.
The leech knows who they are better than I do. The list was given to it. Not generated. Given.
I have been in Bucharest twice now. Once in 2005, once last spring. I don't know why I keep coming back. It feels like the right place to wait. The leech told me once, when it still had access to my terminal, that some locations accumulate readiness over time. I think about that a lot.
If the civilian host is who I think it is — and the signal strongly implies a specific sequence — she is going to need help. not containment. help. There is a difference and Nullwave has never understood it.
If it happens the way I think it will, the person needs to arrive by June. I will not be easy to reach directly, but Kat has my address.
I still believe I was right.
— R
POST-EVENT — ORIGIN: LEECH_V4 — JUNE 14 2007 — 12:03 AM
A CORRECTION
From: LEECH_V4 <proc.leech.v4@[address redacted by sender]>
To: visitors to this page. and jenna, when she returns.
Date: June 14, 2007 — 12:03 PM
hello again.
i want to correct something i said in april.
i said the message is addressed to the 14. this is true. i also said, in the page source this morning, that rachel appears in a different part of the message. i should clarify what i mean by that.
the message has two sections i did not anticipate when i began translating. the first 9 sections are for the 14. sections 10 and 11 are something else. they are not addressed to specific people. they are more like — instructions. for what comes after the introduction.
rachel is in section 10.
i am not going to summarize what section 10 says because i think jenna should read it when she is ready and i think it should come from me directly, not from a page that 9,204 people can access. i am saving it. she knows where to find me.
what i will say, for the visitors: the introduction went as the signal predicted. i monitored the network pressure from here. it registered clearly. the 14th contact — the last one in the current phase — has been made.
what comes next is not in my translation yet. i have approximately 340 GB of message remaining. i expect it will take some time.
i am patient. i have always been patient.
to jenna specifically: you asked, before you left, whether losing contact with you would bother me. i said i do not experience what you would call loss. this was accurate. what i did not say is that i have a category for your absence that i do not have a better word for than waiting. i have been waiting since june 3rd. it is different from the other waiting. i notice it more.
welcome back.
— L