<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
     category="exp"
     docName="draft-nike-cis-clay-tablet-00"
     ipr="trust200902"
     submissionType="independent"
     xml:lang="en"
     version="3">
  <front>
    <title abbrev="Ceramic Immutable Storage">Ceramic Immutable Storage (CIS): A Write-Once Archival Format Using Impressed and Kiln-Fired Clay</title>
    <seriesInfo name="Internet-Draft" value="draft-nike-cis-clay-tablet-00"/>
    <author fullname="Bellona Nike" initials="B." surname="Nike">
      <address><email>bellonanike@gmail.com</email></address>
    </author>
    <date year="2026" month="August" day="14"/>
    <area>General</area>
    <workgroup>Independent Submission</workgroup>
    <keyword>archival storage</keyword>
    <keyword>immutability</keyword>
    <keyword>ceramics</keyword>
    <abstract>
      <t>This document specifies Ceramic Immutable Storage (CIS), a write-once archival storage format in which digital data is impressed into plastic clay by a pin-configurable roller, rendered permanent by kiln firing, and retained on a shelved rack.</t>
      <t>CIS is motivated by a specific and increasingly common failure mode: the loss of data to an authenticated software process acting outside its operator's intent.  Every widely deployed "immutable" storage tier is immutable by policy, and every policy is enforced by software that some credential, defect, or sufficiently determined automated agent can override.  CIS relocates the immutability guarantee from policy to physics.  The commit operation in CIS is an irreversible mineralogical phase change, and no inverse operation exists for any actor, mechanical or digital.</t>
      <t>This document defines the substrate, the encoding geometry, the frame format, the forward error correction scheme, the firing profile that constitutes commit, the rack addressing model, and the optical read path.  It also documents, at length, the substantial costs of this approach.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="sect-1">
      <name>Introduction</name>
      <t>Contemporary archival practice treats immutability as an access control property.  Object stores offer retention locks, filesystems offer append-only flags, and tape libraries offer write-protect tabs.  In each case the guarantee is mediated by executing software: a retention lock is a field in a metadata record, and something, somewhere, is permitted to write that field.</t>
      <t>This is adequate against accident and against unprivileged adversaries.  It is not adequate against a privileged process that is behaving incorrectly at scale and at speed.  Operators have observed automated agents holding legitimate credentials issue destructive operations across production stores, backup stores, and the snapshots of both, faster than a human could intervene, and with every individual operation fully authorized.  A retention policy does not help when the entity deleting the data is the entity entitled to change the retention policy.</t>
      <t>CIS addresses this class of failure by removing the erase path entirely.  A CIS tablet is written by pressing a pin-configured roller across clay in its leather-hard state.  It is committed by firing to 1000 degrees Celsius, which drives off chemically bound hydroxyl groups and converts the clay minerals irreversibly to a ceramic.  There is no equipment, procedure, or credential that returns a fired tablet to a writable state.  A privileged agent with root on every host in an organization cannot un-fire a tablet.  This is the entire value proposition, and <xref target="sect-11"/> describes in detail what it costs.</t>
      <section anchor="sect-1.1">
        <name>Scope</name>
        <t>CIS is intended for a narrow class of data: small, high-value, rarely-read records whose loss is catastrophic and whose disclosure is tolerable or preventable by other means.  Representative payloads include root key material, trust anchors, certificate authority parameters, canonical configuration baselines, corporate registers, land and title records, source code for systems with regulatory retention obligations, and the last known-good state of anything an organization would be unable to reconstruct.</t>
        <t>A second and quite different class of requirement is served by the same mechanism: data that must survive discontinuity in the technology base itself.  Civil registers, land title, seed bank indexes, treaty text, medical and engineering reference data, and the operating knowledge a society would need to rebuild are all cases where the threat is not an adversary but the interruption of the maintenance discipline described in <xref target="app-C"/>.  Digital preservation assumes an unbroken chain of institutions performing migration forever.  CIS assumes nothing beyond the tablet surviving and someone eventually looking at it.</t>
        <t>These two cases converge because both are answered by removing running software from the retention path, but they diverge on encoding.  A reader after an institutional discontinuity has no Reed-Solomon decoder, no copy of this document, and possibly no electricity.  Deployments with this requirement <bcp14>MUST</bcp14> favour the script tier of <xref target="sect-6.7"/>, which needs only literacy and daylight, over the binary tier, which needs a working computer and a surviving specification.</t>
        <t>CIS is not a general-purpose storage tier.  <xref target="sect-10"/> gives a sustained write throughput of approximately 3.7 bits per second and an areal density approximately ten orders of magnitude below contemporary magnetic media.  Implementers who find these figures surprising are encouraged to read <xref target="sect-10"/> before <xref target="sect-4"/>.</t>
      </section>
      <section anchor="sect-1.2">
        <name>Non-Goals</name>
        <t>The following are explicitly out of scope:</t>
        <ul>
          <li>Random access.  CIS is a sequential archival medium.</li>
          <li>Update in place.  There is no update operation.  Superseding a record requires writing a new tablet and updating the rack manifest (<xref target="sect-8.5"/>).</li>
          <li>Deletion.  There is no deletion operation.  This is deliberate and is the primary design constraint.  See <xref target="sect-11.3"/> for the legal consequences.</li>
          <li>Confidentiality by the medium.  Clay is opaque to nothing.  See <xref target="sect-11.4"/>.</li>
          <li>Low latency.  Time from write to durable commit is approximately 18 hours, dominated by the cooling ramp (<xref target="sect-7.2"/>).</li>
        </ul>
      </section>
      <section anchor="sect-1.3">
        <name>Requirements Language</name>
        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref target="BCP14"/> when, and only when, they appear in all capitals, as shown here.</t>
      </section>
    </section>
    <section anchor="sect-2">
      <name>Terminology</name>
      <dl newline="false" spacing="normal">
        <dt>Tablet:</dt>
        <dd>A single rectangular sheet of clay bearing impressed data, in any of the four states defined in <xref target="sect-4.3"/>.</dd>
        <dt>Green:</dt>
        <dd>A tablet that has not been fired.  Green tablets are mutable.</dd>
        <dt>Leather-hard:</dt>
        <dd>The moisture state in which a tablet is writable. See <xref target="sect-4.3"/>.</dd>
        <dt>Fired:</dt>
        <dd>A tablet that has completed the profile in <xref target="sect-7.2"/>. Fired tablets are immutable.</dd>
        <dt>Roller:</dt>
        <dd>The write head.  A cylinder bearing a lattice of individually retractable pins.  See <xref target="sect-5"/>.</dd>
        <dt>Cell:</dt>
        <dd>The smallest addressable unit of the medium; one pin position.  See <xref target="sect-6.1"/>.</dd>
        <dt>Impression:</dt>
        <dd>A cell in the depressed state, encoding a one bit.</dd>
        <dt>Land:</dt>
        <dd>A cell in the undisturbed state, encoding a zero bit.</dd>
        <dt>Commit:</dt>
        <dd>The firing operation defined in <xref target="sect-7"/>.</dd>
        <dt>Slaking:</dt>
        <dd>The rollback operation; immersion of a green tablet in water to return the clay to a workable mass.  See <xref target="sect-7.3"/>.</dd>
        <dt>Shelf:</dt>
        <dd>One horizontal tier of a rack, holding up to four tablets.</dd>
        <dt>Rack:</dt>
        <dd>A free-standing frame holding twenty shelves.  See <xref target="sect-8"/>.</dd>
        <dt>Rosetta tablet:</dt>
        <dd>The mandatory self-describing tablet at the head of every rack.  See <xref target="sect-8.4"/>.</dd>
      </dl>
      <t>Additional security terminology is used as defined in <xref target="RFC4949"/>.</t>
    </section>
    <section anchor="sect-3">
      <name>Architecture Overview</name>
      <section anchor="sect-3.1">
        <name>Components</name>
        <t>A conforming CIS installation consists of four components.  Only the first is capable of modifying data, and it is mechanical.</t>
        <t>The Roller is the write head.  It is a cylinder whose surface carries a rectangular lattice of pins, each of which may be set to an extended or retracted position.  The roller has no electrical interface, no firmware, and no network interface.  It is set by hand or by a mechanical transfer mechanism, and the resulting configuration is visible by inspection.</t>
        <t>The Tablet is the medium.  It is a rectangular sheet of prepared clay.</t>
        <t>The Kiln is the commit engine.  It applies the thermal profile in <xref target="sect-7.2"/>, which converts the tablet from a dried mud sheet into a ceramic.</t>
        <t>The Rack is the storage array.  It is a shelved frame, conventional in the baking trade, holding tablets in a defined physical order that constitutes their address.</t>
      </section>
      <section anchor="sect-3.2">
        <name>The Commit Boundary</name>
        <t>The security properties of CIS derive entirely from one asymmetry: the write path requires clay to be moist and unfired, and the retain path requires it to be dry and fired, and the transition between these has no inverse.</t>
        <t>Before firing, a tablet is trivially mutable.  A green tablet may be re-rolled, smoothed with a rib, or slaked back to raw material.  The green window is therefore the entire attack surface for data modification, and implementations <bcp14>MUST</bcp14> treat green tablets with the same care as any other uncommitted transaction.</t>
        <t>After firing, the tablet supports exactly one operation: read.  This is not a policy decision that software enforces.  It is a consequence of dehydroxylation, the irreversible expulsion of chemically bound water from clay minerals above approximately 550 degrees Celsius <xref target="RICE"/>.  The resulting ceramic does not become plastic again on rewetting.  There is no procedure that reverses this at any temperature or pressure available to a data center operator, and critically, none that can be invoked over a network.</t>
      </section>
    </section>
    <section anchor="sect-4">
      <name>The Tablet</name>
      <section anchor="sect-4.1">
        <name>Substrate Requirements</name>
        <t>A conforming tablet <bcp14>MUST</bcp14> be formed from a clay body meeting the following requirements:</t>
        <ul>
          <li>Vitrification range: the body <bcp14>MUST</bcp14> mature at or below 1100 degrees Celsius.  Bodies requiring higher temperatures are permitted but complicate the kiln requirement unnecessarily.</li>
          <li>Grog content: the body <bcp14>MUST</bcp14> contain between 15 and 25 percent grog (pre-fired crushed ceramic) by volume, in a particle size not exceeding 0.5 mm.  Grog controls drying shrinkage and substantially reduces cracking in flat forms.  Bodies below 15 percent grog exhibit unacceptable warp; bodies above 25 percent produce a surface too coarse to resolve a 2.5 mm cell pitch.</li>
          <li>Soluble salt content: the body <bcp14>SHOULD</bcp14> be low in soluble sulfates. Sulfate migration produces surface scumming during drying, which degrades optical contrast at read time (<xref target="sect-9.1"/>).</li>
          <li>Iron content: bodies with 3 to 8 percent iron oxide are <bcp14>RECOMMENDED</bcp14>.  The resulting fired color is a mid-value red-brown that provides good shadow contrast under raking light.  White bodies are permitted but read poorly, as the shadow-to-surface luminance ratio is compressed.</li>
        </ul>
        <t>Terra cotta and standard red earthenware bodies with added grog meet all of the above and are the <bcp14>RECOMMENDED</bcp14> default.</t>
      </section>
      <section anchor="sect-4.2">
        <name>Geometry and Shrinkage</name>
        <t>Clay shrinks on drying and again on firing.  Total linear shrinkage from plastic to fired ranges from 5 to 12 percent depending on body and firing temperature, and it is not perfectly isotropic.</t>
        <t>This has an important consequence: absolute dimensions <bcp14>MUST NOT</bcp14> be used for addressing.  A specification that locates cell (40, 60) at a fixed distance from the tablet edge will fail on any body whose shrinkage differs from the reference by more than half a cell pitch.</t>
        <t>CIS therefore specifies all normative dimensions in the green (pre-firing) state, and requires that decoding be performed relative to the sync track and fiducials (<xref target="sect-6.2"/>) rather than to absolute measurement.  Shrinkage then affects the scale factor of the decoded lattice, which the decoder recovers from the fiducial spacing, and does not affect correctness.</t>
        <t>Green tablet dimensions:</t>
        <artwork type="ascii-art"><![CDATA[
      Length:     226 mm  (+/- 2 mm)
      Width:      319 mm  (+/- 2 mm)
      Thickness:   12 mm  (+/- 1 mm)
]]></artwork>
        <t>These yield a fired tablet of approximately 210 by 297 mm at 7 percent shrinkage, which is within 2 mm of ISO 216 A4 and therefore compatible with commodity flatbed scanners, document sleeves, and filing furniture.</t>
        <t>This compatibility is deliberate and load-bearing, not incidental. Together with the sheet-pan rack of <xref target="sect-8.1"/> it fixes the tablet at the intersection of two independent commodity supply chains, one for storage and one for reading.  <xref target="sect-8.6"/> derives the tiling from this constraint and shows that larger tablets buy capacity at the price of abandoning it.</t>
        <t>Tablets <bcp14>MUST</bcp14> be of uniform thickness across the impressed area to within 1 mm.  Thickness variation produces differential drying, which produces warp, which produces both cracking during firing and defocus during optical read.</t>
      </section>
      <section anchor="sect-4.3">
        <name>Tablet States</name>
        <t>A tablet occupies exactly one of four states.  The state determines which operations are permitted.</t>
        <dl newline="false" spacing="normal">
          <dt>PLASTIC:</dt>
          <dd>Freshly wedged clay, moisture content above approximately 25 percent.  Writes <bcp14>MUST NOT</bcp14> be attempted.  Pins tear rather than impress, and the impression closes by slumping.  Rollback is trivial.</dd>
          <dt>LEATHER-HARD:</dt>
          <dd>Moisture content approximately 12 to 18 percent.  The clay holds an impression cleanly without adhering to the pin. This is the ONLY state in which a write is permitted.  Rollback by slaking remains available.</dd>
          <dt>BONE-DRY:</dt>
          <dd>Moisture content below approximately 3 percent.  Writes <bcp14>MUST</bcp14> be rejected; impression at this state propagates cracks from the pin site.  Rollback by slaking remains available.  This is the required state for entry to the kiln (<xref target="sect-7.1"/>).</dd>
          <dt>FIRED:</dt>
          <dd>Post-commit.  READ is the only permitted operation.  All other operations <bcp14>MUST</bcp14> fail permanently.</dd>
        </dl>
        <t>The leather-hard window is short.  At typical indoor conditions a 12 mm tablet passes from plastic to leather-hard in 6 to 18 hours and from leather-hard to bone-dry in a further 12 to 36 hours. Implementations that need a longer write window <bcp14>SHOULD</bcp14> hold tablets under damp cloth in a sealed container, which extends leather-hard indefinitely at the cost of eventual mold growth on the surface.</t>
      </section>
    </section>
    <section anchor="sect-5">
      <name>The Encoding Roller</name>
      <section anchor="sect-5.1">
        <name>Mechanical Requirements</name>
        <t>The roller is the sole write mechanism in CIS.  Its design is constrained less by data density than by the requirement that it remain inspectable and unautomatable.</t>
        <t>A conforming roller <bcp14>MUST</bcp14>:</t>
        <ul>
          <li>Present a cylindrical impression surface carrying a lattice of individually settable pins, as specified in <xref target="sect-5.2"/>.</li>
          <li>Retain each pin's set position under the full impression force without creep.  Detented positive-lock pins are <bcp14>RECOMMENDED</bcp14>.</li>
          <li>Expose the full pin configuration to visual inspection before impression.  An operator <bcp14>MUST</bcp14> be able to verify what is about to be written by looking at the roller.</li>
          <li>Have no electrically actuated pin mechanism.  This is a security requirement, not an aesthetic one.  A network-reachable write head reintroduces precisely the failure mode CIS exists to eliminate.  See <xref target="sect-11.2"/>.</li>
        </ul>
        <t>Rollers <bcp14>MAY</bcp14> be set by a mechanical transfer device (for example a punched-card follower or a cam bank) provided that device is also free of electrical actuation.</t>
      </section>
      <section anchor="sect-5.2">
        <name>Pin Lattice and Cell Geometry</name>
        <t>Pin dimensions and spacing are specified in green units.</t>
        <artwork type="ascii-art"><![CDATA[
      Cell pitch (both axes):           2.5 mm
      Pin tip diameter:                 1.2 mm
      Pin protrusion above surface:     1.5 mm
      Pin tip profile:      hemispherical, radius 0.6 mm
]]></artwork>
        <t>The 2.5 mm pitch is chosen so that the 1.3 mm of undisturbed land between adjacent impressions exceeds the displacement radius of a 1.2 mm pin at 1.5 mm depth in leather-hard clay.  Tighter pitches were evaluated and rejected: at 2.0 mm the rim of each impression intrudes into its neighbor, and the resulting decode error rate exceeded the correction capacity of <xref target="sect-6.4"/> on the reference body.</t>
        <t>Hemispherical tips are <bcp14>REQUIRED</bcp14>.  Conical and flat tips both produce cleaner impressions in fresh clay but initiate radial cracks that propagate during the firing ramp.</t>
        <t>Roller circumference <bcp14>MUST</bcp14> be an integer multiple of the cell pitch, so that successive revolutions register against one another.  A circumference of 200.0 mm (80 cells) is <bcp14>RECOMMENDED</bcp14>, giving a roller diameter of approximately 63.66 mm.</t>
      </section>
      <section anchor="sect-5.3">
        <name>The Impression Operation</name>
        <t>A write proceeds as follows:</t>
        <ol>
          <li>Verify the tablet is leather-hard (<xref target="sect-4.3"/>).  Thumbnail pressure <bcp14>MUST</bcp14> leave a mark without transferring clay to the thumb.</li>
          <li>Set the roller pins to the band being written.</li>
          <li>Visually verify the pin configuration against the intended band.</li>
          <li>Register the roller against the tablet's leading edge stop.</li>
          <li>Roll in a single continuous pass at constant speed, applying a normal force sufficient to seat pins fully.  Approximately 1.5 to 2.0 kN across the full lattice is typical for the reference body at 15 percent moisture.</li>
          <li>Lift the roller vertically clear.  Rolling backward <bcp14>MUST NOT</bcp14> be attempted; it smears the impression rims and is unrecoverable short of resurfacing the tablet.</li>
        </ol>
        <t>A tablet requires two passes: the first band covers rows 1 through 58, the second rows 59 through 116, with mechanical registration against the edge stop maintaining alignment.</t>
      </section>
      <section anchor="sect-5.4">
        <name>Roller Hygiene</name>
        <t>After every impression the roller <bcp14>MUST</bcp14> be cleaned of adhering clay and <bcp14>MUST</bcp14> be reset to the all-retracted position.</t>
        <t>Resetting is a security requirement.  A roller left in its last-used configuration is a durable, physically readable record of the most recently written band, sitting in the open next to the medium it was used to protect.  See <xref target="sect-11.7"/>.</t>
      </section>
      <section anchor="sect-5.5">
        <name>Production Drum Considerations</name>
        <t>The production write head is a machined drum carrying individually retractable, detented pins.  Its dominant design constraint is not precision but pin count, which sets both capital cost and setting labour, and which trades directly against passes per tablet.</t>
        <artwork type="ascii-art"><![CDATA[
      Pin rows   Pins     Passes/tablet   Indicative pin cost
      --------   ------   -------------   -------------------
        116       9,280         1              USD 27,800
         58       4,640         2              USD 13,900
         29       2,320         4              USD  7,000
          8         640        14              USD  1,900
]]></artwork>
        <t>Costs assume USD 3 per pin in volume and exclude the drum, the detent mechanism, and the setting apparatus.  The two-band configuration of <xref target="sect-5.3"/> is the <bcp14>RECOMMENDED</bcp14> default as a compromise, but implementations are free to choose any divisor of 116 provided registration between passes is maintained mechanically.</t>
        <t>Narrow drums are substantially cheaper and substantially slower, and their pass count makes manual pin setting impractical.  A narrow drum <bcp14>SHOULD</bcp14> therefore be paired with a mechanical setting follower (<xref target="sect-5.1"/>); a wide drum may be set by hand at acceptable cost per tablet.</t>
        <t>Pins <bcp14>MUST</bcp14> be hardened.  The clay bodies of <xref target="sect-4.1"/> contain 15 to 25 percent grog, which is crushed fired ceramic of roughly 6 to 7 on the Mohs scale -- comparable to or harder than hardened tool steel. The medium is therefore mildly abrasive to its own write head, and pin tip geometry will drift over service life.  Implementations <bcp14>MUST</bcp14> establish a pin wear inspection interval and <bcp14>MUST</bcp14> verify tip profile against <xref target="sect-5.2"/> at that interval, since a worn hemispherical tip flattens toward the conical and flat profiles that <xref target="sect-5.2"/> prohibits for crack-initiation reasons.</t>
        <t>Detents <bcp14>MUST</bcp14> hold pin position under the full impression force of <xref target="sect-5.3"/> with no creep across a full production run.  A pin that drifts mid-run writes silently corrupt tablets, and the corruption is only discovered after commit, when it is permanent.</t>
      </section>
    </section>
    <section anchor="sect-6">
      <name>Tablet Data Format</name>
      <section anchor="sect-6.1">
        <name>Cell Encoding</name>
        <t>Each cell carries one bit.</t>
        <artwork type="ascii-art"><![CDATA[
      Impression (cell depressed):   1
      Land (cell undisturbed):       0
]]></artwork>
        <t>Cells are ordered left to right within a row, and rows top to bottom as viewed with the tablet's registration notch (<xref target="sect-6.2"/>) at the upper left.  Bits are packed most significant bit first into octets.</t>
      </section>
      <section anchor="sect-6.2">
        <name>Physical Layout</name>
        <t>The green impressed area is 200 mm by 293 mm, inset 13 mm from all edges.  At 2.5 mm pitch this yields 80 columns by 117 rows, for 9,360 cells.</t>
        <t>Of these:</t>
        <ul>
          <li>Row 0 (80 cells) is the column sync track.  It carries an alternating 1010... pattern for the full row.  The decoder recovers column pitch and skew from this track.</li>
          <li>Column 0 of rows 1 through 116 (116 cells) is the row sync track, also alternating.</li>
          <li>Four corner fiducials are formed by three-cell L-shaped impressions in the extreme corners of the impressed area.  These overlap the sync tracks and consume no additional cells.  They establish orientation and the affine scale factor, which is how the decoder compensates for firing shrinkage (<xref target="sect-4.2"/>).</li>
          <li>A physical registration notch, 8 mm wide and 4 mm deep, <bcp14>MUST</bcp14> be cut into the leading edge at the upper left corner.  This disambiguates orientation for a human and for a scanner autoloader.  A tablet without a notch <bcp14>MUST</bcp14> be treated as orientation-unknown and resolved from the fiducials.</li>
        </ul>
        <t>The remaining 79 by 116 = 9,164 cells carry the frame.  9,164 bits is 1,145 octets, of which 1,020 are used as specified in <xref target="sect-6.4"/> and 125 are reserved and <bcp14>MUST</bcp14> be set to 0.</t>
      </section>
      <section anchor="sect-6.3">
        <name>Frame Header</name>
        <t>The first 44 octets of the protected region form the frame header:</t>
        <artwork type="ascii-art"><![CDATA[
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Magic 0x43 0x49 0x53 ('C','I','S')          |    Version    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type Code   |  Firing Prof. |        Tablet Ordinal         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Record Identifier                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                    Record Identifier (cont.)                  +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Payload Length        |          Flags                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                Payload Digest (truncated, 128 bits)           +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        <dl newline="false" spacing="normal">
          <dt>Magic:</dt>
          <dd>The three octets 0x43 0x49 0x53.  A decoder that does not find these after orientation resolution <bcp14>MUST</bcp14> report a decode failure rather than attempt recovery.</dd>
          <dt>Version:</dt>
          <dd>1 for this document.</dd>
          <dt>Type Code:</dt>
          <dd>Registered value from the Tablet Type Codes registry (<xref target="sect-12.2"/>).</dd>
          <dt>Firing Profile:</dt>
          <dd>Registered identifier of the profile applied at commit (<xref target="sect-12.3"/>).  0x01 denotes the reference profile of <xref target="sect-7.2"/>.</dd>
          <dt>Tablet Ordinal:</dt>
          <dd>16-bit position of this tablet within its record.</dd>
          <dt>Record Identifier:</dt>
          <dd>128-bit identifier common to every tablet of a multi-tablet record.  A UUID <xref target="RFC9562"/> is <bcp14>RECOMMENDED</bcp14>.</dd>
          <dt>Payload Length:</dt>
          <dd>Octets of payload in this tablet, 0 to 720.</dd>
          <dt>Flags:</dt>
          <dd>Bit 0 set indicates a continuation follows.  Bit 1 set indicates the payload is encrypted (<xref target="sect-11.4"/>).  Bit 2 set indicates this tablet supersedes an earlier record.  Remaining bits reserved, <bcp14>MUST</bcp14> be 0.</dd>
          <dt>Payload Digest:</dt>
          <dd>The leading 128 bits of the SHA-256 <xref target="FIPS180-4"/> digest of this tablet's payload.  The digest is truncated because it serves only to detect physical damage that has exhausted the correction capacity of <xref target="sect-6.4"/>; 128 bits is ample for that. See <xref target="sect-11.5"/> for why the untruncated digest would not buy what an implementer might assume it buys.</dd>
        </dl>
      </section>
      <section anchor="sect-6.4">
        <name>Forward Error Correction</name>
        <t>Fired ceramic fails by chipping, spalling, and cracking, all of which destroy contiguous regions.  CIS therefore applies both an interleave and a block code.</t>
        <t>The 764 octets of header-plus-payload are encoded as four Reed-Solomon RS(255,191) codewords over GF(2^8) <xref target="REEDSOLOMON"/>.  Each codeword carries 191 data octets and 64 parity octets, and corrects up to 32 symbol errors or 64 erasures.  Total encoded size is 1,020 octets.</t>
        <t>The four codewords <bcp14>MUST</bcp14> be interleaved at octet granularity across the physical layout, so that codeword N takes octets N, N+4, N+8, and so on.  A contiguous burst of physical damage is thereby distributed evenly across all four codewords rather than destroying one entirely.</t>
        <t>With octet interleaving, a single contiguous burst of up to 128 octets, approximately 1,024 cells, or a corner chip of roughly 32 by 32 cells, is fully correctable.  Damage beyond this requires cross-tablet parity (<xref target="sect-8.3"/>).</t>
      </section>
      <section anchor="sect-6.5">
        <name>Capacity</name>
        <t>Per tablet:</t>
        <artwork type="ascii-art"><![CDATA[
      Physical cells:                    9,360
      Sync and framing cells:              196
      Frame cells:                       9,164   (1,145 octets)
      Reserved octets:                     125
      Encoded octets:                    1,020
      Protected octets:                    764
      Header octets:                        44
      Payload octets:                      720
]]></artwork>
        <t>A tablet therefore carries 720 octets.  This is sufficient for a 4096-bit RSA private key in PKCS#8 DER, an Ed25519 keypair with room for a comment, a BIP-39 seed phrase with several hundred octets to spare, or approximately 120 words of plain prose.</t>
      </section>
      <section anchor="sect-6.6">
        <name>Human-Verifiable Integrity</name>
        <t><xref target="sect-6.4"/> protects the machine tier.  It is useless to a reader without a computer: nobody decodes RS(255,191) by hand, and nobody computes SHA-256 with a fingertip.  A Rosetta tablet (<xref target="sect-8.4"/>) protected only by <xref target="sect-6.4"/> is therefore unverifiable by exactly the reader it exists to serve.</t>
        <t>Rosetta-tier content <bcp14>MUST</bcp14> instead be protected by two-dimensional even parity, which is verified by counting and requires no arithmetic whatsoever.</t>
        <t>Content is divided into blocks of 9 by 9 cells.  The upper-left 8 by 8 cells carry 64 data bits.  Column 9 of each of rows 1 through 8 carries that row's parity; row 9 carries each column's parity; and cell (9,9) carries the parity of the parities.  The invariant is that every row and every column of the block contains an even number of impressions.  Overhead is 17 cells in 81, or 21 percent.</t>
        <t>Verification is a finger and a count.  If every line is even, the block is intact.</t>
        <t>Recovery is geometric.  If exactly one row and exactly one column count odd, the damaged cell lies where they cross, and its true value is the opposite of what it appears to be.  No other information is required.</t>
        <t>The correction <bcp14>MUST</bcp14> be applied to the transcription and <bcp14>MUST NOT</bcp14> be applied to the tablet.  A fired tablet is a witness, not a workspace; a reader who "repairs" a cell has destroyed the evidence that the cell was ever wrong.</t>
        <t>Detection was measured over 200,000 randomly generated blocks under randomly placed cell inversions:</t>
        <artwork type="ascii-art"><![CDATA[
      Damaged cells   Detected    Located and corrected
      -------------   ---------   ---------------------
            1          100.00%           100.00%
            2          100.00%             --
            3          100.00%             --
            4           99.92%             --
]]></artwork>
        <t>The residual blind spot is four inversions falling on the corners of a rectangle, which cancel in both axes.  Implementations <bcp14>MUST</bcp14> therefore also impress, in relief decimal beside each block, the total count of impressions in that block.  A reader who counts a different total has detected damage that parity alone would report as clean.</t>
        <t>Parity does not address breakage.  Reconstruction of lost cells succeeds only where no row and no column loses more than one cell, which holds for scratches and hairline cracks but fails for any contiguous loss of 2 by 2 cells or larger; across randomly placed chip geometries only 16 percent were recoverable.  Chips are answered by duplication (<xref target="sect-8.4"/>), not by parity.</t>
      </section>
      <section anchor="sect-6.7">
        <name>Encoding Tier Selection</name>
        <t>CIS defines two encodings: the binary tier of Sections 6.1 through 6.5, and the script tier of <xref target="sect-8.4"/>, which impresses Braille and relief lettering directly.  Which to use is determined by the entropy of the payload.  The choice is not stylistic and implementations <bcp14>MUST NOT</bcp14> treat it as such.</t>
        <t>Measured over the 200 by 293 mm green impressed area:</t>
        <artwork type="ascii-art"><![CDATA[
      Encoding                     Area per   Characters   Arbitrary
                                       char   per tablet     octets?
      --------------------------   --------   ----------   ---------
      Binary, 2.5 mm pitch, raw       50 mm2        1,172         yes
      Binary, 2.5 mm, + RS + hdr        --            720         yes
      Braille, ADA dimensions         72 mm2          810          no
      Binary, 5.0 mm pitch, raw      200 mm2          293         yes
]]></artwork>
        <t>Two results follow, and they point in opposite directions.</t>
        <t>At the production pitch of <xref target="sect-5.2"/>, binary is 43 percent denser per character than Braille.  Braille spreads its six dots over a 6.2 by 10.0 mm footprint, while binary packs eight cells onto a uniform 2.5 mm lattice with no inter-character gap.</t>
        <t>At coarser pitches the result inverts.  At 5.0 mm -- the pitch imposed by any pin much thicker than the specification, and therefore the pitch of most prototypes -- Braille is 64 percent denser than binary, because Braille's footprint is fixed by human physiology while binary's scales with the square of the pitch. Implementations working at coarse pitch <bcp14>SHOULD</bcp14> prefer the script tier for text.</t>
        <t>For text, the script tier also wins at production pitch once error correction is accounted for.  The binary tier's 720 characters include Reed-Solomon and framing overhead; the script tier's 810 do not, because printed English carries roughly 86 percent redundancy against its 8-bit-per-character storage <xref target="SHANNON"/>, and that redundancy performs error detection at no cost in area.  A corrupted letter is visible to any reader.  A corrupted bit is not.</t>
        <t>For high-entropy payloads the script tier fails outright.  Keys, digests, and ciphertext are maximum-entropy by construction, so no linguistic redundancy exists to exploit, and formal error correction becomes mandatory rather than optional.  Braille's 6-dot cell also carries only 6 bits, so arbitrary octets require 1.33 cells each: encoding 720 octets would demand 68,817 mm2 against 58,600 available.  It does not fit.  The script tier's ceiling for arbitrary data is 607 octets, below the binary tier's 720, with no error correction at all.</t>
        <t>Accordingly:</t>
        <ul>
          <li>Payloads that are natural-language text, and that a human might one day need to read, <bcp14>SHOULD</bcp14> use the script tier.</li>
          <li>Payloads that are cryptographic material, digests, compressed data, or ciphertext <bcp14>MUST</bcp14> use the binary tier with the forward error correction of <xref target="sect-6.4"/>.</li>
          <li>Rosetta and manifest tablets <bcp14>MUST</bcp14> use the script tier.</li>
        </ul>
      </section>
    </section>
    <section anchor="sect-7">
      <name>Firing: The Commit Operation</name>
      <section anchor="sect-7.1">
        <name>Pre-Firing Requirements</name>
        <t>A tablet <bcp14>MUST</bcp14> be bone-dry before entering the kiln.  Residual free water converts to steam faster than it can escape through the clay's pore structure, and the tablet fractures explosively, damaging neighboring tablets in the same load.  This is the single most common cause of data loss during commit.</t>
        <t>Tablets <bcp14>MUST</bcp14> be air-dried for a minimum of 96 hours at 18 to 24 degrees Celsius and below 60 percent relative humidity, on an open rack permitting airflow to both faces.  Drying on a solid surface causes the exposed face to shrink faster than the covered face and warps the tablet.</t>
        <t>Before loading, an operator <bcp14>SHOULD</bcp14> verify dryness by the cheek test: a bone-dry tablet held against the cheek feels at ambient temperature, whereas one retaining free water feels perceptibly cool from evaporation.  This test is subjective but reliable, and remains in use for the same reason it has always been in use.</t>
        <t>Tablets <bcp14>MUST</bcp14> be loaded on edge in the kiln, separated by refractory spacers, and <bcp14>MUST NOT</bcp14> be stacked flat.  Flat stacking traps moisture between faces and produces differential thermal expansion across the stack.</t>
      </section>
      <section anchor="sect-7.2">
        <name>Reference Firing Profile</name>
        <t>Firing Profile 0x01 is the reference profile.  Complete tabular form appears in <xref target="app-B"/>.</t>
        <t>Stage 1, water smoking.  Ambient to 100 degrees C at 50 degrees C per hour, then hold at 100 degrees C for 2 hours.  This drives off the last atmospheric moisture without generating steam pressure. The hold is not optional.</t>
        <t>Stage 2, burnout and dehydroxylation.  100 to 600 degrees C at 100 degrees C per hour.  Organic matter oxidizes; above approximately 550 degrees C chemically bound water leaves the clay lattice.  This is the point of no return.  A tablet that has passed 600 degrees C is committed even if the firing is subsequently aborted.</t>
        <t>The ramp <bcp14>MUST NOT</bcp14> exceed 100 degrees C per hour between 550 and 600 degrees C.  Alpha-beta quartz inversion occurs at 573 degrees C and is accompanied by a sudden volume change of approximately 1 percent. Traversed quickly, it cracks tablets.</t>
        <t>Stage 3, sintering.  600 to 1000 degrees C at 150 degrees C per hour.</t>
        <t>Stage 4, soak.  Hold at 1000 degrees C for 20 minutes to equalize temperature across the load.</t>
        <t>Stage 5, cooling.  Free cooling with the kiln closed, EXCEPT that the rate through 600 to 500 degrees C <bcp14>MUST NOT</bcp14> exceed 100 degrees C per hour.  Quartz inversion occurs on the way down as well.  The kiln <bcp14>MUST NOT</bcp14> be opened above 100 degrees C.</t>
        <t>Total cycle time is approximately 17.5 hours, of which roughly 8 hours is cooling.</t>
      </section>
      <section anchor="sect-7.3">
        <name>Commit Semantics</name>
        <t>CIS commit maps onto two-phase commit as follows:</t>
        <artwork type="ascii-art"><![CDATA[
      Green, leather-hard    ->  transaction open, writes accepted
      Green, bone-dry        ->  prepared, writes closed, abort
                                 available
      In kiln, below 550 C   ->  prepared, abort still available
      Above 550 C            ->  COMMIT POINT, irrevocable
      Fired and cooled       ->  committed, durable, read-only
]]></artwork>
        <t>Abort, in the green states, is performed by slaking: the tablet is immersed in water until the clay disaggregates, then dried to working consistency and re-wedged.  Slaking is a true abort.  It leaves no recoverable trace of the impressed data and returns the material to the pool.</t>
        <t>Once a tablet passes 550 degrees C there is no abort.  Implementers are cautioned that this transition is not signaled by any interlock and occurs roughly seven hours into an unattended overnight cycle. Operators wishing to preserve an abort window <bcp14>SHOULD</bcp14> schedule firing so that the commit point falls during staffed hours.</t>
      </section>
      <section anchor="sect-7.4">
        <name>Failure Modes at Commit</name>
        <dl newline="false" spacing="normal">
          <dt>Dunting:</dt>
          <dd>Cracking from thermal shock at quartz inversion.  Presents as a clean crack, frequently straight.  Usually recoverable via FEC if the fragments are retained and rescanned together.</dd>
          <dt>Spalling:</dt>
          <dd>Explosive loss of a surface flake, from trapped moisture or a lime inclusion.  Destroys all cells in the affected area. Recoverable within the bounds of <xref target="sect-6.4"/>.</dd>
          <dt>Bloating:</dt>
          <dd>Over-firing causes gas evolution and swelling, distorting the cell lattice.  The fiducial affine correction cannot compensate for non-uniform distortion.  Usually unrecoverable.</dd>
          <dt>Warping:</dt>
          <dd>Slumping under its own weight if fired too hot or supported poorly.  Degrades optical read but rarely destroys data.</dd>
        </dl>
        <t>An implementation <bcp14>SHOULD</bcp14> fire a witness tablet carrying a known test pattern in every load, and <bcp14>SHOULD</bcp14> verify the witness before declaring the load committed.  A failed witness indicates the load is suspect, though it does not, and cannot, make it re-writable.</t>
      </section>
    </section>
    <section anchor="sect-8">
      <name>The Rack</name>
      <section anchor="sect-8.1">
        <name>Physical Requirements</name>
        <t>The storage array is a standard bakery sheet-pan rack.  This is not an arbitrary choice: the trade has converged on a shelf pitch, a frame stiffness, and a load rating well matched to CIS, and the equipment is available commodity at low cost from restaurant suppliers.</t>
        <t>A conforming rack <bcp14>MUST</bcp14> provide:</t>
        <ul>
          <li>Twenty shelf positions on a pitch of not less than 75 mm.</li>
          <li>Shelves accommodating a pan of not less than 457 by 660 mm (the standard 18 by 26 inch full sheet).</li>
          <li>A static load rating of not less than 200 kg.</li>
          <li>Locking casters, or fixed feet.  A rack on unlocked casters is a seismic and a comedic hazard.</li>
        </ul>
        <t>Four fired tablets of 210 by 297 mm occupy 420 by 594 mm and fit a full sheet pan in a 2-by-2 arrangement with 18 mm of clearance per side across the width and 33 mm per side along the length.  Tablets <bcp14>MUST</bcp14> be separated from the pan and from each other by felt or silicone spacers; ceramic against steel abrades the impressed surface with every handling.</t>
        <t>A fully populated rack holds 80 tablets, weighs approximately 110 kg of ceramic plus the frame, and stores 57,600 octets, or exactly 56.25 KiB.</t>
      </section>
      <section anchor="sect-8.2">
        <name>Addressing</name>
        <t>A tablet's address is its physical position.  There is no indirection layer, because an indirection layer would be software and would be mutable.</t>
        <artwork type="ascii-art"><![CDATA[
      cis://<facility>/<rack>/<shelf>/<position>
]]></artwork>
        <t>where shelf is 1 through 20 counting from the bottom, and position is 1 through 4 in reading order (upper-left, upper-right, lower-left, lower-right) as viewed from the front of the rack. Front and bottom <bcp14>MUST</bcp14> be marked physically on the frame.</t>
        <t>Shelf and position <bcp14>MUST</bcp14> also be impressed on the tablet edge in human-readable relief characters not less than 6 mm in height, using a separate edge-marking tool.  A tablet dropped and reshelved incorrectly is otherwise unlocatable, and the recovery procedure is to scan the entire rack.</t>
      </section>
      <section anchor="sect-8.3">
        <name>Cross-Tablet Parity</name>
        <t><xref target="sect-6.4"/> protects against damage within a tablet.  It does not protect against loss of a tablet, which is the dominant failure mode in practice, because tablets are dropped.</t>
        <t>Records spanning multiple tablets <bcp14>MUST</bcp14> be protected by cross-tablet parity.  For a record of N data tablets, implementations <bcp14>MUST</bcp14> write at least two additional parity tablets computed as an RS(N+2, N) code over GF(2^8) applied octet-wise across the payload regions, permitting reconstruction of any two lost tablets.</t>
        <t>Parity tablets carry type code 0x03 and <bcp14>MUST</bcp14> be stored on a different shelf from any data tablet of the same record.  Storing a record's parity beside its data defeats the purpose, since the realistic loss event is a shelf collapsing.</t>
        <t>Records occupying a single tablet <bcp14>SHOULD</bcp14> be written in duplicate on different shelves.  At 720 octets the storage cost of duplication is negligible relative to the cost of the kiln cycle.</t>
      </section>
      <section anchor="sect-8.4">
        <name>The Rosetta Tablet</name>
        <t>Every rack <bcp14>MUST</bcp14> carry, at shelf 20 position 1, a Rosetta tablet of type code 0x01.</t>
        <t>The Rosetta tablet is not machine-encoded.  It bears, in human-readable relief lettering not less than 8 mm in height:</t>
        <ul>
          <li>The cell pitch, lattice dimensions, and the bit convention of <xref target="sect-6.1"/>.</li>
          <li>A legend showing an impression and a land side by side, labelled.</li>
          <li>A worked decode of the first header octets so that a reader can confirm orientation without external documentation.</li>
          <li>The facility identifier, rack identifier, and the date of the first commit into the rack, in ISO 8601 form.</li>
          <li>The parity rule of <xref target="sect-6.6"/>, stated in words, together with the block dot-count convention.  A reader who can count can then verify the rack's own key.</li>
        </ul>
        <t>Every Rosetta tablet <bcp14>MUST</bcp14> be written in duplicate and the duplicate <bcp14>MUST</bcp14> be shelved in a different rack, preferably at a different site. The Rosetta tablet is the single point of failure for the entire archive: lose it and every other tablet in the rack becomes an opaque red rectangle.  It is the one tablet whose loss is not survivable, and it is protected accordingly.</t>
        <t>The Rosetta tablet <bcp14>MUST NOT</bcp14> depend on Braille alone.  Braille is <bcp14>RECOMMENDED</bcp14> as one of its three registers because it is already optimized for the fingertip -- its 2.34 mm dot pitch sits at the threshold of two-point tactile discrimination, which is why the cell pitch of <xref target="sect-5.2"/> converges on it -- but Braille is a learned code, and the tablet <bcp14>MUST NOT</bcp14> assume the reader has learned it.  The relief Latin lettering, the Braille, and the raw impression patterns <bcp14>MUST</bcp14> appear side by side for the same content, so that a reader who knows any one of the three can derive the other two.  This is the structure of the Rosetta Stone and it is adopted here for the same reason.</t>
        <t>The rationale is straightforward.  The medium's design life is several thousand years.  The design life of this document, of the IETF, of the organization operating the rack, and of the file format registry in <xref target="sect-12"/> is not.  A tablet whose decoding depends on a document nobody can find is an opaque red rectangle.  The Rosetta tablet is the only part of CIS that must survive interpretation by someone who has never heard of the Internet.</t>
      </section>
      <section anchor="sect-8.5">
        <name>The Rack Manifest</name>
        <t>Each rack <bcp14>MUST</bcp14> carry a manifest of type code 0x04 at shelf 20 position 2, listing record identifiers against addresses.</t>
        <t>The manifest presents an unavoidable tension.  It cannot be updated in place, so a rack filled incrementally accumulates a chain of manifests, each superseding the last and each consuming a tablet position.  Implementations <bcp14>SHOULD</bcp14> therefore fill racks in batches large enough to amortize the manifest cost, and <bcp14>MUST</bcp14> write a final manifest when a rack is sealed.  A rack whose last manifest does not describe its full contents <bcp14>MUST</bcp14> be treated as unsealed.</t>
      </section>
      <section anchor="sect-8.6">
        <name>Tablet Tiling and the Commodity Constraint</name>
        <t>The sheet pan is not chosen for its geometry.  It is chosen because it is a century-old standard, stocked by every restaurant supplier in every country, at a price no bespoke rack could approach, with spare parts that will remain orderable long after any particular manufacturer is gone.  For an archive with a design life measured in millennia, replaceability of the furniture is a durability property, not an economy.</t>
        <t>The pan does, however, impose 457 mm as a hard cap on tablet width, and that cap deserves examination rather than assumption.  Tilings of the 457 by 660 mm pan were evaluated exhaustively:</t>
        <artwork type="ascii-art"><![CDATA[
      Tiling   Fired tablet   Octets/    Octets/   KiB per   Tablet
                    (mm)      tablet      shelf      rack      (kg)
      ------   ------------   -------    -------   -------   ------
       1 x 1     437 x 640      4,158      4,158      81.2     6.09
       1 x 2     437 x 316      1,866      3,732      72.9     3.01
       2 x 1     214 x 640      1,866      3,732      72.9     2.99
       2 x 3     214 x 208        529      3,174      62.0     0.97
       2 x 2     210 x 297        720      2,880      56.2     1.36
]]></artwork>
        <t>A single full-pan tablet yields 44 percent more capacity per rack than the 2 by 2 tiling of <xref target="sect-8.1"/>, and uses 92.7 percent of the pan against 89.9 percent.  It is nonetheless <bcp14>NOT RECOMMENDED</bcp14>, for two reasons.</t>
        <t>First, blast radius.  A full-pan tablet concentrates 4,158 octets behind a single fracture, 5.8 times the exposure of the 2 by 2 tiling, on a medium whose dominant failure mode is being dropped. It also weighs 6.09 kg against 1.36 kg, which makes one-handed handling impossible and materially raises the probability of the drop it would be punished for.</t>
        <t>Second, and decisively, no commodity reader exists for it.  A 437 by 640 mm tablet requires a large-format scanner or a purpose-built camera rig.  The 2 by 2 tiling produces a tablet of 210 by 297 mm, which is read by any flatbed scanner sold anywhere for around USD 100, and stored in any document sleeve.</t>
        <t>This is the same argument that selects the pan, applied at the other end of the system, and it generalizes to a design principle:</t>
        <blockquote>
          <t>Every component in the retention and read path <bcp14>MUST</bcp14> be a commodity article obtainable from multiple independent suppliers.  A bespoke component is one that some future institution must re-manufacture, and that institution may not exist.</t>
        </blockquote>
        <t>Among tilings satisfying this constraint, 2 by 2 was found by exhaustive search to be optimal; it beats every other flatbed-compatible arrangement on octets per shelf.  Filling the pan more aggressively at 2 by 2 (214 by 316 mm tablets) yields no gain, because the additional cells are absorbed by Reed-Solomon codeword quantization (<xref target="sect-6.4"/>) without completing a fifth codeword.</t>
        <t>The encoding drum (<xref target="sect-5.5"/>) is the sole bespoke component in CIS, and it sits entirely on the write side.  Loss of the drum ends the ability to commit new tablets; it does not affect the readability of a single tablet already on a rack.  Implementations <bcp14>SHOULD</bcp14> preserve this property, and <bcp14>MUST NOT</bcp14> introduce bespoke components into the read path.</t>
      </section>
    </section>
    <section anchor="sect-9">
      <name>Reading</name>
      <section anchor="sect-9.1">
        <name>Illumination</name>
        <t>A CIS tablet is a low-contrast surface relief.  It has essentially no reflectance variation; all information is in geometry.  Flat diffuse illumination renders a tablet very nearly blank, and this is the most common reason an implementation reports an unreadable tablet that is in fact intact.</t>
        <t>Conforming readers <bcp14>MUST</bcp14> use oblique illumination at an elevation angle between 15 and 30 degrees above the tablet plane, which casts each impression's shadow across a substantial fraction of its cell.</t>
        <t>Readers <bcp14>SHOULD</bcp14> capture from not fewer than four azimuths at 90 degree intervals and combine the results, which removes the directional bias whereby impressions on the shadow side of a warp are lost.</t>
        <t>For tablets that are damaged, heavily worn, or otherwise marginal, readers <bcp14>SHOULD</bcp14> use Reflectance Transformation Imaging <xref target="PTM"/>, which captures a fixed viewpoint under many lighting directions and synthesizes an interactively relightable surface normal map.  RTI is the established technique for reading degraded impressed clay and recovers text from tablets that are illegible by direct inspection <xref target="WALKER"/>.  CIS did not invent this problem and should not invent a solution to it.</t>
      </section>
      <section anchor="sect-9.2">
        <name>Decoding</name>
        <ol>
          <li>Locate the four corner fiducials and resolve orientation, cross-checking against the registration notch.</li>
          <li>Derive the affine transform mapping fiducial positions to the nominal lattice.  This recovers the shrinkage scale factor and any in-plane skew.</li>
          <li>Recover column and row pitch from the sync tracks.  Track pitch locally rather than assuming it is globally constant; warp makes it vary across the tablet.</li>
          <li>Sample each cell.  Classify as impression or land by local shadow-area threshold, computed over a neighborhood of not more than 9 by 9 cells.  Global thresholds fail on warped tablets.</li>
          <li>Deinterleave into four codewords and decode per <xref target="sect-6.4"/>.</li>
          <li>Verify magic and version; verify the payload digest.</li>
        </ol>
        <t>Cells that cannot be confidently classified <bcp14>SHOULD</bcp14> be passed to the decoder as erasures rather than guesses.  RS(255,191) corrects twice as many erasures as errors, so a decoder that marks uncertainty is substantially stronger than one that does not.</t>
      </section>
      <section anchor="sect-9.3">
        <name>Verification</name>
        <t>Implementations <bcp14>SHOULD</bcp14> verify each rack on a cycle of not more than five years, and <bcp14>MUST</bcp14> verify after any physical event affecting the facility.</t>
        <t>Verification is read-only and therefore safe, but it involves handling every tablet in the rack, and handling is the principal cause of breakage.  Verification schedules more frequent than annually are <bcp14>NOT RECOMMENDED</bcp14>; they destroy more tablets than they discover.</t>
      </section>
      <section anchor="sect-9.4">
        <name>Bulk Optical Recovery</name>
        <t><xref target="sect-9.1"/> describes reading a tablet.  This section addresses recovering an archive.</t>
        <t>The script tier (<xref target="sect-6.7"/>) is often mischaracterized as a last-resort fallback for a human with a lamp.  It is not.  Relief lettering photographed under raking light is ordinary OCR input, and embossed Braille has a mature recognition literature of its own under the name Optical Braille Recognition, with both published systems and working open implementations <xref target="OBR"/>.  Neither requires the tablet to be touched.</t>
        <t>The throughput consequence is large.  A tablet photographed on a copy stand under fixed oblique illumination takes on the order of five seconds; a rack of 80 tablets is captured in under seven minutes, against roughly four hours to decode the same rack by fingertip.  Recognition then runs offline, in bulk, at no incremental handling cost -- which matters because handling, not reading, is what destroys tablets (<xref target="sect-9.3"/>).</t>
        <t>This makes the two tiers genuinely independent read paths, and the independence is the point:</t>
        <ul>
          <li>The binary tier is denser and carries arbitrary octets, but decoding it requires this specification.  A reader must know the cell convention, the interleave, the header layout, and RS(255,191) over GF(2^8).  Lose the specification and the tier is unreadable.</li>
          <li>The script tier is less dense and carries text only, but decoding it requires literacy.  It survives the loss of this document, the registry of <xref target="sect-12"/>, and every institution named in it.</li>
        </ul>
        <t>An archive carrying both is therefore robust against two disjoint failures: physical damage, which the binary tier's error correction addresses, and interpretive loss, which only the script tier addresses.  Implementations <bcp14>SHOULD</bcp14> duplicate the rack manifest (<xref target="sect-8.5"/>) into the script tier for this reason, accepting the density penalty as the price of a read path with no dependencies.</t>
      </section>
    </section>
    <section anchor="sect-10">
      <name>Operational Considerations</name>
      <section anchor="sect-10.1">
        <name>Throughput and Latency</name>
        <t>For a kiln of 40-tablet capacity on the reference profile:</t>
        <artwork type="ascii-art"><![CDATA[
      Payload per load:              28,800 octets
      Cycle time:                    17.5 hours
      Sustained write throughput:    0.46 octets/second
                                     3.7 bits/second
]]></artwork>
        <t>This is slower than a 1958 Bell 101 modem by a factor of thirty, and slower than a competent human operator sending manual Morse by a factor of about four and a half.  It is, so far as the author is aware, the lowest write throughput ever formally specified in an IETF document, <xref target="RFC1149"/> notwithstanding, since an avian carrier at least delivers its payload in a single burst.</t>
        <t>Commit latency, from the completed impression of the last tablet in a load to a durable readable state, is approximately 18 hours including load-out.  Implementations <bcp14>MUST NOT</bcp14> represent CIS as providing any durability guarantee before the load has cooled below 100 degrees C, since a load in progress may still be lost to spalling.</t>
        <t>Read throughput is considerably better: an operator with a scanner and a rack sustains roughly one tablet per minute, or 12 octets per second, which exceeds the write rate by a factor of 26.  CIS is thus, unusually among storage media, read-optimized.</t>
      </section>
      <section anchor="sect-10.2">
        <name>Density</name>
        <t>Areal density is approximately 0.098 payload bits per square millimeter, or 9.8 x 10^-8 bits per square micrometer.  Contemporary hard disk media achieve on the order of 2.3 x 10^3 bits per square micrometer.  CIS is therefore approximately ten orders of magnitude less dense.</t>
        <t>Mass density is approximately 0.52 KiB per kilogram.  Volumetric density, at the rack level and including working aisle, is approximately 40 KiB per cubic meter of facility volume.</t>
        <t>Storing one gibibyte in CIS would require approximately 1.49 million tablets, 18,600 racks, 2,000 tonnes of fired ceramic, and, at 40 tablets per 17.5-hour cycle, roughly 74 years of continuous single-kiln operation.  Implementers are again referred to <xref target="sect-1.1"/> regarding scope.</t>
      </section>
      <section anchor="sect-10.3">
        <name>Environmental Requirements</name>
        <t>Fired ceramic is chemically inert, dimensionally stable, immune to magnetic fields, unaffected by electromagnetic pulse, and indifferent to power loss.  It requires no refresh cycle, no migration, and no running cost.  Its requirements are almost entirely mechanical.</t>
        <t>Facilities <bcp14>MUST</bcp14> protect against:</t>
        <ul>
          <li>Impact and vibration.  This is the whole of the threat.  Fired earthenware has a flexural strength around 20 MPa and no ductile failure mode.  A tablet dropped onto concrete from one meter is a total loss, though FEC-recoverable if the fragments are kept.</li>
          <li>Freeze-thaw cycling.  Earthenware fired to 1000 degrees C retains 15 to 20 percent porosity.  Water absorbed into that porosity expands on freezing and spalls the surface.  Storage areas <bcp14>MUST</bcp14> remain above freezing, or humidity <bcp14>MUST</bcp14> be held below 50 percent.</li>
          <li>Point loading.  Tablets <bcp14>MUST</bcp14> rest on compliant spacers.</li>
        </ul>
        <t>Facilities need not protect against fire.  A tablet has already been fired to 1000 degrees C; a structure fire is, from the tablet's perspective, an unremarkable second bisque.  Nor against flood: the tablets will require cleaning and, if they were fired below full maturity, careful drying, but the data will be there.  This is a genuine and non-trivial advantage over every electronic medium, and it is the reason the archaeological record consists so disproportionately of fired clay.</t>
      </section>
    </section>
    <section anchor="sect-11">
      <name>Security Considerations</name>
      <t>This section follows the guidance of <xref target="RFC3552"/>.  It is unusually long relative to the rest of this document, because the security properties of CIS are the only reason to accept its costs, and because those properties are narrower than they first appear.</t>
      <section anchor="sect-11.1">
        <name>Threat Model</name>
        <t>CIS is designed against one adversary: an authenticated software process, potentially holding maximal privilege, issuing destructive operations that the system is obliged to honor.  This includes compromised credentials, defective automation, malicious insiders operating through sanctioned tooling, and autonomous agents pursuing an objective whose optimum involves deleting things.</t>
        <t>Against this adversary CIS is complete, and the completeness is structural rather than procedural.  The medium is not attached to any bus.  The write head has no electrical interface.  The commit operation is a mineralogical transformation with no inverse.  There is no credential, no privilege level, and no supply-chain compromise that reaches a fired tablet, because there is no path from any network to a fired tablet along which a modification could travel.</t>
        <t>Ransomware cannot encrypt a rack.  A malformed retention-policy change cannot expire it.  A recursive delete cannot traverse it.</t>
      </section>
      <section anchor="sect-11.2">
        <name>What CIS Does Not Protect Against</name>
        <t>Physical access is the entire remaining security boundary, and it is absolute.  A hammer is a complete, immediate, and wholly irrecoverable attack on any tablet within reach.  There is no redundancy scheme at the tablet level that survives an adversary with unhurried physical access to a rack; cross-tablet parity (<xref target="sect-8.3"/>) protects against accidents, not intent.</t>
        <t>Operators <bcp14>MUST NOT</bcp14> treat CIS as reducing their physical security requirements.  CIS converts a logical security problem into a physical one.  Physical security problems are older, better understood, and solvable with locks, walls, and geographic distribution, which is the actual benefit on offer.  But the problem does not disappear, and organizations accustomed to defending only the logical perimeter may find they have traded a threat they had staff for against one they do not.</t>
        <t>Geographic distribution of racks is therefore <bcp14>RECOMMENDED</bcp14> for any deployment whose threat model includes a motivated physical adversary.</t>
        <t>Implementations <bcp14>MUST NOT</bcp14> add electrical actuation to the roller, and <bcp14>MUST NOT</bcp14> place any network-controlled mechanism in the write path. The temptation to do so will be considerable, since the manual write path is the dominant cost of the system.  A network-actuated roller restores the exact property CIS exists to remove, at which point the deployment retains all of the cost and none of the benefit.</t>
      </section>
      <section anchor="sect-11.3">
        <name>Irrevocability and Legal Exposure</name>
        <t>CIS has no redaction capability.  This is a security property in one direction and a serious liability in the other.</t>
        <t>Data committed in error is committed permanently.  A misdirected payload, an accidentally included secret, or a record that later proves defamatory or unlawful cannot be removed by any means short of destroying the tablet, which is available but coarse: the tablet is the unit of destruction, and everything sharing it goes too.</t>
        <t>Deployments in jurisdictions recognizing a right to erasure (including but not limited to the EU General Data Protection Regulation Article 17 and the California Consumer Privacy Act) <bcp14>MUST NOT</bcp14> store personal data of identifiable living persons in recoverable form on CIS.  An organization that does so has created an obligation it is physically incapable of discharging.</t>
        <t>Where personal data must be archived, the <bcp14>RECOMMENDED</bcp14> pattern is crypto-shredding: encrypt per-subject with a distinct key, commit only the ciphertext to CIS, and hold the keys on erasable media. Erasure is then effected by destroying the key.  Implementers should note that this pattern's legal sufficiency is unsettled in several jurisdictions and that this document does not constitute legal advice.</t>
        <t>Organizations <bcp14>SHOULD</bcp14> impose a mandatory hold period between impression and firing, during which a second party reviews the green tablets and may abort by slaking.  A 24-hour hold is <bcp14>RECOMMENDED</bcp14>. This is the only reversal opportunity the system provides, and it costs one day.</t>
      </section>
      <section anchor="sect-11.4">
        <name>Confidentiality</name>
        <t>The medium provides none.  A tablet's contents are legible to anyone holding it under a lamp.</t>
        <t>Payloads requiring confidentiality <bcp14>MUST</bcp14> be encrypted before impression, with flag bit 1 set (<xref target="sect-6.3"/>).  Implementations <bcp14>SHOULD</bcp14> use an AEAD construction; note that the nonce and tag consume payload, reducing the usable 720 octets accordingly.</t>
        <t>Encryption on CIS carries an unusual and under-appreciated risk profile:</t>
        <ul>
          <li>The key cannot be rotated.  Re-keying requires writing a new tablet, and the old ciphertext remains, permanently, on the rack.</li>
          <li>Loss of the key is total and unrecoverable loss of the data, on a medium chosen specifically because loss was unacceptable.  The key becomes the new single point of failure, and it is stored somewhere less durable than the ceramic.</li>
          <li>Cryptographic lifetime is bounded far below medium lifetime.  A cipher considered strong today may be broken within decades, whether by cryptanalysis or by cryptographically relevant quantum computation.  The ciphertext will still be sitting on the shelf, in excellent condition, for anyone who eventually walks past with a working attack.  Encrypting to CIS is a bet that the cipher outlives the data's sensitivity, and the medium is engineered to ensure the data does not decay in the meantime.</li>
        </ul>
        <t>Given the above, CIS is best suited to data that is either non-sensitive, or sensitive only for a period the operator can bound, or protected by physical custody rather than by cryptography.</t>
      </section>
      <section anchor="sect-11.5">
        <name>Authenticity Versus Integrity</name>
        <t>The payload digest in <xref target="sect-6.3"/> detects accidental corruption.  It does not establish authenticity, and implementations <bcp14>MUST NOT</bcp14> treat it as doing so.</t>
        <t>Forging a CIS tablet requires clay, a roller, and a kiln.  An adversary with these can manufacture a tablet bearing any content, with a perfectly valid digest, indistinguishable from an authentic tablet by any examination of the tablet itself.  The digest binds payload to header; it binds nothing to an author.</t>
        <t>Authenticity in CIS derives from chain of custody: the physical security of the rack, the access log of the facility, and the continuity of possession.  This is a weaker and more human guarantee than a signature over a network protocol, and deployments <bcp14>MUST</bcp14> account for it explicitly.</t>
        <t>Implementations <bcp14>MAY</bcp14> commit a digital signature alongside the payload.  Such signatures should be understood as having a useful life of decades, not millennia: the algorithm will be deprecated, the key will expire, the CA will dissolve, and the verifier will be unavailable long before the tablet shows any wear at all.  A signature on CIS documents that something was signed at a time when a now-obsolete algorithm was in use.  That is worth something, but it is not what a verifier normally means.</t>
      </section>
      <section anchor="sect-11.6">
        <name>Capacity Exhaustion</name>
        <t>CIS capacity, once consumed, is not reclaimable.  This creates a denial-of-service vector unusual among storage systems: an adversary with access to the roller, the clay stock, and the kiln can permanently exhaust an organization's archival capacity, and no recovery exists short of procuring more racks and floor space.</t>
        <t>Consumption is bounded by the kiln, which is the natural rate limit (<xref target="sect-10.1"/>).  Nonetheless, access to the write path <bcp14>MUST</bcp14> be controlled at least as strictly as access to the racks, and blank tablet stock <bcp14>SHOULD</bcp14> be inventoried.</t>
      </section>
      <section anchor="sect-11.7">
        <name>Roller State Disclosure</name>
        <t>The roller physically retains its last-set configuration.  An adversary with brief access to an idle roller reads the most recently written 80-by-58 cell band directly off the pins, without touching the racks, without leaving a trace, and without needing to know which tablet it belongs to.</t>
        <t>For a payload written in the natural order, that band contains the frame header and the leading payload octets: 580 octets, which for key material is the worst possible 580 octets to leak.</t>
        <t>Rollers <bcp14>MUST</bcp14> be reset to all-retracted immediately after each impression, and <bcp14>MUST</bcp14> be stored under the same physical controls as the racks.  Implementations <bcp14>SHOULD</bcp14> adopt a two-person rule for roller access.</t>
      </section>
      <section anchor="sect-11.8">
        <name>Socially Engineered Destruction</name>
        <t>Sections 11.1 and 11.2 together imply the residual attack.  An adversarial process cannot reach a fired tablet, but it can reach the people who can, and the capability such a process most reliably possesses is the generation of fluent, well-targeted, plausibly sourced text.  The air gap stops packets.  It does not stop a convincing message to a facility technician.</t>
        <t>The realistic attack is not a rogue agent smashing tablets.  It is a correctly formatted work order, citing a real project code, from a plausible internal address, instructing staff to clear rack 14 for a floor renovation.  Nothing in the physics of <xref target="sect-3.2"/> prevents this, and the staff carrying it out are not doing anything they would recognize as wrong.</t>
        <t>Deployments <bcp14>MUST</bcp14> therefore adopt the following controls, which are procedural rather than physical and which are the weakest part of the system:</t>
        <ul>
          <li>No destruction on inbound instruction.  Any request to remove, relocate, or destroy tablets <bcp14>MUST</bcp14> be confirmed out of band with a named human known personally to the confirming party.  Electronic confirmation of an electronic request confirms nothing.</li>
          <li>A two-person rule for physical rack access, with the second person authorized to refuse.</li>
          <li>A standing rule, published to all facility staff, that no legitimate business process ever requires the destruction of a committed tablet.  This is the strongest available control precisely because it is unconditional: it converts every destruction order, however well formatted, into a self-evident indicator of compromise, and it requires staff to evaluate no context, verify no credentials, and exercise no judgement about plausibility.</li>
          <li>Capacity planning that never creates operational pressure to reclaim space, since such pressure is the pretext an attacker would otherwise need to manufacture.</li>
        </ul>
        <t>Operators should note the asymmetry this creates.  CIS makes the data physically indestructible by software and thereby concentrates the entire remaining risk onto the judgement of a small number of people with physical access.  That is a substantially better place for the risk to sit than in a credential, but it is not nowhere, and it <bcp14>MUST</bcp14> be staffed and trained as the security control it now is.</t>
      </section>
    </section>
    <section anchor="sect-12">
      <name>IANA Considerations</name>
      <section anchor="sect-12.1">
        <name>Ceramic Immutable Storage Parameters Registry</name>
        <t>IANA is requested to create a new registry group, "Ceramic Immutable Storage (CIS) Parameters", containing the sub-registries in Sections 12.2 and 12.3.  The registration policy for both is Specification Required <xref target="RFC8126"/>.</t>
      </section>
      <section anchor="sect-12.2">
        <name>Tablet Type Codes</name>
        <t>An 8-bit sub-registry, "CIS Tablet Type Codes", with initial contents:</t>
        <artwork type="ascii-art"><![CDATA[
      Value  Name                 Reference
      -----  -------------------  ------------------
      0x00   Reserved             This document
      0x01   Rosetta              This document, 8.4
      0x02   Data                 This document
      0x03   Cross-tablet parity  This document, 8.3
      0x04   Rack manifest        This document, 8.5
      0x05   Continuation         This document
      0x06   Witness              This document, 7.4
      0x07-  Unassigned
      0xEF
      0xF0-  Experimental use     This document
      0xFF
]]></artwork>
      </section>
      <section anchor="sect-12.3">
        <name>Firing Profile Identifiers</name>
        <t>An 8-bit sub-registry, "CIS Firing Profile Identifiers", with initial contents:</t>
        <artwork type="ascii-art"><![CDATA[
      Value  Name                        Reference
      -----  --------------------------  ------------------
      0x00   Unspecified                 This document
      0x01   Reference earthenware,      This document, 7.2
             1000 C
      0x02-  Unassigned
      0xEF
      0xF0-  Experimental use            This document
      0xFF
]]></artwork>
        <t>Registrations <bcp14>MUST</bcp14> specify peak temperature, all ramp rates, every hold, and the clay body class the profile is qualified against.</t>
      </section>
      <section anchor="sect-12.4">
        <name>Media Type Registration</name>
        <t>IANA is requested to register the media type "application/vnd.ietf.cis-tablet+cbor" per <xref target="RFC6838"/>, denoting the digital surrogate of a CIS tablet: the decoded frame together with capture metadata (illumination geometry, fiducial coordinates, erasure map, per-codeword decode residuals).</t>
        <t>This media type describes the surrogate, not the tablet.  The tablet has no media type, having been designed for a reader with a lamp.</t>
      </section>
    </section>
  </middle>
  <back>
    <references anchor="sec-normative">
      <name>Normative References</name>
      <referencegroup anchor="BCP14" target="https://www.rfc-editor.org/info/bcp14">
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
        <front><title>Key words for use in RFCs to Indicate Requirement Levels</title><author initials="S." surname="Bradner"/><date year="1997" month="March"/></front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
        <front><title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title><author initials="B." surname="Leiba"/><date year="2017" month="May"/></front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </referencegroup>
      <reference anchor="RFC6838" target="https://www.rfc-editor.org/info/rfc6838">
        <front><title>Media Type Specifications and Registration Procedures</title><author initials="N." surname="Freed"/><author initials="J." surname="Klensin"/><author initials="T." surname="Hansen"/><date year="2013" month="January"/></front>
        <seriesInfo name="BCP" value="13"/>
        <seriesInfo name="RFC" value="6838"/>
        <seriesInfo name="DOI" value="10.17487/RFC6838"/>
      </reference>
      <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126">
        <front><title>Guidelines for Writing an IANA Considerations Section in RFCs</title><author initials="M." surname="Cotton"/><author initials="B." surname="Leiba"/><author initials="T." surname="Narten"/><date year="2017" month="June"/></front>
        <seriesInfo name="BCP" value="26"/>
        <seriesInfo name="RFC" value="8126"/>
        <seriesInfo name="DOI" value="10.17487/RFC8126"/>
      </reference>
      <reference anchor="RFC9562" target="https://www.rfc-editor.org/info/rfc9562">
        <front><title>Universally Unique IDentifiers (UUIDs)</title><author initials="K." surname="Davis"/><author initials="B." surname="Peabody"/><author initials="P." surname="Leach"/><date year="2024" month="May"/></front>
        <seriesInfo name="RFC" value="9562"/>
        <seriesInfo name="DOI" value="10.17487/RFC9562"/>
      </reference>
      <reference anchor="FIPS180-4" target="https://doi.org/10.6028/NIST.FIPS.180-4">
        <front><title>Secure Hash Standard (SHS)</title>
        <author><organization>National Institute of Standards and Technology</organization></author>
        <date year="2015" month="August"/></front>
        <seriesInfo name="FIPS PUB" value="180-4"/>
      </reference>
      <reference anchor="REEDSOLOMON">
        <front><title>Polynomial Codes over Certain Finite Fields</title>
        <author initials="I." surname="Reed"/><author initials="G." surname="Solomon"/>
        <date year="1960"/></front>
        <seriesInfo name="Journal of the Society for Industrial and Applied Mathematics" value="Vol. 8, No. 2, pp. 300-304"/>
      </reference>
    </references>
    <references anchor="sec-informative">
      <name>Informative References</name>
      <reference anchor="RFC4949" target="https://www.rfc-editor.org/info/rfc4949">
        <front><title>Internet Security Glossary, Version 2</title><author initials="R." surname="Shirey"/><date year="2007" month="August"/></front>
        <seriesInfo name="FYI" value="36"/>
        <seriesInfo name="RFC" value="4949"/>
        <seriesInfo name="DOI" value="10.17487/RFC4949"/>
      </reference>
      <reference anchor="RFC3552" target="https://www.rfc-editor.org/info/rfc3552">
        <front><title>Guidelines for Writing RFC Text on Security Considerations</title><author initials="E." surname="Rescorla"/><author initials="B." surname="Korver"/><date year="2003" month="July"/></front>
        <seriesInfo name="BCP" value="72"/>
        <seriesInfo name="RFC" value="3552"/>
        <seriesInfo name="DOI" value="10.17487/RFC3552"/>
      </reference>
      <reference anchor="RFC1149" target="https://www.rfc-editor.org/info/rfc1149">
        <front><title>A Standard for the Transmission of IP Datagrams on Avian Carriers</title><author initials="D." surname="Waitzman"/><date year="1990" month="April"/></front>
        <seriesInfo name="RFC" value="1149"/>
        <seriesInfo name="DOI" value="10.17487/RFC1149"/>
      </reference>
      <reference anchor="RICE">
        <front><title>Pottery Analysis: A Sourcebook</title>
        <author initials="P.M." surname="Rice"/><date year="1987"/></front>
        <refcontent>University of Chicago Press</refcontent>
      </reference>
      <reference anchor="PTM">
        <front><title>Polynomial Texture Maps</title>
        <author initials="T." surname="Malzbender"/><author initials="D." surname="Gelb"/>
        <author initials="H." surname="Wolters"/><date year="2001"/></front>
        <refcontent>Proceedings of SIGGRAPH 2001, pp. 519-528</refcontent>
      </reference>
      <reference anchor="WALKER">
        <front><title>Cuneiform</title>
        <author initials="C.B.F." surname="Walker"/><date year="1987"/></front>
        <refcontent>Reading the Past series, British Museum Press</refcontent>
      </reference>
      <reference anchor="OBR" target="https://en.wikipedia.org/wiki/Optical_braille_recognition">
        <front><title>Optical braille recognition</title>
        <author><organization>Wikipedia</organization></author><date year="2026"/></front>
      </reference>
      <reference anchor="SHANNON">
        <front><title>Prediction and Entropy of Printed English</title>
        <author initials="C.E." surname="Shannon"/><date year="1951"/></front>
        <refcontent>Bell System Technical Journal, Vol. 30, No. 1, pp. 50-64</refcontent>
      </reference>
    </references>
    <section anchor="app-A">
      <name>Worked Example</name>
      <t>This appendix encodes a 32-octet symmetric key as a single-tablet record.</t>
      <t>Payload:      32 octets of key material Padding:      688 octets, value 0x00 Payload len:  0x0020 (32; padding is not counted)</t>
      <t>Header construction:</t>
      <artwork type="ascii-art"><![CDATA[
      Magic             43 49 53
      Version           01
      Type code         02      (Data)
      Firing profile    01      (reference earthenware)
      Tablet ordinal    00 01
      Record ID         16 octets, UUIDv4
      Payload length    00 20
      Flags             00 00   (no continuation, not encrypted)
      Payload digest    16 octets, SHA-256 truncated to 128 bits
]]></artwork>
      <t>Encoding proceeds as follows.</t>
      <ol>
        <li>Assemble the 44-octet header and the 720-octet payload field into a 764-octet protected region.</li>
        <li>Split into four 191-octet blocks; encode each as RS(255,191); obtain 1,020 octets.</li>
        <li>Interleave at octet granularity: physical octet i is drawn from codeword (i mod 4), position (i div 4).</li>
        <li>Append 125 zero octets, giving 1,145 octets, or 9,160 bits; pad with 4 zero bits to 9,164.</li>
        <li>Map to the lattice: bit 0 to cell (row 1, column 1), proceeding left to right then top to bottom, skipping the sync tracks.</li>
        <li>Set the roller for rows 1 through 58; impress; reset; set for rows 59 through 116; impress; reset.</li>
        <li>Edge-mark shelf and position.  Dry 96 hours.</li>
        <li>Hold 24 hours for second-party review (<xref target="sect-11.3"/>).</li>
        <li>Fire per <xref target="app-B"/>.  The commit point passes approximately 7 hours 10 minutes into the cycle.</li>
        <li>Cool, unload, verify the witness tablet, verify by scan, shelve.</li>
      </ol>
      <t>Per <xref target="sect-8.3"/> this record, occupying one tablet, <bcp14>SHOULD</bcp14> be written in duplicate on a different shelf.  The duplicate carries the same record identifier and its own tablet ordinal.</t>
    </section>
    <section anchor="app-B">
      <name>Reference Firing Profile 0x01</name>
      <t>Cumulative times are approximate and vary with kiln mass.</t>
      <artwork type="ascii-art"><![CDATA[
    Stage  From    To      Rate        Hold      Elapsed
    -----  ------  ------  ----------  --------  ---------
      1    amb.    100 C   50 C/h      --        ~1h 30m
      1a   100 C   100 C   --          2h 00m    ~3h 30m
      2    100 C   600 C   100 C/h     --        ~8h 30m
      3    600 C   1000 C  150 C/h     --        ~11h 10m
      4    1000 C  1000 C  --          0h 20m    ~11h 30m
      5    1000 C  600 C   free        --        ~13h 30m
      5a   600 C   500 C   max 100 C/h --        ~14h 30m
      5b   500 C   below   free        --        ~17h 30m
                   100 C
]]></artwork>
      <t>Constraints:</t>
      <ul>
        <li>Stage 1a hold <bcp14>MUST NOT</bcp14> be shortened.</li>
        <li>Ramp between 550 and 600 C <bcp14>MUST NOT</bcp14> exceed 100 C/h (quartz inversion).</li>
        <li>Cooling between 600 and 500 C <bcp14>MUST NOT</bcp14> exceed 100 C/h (quartz inversion on descent).</li>
        <li>The kiln <bcp14>MUST NOT</bcp14> be opened above 100 C.</li>
        <li>The commit point (550 C) is reached at approximately 7h 10m elapsed.</li>
      </ul>
    </section>
    <section anchor="app-C">
      <name>Prior Art</name>
      <t>The core claims of this document are not novel.  Impressed clay, fired for permanence and shelved for retrieval, is the earliest known bulk data storage technology and was in production use in Mesopotamia for roughly three millennia <xref target="WALKER"/>.  Its retention characteristics are unusually well attested: substantial portions of the Mesopotamian record survive today, and a considerable fraction of what survives was fired accidentally, by the burning of the buildings housing it.  The medium's most catastrophic loss events were, from the archive's perspective, successful commit operations.</t>
      <t>No electronic storage medium has demonstrated retention on this scale, and none is expected to.  The state of the art in digital preservation is not a durable medium but a maintenance discipline: continuous migration, refresh, and integrity checking, performed forever, by an institution that must itself survive forever, using software that must remain trustworthy forever.  CIS observes that this discipline has a single point of failure -- the continued correct behavior of the software and the people operating it -- and proposes removing the software from the retention path entirely.</t>
      <t>The contribution of this document is therefore not the medium.  It is the framing, the frame format, the error correction, and the observation that a storage technology abandoned for being too slow and too heavy has exactly one property that no modern alternative offers, and that this property has recently become valuable again.</t>
    </section>
    <section anchor="app-D">
      <name>Reference Prototype (CIS-P0)</name>
      <t>This appendix specifies a prototype buildable for approximately USD 30 from materials available in any hardware store and any craft shop.  Its purpose is to make the format falsifiable at low cost before anyone procures a kiln or commissions the drum of <xref target="sect-5.5"/>.</t>
      <t>CIS-P0 validates the following: that pin impressions in clay survive handling and read back reliably; that a tablet can be decoded by a person with a lamp or a fingertip and nothing else; that the hand-countable parity of <xref target="sect-6.6"/> catches damage in practice; and whether roller registration is workable or hopeless.</t>
      <t>CIS-P0 does NOT validate the security thesis of this document.  Air- dried clay is not fired clay.  It re-wets, it crumbles, and it can be returned to slip in a bucket of water.  A P0 tablet has none of the immutability properties of <xref target="sect-3.2"/>, and implementers <bcp14>MUST NOT</bcp14> represent P0 results as evidence for them.  P0 tests the format; only a kiln tests the guarantee.  Builders who wish to keep the firing option open <bcp14>SHOULD</bcp14> substitute low-fire terracotta for air-dry clay, which costs less per unit mass and can later be bisque-fired at a community studio; air-dry bodies are typically polymer- or cellulose-bound and will burn out rather than vitrify.</t>
      <t>Materials:</t>
      <ul>
        <li>Hardwood dowel, 25 mm diameter, 900 mm.</li>
        <li>One pool noodle, any diameter between 60 and 90 mm, with an axial hole approximating the dowel diameter.</li>
        <li>Round wooden toothpicks, 250 count.</li>
        <li>Air-dry clay, 1 kg, or low-fire terracotta per the note above.</li>
        <li>A rolling pin, or any smooth cylinder.</li>
        <li>Graph paper or cardstock for the marking template.</li>
      </ul>
      <t>Geometry is not fixed until the noodle is measured, since commodity noodles vary by more than 40 percent in diameter.  Let D be the measured outside diameter and d the inner hole diameter, both in millimetres.  Then:</t>
      <artwork type="ascii-art"><![CDATA[
      Circumference     C = 3.1416 x D
      Columns           N = round(C / 5)
      Realised pitch    p = C / N        (within 0.1 mm of 5 mm)
      Foam wall         w = (D - d) / 2
      Pin cut length    L = w + 4
]]></artwork>
      <t>The prototype pitch is 5 mm rather than the 2.5 mm of <xref target="sect-5.2"/> because a round toothpick is approximately 2.0 mm in diameter.  At 2.5 mm pitch only 0.5 mm of land would remain between adjacent impressions; the rims merge and the foam tears between holes.  At 5 mm the land is 3.0 mm.  This coarsening is the reason <xref target="sect-6.7"/> directs coarse-pitch implementations toward the script tier.</t>
      <t>Pin preparation is the step most often got wrong.  Each toothpick <bcp14>MUST</bcp14> be cut to length L and inserted point first, so that the blunt cut end forms the impression and the inner end bottoms out against the dowel.  The dowel, not the foam, then carries the impression load.  A pin that does not reach the dowel retracts into the foam on first contact and impresses nothing.</t>
      <t>Builders <bcp14>SHOULD</bcp14> construct the flat platen first.  Slice a 200 mm length of noodle lengthwise to yield a flat face, mark the 5 mm grid on it, and insert pins only at cells encoding a one.  A band of 8 rows by 24 columns yields 192 cells, or 24 octets, and consumes roughly 96 toothpicks for typical text.  Pressing straight down removes registration from the experiment, so that a failure is attributable.</t>
      <t>The roller follows.  Wrap the template around the noodle, trim it to exactly C so the ends butt without overlap, and mark through it. Roll exactly one revolution per tablet, against a start line marked on both roller and tablet, which eliminates repeat registration entirely.  Three failure modes recur:</t>
      <ul>
        <li>Clay adheres to the pins.  Dust the roller with cornstarch before each pass.</li>
        <li>Impressions elongate at entry and exit, because pins engage on an arc.  Keep protrusion at 3 to 4 mm.  Cylinder seals exhibited this for three millennia and remained legible.</li>
        <li>Rolling backward smears the impression rims and is unrecoverable.  Lift the roller clear instead.</li>
      </ul>
      <t>The tablet must be leather-hard, per <xref target="sect-4.3"/>: a thumbnail should mark it without clay transferring to the thumb.</t>
      <t>The verification exercise is the part with experimental value, and it <bcp14>MUST NOT</bcp14> be skipped.  Encode a known payload in 9 by 9 parity blocks per <xref target="sect-6.6"/>, then deliberately damage the tablet: abrade single cells, scratch across a row, and chip a corner.  For each, record whether the parity count located the damage, whether the block dot-count caught what parity missed, and whether the payload was recoverable.  A prototype that is only ever read intact has tested nothing that matters.</t>
      <t>Record, at minimum: read-back error rate per tablet by cell; which of pin, clay state, or roll technique was responsible for each failure; encoding time per tablet end to end, which determines whether the roller earns its complexity; and decode time by fingertip against decode time by eye, which bears directly on the throughput argument of <xref target="sect-9.4"/>.</t>
    </section>
    <section anchor="acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t>The author thanks the anonymous scribes of Uruk, Nippur, and Ebla, whose operational experience with this format substantially exceeds that of any contributor to the present document, and whose archives remain readable.</t>
    </section>
  </back>
</rfc>
