Services of the cliff station
ELECTRICFALCON LLC offers six service lines, all run from the Draper cliff station at 8 E Manilla Cir, Draper - 84020-5106, United States (US). Each line is a working routine with its own documents, its own cadence and its own definition of done. Clients usually begin with one and add others as the relationship deepens.
A patrol sheet bay is the permanent home for everything we know about one integrated environment. It holds the inventory of components, the checkpoints that must be verified on a schedule, the thresholds that define normal behaviour, and the names of the people responsible for each response. Each bay is written so that a new engineer can open it cold and understand the system within an hour.
The bay is not a static document. It is revised every time a sighting log reveals something the original sheets missed. Over a year a well kept bay becomes the most accurate description of the system anywhere in the organisation, often more accurate than the vendor documentation, because it records what the system actually does rather than what it was designed to do. Clients typically keep the bay open to their own staff between review rounds, and we encourage that access, since a bay nobody reads is a museum piece.
The work includes an initial inventory pass, a checkpoint design workshop with the client team, and a written handover at the end of each cycle. Bays are stored in the client repository wherever possible so that ownership stays clear.
Sighting logs record events while they are fresh. An entry states what was observed, when it was observed, which system it affects and what immediate action was taken. Entries are written in plain sentences, not codes, so that a manager can read a week of logs without asking an engineer to translate. The log is append-only, which means that corrections are added rather than applied by editing history.
A run is the routine that reviews the log. Depending on the cadence agreed with the client, a run may happen daily, weekly or at each deployment. The reviewer groups related entries, identifies patterns that a single event would hide, and decides whether the pattern calls for a banding window or a nest survey review. Every decision is written back into the log so that the reasoning is visible to anyone who follows.
Over time the logs become a history of the system that is genuinely usable. When a client asks why a particular interface behaves the way it does, the answer is usually in a log entry from the day the interface changed.
Watch notes are the shortest and most valuable documents we produce. A note explains one decision, one workaround or one open question in a couple of paragraphs, with enough context that the reader does not need to reconstruct the situation. Notes are filed against the patrol sheet bay they belong to and are reviewed at every cycle.
The desk is the routine that keeps notes flowing. Engineers are expected to write a note whenever they make a choice that future readers would find surprising. A note might explain why a particular vendor library was pinned to an older version, why a scheduled job runs at an unusual hour, or why an apparently redundant check exists. These are exactly the details that vanish when staff change, and they are exactly the details that cost the most to rediscover.
At the end of an engagement the note collection is usually the first thing a client team reads. It becomes the institutional memory of the system, and it is often cited as the reason a new engineer became productive quickly.
A banding window is a defined period during which a change is applied and watched closely. It is used for changes that are too large for continuous deployment and too risky for a quiet push. The window has a start time, a rollback condition and a named observer. Nothing enters the window without a written statement of what success looks like and what failure looks like.
During the window, the observing engineer stays on the log until the agreed signal has arrived, whether that is a number of successful transactions, a period of stable latency or a clean run of scheduled jobs. If the rollback condition triggers, the window ends and the reversal is executed without debate. The purpose of writing the condition in advance is precisely to remove the debate from a moment when it is least welcome.
After the window closes, a short record is appended to the sighting log describing the outcome and any follow-up work. Windows are scheduled in advance and published to the client so that their own teams can plan around them.
A nest survey looks outward. It examines the dependencies a system leans on, including cloud providers, third party services, libraries and internal teams that supply data or support. The survey asks a simple question on each dependency: if this changed suddenly, what would break, and how soon would we know?
The round produces a written assessment for each dependency with a classification, an owner and a monitoring suggestion. Dependencies that are well covered already are recorded as covered so that the survey does not generate unnecessary work. Dependencies that carry silent risk receive a specific recommendation, which may be a monitoring addition, a contractual question for the client or a piece of integration work.
We recommend a survey round at least twice a year for any system that handles sensitive records, and quarterly for systems whose vendor landscape changes quickly. A survey round usually takes two to three weeks including the written report and a review meeting with the client team.
A release sitting is a scheduled event, not a technical action. The system is released in the usual way, but the release is attended by a named witness from outside the engineering pair who built the change. The witness reads the checklist aloud, confirms each item, and signs the record. The sitting takes half an hour and is the point at which a change stops being the property of the engineer who made it.
The practice exists because releases are the moment when a hidden assumption is most expensive. A checklist that says the backup was verified an hour ago, the rollback path has been tested and the on-call engineer knows the change catches assumptions that would otherwise surface at the worst possible time. The witness is deliberately not the author, which makes it harder for the author to skip a step that seems obvious.
Each sitting produces a one page record with the names, times and outcome. These records are kept with the patrol sheet bay and form the spine of a release history that survives staff changes.
ELECTRICFALCON LLC opens its release window to teams that would like one written routine instead of six disconnected reports.
Process overview
Every engagement moves through four stages. The timeline is a guide rather than a promise, because a system that has never been documented takes longer to read than one that has.