Owner Control of Drawings, Software, Passwords, and Technical Records

Published control-system manuals are generic to the product and contain none of the wiring particulars of an individual instrument. Solid State Organ Systems says so plainly on its legacy-capture page: because the manuals are generic, you will not find individual wiring information for a specific instrument there, and it points the reader instead to the records it keeps of every installation. That is one supplier describing its own practice; it does not establish that other suppliers keep comparable records or would release them. The practical lesson runs the other way. A manual will tell a future technician how the product works, and only an instrument-specific record will tell them how this instrument was wired and configured.

The same applies to commissioning data. Peterson’s 2005 guide for bringing up a new ICS-4000 installation has the installer record Satellite Micro Board address-switch settings at each of six commissioning stages, together with the exact text of any error message, voltage measurements, and hub and data-cable configuration when a fault appears. That makes the physical addressing of a distributed control system a discrete data point in the installation record, separate from the firmware version and from any stored combinations. The guide does not say whether the church, as opposed to the installer, receives a copy, which is exactly why the owner should ask for one. The guide is dated 2005 and describes one product’s architecture; other systems may have no comparable step, and the current procedure would need to be reconfirmed with the manufacturer.

Documentation also outlives parts. As of September 1, 2026, Solid State Organ Systems, Syndyne, Peterson, and PipeOrganControl.com all still publish manuals for products they no longer sell, while none of the four publishes a parts list, stock position, or price for those products. Nor do the four use a common vocabulary for retirement: Syndyne labels a product category Legacy, Solid State Organ Systems groups products under Legacy Systems while claiming lifetime support for everything it has made, PipeOrganControl.com gives its superseded generations closed production date ranges, and Peterson applies no status label at all. Each of those is a company’s description of its own products. The absence of a retirement label is not evidence that a product is supported, and the presence of one is not evidence that it is not.

Drawings are documents the client approves, which is the strongest reason the client should end up holding them. The American Institute of Organbuilders’ Guidelines for Fine Organbuilding state at section 4.03 that detailed casework drawings should be submitted for the client’s approval before construction begins, and at section 5.02 that old pipework should be clearly described as such in the contract specifications. Those guidelines date from 1994, the Institute expressly does not warrant that its members follow them, and neither provision requires the documents to be handed over or retained after completion. An owner who wants the approved drawings and the contract specification in its own file therefore has to say so in the written agreement rather than rely on trade guidance to deliver them.

Whether a proposal names the documents it will deliver at closeout is one of the things worth holding competing proposals to; Comparing Pipe-Organ Bids and Service Proposals covers how to compare them on the same terms.

The organist or user credential covers operation: choosing memory levels, setting pistons, and the other things an organist does at the bench. On Syndyne’s MS8400 the organist side consists of up to 50 organist accounts, each protected by a four-digit numeric access code and each holding 100 memory levels. On Peterson’s ICS-4000 the organist works in a folder protected by a three-character password, and Peterson lists setting and editing pistons in an unlocked folder, selecting memory levels, creating crescendo patterns, recording and playing songs, and changing the folder’s own name and password as organist-level functions. Solid State Organ Systems says memory levels in its CFM capture system can be reached with a PIN code or through an Organist Palette, though whether a PIN is actually configured on a given instrument is an installation decision.

These codes are convenience locks between organists, not security controls; a three-character or four-digit code keeps one organist’s settings from being overwritten by another. That distinction matters when an owner asks what has been secured, because the organist credential protects registrations, not the instrument. Peterson also notes that an organist may find piston functions unavailable in a locked folder without anything being wrong, and Syndyne’s user manual is, in the company’s own words, intended to be left with the organist for training and reference.

The builder or installer credential is a separate tier that reaches configuration, and it is distinct from the organist or user credential in both function and custody. Syndyne’s MS8400 documentation describes a full-access Builder account alongside the organist accounts, with the builder assigning which menus each organist may see, and its builder manual documents a separate builder access mode on the console touchscreen. The user manual states that the System Configuration Menu is for advanced users and installers only, that the MIDI stops menu shows only what the builder has left unlocked, that the remote tuner is deactivated by default, and that test and diagnostic functions appear at the builder’s discretion. Syndyne’s own description of its audience split is explicit: the builder manual gives an organ builder what is needed to install and configure the system, and the user manual is meant to stay with the organist.

Peterson draws the same line across four product generations, from the Single Board Duo Set and the MIDI Resource System through the MSP-1000 to the ICS-4000: operation belongs to the organist and configuration to the organ builder or technician. On the current ICS-4000 a Supervisor Mode gated by a changeable four-character password covers creating organist folders, clearing memory, software updates, and satellite board status. A further Organ Builder’s Menu behind its own password covers locking the crescendo and tutti, calibrating the crescendo and expression shoes, system programming, and saving and restoring all combination-action data. Solid State Organ Systems states that the scope of pistons, meaning which stops each piston controls, is most often set by the organ technician at installation. Its MultiSystem Modular is configured through a built-in web server reached over a wireless network whose password is supplied on paper in the welcome pack, and the configuration route depends on a third-party domain remaining reachable; both are items an owner should record before the pack is lost.

Two consequences follow for an owner. First, a request to change how the instrument is configured, rather than how it is registered, falls on the builder side of the line whatever the owner’s wishes, and the manual for each system says so. Second, the builder-level credential ordinarily leaves with the installer, and none of the suppliers examined publishes who is entitled to hold it or how a replacement is obtained; Peterson goes only as far as saying it sells to professional organ builders and organ servicepersons. The manuals establish that these tiers exist, not what any particular owner is permitted to do with them, and no credential, current or legacy, should be tried on a live instrument by anyone other than its authorized custodian.

A system configuration backup is a stored copy of the control system’s settings, and on documented systems it is produced from the builder tier, not the organist tier. Syndyne’s MS8400 builder manual lists Backup All Cards, Backup Single Card, Restore All Cards, Restore Single Card, and Firmware Update as system functions, and its quick-start guide places backing up the system configuration as the final step of the builder’s twelve-step bring-up sequence. Peterson’s ICS-4000 places Save and Restore All Combination Action Data behind the Builder’s Password, and its commissioning guide treats satellite board address settings as a separate recorded item from the firmware version and from the combination data. A complete stored record of a system therefore has more than one part: the configuration, the firmware version, the hardware addressing where the architecture has it, and the registrations.

For the owner this defines the request rather than the procedure. The backup is made when the builder configures the system, and the moment it exists is the moment to ask for a copy, stored somewhere the owner controls. These functions are documented for the named current systems, an older system cannot be assumed to have an equivalent, and how any backup is made, stored, or restored on a particular instrument is the technician’s work, not the owner’s.

Holding the software is not the same as owning it, and at least one manufacturer’s published terms say so directly. Peterson’s Conditions of Sale, in the May 2004 revision it still links from its catalog index, state that the software and documentation supplied with Peterson products remain Peterson’s property under United States copyright law and international treaties, and that the buyer receives a single-product license to use the software in the specific device it was supplied for. On those terms the church owns the organ and holds a license to the software inside it; it does not own the software. A 2004 document cannot be assumed to state 2026 terms, and other vendors’ terms differ, so the current conditions should be obtained from the vendor of the system actually installed.

General church-compliance guidance points the same way. The Evangelical Council for Financial Accountability advises religious organizations that copyrighted software may not be copied without permission, including software the church itself owns, and recommends a policy against installing duplicate copies without administrator authorization; that guidance addresses copyright compliance generally and says nothing about organ control systems or about what happens when a vendor-held credential is lost. A further point comes from the United States Copyright Office, which explains that copyright is personal property that can be transferred in writing, pass by will, or pass by operation of law. A vendor’s dissolution therefore does not make its software ownerless; it raises the separate question of who now holds the rights. None of this is legal advice, and a question about a specific license belongs with counsel.

On the questions an owner most wants answered, the suppliers examined publish no policy at all. As of September 1, 2026, Peterson’s public documentation contained no written statement of who is entitled to receive ICS-4000 software files, passwords, configuration tools, or remote diagnostic assistance, on what terms, at what price, or for how long; the nearest statements are that updates are made available to organ builders and that Peterson sells only to professional organ builders and organ servicepersons. As of September 2, 2026, Syndyne’s support page published product documentation only, with no statement of who may obtain support and no firmware or software update policy. On the same date the PipeOrganControl.com home page published by Deahl & Associates named two support contacts and a parts store but said nothing about configuration backup or its update model. An absence on a public page is not evidence of an absence in the terms a vendor quotes to builders, and these pages change without notice.

The consequence is direct. Since no published policy tells an owner what it may have, the entitlement has to be created in the project documents: the written agreement should say which credentials, records, and backups the owner receives, which remain with the builder or vendor, and what vendor restriction, if any, limits the transfer. Where a vendor sells only to professional organ builders and servicepersons, a written answer about access has to come through an authorized channel rather than from the public site.

A software escrow agreement is the general commercial mechanism for continuity when a vendor disappears: the vendor deposits source code and related technical materials with a neutral third-party agent, who releases them to the customer only on a defined trigger such as bankruptcy, acquisition, or abandonment of support. That mechanism comes from commercial software generally; none of the organ control-system suppliers named on this page publicly describes offering or participating in one, so an owner should treat escrow as a question to ask rather than a service to expect.

What the trade does publish is documentation. Opus-Two, for example, states that its Z-tronics relay systems are supplied with full documentation, complete schematics, and service information, and it maintains a schematic and datasheet archive on the Z-tronics site without stating any eligibility condition, price, or term for obtaining it. Publishing an archive establishes neither its completeness nor an owner’s entitlement to its contents, and Opus-Two’s own domain could not be reached on September 1, 2026, leaving that archive reachable only through the second site. The durable position for an owner is the same in every case: hold the instrument-specific records yourself, because vendor sites, archives, and support pages all change without notice.

Ask for each record at the point in a project where it is created, because that is when it is easiest to obtain. Approved casework drawings and the contract specification exist before construction starts. The commissioning record and the system configuration backup exist at the end of bring-up, when the builder makes the backup as the last step of configuration. The organist or user credential, and the welcome pack with any wireless credential, exist at handover. Ask at the same time which credential tier each item belongs to, who holds the builder or installer credential once the installer leaves, and what vendor restriction, if any, prevents its transfer. Record the answer in writing even when the answer is that the builder retains it, because a documented limitation is something a successor can act on.

The owner’s part of this is administrative, not technical. Owner-side preparation never involves entering the instrument, opening the console, or trying a credential on a live system; if a legacy credential is in question, it stays untested until the authorized custodian handles it. Keep these records where the institution, rather than one individual, can find them, since a credential delivered on paper is easily lost and the access boundary is a records problem for the institution before it is anything else. Keep the dated record of work itself in the instrument service history, which is a separate file with its own rules. Who signs the request and accepts the deliverables is a governance question owned by Organ-Committee Authority and Approval of Technical Work, and what happens to the access boundary when the current provider retires is covered in What to Do When the Existing Technician Retires.

Craftsman Pipe Organs follows the same division on its own work. Restricted provider, builder, or installer credentials remain with the person or company to which they were issued, and owners receive the project-specific credentials, documentation, configuration records, backups, and access rights they are entitled to receive and that are reasonably necessary for operation and future service, subject to disclosed vendor restrictions, with known access limitations disclosed before acceptance. Which closeout documents are delivered on a given project is defined by the written scope, and records reconstruction or custom documentation is billable unless the accepted written proposal or agreement includes it. That description of what Craftsman documents and hands over carries no claim of manufacturer authorization, builder credential, or professional certification.

The Organ Historical Society’s Pipe Organ Database does not hold any of this and cannot substitute for it. It is a publicly editable historical identification and cataloguing resource maintained by an outside organization, describing builders, opus numbers, stoplists, photographs, installation history, and alterations; wiring diagrams, control-system software and configuration files, access credentials, and service history are not among its holdings. An entry there is useful for identification, but the technical record of the instrument exists only where the owner keeps it. When a condition survey is being arranged, the same owner-held records are what needs assembling first; How to Prepare for a Condition Survey lists what to bring together, and the Owner Planning hub routes the other decisions around it.