ZDDC
ea385b5366
ZDDC — Zero Day Document Control. A file-naming convention plus five single-file HTML tools (archive, transmittal, classifier, mdedit, landing) and an optional Go HTTP server (zddc-server) with ACL and a virtual archive index. Self-contained, offline-capable, dependency-free. See README.md for an overview, AGENTS.md and ARCHITECTURE.md for the build/release/architecture detail, bootstrap/README.md for the two-level deployment install pattern, and zddc/README.md for the HTTP server.
1020 lines
No EOL
50 KiB
HTML
1020 lines
No EOL
50 KiB
HTML
<!DOCTYPE html>
|
||
<html lang="en">
|
||
<head>
|
||
<meta charset="UTF-8">
|
||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||
<title>Technical Reference — Zero Day Document Control (ZDDC)</title>
|
||
<meta name="description" content="Complete specification for the ZDDC filename convention, revision system, status codes, folder structure, and transmittal workflow.">
|
||
<meta property="og:type" content="website">
|
||
<meta property="og:url" content="https://zddc.varasys.io/reference.html">
|
||
<meta property="og:title" content="Technical Reference — ZDDC">
|
||
<meta property="og:description" content="Complete technical reference for ZDDC: naming convention, tracking numbers, revisions, status codes, folder structure, and transmittal workflow.">
|
||
<meta name="theme-color" content="#2a5a8a">
|
||
<link rel="preconnect" href="https://fonts.googleapis.com">
|
||
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
|
||
<link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;500;600;700;800&display=swap" rel="stylesheet">
|
||
<link rel="stylesheet" href="css/style.css">
|
||
</head>
|
||
<body>
|
||
<!-- Header -->
|
||
<header class="site-header">
|
||
<div class="container header-content">
|
||
<a href="/" class="brand">
|
||
<div class="brand-logo">
|
||
<svg viewBox="0 0 24 24">
|
||
<path d="M3 5h18v2H3V5zm0 6h12v2H3v-2zm0 6h6v2H3v-2z" />
|
||
</svg>
|
||
</div>
|
||
<span class="brand-name">ZDDC</span>
|
||
</a>
|
||
<nav class="header-nav">
|
||
<div class="dropdown">
|
||
<button class="dropdown-toggle" type="button" aria-haspopup="true">
|
||
<span>Tools</span>
|
||
<svg viewBox="0 0 24 24" style="width: 14px; height: 14px; fill: currentColor;">
|
||
<path d="M7 10l5 5 5-5z"/>
|
||
</svg>
|
||
</button>
|
||
<div class="dropdown-menu">
|
||
<div class="dropdown-menu__inner">
|
||
<a href="releases/archive_latest.html">
|
||
<svg class="dropdown-menu-icon" viewBox="0 0 24 24"><path d="M20 6H4a2 2 0 00-2 2v10a2 2 0 002 2h16a2 2 0 002-2V8a2 2 0 00-2-2zm0 12H4V8h16v10zM4 2h16v2H4z"/></svg>
|
||
Archive Browser
|
||
</a>
|
||
<a href="releases/transmittal_latest.html">
|
||
<svg class="dropdown-menu-icon" viewBox="0 0 24 24"><path d="M20 4H4c-1.1 0-2 .9-2 2v12c0 1.1.9 2 2 2h16c1.1 0 2-.9 2-2V6c0-1.1-.9-2-2-2zm0 4l-8 5-8-5V6l8 5 8-5v2z"/></svg>
|
||
Transmittal Creator
|
||
</a>
|
||
<a href="releases/classifier_latest.html">
|
||
<svg class="dropdown-menu-icon" viewBox="0 0 24 24"><path d="M3 18h18v-2H3v2zm0-5h18v-2H3v2zm0-7v2h18V6H3z"/></svg>
|
||
Document Classifier
|
||
</a>
|
||
<a href="releases/mdedit_latest.html">
|
||
<svg class="dropdown-menu-icon" viewBox="0 0 24 24"><path d="M3 17.25V21h3.75L17.81 9.94l-3.75-3.75L3 17.25zM20.71 7.04a1 1 0 000-1.41l-2.34-2.34a1 1 0 00-1.41 0l-1.83 1.83 3.75 3.75 1.83-1.83z"/></svg>
|
||
Markdown Editor
|
||
</a>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<a href="reference.html" class="nav-link active">Docs</a>
|
||
</nav>
|
||
</div>
|
||
</header>
|
||
|
||
<!-- Page Title Area -->
|
||
<div class="container" style="margin-top: var(--spacing-xl);">
|
||
<h1>Technical Reference</h1>
|
||
<p style="color: var(--color-text-muted); font-size: 1.125rem; margin-bottom: 0;">
|
||
Complete specification for the ZDDC information management convention. Sections 2–7 cover <strong>file naming</strong>. Sections 8–9 cover <strong>folder naming</strong> and the transmittal workflow.
|
||
</p>
|
||
</div>
|
||
|
||
<!-- Reference Layout: Sidebar TOC + Content -->
|
||
<div class="container ref-layout">
|
||
<!-- Sidebar TOC -->
|
||
<aside class="ref-toc" id="sidebar-toc">
|
||
<h3 class="muted" style="font-size: 0.875rem; font-weight: 600; margin-bottom: var(--spacing-sm);">On this page</h3>
|
||
<nav>
|
||
<div class="ref-toc__item"><a href="#overview" class="ref-toc__link">1. Overview</a></div>
|
||
<div class="ref-toc__item"><a href="#filename-format" class="ref-toc__link">2. Filename format</a></div>
|
||
<div class="ref-toc__item"><a href="#tracking-numbers" class="ref-toc__link">3. Tracking numbers</a></div>
|
||
<div class="ref-toc__item"><a href="#revisions" class="ref-toc__link">4. Revisions</a></div>
|
||
<div class="ref-toc__item"><a href="#draft-prefix" class="ref-toc__link">5. Draft prefix (~)</a></div>
|
||
<div class="ref-toc__item"><a href="#revision-modifiers" class="ref-toc__link">6. Revision modifiers (+)</a></div>
|
||
<div class="ref-toc__item"><a href="#status-codes" class="ref-toc__link">7. Status codes</a></div>
|
||
<div class="ref-toc__item"><a href="#folder-naming" class="ref-toc__link">8. Folder naming</a></div>
|
||
<div class="ref-toc__item"><a href="#transmittal-workflow" class="ref-toc__link">9. Transmittal workflow</a></div>
|
||
<div class="ref-toc__item"><a href="#tools" class="ref-toc__link">10. Tools</a></div>
|
||
</nav>
|
||
</aside>
|
||
|
||
<!-- Main Content -->
|
||
<main class="ref-content">
|
||
<!-- Section 1: Overview -->
|
||
<section id="overview">
|
||
<h2>1. Overview</h2>
|
||
<p>ZDDC — Zero Day Document Control — is an information management convention built on two rules:</p>
|
||
<ul style="margin: var(--spacing-md) 0; padding-left: 1.5rem; color: var(--color-text-muted); line-height: 1.65;">
|
||
<li><strong>File naming</strong> — every deliverable filename encodes its tracking number, revision, status, and title. This makes each file self-describing and independently searchable without opening it.</li>
|
||
<li><strong>Folder naming</strong> — transmittal folders follow the same convention, date-prefixed so they sort chronologically and can be searched by the tracking numbers of the deliverables they contain.</li>
|
||
</ul>
|
||
<p>Together, these two rules mean a plain folder on any shared drive becomes a fully searchable, auditable information management system. No server, no database, no software required to read the archive.</p>
|
||
<p>Because every deliverable is self-describing — its identity, revision, and status encoded in the filename itself — the convention works across organisational boundaries without requiring a shared platform. A project adopting ZDDC can extend the same convention to its clients, subcontractors, vendors, and any other party in the project ecosystem. Each party maintains their own archive; the shared naming convention makes every archive mutually intelligible. Adoption can be voluntary or contractually required. The result is a globally scalable, distributed information management system built on nothing more than agreed file naming and standard directory structures.</p>
|
||
<p>The four tools implement interfaces around this structure — but they're optional. The structure works without them, and any party can participate using only their file browser.</p>
|
||
<div class="highlight-box" style="margin-top: var(--spacing-lg);">
|
||
<p><strong>Convention harmonization.</strong> The convention is designed to be applied at multiple organisational scopes simultaneously — corporate, client, project, department — and the code registries at each scope should be harmonized so they do not conflict. A corporate discipline code such as <code>HR</code> (Human Resources) does not exist at the project level, so there is no clash. But a code that means one thing corporately and something different on a project would create ambiguity in a unified archive. The ideal is that conventions flow down: corporate establishes the master code registry, projects inherit it and extend it only where gaps exist, and no code is reused with a different meaning at a lower scope.</p>
|
||
</div>
|
||
<div class="highlight-box" style="margin-top: var(--spacing-md);">
|
||
<p><strong>A note on terminology.</strong> "Document control" is the traditional term for managing the flow of project information, inherited from an era when a document meant a literal piece of paper. Today the same discipline applies to any file or dataset — PDFs, models, spreadsheets, native CAD files — and the field has increasingly adopted the term <em>information management</em> to reflect this. ZDDC uses the word <strong>deliverable</strong> throughout: anything with a tracking number and a revision history, regardless of file format or medium.</p>
|
||
</div>
|
||
</section>
|
||
|
||
<!-- Section 2: Filename format -->
|
||
<section id="filename-format">
|
||
<h2>2. Filename format</h2>
|
||
<p>The ABNF-like grammar below is a formal machine-readable definition of the filename format — primarily useful for parsers and AI systems. The human-readable explanation of each field follows in the sections below.</p>
|
||
<div class="code-block">
|
||
filename = trackingNumber "_" revision " (" status ") - " title "." extension
|
||
trackingNumber = field *("-" field)
|
||
field = 1*(%x41-5A / %x30-39) ; uppercase alpha or digit; no spaces, no underscores
|
||
revision = ["~"] baseRevision ["+" modifier]
|
||
baseRevision = letterRev / numberRev / dateRev
|
||
letterRev = 1*%x41-5A ; A, B, C… — design/review phase
|
||
numberRev = 1*%x30-39 ; 0, 1, 2… — construction/record phase
|
||
dateRev = 4DIGIT "-" 2DIGIT "-" 2DIGIT ; YYYY-MM-DD — recurring/living deliverables
|
||
modifier = modLetter 1*%x30-39 ; e.g. C1, N2, Q1, B1
|
||
modLetter = "C" / "N" / "Q" / "B"
|
||
status = "IFA" / "IFB" / "IFC" / "IFD" / "IFI" / "IFP" / "IFR" / "IFU" / "REC"
|
||
/ "RSA" / "RSB" / "RSC" / "RSD" / "RSI"
|
||
/ "---"
|
||
; Constraint: RSA / RSB / RSC / RSD / RSI (review status codes) are only valid
|
||
; when modifier is present (i.e. on +C and +Q files).
|
||
; "---" indicates no status assigned; used on working drafts.
|
||
</div>
|
||
<p>Rules:</p>
|
||
<ul style="margin: var(--spacing-md) 0; padding-left: 1.5rem; color: var(--color-text-muted); line-height: 1.65;">
|
||
<li>Tracking number: no spaces, no underscores, hyphens as separators only</li>
|
||
<li>Underscore <code>_</code> separates tracking number from revision</li>
|
||
<li>Revision: no spaces; may include <code>~</code> prefix and/or <code>+</code> modifier</li>
|
||
<li>Space before <code>(status)</code></li>
|
||
<li>Space-dash-space <code> - </code> before title</li>
|
||
<li>Extension is the original file extension, preserved exactly</li>
|
||
</ul>
|
||
|
||
<p>Anatomy (from left to right):</p>
|
||
<div class="filename-anatomy">
|
||
<span class="filename-anatomy__part filename-anatomy__part--tracking">123456-EL-SPC-2623</span>
|
||
<span class="filename-anatomy__part">_</span>
|
||
<span class="filename-anatomy__part filename-anatomy__part--revision">B</span>
|
||
<span class="filename-anatomy__part"> </span>
|
||
<span class="filename-anatomy__part filename-anatomy__part--status">(IFC)</span>
|
||
<span class="filename-anatomy__part"> - </span>
|
||
<span class="filename-anatomy__part filename-anatomy__part--title">Specification For Switchgear.pdf</span>
|
||
</div>
|
||
|
||
<p>Real examples:</p>
|
||
<div class="code-block">
|
||
123456-EM-MDL-0001_A (IFR) - Master Deliverables List.pdf
|
||
123456-EL-SPC-2623_A (IFR) - Specification For Switchgear.pdf
|
||
123456-EL-ARR-0003_A+C1 (RSB) - Electrical Room Equipment Arrangement.pdf
|
||
123456-EL-ARR-0003_0 (IFC) - Electrical Room Equipment Arrangement.pdf
|
||
123456-ME-RFI-0024_A (IFR) - Mechanical Room Size RFI.pdf
|
||
</div>
|
||
</section>
|
||
|
||
<!-- Section 3: Tracking numbers -->
|
||
<section id="tracking-numbers">
|
||
<h2>3. Tracking numbers</h2>
|
||
<p>A tracking number is a deliverable's <strong>permanent identifier</strong>. It never changes — regardless of revision, status, or content changes. Think of it like a passport number: your name can change, your passport number doesn't.</p>
|
||
<p>No spaces, no underscores — hyphens as separators only. Format is yours to define; it must be consistent within the scope it covers.</p>
|
||
|
||
<h3>Field definitions (in order)</h3>
|
||
<p>Tracking numbers are composed of the following fields, in order:</p>
|
||
<ul style="margin: var(--spacing-md) 0; padding-left: 1.5rem; color: var(--color-text-muted); line-height: 1.65;">
|
||
<li><strong>originator</strong> — Organizational unit responsible for the deliverable</li>
|
||
<li><strong>project</strong> — Project identifier; 000000 reserved for corporate-scope deliverables</li>
|
||
<li><strong>[phase]</strong> — Optional phase code (e.g., P1, P2)</li>
|
||
<li><strong>[area]</strong> — Optional area/budget code</li>
|
||
<li><strong>discipline</strong> — Engineering or functional group (e.g., EL, ME, CV, PM)</li>
|
||
<li><strong>type</strong> — Document category within discipline</li>
|
||
<li><strong>sequence</strong> — Zero-padded integer</li>
|
||
<li><strong>[suffix]</strong> — Optional hyphenated suffix for appendices or sheets</li>
|
||
</ul>
|
||
|
||
<h3>Schema rules</h3>
|
||
<p>Choose the schema that matches your structure. The fields within brackets <code>[ ]</code> are optional and must be omitted consistently across all tracking numbers when not used.</p>
|
||
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th scope="col">Schema name</th>
|
||
<th scope="col">Pattern</th>
|
||
<th scope="col">Example</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>Basic</td>
|
||
<td><code>originator-project-discipline-type-sequence</code></td>
|
||
<td><code>ACME-123456-EL-SPC-2623</code></td>
|
||
</tr>
|
||
<tr>
|
||
<td>With Areas</td>
|
||
<td><code>originator-project-area-discipline-type-sequence</code></td>
|
||
<td><code>ACME-123456-B02-EL-SPC-2623</code></td>
|
||
</tr>
|
||
<tr>
|
||
<td>With Phases</td>
|
||
<td><code>originator-phase-project-discipline-type-sequence</code></td>
|
||
<td><code>ACME-P1-123456-EL-SPC-2623</code></td>
|
||
</tr>
|
||
<tr>
|
||
<td>Corporate</td>
|
||
<td><code>originator-000000-discipline-type-sequence</code></td>
|
||
<td><code>ACME-000000-QA-PROC-0042</code></td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<div class="highlight-box" style="margin-top: var(--spacing-lg);">
|
||
<p><strong>Rule: 000000 placeholder.</strong> The Corporate schema uses <code>000000</code> as a reserved project placeholder, indicating the document belongs to the originator's corporate library rather than a specific project. The same originator code and discipline/type conventions apply, so corporate documents sort naturally alongside project documents in a unified archive.</p>
|
||
</div>
|
||
|
||
<h3>Discipline codes</h3>
|
||
<p>Discipline codes identify the engineering or functional group responsible for the document. They are defined per project and should be documented in the Master Deliverables List.</p>
|
||
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th scope="col">Discipline</th>
|
||
<th scope="col">Description</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td><code>EL</code></td>
|
||
<td>Electrical</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>ME</code></td>
|
||
<td>Mechanical</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>CV</code></td>
|
||
<td>Civil</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>PM</code></td>
|
||
<td>Project Management</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>QA</code></td>
|
||
<td>Quality Assurance</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>PC</code></td>
|
||
<td>Procurement</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<h3>Type codes</h3>
|
||
<p>Type codes identify the document category within a discipline. Type codes are scoped per discipline — the same code may mean different things in different disciplines.</p>
|
||
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th scope="col">Discipline</th>
|
||
<th scope="col">Type</th>
|
||
<th scope="col">Description</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td rowspan="3"><code>EL</code></td>
|
||
<td><code>SPC</code></td>
|
||
<td>Specification</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>DWG</code></td>
|
||
<td>Drawing</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>RPT</code></td>
|
||
<td>Report</td>
|
||
</tr>
|
||
<tr>
|
||
<td rowspan="2"><code>ME</code></td>
|
||
<td><code>SPC</code></td>
|
||
<td>Specification</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>MEMO</code></td>
|
||
<td>Memorandum</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>PM</code></td>
|
||
<td><code>MOM</code></td>
|
||
<td>Minutes of Meeting</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<p><strong>Rule: Avoid ambiguity.</strong> On multi-discipline projects, type codes with overlapping meanings should be avoided or a cross-discipline registry should be agreed upon and documented.</p>
|
||
|
||
<h3>Sequence numbers</h3>
|
||
<p>Sequence numbers make the tracking number unique given all the preceding fields. Use zero-padded integers (e.g., <code>0001</code>, <code>0042</code>).</p>
|
||
<p>A suffix separated by a hyphen can denote appendices or sheets that are structural parts of the same deliverable:</p>
|
||
<div class="code-block">
|
||
ACME-123456-EL-SPC-2623 ← base document
|
||
ACME-123456-EL-SPC-2623-A ← Appendix A
|
||
ACME-123456-EL-SPC-2623-B ← Appendix B
|
||
ACME-123456-EL-SPC-2623-01 ← Sheet 1 of a multi-sheet drawing
|
||
ACME-123456-EL-SPC-2623-02 ← Sheet 2</div>
|
||
<div class="highlight-box" style="margin-top: var(--spacing-md);">
|
||
<p><strong>Suffix vs. attachment rule:</strong> Use a suffix only for content that is a structural part of the deliverable (appendices, sheets). Files that accompany but are independent of the deliverable should be filed as separate documents with their own tracking numbers — not as suffixes.</p>
|
||
</div>
|
||
|
||
<div class="highlight-box" style="margin-top: var(--spacing-md);">
|
||
<p><strong>Search benefit:</strong> Because discipline and type are embedded in every filename, your file browser's search box is already a filter. Search <code>EL-SPC</code> to find all electrical specifications. Sort by name and every document groups with its full history.</p>
|
||
</div>
|
||
</section>
|
||
|
||
<!-- Section 4: Revisions -->
|
||
<section id="revisions">
|
||
<h2>4. Revisions</h2>
|
||
<p>The revision field indicates the iteration stage of the deliverable. It consists of an optional <code>~</code> draft prefix, a base revision, and an optional <code>+</code> modifier.</p>
|
||
|
||
<h3>Base revision types</h3>
|
||
<p>Base revisions are one of three types: letter revisions (A, B, C...), number revisions (0, 1, 2...), or date-based revisions.</p>
|
||
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th scope="col">Type</th>
|
||
<th scope="col">Format</th>
|
||
<th scope="col">Phase</th>
|
||
<th scope="col">Sort behavior</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>Letter revision</td>
|
||
<td><code>[A-Z]+</code></td>
|
||
<td>Design/review phase</td>
|
||
<td>Sorts before number revisions ( lexical)</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Number revision</td>
|
||
<td><code>[0-9]+</code></td>
|
||
<td>Construction/record phase</td>
|
||
<td>Sorts after letter revisions ( lexical)</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Date revision</td>
|
||
<td><code>YYYY-MM-DD</code></td>
|
||
<td>Recurring or living documents</td>
|
||
<td>Sorts chronologically (ISO 8601)</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<h3>Letter revisions (design/review phase)</h3>
|
||
<p>Letter revisions are used during the design and review phase. They sort lexically, so A < B < C, etc.</p>
|
||
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th scope="col">Revision</th>
|
||
<th scope="col">Meaning</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td><code>A</code></td>
|
||
<td>First issued revision</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>B</code></td>
|
||
<td>Second issued revision</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>C</code>, <code>D</code>, …</td>
|
||
<td>Subsequent revisions</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<h3>Number revisions (construction/record phase)</h3>
|
||
<p>Number revisions are used after approval, typically at the Issued For Construction (IFC) stage. They sort lexically after letter revisions.</p>
|
||
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th scope="col">Revision</th>
|
||
<th scope="col">Meaning</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td><code>0</code></td>
|
||
<td>First numeric revision (typically after approval, IFC)</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>1</code>, <code>2</code>, …</td>
|
||
<td>Subsequent numeric revisions</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<h3>Date-based revisions</h3>
|
||
<p>Date-based revisions apply to documents that are updated in place under a single permanent tracking number, where the date of the revision is the most meaningful piece of information a reader needs.</p>
|
||
|
||
<p><strong>Rule: Two use cases for date-based revisions:</strong></p>
|
||
<ol style="margin: var(--spacing-md) 0 0 1.5rem; color: var(--color-text-muted); line-height: 1.65;">
|
||
<li><strong>Recurring documents</strong> — issued on a fixed cadence (e.g., meeting minutes). The tracking number is fixed; the revision identifies which occurrence.</li>
|
||
<li><strong>Living documents</strong> — issued on demand (e.g., schedules, risk registers). The tracking number is fixed; the revision indicates freshness.</li>
|
||
</ol>
|
||
|
||
<p><strong>Rule: Contra-indication.</strong> Documents that get a new tracking number each period (e.g., monthly progress reports where each month is a distinct deliverable) use normal letter and number revisions, not date-based revisions.</p>
|
||
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th scope="col">Cadence</th>
|
||
<th scope="col">Revision format</th>
|
||
<th scope="col">Example</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>Quarterly</td>
|
||
<td><code>YYQX</code></td>
|
||
<td><code>25Q1</code> = Q1 2025</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Monthly</td>
|
||
<td><code>YYMM</code></td>
|
||
<td><code>2503</code> = March 2025</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Twice monthly</td>
|
||
<td><code>YYMM-XX</code></td>
|
||
<td><code>2503-01</code>, <code>2503-02</code></td>
|
||
</tr>
|
||
<tr>
|
||
<td>Daily</td>
|
||
<td><code>YYYY-MM-DD</code></td>
|
||
<td><code>2025-03-14</code> = 14 March 2025</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<div class="code-block" style="margin-top: var(--spacing-md);">
|
||
<!-- Standing meeting minutes — monthly cadence -->
|
||
ACME-123456-PM-MOM-0001_2503 (IFI) - Project Steering Committee Minutes.pdf
|
||
ACME-123456-PM-MOM-0001_2504 (IFI) - Project Steering Committee Minutes.pdf
|
||
ACME-123456-PM-MOM-0001_2505 (IFI) - Project Steering Committee Minutes.pdf
|
||
|
||
<!-- Project schedule — issued on demand, date shows freshness -->
|
||
ACME-123456-PM-SCH-0001_2503-07 (IFI) - Master Project Schedule.pdf
|
||
ACME-123456-PM-SCH-0001_2503-21 (IFI) - Master Project Schedule.pdf
|
||
ACME-123456-PM-SCH-0001_2505-14 (IFI) - Master Project Schedule.pdf
|
||
|
||
<!-- Critical milestones — issued on demand -->
|
||
ACME-123456-PM-MLT-0001_2503-07 (IFI) - Critical Milestones Table.pdf
|
||
ACME-123456-PM-MLT-0001_2506-02 (IFI) - Critical Milestones Table.pdf</div>
|
||
<p>Date-based revisions sort lexically in the correct chronological order — your file browser will list them in date order when sorted by name.</p>
|
||
</section>
|
||
|
||
<!-- Section 5: Draft prefix (~) -->
|
||
<section id="draft-prefix">
|
||
<h2>5. Draft prefix (<code>~</code>)</h2>
|
||
<p>The <code>~</code> prefix indicates a working draft, not yet formally issued.</p>
|
||
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th scope="col">Field</th>
|
||
<th scope="col">Meaning</th>
|
||
<th scope="col">Effect on filename</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>~ position</td>
|
||
<td>Prepends the base revision</td>
|
||
<td><code>_<code>~A</code>, <code>~B</code></code></td>
|
||
</tr>
|
||
<tr>
|
||
<td>Sort position</td>
|
||
<td>Sorts after the base revision</td>
|
||
<td><code>~B</code> sorts after <code>B</code></td>
|
||
</tr>
|
||
<tr>
|
||
<td>Status field</td>
|
||
<td>Intended status when issued</td>
|
||
<td>Shows what status the draft will carry when issued</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<p>Examples:</p>
|
||
<div class="code-block">
|
||
123456-EL-SPC-2623_~A (IFR) - Working draft — will be issued for review
|
||
123456-EL-SPC-2623_A (IFR) - Rev A — formally issued for review
|
||
123456-EL-SPC-2623_~B (IFC) - Working draft of Rev B, for construction
|
||
123456-EL-SPC-2623_B (IFA) - Rev B — issued for approval
|
||
123456-EL-SPC-2623_~0 (IFC) - Working draft ofRev 0, construction issue
|
||
123456-EL-SPC-2623_0 (IFC) - Rev 0 — Issued For Construction</div>
|
||
</section>
|
||
|
||
<!-- Section 6: Revision modifiers (+) -->
|
||
<section id="revision-modifiers">
|
||
<h2>6. Revision modifiers (<code>+</code>)</h2>
|
||
<p>Revision modifiers associate a file with a base revision without incrementing the revision. Used for comments, backup material, native source files, and quality records. Sorts after the base revision in alphabetical order.</p>
|
||
|
||
<p>The number after the modifier letter — <code>+C1</code>, <code>+C2</code>, and so on — is simply a sequence counter for uniqueness. If two reviewers each return a separate set of comments, they become <code>+C1</code> and <code>+C2</code>. The same applies to all modifiers: the number distinguishes multiple files of the same type attached to the same revision.</p>
|
||
|
||
<h3>Modifier table</h3>
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th scope="col">Modifier</th>
|
||
<th scope="col">Meaning</th>
|
||
<th scope="col">Typical status</th>
|
||
<th scope="col">Sort position</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td><code>+C1</code>, <code>+C2</code></td>
|
||
<td>Comments on the base revision</td>
|
||
<td><span class="status-badge">RSA</span> <span class="status-badge">RSB</span> <span class="status-badge">RSC</span> <span class="status-badge">RSD</span></td>
|
||
<td>After base revision</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>+B1</code>, <code>+B2</code></td>
|
||
<td>Backup material supporting base content</td>
|
||
<td><span class="status-badge">IFI</span></td>
|
||
<td>After base revision</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>+N1</code>, <code>+N2</code></td>
|
||
<td>Native format files (editable source, e.g., CAD or source files)</td>
|
||
<td><span class="status-badge">IFI</span></td>
|
||
<td>After base revision</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>+Q1</code>, <code>+Q2</code></td>
|
||
<td>Quality check records</td>
|
||
<td><span class="status-badge">RSA</span> <span class="status-badge">RSI</span></td>
|
||
<td>After base revision</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<div style="margin-top: var(--spacing-xl); border-top: 1px solid var(--color-border); padding-top: var(--spacing-lg);">
|
||
<p style="margin-bottom: var(--spacing-md); color: var(--color-text-muted);">Every project team already does the things described below. ZDDC just gives each one a consistent place in the filename. Start with the formal revisions — the rest follows naturally.</p>
|
||
|
||
<h4 style="font-size: 1rem; font-weight: 600; margin-bottom: var(--spacing-sm); color: var(--color-text);">The formal revisions</h4>
|
||
<div style="overflow-x: auto;">
|
||
<table style="margin-top: 0;">
|
||
<thead>
|
||
<tr>
|
||
<th scope="col">Filename</th>
|
||
<th scope="col">What it is</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td><code>123456-EL-SPC-2623_~A (IFR)</code></td>
|
||
<td>Working draft — intended for issue for review</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>123456-EL-SPC-2623_A (IFR)</code></td>
|
||
<td>Rev A — formally issued for review</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>123456-EL-SPC-2623_~B (IFR)</code></td>
|
||
<td>Working draft of Rev B, incorporating reviewer comments</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>123456-EL-SPC-2623_B (IFA)</code></td>
|
||
<td>Rev B — issued for approval</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>123456-EL-SPC-2623_~0 (IFC)</code></td>
|
||
<td>Working draft of construction issue</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>123456-EL-SPC-2623_0 (IFC)</code></td>
|
||
<td>Rev 0 — Issued For Construction</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>123456-EL-SPC-2623_~1 (IFC)</code></td>
|
||
<td>Working construction revision — field change</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>123456-EL-SPC-2623_1 (IFC)</code></td>
|
||
<td>Rev 1 — construction revision issued</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>123456-EL-SPC-2623_~2 (REC)</code></td>
|
||
<td>Working as-built — being prepared for record</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>123456-EL-SPC-2623_2 (REC)</code></td>
|
||
<td>Rev 2 — Issued For Record (as-built)</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
|
||
<h4 style="font-size: 1rem; font-weight: 600; margin-top: var(--spacing-xl); margin-bottom: var(--spacing-sm); color: var(--color-text);">+ Native source files</h4>
|
||
<p style="margin-top: var(--spacing-sm); margin-bottom: var(--spacing-sm); color: var(--color-text-muted); font-size: 0.9rem;">Native source files are saved alongside the published PDF, tied to exactly the revision they produced.</p>
|
||
<div style="overflow-x: auto;">
|
||
<table style="margin-top: var(--spacing-sm);">
|
||
<thead>
|
||
<tr>
|
||
<th scope="col">Filename</th>
|
||
<th scope="col">What it is</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td><code>123456-EL-SPC-2623_A+N1 (IFI)</code></td>
|
||
<td>Native source files for Rev A (e.g., CAD or Word ZIP)</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>123456-EL-SPC-2623_B+N1 (IFI)</code></td>
|
||
<td>Native source files for Rev B</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>123456-EL-SPC-2623_0+N1 (IFI)</code></td>
|
||
<td>Native source files for Rev 0</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>123456-EL-SPC-2623_1+N1 (IFI)</code></td>
|
||
<td>Native source files for Rev 1</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>123456-EL-SPC-2623_2+N1 (IFI)</code></td>
|
||
<td>Native source files for as-built record</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
|
||
<h4 style="font-size: 1rem; font-weight: 600; margin-top: var(--spacing-xl); margin-bottom: var(--spacing-sm); color: var(--color-text);">+ Internal quality checks</h4>
|
||
<p style="margin-top: var(--spacing-sm); margin-bottom: var(--spacing-sm); color: var(--color-text-muted); font-size: 0.9rem;">Quality check records are kept in the archive, attached to the revision they checked, without cluttering the main sequence.</p>
|
||
<div style="overflow-x: auto;">
|
||
<table style="margin-top: var(--spacing-sm);">
|
||
<thead>
|
||
<tr>
|
||
<th scope="col">Filename</th>
|
||
<th scope="col">What it is</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td><code>123456-EL-SPC-2623_A+Q1 (RSA)</code></td>
|
||
<td>Quality check of Rev A draft — approved</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>123456-EL-SPC-2623_B+Q1 (RSA)</code></td>
|
||
<td>Quality check of Rev B draft — approved</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>123456-EL-SPC-2623_0+Q1 (RSA)</code></td>
|
||
<td>Quality check of Rev 0 — approved</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>123456-EL-SPC-2623_1+Q1 (RSA)</code></td>
|
||
<td>Quality check of Rev 1 — approved</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>123456-EL-SPC-2623_2+Q1 (RSA)</code></td>
|
||
<td>Quality check of as-built — approved</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
|
||
<h4 style="font-size: 1rem; font-weight: 600; margin-top: var(--spacing-xl); margin-bottom: var(--spacing-sm); color: var(--color-text);">+ Client or reviewer comments</h4>
|
||
<p style="margin-top: var(--spacing-sm); margin-bottom: var(--spacing-sm); color: var(--color-text-muted); font-size: 0.9rem;">Comments come back from reviewers anyway — as marked-up PDFs, emails, spreadsheets. The <code>+C</code> modifier gives each set of comments a place in the archive alongside the revision it applies to. The number suffix (<code>+C1</code>, <code>+C2</code>…) simply distinguishes between multiple sets of comments on the same revision.</p>
|
||
<div style="overflow-x: auto;">
|
||
<table style="margin-top: var(--spacing-sm);">
|
||
<thead>
|
||
<tr>
|
||
<th scope="col">Filename</th>
|
||
<th scope="col">What it is</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td><code>123456-EL-SPC-2623_A+C1 (RSB)</code></td>
|
||
<td>Reviewer comments on Rev A — incorporate and resubmit</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>123456-EL-SPC-2623_B+C1 (RSA)</code></td>
|
||
<td>Reviewer comments on Rev B — approved, no further review</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</div>
|
||
</div>
|
||
</section>
|
||
|
||
<!-- Section 7: Status codes -->
|
||
<section id="status-codes">
|
||
<h2>7. Status codes</h2>
|
||
<p>Status codes indicate the approval or review state of a deliverable. They appear in parentheses in the filename.</p>
|
||
|
||
<h3>Primary status codes (closed set)</h3>
|
||
<p>Primary status codes are used on formally issued deliverables. The status field in a draft filename shows the <em>intended</em> status when issued.</p>
|
||
|
||
<p><strong>Rule: No DFT status.</strong> Draft status is not encoded as a status field. It is indicated by the <code>~</code> prefix on the revision, and <em>must also be physically marked</em> in the file itself (e.g., a DRAFT watermark or stamp).</p>
|
||
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th scope="col">Code</th>
|
||
<th scope="col">Meaning</th>
|
||
<th scope="col">Action required</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td><span class="status-badge">IFA</span></td>
|
||
<td>Issued For Approval</td>
|
||
<td>Formal sign-off required before proceeding</td>
|
||
</tr>
|
||
<tr>
|
||
<td><span class="status-badge">IFB</span></td>
|
||
<td>Issued For Bid</td>
|
||
<td>Price to this — binding scope</td>
|
||
</tr>
|
||
<tr>
|
||
<td><span class="status-badge">IFC</span></td>
|
||
<td>Issued For Construction</td>
|
||
<td>Build to this — approved</td>
|
||
</tr>
|
||
<tr>
|
||
<td><span class="status-badge">IFD</span></td>
|
||
<td>Issued For Design</td>
|
||
<td>Rely-upon inputs for downstream design. Confirmed items may be used to proceed. Items marked as holds are issued for awareness only and must not be relied upon until the hold is lifted.</td>
|
||
</tr>
|
||
<tr>
|
||
<td><span class="status-badge">IFI</span></td>
|
||
<td>Issued For Information</td>
|
||
<td>No action required — for awareness only</td>
|
||
</tr>
|
||
<tr>
|
||
<td><span class="status-badge">IFP</span></td>
|
||
<td>Issued For Purchase</td>
|
||
<td>Procurement may proceed to this version</td>
|
||
</tr>
|
||
<tr>
|
||
<td><span class="status-badge">IFR</span></td>
|
||
<td>Issued For Review</td>
|
||
<td>Please review and return comments</td>
|
||
</tr>
|
||
<tr>
|
||
<td><span class="status-badge">IFU</span></td>
|
||
<td>Issued For Use</td>
|
||
<td>Approved for operational use</td>
|
||
</tr>
|
||
<tr>
|
||
<td><span class="status-badge">REC</span></td>
|
||
<td>Issued For Record</td>
|
||
<td>Final as-built or archived version</td>
|
||
</tr>
|
||
<tr>
|
||
<td><span class="status-badge">---</span></td>
|
||
<td>No status</td>
|
||
<td>Working version — status not yet assigned</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<h3>Review status codes (closed set)</h3>
|
||
<p>Review status codes are used as the status on <code>+C</code> (client or reviewer comments) and <code>+Q</code> (internal quality check) files. They record the outcome of the review — what the reviewer concluded and what action is required on the base document.</p>
|
||
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th scope="col">Code</th>
|
||
<th scope="col">Meaning</th>
|
||
<th scope="col">Consequence</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td><span class="status-badge">RSA</span></td>
|
||
<td>Review Status A</td>
|
||
<td>No comments — approved as submitted</td>
|
||
</tr>
|
||
<tr>
|
||
<td><span class="status-badge">RSB</span></td>
|
||
<td>Review Status B</td>
|
||
<td>Incorporate comments, resubmit for record</td>
|
||
</tr>
|
||
<tr>
|
||
<td><span class="status-badge">RSC</span></td>
|
||
<td>Review Status C</td>
|
||
<td>Incorporate comments, resubmit before proceeding</td>
|
||
</tr>
|
||
<tr>
|
||
<td><span class="status-badge">RSD</span></td>
|
||
<td>Review Status D</td>
|
||
<td>Rejected — resubmit per stated requirements</td>
|
||
</tr>
|
||
<tr>
|
||
<td><span class="status-badge">RSI</span></td>
|
||
<td>No Review Required</td>
|
||
<td>Supplemental information only</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<h3>Typical review cycles</h3>
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th scope="col">Cycle type</th>
|
||
<th scope="col">Sequence</th>
|
||
<th scope="col">Notes</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>Typical</td>
|
||
<td><code>IFR</code> → <code>RSA</code></td>
|
||
<td>Reviewer approved without comments</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Extended</td>
|
||
<td><code>IFR</code> → <code>RSC</code> → <code>IFA</code> → <code>RSB</code></td>
|
||
<td>Comments require resubmission, then approval, then final record</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
</section>
|
||
|
||
<!-- Section 8: Folder naming -->
|
||
<section id="folder-naming">
|
||
<h2>8. Folder naming</h2>
|
||
<p>Transmittal folders follow the same convention as filenames — date-prefixed so folders sort chronologically:</p>
|
||
|
||
<div class="code-block">
|
||
folder = date "_" trackingNumber " (" status ") - " title
|
||
date = 4DIGIT "-" 2DIGIT "-" 2DIGIT
|
||
</div>
|
||
<p>Format: <code>YYYY-MM-DD_trackingNumber (status) - title</code></p>
|
||
|
||
<div class="code-block">
|
||
2025-10-31_123456-EM-SUB-0001 (IFR) - General Arrangement for Review
|
||
2025-10-31_123456-EL-TRN-0043 (IFC) - Electrical Design Issued For Construction</div>
|
||
|
||
<h3>Two tracking numbers in play</h3>
|
||
<p>Two tracking numbers are always in play:</p>
|
||
<ul style="margin: var(--spacing-md) 0; padding-left: 1.5rem; color: var(--color-text-muted); line-height: 1.65;">
|
||
<li><strong>Deliverable tracking number</strong> — embedded in each filename; permanent; unchanged across all packages it ever travels in</li>
|
||
<li><strong>Submittal package tracking number</strong> — in the folder name; reused by the response (same number, different date/status/optionally different title); a resubmittal gets a NEW tracking number</li>
|
||
</ul>
|
||
|
||
<h3>Submittal, response, and resubmittal rules</h3>
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th scope="col">Action</th>
|
||
<th scope="col">Submittal tracking number</th>
|
||
<th scope="col">Revision date</th>
|
||
<th scope="col">Status</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>Initial submittal</td>
|
||
<td>New tracking number</td>
|
||
<td>Issue date</td>
|
||
<td>Issued For Review</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Response</td>
|
||
<td>Reuses original tracking number</td>
|
||
<td>Response date</td>
|
||
<td>Review outcome (RSA, RSC, RSB, or RSD)</td>
|
||
</tr>
|
||
<tr>
|
||
<td>Resubmittal</td>
|
||
<td>New tracking number</td>
|
||
<td>Resubmittal date</td>
|
||
<td>Typically Issued For Approval</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<div class="code-block">
|
||
<!-- Submittal package SUB-0026 contains twenty drawings -->
|
||
2025-10-31_123456-ST-SUB-0026 (IFR) - Structural Steelwork for Review
|
||
2025-11-14_123456-ST-SUB-0026 (RSC) - Structural Steelwork for Review
|
||
|
||
<!-- Resubmittal SUB-0031 contains only the one drawing that needed revision -->
|
||
2025-12-01_123456-ST-SUB-0031 (IFA) - Column Base Plate Detail — Resubmittal
|
||
2025-12-09_123456-ST-SUB-0031 (RSB) - Column Base Plate Detail — Resubmittal</div>
|
||
<p>The status on a package folder is the lowest review outcome across all deliverables inside it. It summarises the package; it does not override the outcome of any individual deliverable.</p>
|
||
|
||
<h3>Tracking individual deliverables</h3>
|
||
<p>Search the deliverable's own tracking number across all transmittal folders in <code>issued/</code> and <code>received/</code>. Every folder containing that number is part of its history: which package first carried it, what the response was, which resubmittal carried the revision, and what the final outcome was.</p>
|
||
</section>
|
||
|
||
<!-- Section 9: Transmittal workflow -->
|
||
<section id="transmittal-workflow">
|
||
<h2>9. Transmittal workflow</h2>
|
||
<p>Each third party (client, contractor, vendor, etc.) has a separate subfolder. All communication with that party lives in one place.</p>
|
||
|
||
<div class="code-block">
|
||
project/
|
||
{party-name}/
|
||
incoming/ ← transmittals received from party, awaiting acceptance
|
||
received/ ← permanent record of accepted transmittals from party
|
||
issued/ ← your copies of transmittals sent to party
|
||
</div>
|
||
<p><strong>5-step workflow:</strong></p>
|
||
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th scope="col">Step</th>
|
||
<th scope="col">Actor</th>
|
||
<th scope="col">Action</th>
|
||
<th scope="col">Verification</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td>1</td>
|
||
<td>Sender</td>
|
||
<td>Creates transmittal folder and uploads to receiver's <code>incoming/</code></td>
|
||
<td>Filenames match ZDDC convention</td>
|
||
</tr>
|
||
<tr>
|
||
<td>2</td>
|
||
<td>Receiver</td>
|
||
<td>Validates filenames, completeness, and SHA-256 checksums</td>
|
||
<td>All checksums match</td>
|
||
</tr>
|
||
<tr>
|
||
<td>3</td>
|
||
<td>Receiver</td>
|
||
<td>Moves folder from <code>incoming/</code> to <code>received/</code></td>
|
||
<td>Permanent record established</td>
|
||
</tr>
|
||
<tr>
|
||
<td>4</td>
|
||
<td>Receiver</td>
|
||
<td>Saves acknowledgment with SHA-256 hashes</td>
|
||
<td>"Official" version recorded</td>
|
||
</tr>
|
||
<tr>
|
||
<td>5</td>
|
||
<td>Receiver</td>
|
||
<td>Notifies sender and distribution list</td>
|
||
<td>Hashes included in notification</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<div class="highlight-box" style="margin-top: var(--spacing-lg);">
|
||
<p><strong>What SHA-256 gives you:</strong> Mathematical fingerprint of file contents. Single byte change → hash changes. When acknowledgment records hashes, you can verify years later that the file is identical to what was transmitted.</p>
|
||
</div>
|
||
</section>
|
||
|
||
<!-- Section 10: Tools -->
|
||
<section id="tools">
|
||
<h2>10. Tools</h2>
|
||
<p>Four single-file HTML applications — each is complete and self-contained. Save them locally and they work forever, without internet, without updates, without a subscription.</p>
|
||
|
||
<div style="display: grid; grid-template-columns: repeat(auto-fit, minmax(280px, 1fr)); gap: var(--spacing-lg); margin-top: var(--spacing-lg);">
|
||
<a href="releases/archive_latest.html" class="tool-card" style="text-decoration: none; display: block;">
|
||
<div class="tool-card__title">Archive Browser</div>
|
||
<div class="tool-card__desc">Browse, search, filter your project folder. Filter by tracking number, discipline, revision, status, or free text. Group by transmittal. Download selected files as ZIP.</div>
|
||
<div class="tool-card__link">Open Archive Browser</div>
|
||
</a>
|
||
|
||
<a href="releases/transmittal_latest.html" class="tool-card" style="text-decoration: none; display: block;">
|
||
<div class="tool-card__title">Transmittal Creator</div>
|
||
<div class="tool-card__desc">Fill in metadata, drag in files, publish a self-contained HTML transmittal record with SHA-256 checksums. Supports digital signatures. The published file IS the transmittal record.</div>
|
||
<div class="tool-card__link">Create Transmittal</div>
|
||
</a>
|
||
|
||
<a href="releases/classifier_latest.html" class="tool-card" style="text-decoration: none; display: block;">
|
||
<div class="tool-card__title">Document Classifier</div>
|
||
<div class="tool-card__desc">Spreadsheet-like interface for bulk-renaming files to ZDDC format. Copy/paste with Excel. Point it at a folder, fill in the columns, save all at once.</div>
|
||
<div class="tool-card__link">Run Classifier</div>
|
||
</a>
|
||
|
||
<a href="releases/mdedit_latest.html" class="tool-card" style="text-decoration: none; display: block;">
|
||
<div class="tool-card__title">Markdown Editor</div>
|
||
<div class="tool-card__desc">Browser-based markdown editor with live preview, YAML front matter support, and table of contents. Direct local file access via File System Access API.</div>
|
||
<div class="tool-card__link">Open Editor</div>
|
||
</a>
|
||
</div>
|
||
|
||
<p style="margin-top: var(--spacing-xl); color: var(--color-text-muted);">Local directory access relies on the <a href="https://www.chromium.org/Home/">Chromium</a>-based browser File System Access API. It does not work in Firefox or Safari.</p>
|
||
</section>
|
||
</main>
|
||
</div>
|
||
|
||
<!-- Footer -->
|
||
<footer class="site-footer">
|
||
<div class="container footer-content">
|
||
<span>ZDDC is open source — <a href="https://codeberg.org/VARASYS/ZDDC">codeberg.org/VARASYS/ZDDC</a></span>
|
||
</div>
|
||
</footer>
|
||
|
||
<script src="js/layout.js"></script>
|
||
</body>
|
||
</html> |