ZDDC
079763f5ae
All checks were successful
Deploy content to live site / deploy (push) Successful in 2s
Reshape the landing page around three tools with Browse as the hero — it needs nothing to run; .zddc files only add labels, per-folder tools, permissions, and transmittal actions. Surface Classify (assign tracking numbers, build transmittals) as its own tool; keep Archive as the read-only access UI. Condense the zddc-server section and reword it as an optional web-server app. reference.html: list all three tools (Section 11) and document the TBD status code (in shared/zddc.js, used for forecast/planned folders) in the ABNF grammar and the status table. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
1319 lines
No EOL
72 KiB
HTML
1319 lines
No EOL
72 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">
|
||
<svg class="brand-logo" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 64 64" aria-hidden="true">
|
||
<rect width="64" height="64" rx="12" fill="#1e3a5f"/>
|
||
<g fill="#fff">
|
||
<rect x="14" y="18" width="36" height="7"/>
|
||
<polygon points="43,25 50,25 21,43 14,43"/>
|
||
<rect x="14" y="43" width="36" height="7"/>
|
||
</g>
|
||
</svg>
|
||
<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/browse.html">
|
||
<svg class="dropdown-menu-icon" viewBox="0 0 24 24"><path d="M10 4H4c-1.1 0-2 .9-2 2v12c0 1.1.9 2 2 2h16c1.1 0 2-.9 2-2V8c0-1.1-.9-2-2-2h-8l-2-2z"/></svg>
|
||
Browse
|
||
</a>
|
||
<a href="releases/classifier.html">
|
||
<svg class="dropdown-menu-icon" viewBox="0 0 24 24"><path d="M3 5h18v2H3V5zm0 6h18v2H3v-2zm0 6h12v2H3v-2z"/></svg>
|
||
Classify
|
||
</a>
|
||
<a href="releases/archive.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
|
||
</a>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<a href="reference.html" class="nav-link active">Docs</a>
|
||
<a href="releases/" class="nav-link">Releases</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="#bootstrap" class="ref-toc__link">10. zddc-server bootstrap</a></div>
|
||
<div class="ref-toc__item"><a href="#tools" class="ref-toc__link">11. 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 tools below 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"
|
||
/ "TBD" / "---"
|
||
; Constraint: RSA / RSB / RSC / RSD / RSI (review status codes) are only valid
|
||
; when modifier is present (i.e. on +C and +Q files).
|
||
; "TBD" marks a planned deliverable whose issue status is not yet decided.
|
||
; "---" 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-ELY-0003_A+C1 (RSB) - Electrical Room Equipment Arrangement.pdf
|
||
123456-EL-ELY-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; a recognizable placeholder is used for corporate-scope deliverables</li>
|
||
<li><strong>[phase]</strong> — Optional phase code (e.g., <code>ECI</code>, <code>EPC</code>)</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-project-phase-discipline-type-sequence</code></td>
|
||
<td><code>ACME-123456-ECI-EL-SPC-2623</code></td>
|
||
</tr>
|
||
<tr>
|
||
<td>Corporate</td>
|
||
<td><code>originator-000000-discipline-type-sequence</code></td>
|
||
<td><code>ACME-000000-QC-PRO-0042</code></td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<div class="highlight-box" style="margin-top: var(--spacing-lg);">
|
||
<p><strong>Rule: corporate placeholder.</strong> The Corporate schema substitutes a placeholder for the project identifier, indicating the document belongs to the originator's corporate library rather than a specific project. The placeholder does not have to be <code>000000</code> — any value works as long as it is <em>easily recognizable</em> as a corporate-scope marker and could not be mistaken for a real project number (e.g., <code>000000</code>, <code>CORP</code>, <code>HQ</code>). Pick one and use it consistently. The same originator code and discipline/type conventions apply, so corporate documents sort naturally alongside project documents in a unified archive.</p>
|
||
</div>
|
||
|
||
<div class="highlight-box" style="margin-top: var(--spacing-lg);">
|
||
<p><strong>zddc-server defaults.</strong> The schemas above are deployment-agnostic — any of them is a valid tracking number. The <code>zddc-server</code> reference implementation ships the <strong>Basic</strong> schema by default (<code>originator-project-discipline-type-sequence</code>), plus the optional per-deliverable <code>[suffix]</code> (a hyphenated part marker such as <code>-A</code> for an appendix). Two deployment behaviours are worth knowing:</p>
|
||
<ul style="margin: var(--spacing-md) 0; padding-left: 1.5rem; color: var(--color-text-muted); line-height: 1.65;">
|
||
<li><strong>originator is bound to the party folder.</strong> Under <code>archive/<party>/</code>, the server sets <code>originator</code> from the party-folder name and renders it read-only — the folder is its single source of truth, so it can't drift from where the deliverable is filed.</li>
|
||
<li><strong>phase and area are off by default.</strong> Because they are project-wide (all-or-nothing across a project), the default omits them; a project that needs them enables them on <em>every</em> deliverable by extending the schema in its <code>.zddc</code> configuration.</li>
|
||
</ul>
|
||
</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>AR</code></td>
|
||
<td>Architecture</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>CE</code></td>
|
||
<td>Cost Estimating</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>CM</code></td>
|
||
<td>Construction Management</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>CV</code></td>
|
||
<td>Civil Engineering</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>EL</code></td>
|
||
<td>Electrical Engineering</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>EM</code></td>
|
||
<td>Engineering Management</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>EN</code></td>
|
||
<td>Environmental and Permitting</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>FP</code></td>
|
||
<td>Fire Protection</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>HS</code></td>
|
||
<td>Health and Safety</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>IC</code></td>
|
||
<td>Instrumentation and Control</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>ME</code></td>
|
||
<td>Mechanical Engineering</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>NT</code></td>
|
||
<td>Networking & Telecommunication</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>PL</code></td>
|
||
<td>Planning / Scheduling</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>PM</code></td>
|
||
<td>Project Management</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>PS</code></td>
|
||
<td>Procurement and Subcontracting</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>QC</code></td>
|
||
<td>Quality Assurance / Quality Control</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>SE</code></td>
|
||
<td>Security</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>ST</code></td>
|
||
<td>Structural Engineering</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">Type</th>
|
||
<th scope="col">Description</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr><td><code>BLD</code></td><td>Block Diagram</td></tr>
|
||
<tr><td><code>BOE</code></td><td>Basis of Estimate</td></tr>
|
||
<tr><td><code>BOM</code></td><td>Bill of Materials</td></tr>
|
||
<tr><td><code>CBE</code></td><td>Commercial Bid Evaluation</td></tr>
|
||
<tr><td><code>CBS</code></td><td>Cable Schedule</td></tr>
|
||
<tr><td><code>CED</code></td><td>Cause and Effect Diagram / Description</td></tr>
|
||
<tr><td><code>CLC</code></td><td>Calculation</td></tr>
|
||
<tr><td><code>CLY</code></td><td>Cable Routing / Layout</td></tr>
|
||
<tr><td><code>COI</code></td><td>Certificate of Insurance</td></tr>
|
||
<tr><td><code>CPO</code></td><td>Contract Purchase Order</td></tr>
|
||
<tr><td><code>CTN</code></td><td>Control Narrative</td></tr>
|
||
<tr><td><code>DCR</code></td><td>Design Criteria</td></tr>
|
||
<tr><td><code>DDG</code></td><td>Detail Drawing</td></tr>
|
||
<tr><td><code>DTS</code></td><td>Datasheet</td></tr>
|
||
<tr><td><code>ELE</code></td><td>Elevation / Section Drawing</td></tr>
|
||
<tr><td><code>ELS</code></td><td>Electrical Load Summary</td></tr>
|
||
<tr><td><code>ELY</code></td><td>Arrangement / Equipment Layout Drawing</td></tr>
|
||
<tr><td><code>EQL</code></td><td>Equipment List</td></tr>
|
||
<tr><td><code>EST</code></td><td>Cost Estimate</td></tr>
|
||
<tr><td><code>EXT</code></td><td>Project Extents / Limit Of Disturbance</td></tr>
|
||
<tr><td><code>FAB</code></td><td>Fabrication Drawing</td></tr>
|
||
<tr><td><code>FDN</code></td><td>Foundation Design Documents</td></tr>
|
||
<tr><td><code>FIN</code></td><td>Architectural Finishing Plan / Schedule</td></tr>
|
||
<tr><td><code>FRM</code></td><td>Framing Drawing</td></tr>
|
||
<tr><td><code>GPP</code></td><td>General Plot Plan</td></tr>
|
||
<tr><td><code>INV</code></td><td>Invoice</td></tr>
|
||
<tr><td><code>IOM</code></td><td>Installation, Operation, and Maintenance Manual</td></tr>
|
||
<tr><td><code>IRC</code></td><td>Inspection Certificate</td></tr>
|
||
<tr><td><code>IRP</code></td><td>Inspection Report</td></tr>
|
||
<tr><td><code>KDC</code></td><td>Key Document Design Change Note</td></tr>
|
||
<tr><td><code>LGD</code></td><td>Logic Diagram</td></tr>
|
||
<tr><td><code>LOD</code></td><td>Loading Diagram</td></tr>
|
||
<tr><td><code>LST</code></td><td>List</td></tr>
|
||
<tr><td><code>MDL</code></td><td>Master Deliverables List</td></tr>
|
||
<tr><td><code>MOD</code></td><td>3D Model / Database</td></tr>
|
||
<tr><td><code>MOM</code></td><td>Minutes Of Meeting</td></tr>
|
||
<tr><td><code>MPR</code></td><td>Monthly Progress Report</td></tr>
|
||
<tr><td><code>MTO</code></td><td>Material Take-off</td></tr>
|
||
<tr><td><code>NPT</code></td><td>Nameplate</td></tr>
|
||
<tr><td><code>OUT</code></td><td>Outline Drawing</td></tr>
|
||
<tr><td><code>PCO</code></td><td>Project Change Order</td></tr>
|
||
<tr><td><code>PEP</code></td><td>Project Execution Plan</td></tr>
|
||
<tr><td><code>PHS</code></td><td>Phasing Diagram</td></tr>
|
||
<tr><td><code>PIL</code></td><td>Piling Plan / Elevation / Detail</td></tr>
|
||
<tr><td><code>PLN</code></td><td>Plan Drawing</td></tr>
|
||
<tr><td><code>PMP</code></td><td>Portfolio Management Plan</td></tr>
|
||
<tr><td><code>PNP</code></td><td>Plan & Profile</td></tr>
|
||
<tr><td><code>PRO</code></td><td>Procedure</td></tr>
|
||
<tr><td><code>PSR</code></td><td>Procurement Status Report</td></tr>
|
||
<tr><td><code>REP</code></td><td>Report</td></tr>
|
||
<tr><td><code>RFI</code></td><td>Request For Information</td></tr>
|
||
<tr><td><code>RFP</code></td><td>Request For Proposal</td></tr>
|
||
<tr><td><code>SCD</code></td><td>Schematic</td></tr>
|
||
<tr><td><code>SCH</code></td><td>Project Schedule</td></tr>
|
||
<tr><td><code>SKT</code></td><td>Sketch (informal)</td></tr>
|
||
<tr><td><code>SLD</code></td><td>Single Line Diagram</td></tr>
|
||
<tr><td><code>SOV</code></td><td>Schedule Of Values</td></tr>
|
||
<tr><td><code>SOW</code></td><td>Scope Of Work</td></tr>
|
||
<tr><td><code>SPC</code></td><td>Equipment / Material / Installation Specification</td></tr>
|
||
<tr><td><code>SSR</code></td><td>Supplier / Subcontractor Status Report</td></tr>
|
||
<tr><td><code>STY</code></td><td>Study or Options Comparison</td></tr>
|
||
<tr><td><code>SUB</code></td><td>Submittal</td></tr>
|
||
<tr><td><code>TBE</code></td><td>Technical Bid Evaluation</td></tr>
|
||
<tr><td><code>TRN</code></td><td>Transmittal</td></tr>
|
||
<tr><td><code>WRD</code></td><td>Wiring Diagram</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-LST-0001_2503-07 (IFI) - Critical Milestones List.pdf
|
||
ACME-123456-PM-LST-0001_2506-02 (IFI) - Critical Milestones List.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">TBD</span></td>
|
||
<td>To Be Determined</td>
|
||
<td>Planned or forecast deliverable — issue status not yet decided. Used as a placeholder when a transmittal folder is set up ahead of the document; assign a real status before issuing.</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: Project layout & transmittal workflow -->
|
||
<section id="transmittal-workflow">
|
||
<h2>9. Project layout & transmittal workflow</h2>
|
||
<p>A ZDDC project mirrors the natural lifecycle of an engineering deliverable: <strong>drafted in private, lined up for issue, formally exchanged, kept as record</strong>. Each canonical folder maps to one of those stages, so file location alone tells you where a document is in its lifecycle. An operator only needs to create one file — a <code>.zddc</code> in an empty directory — and the rest of the layout populates as work happens.</p>
|
||
|
||
<div class="code-block">
|
||
project/
|
||
.zddc ← the only file an operator must create
|
||
|
||
archive/ ← The only PHYSICAL project-root directory.
|
||
Everything party-scoped (records, lifecycle,
|
||
immutable archives) lives uniformly under
|
||
archive/<party>/.
|
||
{party-name}/ ← One per counterparty; one for ourselves.
|
||
We treat our own organisation as just another
|
||
party so internal deliverables get the same
|
||
tracking treatment as external ones.
|
||
mdl/ ← The party's Master Deliverables List —
|
||
what they're going to produce. Opens as
|
||
a grid editor; rows are individual .yaml
|
||
files, one per deliverable.
|
||
rsk/ ← Risk register for this party. Same grid
|
||
editor as mdl/.
|
||
incoming/ ← Where the counterparty drops things for us.
|
||
A quality-check buffer before content
|
||
becomes part of the permanent record.
|
||
received/ ← What we've accepted from that party.
|
||
Immutable (WORM); the historical record
|
||
of inbound documents.
|
||
issued/ ← What we sent to that party. Immutable
|
||
(WORM); the historical record of outbound
|
||
documents.
|
||
working/ ← Where this party's staff draft. Each
|
||
person has a private subfolder here
|
||
(named by email) and iterates until ready
|
||
to commit. The browse tool handles
|
||
everything here.
|
||
<your-email>/ ← Your private workspace under THIS
|
||
party. Fenced (inherit:false) by the
|
||
auto-own .zddc, so other team members
|
||
only see what you explicitly share.
|
||
staging/ ← The "about to issue" lane for this party.
|
||
Drop files here and the project_team
|
||
gives them up — only the doc-controller
|
||
can change a file after it lands. Each
|
||
sub-folder declares a planned outbound
|
||
transmittal (name carries the date +
|
||
tracking number).
|
||
reviewing/ ← One place per party to see everything we
|
||
owe a response on. Folders are scaffolded
|
||
by Plan Review, each pairing an inbound
|
||
submittal in received/ with the in-progress
|
||
response draft.
|
||
|
||
ssr/ ← Virtual aggregator: tables rollup of every
|
||
party's ssr.yaml row, with a synthesised
|
||
$party column. Never on disk.
|
||
mdl/ ← Virtual aggregator: tables rollup of every
|
||
party's mdl/*.yaml deliverables.
|
||
rsk/ ← Virtual aggregator: tables rollup of every
|
||
party's rsk/*.yaml risk rows.
|
||
working/ ← Virtual aggregator: browse folder-nav listing
|
||
parties with non-empty content in working/.
|
||
Per-party clicks 302-redirect to the canonical
|
||
archive/<party>/working/.
|
||
staging/ ← Same shape as working/ for the staging slot.
|
||
reviewing/ ← Same shape as working/ for the reviewing slot.
|
||
</div>
|
||
|
||
<p style="margin-top: var(--spacing-md); font-size: 0.95em; color: var(--color-text-soft);"><em>Mechanics:</em> folders materialise on first write, names match case-insensitively, the WORM zones (<code>received/</code>, <code>issued/</code>) enforce write-once via an ACL mask, and the six top-level aggregators (<code>ssr</code>/<code>mdl</code>/<code>rsk</code>/<code>working</code>/<code>staging</code>/<code>reviewing</code>) are virtual — they never materialise on disk but show up in listings, computed from <code>archive/<party>/…</code> at request time. Mkdir at the project root is restricted to <code>archive</code> + system names (<code>_</code>/<code>.</code>-prefixed) so the virtual names can never be shadowed by a physical folder. Drop files where the lifecycle says they go and the layout takes care of itself.</p>
|
||
|
||
<p style="margin-top: var(--spacing-md); font-size: 0.95em; color: var(--color-text-soft);"><em>The in-flight ratchet.</em> <code>working/</code> → <code>staging/</code> → <code>issued/</code> is a one-way handoff. <code>project_team</code> iterates freely in <code>working/</code> (the auto-own-fenced subfolder gives each user a private <code>rwcda</code> workspace). When they drop a file into <code>staging/</code> their access downgrades to <code>cr</code> — they can drop more, but only the <code>document_controller</code> can change what's already there. When DC publishes to <code>issued/</code>, the WORM mask downgrades even DC to <code>cr</code> (write-once). Each handoff is a commitment by permission-loss.</p>
|
||
|
||
<p><strong>5-step transmittal 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>
|
||
|
||
<h3>Drafting a response transmittal</h3>
|
||
<p>Submittals from counterparties (tracking numbers containing <code>-SUB-</code> at status <code>IFR</code> or <code>IFA</code>) require a response transmittal whose status starts with <code>RS</code> (RSA, RSB, RSC, …). The flow walks the ratchet:</p>
|
||
<ol>
|
||
<li>Right-click the submittal in <code>archive/<party>/received/<tracking>/</code> and pick <strong>Plan Review</strong>. The server scaffolds a workflow folder at <code>archive/<party>/reviewing/<tracking>/</code> — its <code>.zddc</code> carries a <code>received_path</code> pointer back to the canonical submittal and a planned response date.</li>
|
||
<li>The party's working subfolder under <code>archive/<party>/working/<your-email>/</code> is where reviewer notes and the response payload are drafted. The <code>reviewing/</code> virtual aggregator at the project root surfaces all open reviews across parties.</li>
|
||
<li>When the response is ready, files move from <code>working/</code> into <code>archive/<party>/staging/</code> for sign-off. Project team's permission on staged files downgrades to <code>cr</code> — the doc controller takes over.</li>
|
||
<li>The doc controller cuts the package from <code>staging/</code> into <code>archive/<party>/issued/</code> via the standard 5-step transmittal flow. The reviewing scaffold is deleted at issue time.</li>
|
||
</ol>
|
||
</section>
|
||
|
||
<!-- Section 10: zddc-server bootstrap -->
|
||
<section id="bootstrap">
|
||
<h2>10. zddc-server bootstrap</h2>
|
||
|
||
<div class="highlight-box">
|
||
<p><strong>A fresh <code>zddc-server</code> deployment grants no access to anyone until two config files are populated.</strong> Without them the server runs but every request returns 403. The embedded defaults ship with empty role members, so deployments must opt-in to authorize anyone — there is no default "anything goes" mode (except <code>--insecure</code>, which is explicitly for deliberately-public archives).</p>
|
||
</div>
|
||
|
||
<p>Two files, both named <code>.zddc</code>. YAML format. Hand-edited.</p>
|
||
|
||
<h3>Step 1 — root <code>/.zddc</code></h3>
|
||
|
||
<p>At <code><ZDDC_ROOT>/.zddc</code>, name at least one admin:</p>
|
||
|
||
<div class="code-block">admins:
|
||
- cwitt@burnsmcd.com
|
||
</div>
|
||
|
||
<p><code>admins:</code> is honored only at the root file. Admins behave as normal users by default and elevate per-request via the <code>zddc-elevate=1</code> cookie (the header toggle visible in every tool) or implicitly when authenticating with a bearer token. This sudo-style model means an admin can't accidentally clobber files in their everyday browsing — elevation is opt-in.</p>
|
||
|
||
<p>Without this file the server refuses to start (the served tree would be publicly accessible to anonymous callers); pass <code>--insecure</code> to acknowledge a deliberately-public deployment.</p>
|
||
|
||
<h3>Step 2 — per-project <code><project>/.zddc</code></h3>
|
||
|
||
<p>In each project, populate role members:</p>
|
||
|
||
<div class="code-block">title: "Project Phoenix"
|
||
roles:
|
||
document_controller:
|
||
members:
|
||
- dc1@burnsmcd.com
|
||
project_team:
|
||
members:
|
||
- '*@burnsmcd.com' # all internal staff
|
||
observer: # optional — external audit
|
||
members:
|
||
- auditor@external.com
|
||
</div>
|
||
|
||
<p>That's it. The embedded cascade does the rest:</p>
|
||
|
||
<ul style="margin: var(--spacing-md) 0; padding-left: 1.5rem; color: var(--color-text-muted); line-height: 1.65;">
|
||
<li><code>project_team</code> gets read across the project plus the in-flight ratchet (<code>cr</code> in <code>working/</code> + <code>reviewing/</code> + <code>staging/</code>, with <code>rwcda</code> inside each user's auto-own-fenced home under <code>working/</code>).</li>
|
||
<li><code>document_controller</code> creates party folders at <code>archive/</code>; when they do, the auto-own <code>.zddc</code> written at <code>archive/<party>/</code> grants both their email AND the <code>document_controller</code> role <code>rwcda</code> — so any DC in the role has full authority at every party a peer created. Explicit <code>rwcd</code> grants at <code>incoming/</code>/<code>staging/</code> for the QC + transfer workflows, and WORM <code>cr</code> at <code>received/</code>/<code>issued/</code> for write-once filing.</li>
|
||
<li><code>observer</code> is pure read-only across the project — intended for external auditors, regulators, and read-only viewers who must not contribute content.</li>
|
||
</ul>
|
||
|
||
<p style="margin-top: var(--spacing-md);">A DC is typically also a project team member (the <code>*@burnsmcd.com</code> glob catches them). The embedded defaults restate <code>document_controller: rwcda</code> at every slot that grants project_team a narrower verb — within-level union of all matched principals gives DCs <code>rwcda</code> ∪ <code>cr</code> = <code>rwcda</code>, preserving full authority. <strong>Document controllers are not subtree-admins anywhere.</strong> Their power comes purely from cascade grants; admin elevation is reserved for the root <code>admins:</code> list (the human escape hatch).</p>
|
||
|
||
<p>Add a new project team member with one line; revoke by removing the line. No need to restate the cascade's grants — they're already in the embedded defaults that ship with <code>zddc-server</code>.</p>
|
||
|
||
<h3>Schema essentials</h3>
|
||
|
||
<table>
|
||
<thead>
|
||
<tr>
|
||
<th scope="col">Key</th>
|
||
<th scope="col">Where</th>
|
||
<th scope="col">Shape</th>
|
||
</tr>
|
||
</thead>
|
||
<tbody>
|
||
<tr>
|
||
<td><code>admins:</code></td>
|
||
<td>Root only</td>
|
||
<td>List of emails. Sudo-style; gates on <code>zddc-elevate=1</code>.</td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>acl:</code></td>
|
||
<td>Anywhere; cascades</td>
|
||
<td><code>{ permissions: { <principal>: <bits> }, inherit: <bool>? }</code></td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>roles:</code></td>
|
||
<td>Anywhere; members union across the cascade</td>
|
||
<td><code>{ <name>: { members: [...], reset: <bool>? } }</code></td>
|
||
</tr>
|
||
<tr>
|
||
<td><code>title:</code></td>
|
||
<td>Per-project only</td>
|
||
<td>String; surfaces on the landing-page picker.</td>
|
||
</tr>
|
||
</tbody>
|
||
</table>
|
||
|
||
<p><strong>Permission bits</strong> — any subset of:</p>
|
||
|
||
<ul style="margin: var(--spacing-md) 0; padding-left: 1.5rem; color: var(--color-text-muted); line-height: 1.65;">
|
||
<li><code>r</code> read</li>
|
||
<li><code>w</code> write (overwrite existing files)</li>
|
||
<li><code>c</code> create (new files, new directories)</li>
|
||
<li><code>d</code> delete</li>
|
||
<li><code>a</code> admin (modify the <code>.zddc</code> ACL at this level — distinct from the root <code>admins:</code> list, which is the elevation-bypass sudo channel)</li>
|
||
</ul>
|
||
|
||
<p>An empty bits string (<code>''</code>) is an explicit deny.</p>
|
||
|
||
<p><strong>Principals</strong> — three forms:</p>
|
||
|
||
<ul style="margin: var(--spacing-md) 0; padding-left: 1.5rem; color: var(--color-text-muted); line-height: 1.65;">
|
||
<li>Email address — must contain <code>@</code>, e.g. <code>alice@burnsmcd.com</code></li>
|
||
<li>Email glob — wildcard on the local part, e.g. <code>'*@acme.com'</code> (quote it in YAML so the leading <code>*</code> doesn't confuse the parser)</li>
|
||
<li>Role name — anything without an <code>@</code>, e.g. <code>document_controller</code>. The role's members are looked up via <code>roles:</code> at any cascade level.</li>
|
||
</ul>
|
||
|
||
<h3>Common footgun</h3>
|
||
|
||
<div class="highlight-box">
|
||
<p><strong>This is silently dropped:</strong></p>
|
||
<div class="code-block" style="margin: var(--spacing-sm) 0;">acl:
|
||
allow:
|
||
- '*@burnsmcd.com'
|
||
</div>
|
||
<p>The YAML parses cleanly but <code>ACLRules</code> only reads <code>permissions:</code>. The <code>allow:</code> block is discarded during unmarshal and you end up with zero grants. Correct form:</p>
|
||
<div class="code-block" style="margin: var(--spacing-sm) 0;">acl:
|
||
permissions:
|
||
'*@burnsmcd.com': r
|
||
</div>
|
||
</div>
|
||
|
||
<h3>Verifying the bootstrap</h3>
|
||
|
||
<p><code>zddc-server</code> prints a startup warning when the root <code>.zddc</code> grants nobody anything — watch for it on first boot:</p>
|
||
|
||
<div class="code-block">level=WARN msg="root .zddc grants nobody anything (no admins,
|
||
no acl.permissions, no role members). ZDDC will refuse every
|
||
request until you populate it..."</div>
|
||
|
||
<p>To dump the full annotated schema (every cascade key with documentation):</p>
|
||
|
||
<div class="code-block">zddc-server show-defaults</div>
|
||
|
||
<p>That prints the embedded <code>defaults.zddc.yaml</code> with comments explaining every option (<code>worm:</code>, <code>auto_own:</code>, <code>auto_own_roles:</code>, <code>auto_own_fenced:</code>, <code>drop_target:</code>, <code>apps:</code>, <code>convert:</code>, <code>records:</code>, <code>available_tools:</code>, <code>default_tool:</code>, <code>dir_tool:</code>, and more). Pipe it to a file and use it as the starting point for any deeper customization.</p>
|
||
</section>
|
||
|
||
<!-- Section 11: Tools -->
|
||
<section id="tools">
|
||
<h2>11. Tools</h2>
|
||
<p>Single-file HTML applications — each is complete and self-contained. Save one locally and it works forever, without internet, without updates, without a subscription. None of them require any configuration to run; <code>.zddc</code> files and <code>zddc-server</code> only add to them. Together they cover the full ZDDC workflow: <strong>browse</strong> to look at anything; <strong>classify</strong> to name incoming files and build transmittals; <strong>archive</strong> to search and export the formal record.</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/browse.html" class="tool-card" style="text-decoration: none; display: block;">
|
||
<div class="tool-card__title">Browse</div>
|
||
<div class="tool-card__desc">Open any folder on your disk — no setup. A file-tree navigator with live preview, plus in-place markdown editing (YAML front matter pane, table of contents) and export to DOCX, HTML, or PDF. Optional <code>.zddc</code> files add friendly labels, per-folder tools, permissions, and transmittal actions; without them it is still a complete browser.</div>
|
||
<div class="tool-card__link">Open Browse</div>
|
||
</a>
|
||
|
||
<a href="releases/classifier.html" class="tool-card" style="text-decoration: none; display: block;">
|
||
<div class="tool-card__title">Classify</div>
|
||
<div class="tool-card__desc">Turn incoming files into properly named ZDDC deliverables. Drop files onto a tree to assign each a tracking number, revision, and status, then organize them into dated transmittal folders ready to issue. Spreadsheet-style editing; writes renamed, sorted copies back to disk. No server required.</div>
|
||
<div class="tool-card__link">Open Classify</div>
|
||
</a>
|
||
|
||
<a href="releases/archive.html" class="tool-card" style="text-decoration: none; display: block;">
|
||
<div class="tool-card__title">Archive</div>
|
||
<div class="tool-card__desc">The read-only window into the formal record. Filter by tracking number, discipline, revision, status, or free text. Group rows by transmittal to see the lifecycle of any deliverable. Download the current selection as a ZIP. The archive is preserved as-issued.</div>
|
||
<div class="tool-card__link">Open Archive</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. Run the tools through <code>zddc-server</code> for any browser, network access, and ACL enforcement.</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> |