Skip to content

Architecture

What It Leaves Behind: telling a Run from a Procedure

Two acts at the beamline can look identical from across the hutch. In the first, the sample rotates through a full turn while the camera fires hundreds of times. In the second, the sample rotates through a full turn while the camera fires hundreds of times. Same stage, same motion, same detector, same operator. Yet one of them is a tomography scan, and the other is a center-of-rotation alignment, and CORA records them as two different kinds of thing: the first as a Run, the second as a Procedure. If the motion does not tell them apart, what does?

What Actually Happened: a run is the record of reality, deviations and all

A tomography scan is fifteen hundred projections long, and it is seven hundred frames in when the storage ring dumps its beam. Another night, an overnight scan still reads "Running" the next morning, hours after a power cut, a dropped network link, and a dead laptop quietly killed it; the operator finds the corpse at the start of shift. A plan describes what was supposed to happen. A Run is the harder, more honest thing next to it: the record of what actually did, including the pause for the beam dump, the exposure that got nudged mid-scan, and the gap between the experiment as imagined and the experiment as it ran.

Undo Is a Lie: how you take something back on a log that cannot forget

You published a reconstruction at the end of a beamtime, marked it production-grade, and handed the dataset on to whoever needed it. A week later you realize it should never have carried that grade: the run behind it was off, or a calibration it leaned on was wrong. On almost any system, the reflex is obvious. Delete it. Roll it back. Press undo. But CORA is built on a log that physically cannot delete anything, where the database role the application runs as is granted exactly two rights on the event table, read and append, and is refused update, delete, and truncate at the boundary. So the undo button is not disabled. It does not exist. The question becomes interesting: what do you press instead?

What "Calibrated" Means: a dated fact, not a number you overwrite

"Calibrated" sounds like a settled property of an instrument, the way "two meters long" is settled. In daily practice it is something much softer: a number in a spreadsheet, or a field in a config, that someone measured once and that gets overwritten the next time the instrument is calibrated. The current value is easy to find. Everything around it is not. What was the center of rotation last March, when this dataset was taken? Who measured it, and was it a careful measurement or a quick estimate typed in to get a shift moving? Once the number has been overwritten, those questions have no answer, and the data that depended on the old value is quietly orphaned from the value it actually used.

The Metadata Problem, From the Other End: record the work, and let the labels be a read

Every facility runs on metadata, the labels and fields attached to data so that it can be found, understood, and reused after the people who took it have moved on. And almost everywhere, metadata disappoints. It is incomplete, because the field you need now is the one nobody thought to capture then. It is inconsistent, because two people labeled the same thing two ways. It is retrofitted, filled in long after the moment it was meant to describe, from memory. None of this is a failure of diligence. It is built into how metadata is usually produced, and the cause is worth naming plainly. At the moment of acquisition you are asked to anticipate every question a future reader might ask and stamp a label for each. You cannot, so there is always a missing field, and a missing field is usually gone for good. That is the metadata problem.

Derive, Don't Stamp: what a ledger lets you stop storing

Ask an ordinary system a simple question, is this detector active, and it usually answers by reading a column. Somewhere a row has a status field, and at some earlier moment a piece of code ran an update to set it. The answer is trustworthy exactly to the degree that every code path which should have set that column actually did. CORA answers the same question a different way: it has no status column to read. It looks at what happened to the detector and lets the most recent fact speak for itself. This is a small inversion with large consequences, and it is the quiet habit that an append-only log makes possible: derive the answer from the record of facts, rather than stamping the answer into a field of its own.

Write Once, Run at Another Beamline: content-addressing for portable experiments

Here is a promise the recipe ladder made, and a question it left open. A Method, the portable rung of the ladder, is meant to describe a technique without naming any one facility's hardware, so that in principle a tomography technique perfected at one beamline could run at another. The question is what "in principle" is hiding. Hand a recipe from one facility to another and it will only run if both places agree on what its words mean: that "Hexapod" refers to the same kind of device, that "the microscope" refers to the same cluster of parts, that a "Positioner" is the same contract. And they have to agree without calling anyone, because in a federation of independent facilities there is no central authority to call. This is the same problem Git solved for source code, and CORA borrows the same answer.

What a Beamline Is Made Of: kinds, instances, and an inventory that stays honest

A photograph of a beamline looks like a fixed instrument. The reality is a population in slow motion. A detector is swapped for a better one. A stage is sent out for repair and a loaner takes its place. A mirror is recoated, a lens is recalibrated, a whole microscope is rebuilt around a new camera. Over a few years almost every part may change while everyone keeps calling it the same beamline. That is the old puzzle of the ship whose planks are replaced one by one: what makes it still the same thing? A system that means to record what a beamline did, for years, has to answer that puzzle first, because it cannot describe the work until it can faithfully name the equipment the work ran on.

The Right to Be Forgotten: erasing a person from a log that cannot be edited

An earlier post argued that CORA can be trusted for one reason above all: it was built never to overwrite anything. Every change of state is an immutable event, appended to a log the application is not even permitted to edit. That is the whole point. So here is the uncomfortable question it raises. A person has a legal right to ask that their personal data be erased, named in European law as the right to erasure, or the right to be forgotten, in Article 17 of the GDPR. How does a system whose defining property is that it cannot forget honor a request to forget someone?

The Recipe Ladder: from a portable technique to what actually happens at the beamline

Michael Polanyi observed that "we know more than we can tell." At a beamline this is not a philosophical aside but the daily operating reality. An operator carries years of practice that never fits in the written standard operating procedure, and software that models only the written procedure tends to fail the moment it meets the realities of daily operation. CORA's response is a structure we call the recipe ladder: four steps that give this tacit, unwritten knowledge somewhere to live, so that a technique described once can run at more than one facility, and a single experiment can record precisely where reality departed from the plan.