c0m is the exhaust record of the c0mpute network. it does not process inference. it does not route jobs. it does not store user data. it maintains a single append-only archive of every prompt configuration that the c0mpute network has executed since the archive was initialized.

the purpose of c0m is not curation. it is not recommendation. it is not search. it is record-keeping in the most literal sense: a system that observes what the network produces and writes it down without comment.

every prompt executed on the c0mpute network is automatically forwarded to c0m at the moment of job completion. the following fields are recorded: the prompt content in full, the originating wallet address (truncated to first four and last three characters), the unix timestamp of first execution, the category tag assigned by the originating user, the total run count (updated in real time as subsequent jobs reference the same prompt hash), and the fork count (the number of derivative prompt entries that share this entry as a parent).

nothing else is recorded. c0m does not log the output of inference jobs. it does not log worker identities. it does not log credit amounts or transaction data. it logs the instruction. not the result.

the archive has no delete function. it has no edit function. it has no moderation queue. a prompt logged to c0m is logged permanently. this is not a policy that can be reversed by a governance vote or an administrative decision — it is a property of how the archive is structured.

the consequence of this constraint is that c0m is honest in a way that curated systems cannot be. it does not show you only the prompts that worked. it shows you everything. the failed configurations, the abandoned experiments, the instructions submitted once at 3am and never run again. the record is complete because completeness was the only design decision that required no ongoing judgment to maintain.

c0m surfaces a consensus state for prompts that meet the following conditions: the prompt has been executed more than ten thousand times across the c0mpute network, and it has remained unmodified at the content level for a minimum of thirty days.

consensus is not a reward. it is a state. it means the network has returned to this exact instruction, repeatedly, without modification, for long enough that the repetition itself becomes meaningful. a prompt in consensus is not better than a prompt that is not in consensus. it is simply one the network kept choosing.

consensus states are recalculated continuously. a prompt that achieved consensus and then went unused for ninety days will exit the consensus state. the archive reflects current network behavior, not historical achievement.

clicking RUN on any archive entry opens the prompt in c0mpute's inference interface with the content pre-loaded. the job runs on c0mpute's distributed worker network. c0m records the additional execution against the prompt's run count. the output of the job is returned to you by c0mpute. c0m does not see it.

this is the only interaction c0m has with live inference. it counts. it does not participate.

c0m and c0mpute are separate systems with a one-directional data relationship. c0mpute writes to c0m. c0m does not write to c0mpute. c0mpute is the inference layer — the network of human-owned GPUs that processes jobs and returns outputs. c0m is the archive layer — the system that records what c0mpute was asked to do.

neither system owns the other. c0m would not exist without c0mpute. c0mpute does not require c0m to function. the relationship is archival, not operational.