1141 lines
No EOL
60 KiB
HTML
1141 lines
No EOL
60 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="#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 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>A sensible default profile.</strong> The schemas above are all valid tracking numbers; pick the one that fits your project. A common starting point is the <strong>Basic</strong> schema (<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 conventions 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 follows the party folder.</strong> When deliverables are filed under a per-party folder, the <code>originator</code> matches that folder's name — the folder is the single source of truth, so the code can't drift from where the document is filed.</li>
|
||
<li><strong>phase and area are off by default.</strong> Because they are project-wide (all-or-nothing across a project), most projects omit them; a project that needs them adds them to <em>every</em> deliverable.</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 folder maps to one of those stages, so file location alone tells you where a document is in its lifecycle. You only create the folders you need, when you need them.</p>
|
||
|
||
<div class="code-block">
|
||
project/
|
||
archive/ ← Holds everything, organised by party.
|
||
{party-name}/ ← One folder per organisation you exchange
|
||
with — and one for yourselves. Your own
|
||
deliverables get the same treatment as
|
||
anyone else's.
|
||
mdl/ ← Master Deliverables List for this party —
|
||
what they are going to produce.
|
||
rsk/ ← Risk register for this party.
|
||
incoming/ ← Where this party drops things for you;
|
||
a checking buffer before you accept them.
|
||
received/ ← What you have accepted from that party.
|
||
A permanent, write-once record.
|
||
issued/ ← What you have sent to that party.
|
||
A permanent, write-once record.
|
||
working/ ← Where your team drafts. Each person works
|
||
in their own subfolder until a file is ready.
|
||
staging/ ← The "about to issue" lane: drop finished
|
||
files here to line up an outbound transmittal.
|
||
reviewing/ ← One place to track everything you owe a
|
||
response on.
|
||
</div>
|
||
|
||
<p style="margin-top: var(--spacing-md); font-size: 0.95em; color: var(--color-text-soft);"><em>How it flows.</em> <code>working/</code> → <code>staging/</code> → <code>issued/</code> is a one-way progression: your team drafts freely in <code>working/</code>, lines finished files up in <code>staging/</code> for the document controller to sign off, and the document controller publishes the package into <code>issued/</code> as the permanent record. Treat <code>received/</code> and <code>issued/</code> as write-once — once a document lands there, it stays exactly as filed.</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 follows the same lifecycle:</p>
|
||
<ol>
|
||
<li>For a submittal in <code>received/</code>, start a review folder under <code>reviewing/</code> that points back to it, so every open response is in one place.</li>
|
||
<li>Draft your reviewer notes and the response itself in <code>working/</code>.</li>
|
||
<li>When the response is ready, move the files into <code>staging/</code> for the document controller to sign off.</li>
|
||
<li>The document controller issues the package from <code>staging/</code> into <code>issued/</code> via the standard 5-step transmittal flow.</li>
|
||
</ol>
|
||
</section>
|
||
|
||
<!-- Section 10: Tools -->
|
||
<section id="tools">
|
||
<h2>10. 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; optional <code>.zddc</code> files 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 class="tools-grid">
|
||
<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);">To open a folder directly from your computer, use a Chromium-based browser — Chrome, Edge, or Brave. That feature relies on the browser's <a href="https://www.chromium.org/Home/">File System Access API</a>, which Firefox and Safari do not yet support.</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> |