peergos-making-yourself-aud.../build/html/iceberg-archive.html
George Lambert 8496ef8338
Some checks are pending
ci / markdown (push) Waiting to run
Put the executive summary on page 2, before the table of contents.
The cover stays page 1. Numbered chapters now start at What Verae
provides. The TOC lists Executive summary at page 2.
2026-09-16 01:21:05 -04:00

259 lines
No EOL
13 KiB
HTML
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<!DOCTYPE html>
<html lang="en" data-content_root="./">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
<title>8. Write-once Iceberg archive &#8212; Making yourself audit-ready with Verae DataCubes</title>
<link rel="stylesheet" type="text/css" href="_static/pygments.css?v=5ecbeea2" />
<link rel="stylesheet" type="text/css" href="_static/basic.css?v=b08954a9" />
<link rel="stylesheet" type="text/css" href="_static/alabaster.css?v=2a97f0c7" />
<link rel="stylesheet" type="text/css" href="_static/verae.css?v=2d7b7068" />
<script src="_static/documentation_options.js?v=250a654d"></script>
<script src="_static/doctools.js?v=fd6eb6e6"></script>
<script src="_static/sphinx_highlight.js?v=6ffebe34"></script>
<link rel="icon" href="_static/VeraeFullLogo.png"/>
<link rel="index" title="Index" href="genindex.html" />
<link rel="search" title="Search" href="search.html" />
<link rel="next" title="9. Architecture for an audit interview" href="architecture.html" />
<link rel="prev" title="7. Verae global timestamping — a cross-blockchain receipt" href="global-timestamping.html" />
<link rel="stylesheet" href="_static/custom.css" type="text/css" />
</head><body>
<div class="document">
<div class="sphinxsidebar" role="navigation" aria-label="Main">
<div class="sphinxsidebarwrapper">
<p class="logo"><a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo of Making yourself audit-ready with Verae DataCubes"/>
</a></p>
<p class="logo">
<a href="index.html">
<img class="logo" src="_static/VeraeFullLogo.png" alt="Logo" />
</a>
</p>
<p class="blurb">Tools for storage, communications, timestamping, verification, and audit — not a certificate.</p>
<search id="searchbox" style="display: none" role="search">
<div class="searchformwrapper">
<form class="search" action="search.html" method="get">
<input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false" placeholder="Search"/>
<input type="submit" value="Go" />
</form>
</div>
</search>
<script>document.getElementById('searchbox').style.display = "block"</script><h3>Navigation</h3>
<p class="caption" role="heading"><span class="caption-text">Contents</span></p>
<ul class="current">
<li class="toctree-l1"><a class="reference internal" href="what-verae-provides.html">1. What Verae provides — and what it does not</a></li>
<li class="toctree-l1"><a class="reference internal" href="datacube-server.html">2. The Verae DataCube Server Solution</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-in-transit.html">3. Secure communications — data in transit</a></li>
<li class="toctree-l1"><a class="reference internal" href="data-at-rest.html">4. Encryption at rest — IPFS blocks and Peergos</a></li>
<li class="toctree-l1"><a class="reference internal" href="timestamped-receipts.html">5. Global timestamped receipts</a></li>
<li class="toctree-l1"><a class="reference internal" href="peergos-eu-evaluations.html">6. Peergos security evaluations in Europe</a></li>
<li class="toctree-l1"><a class="reference internal" href="global-timestamping.html">7. Verae global timestamping — a cross-blockchain receipt</a></li>
<li class="toctree-l1 current"><a class="current reference internal" href="#">8. Write-once Iceberg archive</a><ul>
<li class="toctree-l2"><a class="reference internal" href="#the-deletion-problem">8.1. The deletion problem</a></li>
<li class="toctree-l2"><a class="reference internal" href="#what-write-once-iceberg-means-in-this-solution">8.2. What “write-once Iceberg” means in this solution</a></li>
<li class="toctree-l2"><a class="reference internal" href="#how-cubes-move-into-the-archive">8.3. How cubes move into the archive</a></li>
<li class="toctree-l2"><a class="reference internal" href="#relation-to-classical-worm">8.4. Relation to classical WORM</a></li>
<li class="toctree-l2"><a class="reference internal" href="#what-this-does-and-does-not-satisfy">8.5. What this does, and does not, satisfy</a></li>
</ul>
</li>
<li class="toctree-l1"><a class="reference internal" href="architecture.html">9. Architecture for an audit interview</a></li>
<li class="toctree-l1"><a class="reference internal" href="baa-dpa.html">10. BAAs, DPAs, and ciphertext without host keys</a></li>
<li class="toctree-l1"><a class="reference internal" href="checklist.html">11. Audit-ready checklist</a></li>
<li class="toctree-l1"><a class="reference internal" href="howto.html">12. How to use this briefing</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-james-garfinkel.html">13. James H. Garfinkel</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-stuart-haber.html">14. Stuart Haber</a></li>
<li class="toctree-l1"><a class="reference internal" href="bio-george-lambert.html">15. George Lambert</a></li>
<li class="toctree-l1"><a class="reference internal" href="contact.html">16. Verae Inc — contact</a></li>
</ul>
<div class="relations">
<h3>Related Topics</h3>
<ul>
<li><a href="index.html">Documentation overview</a><ul>
<li>Previous: <a href="global-timestamping.html" title="previous chapter"><span class="section-number">7. </span>Verae global timestamping — a cross-blockchain receipt</a></li>
<li>Next: <a href="architecture.html" title="next chapter"><span class="section-number">9. </span>Architecture for an audit interview</a></li>
</ul></li>
</ul>
</div>
</div>
</div>
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body" role="main">
<section id="write-once-iceberg-archive">
<h1><span class="section-number">8. </span>Write-once Iceberg archive<a class="headerlink" href="#write-once-iceberg-archive" title="Link to this heading"></a></h1>
<section id="the-deletion-problem">
<h2><span class="section-number">8.1. </span>The deletion problem<a class="headerlink" href="#the-deletion-problem" title="Link to this heading"></a></h2>
<p>Encryption at rest stops a disk operator from <strong>reading</strong>.
Hash verification stops a replica from <strong>substituting</strong>.
Timestamped receipts stop a custodian from <strong>back-dating</strong>.
None of those, by themselves, stop a person with legitimate
administrative power from <strong>deleting</strong>.</p>
<p>Deletion is the failure mode that turns a recordkeeping
program into a fine. Off-channel messaging cases at
broker-dealers were, at bottom, failures to <strong>produce</strong>. A
record that existed and was then removed, “cleaned up,” or
rotated out of the only copy is, to an examiner, a record
that cannot be produced.</p>
<p>Compliance therefore needs a tier where <strong>ordinary
administrative power does not include delete</strong>.</p>
</section>
<section id="what-write-once-iceberg-means-in-this-solution">
<h2><span class="section-number">8.2. </span>What “write-once Iceberg” means in this solution<a class="headerlink" href="#what-write-once-iceberg-means-in-this-solution" title="Link to this heading"></a></h2>
<p>DataCubes — the encrypted, hash-chained containers — are
<strong>archived</strong> into an <strong>external, write-once file-storage
solution</strong> built on the <strong>Iceberg</strong> table/file model (a
layout of immutable data files plus a metadata log that
records new snapshots rather than rewriting old ones).</p>
<p>Properties the solution is specified to have:</p>
<ul class="simple">
<li><p><strong>Write once.</strong> A committed archive object is not updated
in place. A correction is a <strong>new</strong> object with a <strong>new</strong>
receipt. The original remains.</p></li>
<li><p><strong>External.</strong> The archive is not the same disk as the
live Peergos instance. Compromising the live server should
not confer delete on the archive.</p></li>
<li><p><strong>Outside any single partys deletion control.</strong> The
customer operator, Verae, and the hosting vendor are each
insufficient, by themselves, to erase a committed archive
file. Practical implementations of that requirement use
some combination of object-lock / WORM flags, dual-control
hold, independent cloud or tape accounts, and contractual
prohibition on early delete — plus the technical fact
that Iceberg snapshots are new files, not overwrites.</p></li>
<li><p><strong>For compliance reasons.</strong> This tier exists because
retention schedules, legal holds, and examiner production
require it — not because it is a convenient backup.</p></li>
</ul>
</section>
<section id="how-cubes-move-into-the-archive">
<h2><span class="section-number">8.3. </span>How cubes move into the archive<a class="headerlink" href="#how-cubes-move-into-the-archive" title="Link to this heading"></a></h2>
<p>A live DataCube is an operational object: it receives new
writes, it is replicated as encrypted IPFS blocks, it is
readable by holders of the right capabilities. On a schedule
and on events (legal hold, period close, exam notice), the
server solution <strong>exports</strong> a cube snapshot:</p>
<ol class="arabic simple">
<li><p>freeze a CID set and cube-chain head;</p></li>
<li><p>confirm Peergos hash verification of every block in the
set;</p></li>
<li><p>register that snapshots hash with Verae timestamping
(first registration of <em>this</em> snapshot);</p></li>
<li><p>write the encrypted snapshot into Iceberg as a new
immutable data file (or set of files) under a snapshot
id that never reuses a previous id;</p></li>
<li><p>record, in admin-history, that the archive job ran, who
authorized it, and which receipt was issued.</p></li>
</ol>
<p>A restore from the archive is the same tamper-evident path
as a restore from IPFS: re-fetch, re-verify hashes, decrypt
only with customer keys.</p>
<p>What “outside the control of any party for deletion” is
and is not
——————————————————-</p>
<p>It is <strong>not</strong> a claim that physics forbids destruction of
every copy in a fire, a court order, or a coordinated
malicious act by every holder of every credential. No
storage system honestly claims that.</p>
<p>It <strong>is</strong> a claim that the <strong>ordinary</strong> delete path — the
button, the <code class="docutils literal notranslate"><span class="pre">rm</span></code>, the lifecycle rule, the “empty trash,”
the support ticket to “please remove that customer folder”
— is not available to any one party acting alone against a
committed archive object. Dual control, object lock, and
separation of the archive account from the live-server
account are the organizational complements to the file
format.</p>
<p>The organizations retention policy still has to name:</p>
<ul class="simple">
<li><p>how long a class of record stays in write-once;</p></li>
<li><p>who can place a legal hold that <strong>extends</strong> that period;</p></li>
<li><p>who, under <strong>what dual control</strong>, may allow a record to
age out <strong>after</strong> the policy period, if aging out is
legally permitted at all.</p></li>
</ul>
<p>Software can refuse a delete API. It cannot write the
retention schedule. Counsel and the records officer do that.</p>
</section>
<section id="relation-to-classical-worm">
<h2><span class="section-number">8.4. </span>Relation to classical WORM<a class="headerlink" href="#relation-to-classical-worm" title="Link to this heading"></a></h2>
<p>Broker-dealer Rule 17a-4 and similar texts speak of
non-rewriteable, non-erasable media, originally meaning
optical WORM, later allowing disk with object-lock semantics
and a designated third party. Veraes public comparison is
that conventional WORM is <strong>immutable by policy</strong> (a vendor
setting), whereas Verae <strong>seals</strong> a record with
cryptographic proof. The Iceberg write-once tier is where
those two ideas meet: the file is not overwritten <strong>and</strong>
the snapshot hash is receipted. An examiner can check the
receipt even if they do not trust the vendors “WORM was
on” screenshot.</p>
</section>
<section id="what-this-does-and-does-not-satisfy">
<h2><span class="section-number">8.5. </span>What this does, and does not, satisfy<a class="headerlink" href="#what-this-does-and-does-not-satisfy" title="Link to this heading"></a></h2>
<p>This is the <strong>technical portion</strong> of retention and
production: committed cubes are not under a single delete
key, they are hash-checkable, and they carry a time of
archival.</p>
<p>It does not satisfy a retention <strong>policy</strong> that was never
written, a legal hold that was never placed, or a production
request that the organization answers from a laptop copy
instead of from the archive. Those are procedures.</p>
</section>
</section>
</div>
</div>
</div>
<div class="clearer"></div>
</div>
<div class="verae-page-footer">
<strong>Verae Inc</strong>
&middot; <a href="https://www.verae.com">https://www.verae.com</a>
&middot; Book a call at <a href="https://www.verae.com">verae.com</a>
&middot; <a href="https://app.verae.com">app.verae.com</a>
</div>
<div class="footer">
&#169;2026, Verae Inc.
</div>
</body>
</html>