DDL Standards · Governance

STD-DDL-LOG-001
The Black Box Standard

Governed Audit Log for DDL Workbooks · v0.2 · 2026-03-28
Ratified 8 LOCK · 1 REVISE CR-DDL-AUDITLOG-002 AccidentalInsight
Standard Metadata
Reference Information
Standard IDSTD-DDL-LOG-001
Common NameThe Black Box Standard
Version0.2
StatusRatified — 8 LOCK / 1 REVISE
Date2026-03-28
AuthorDave Kitchens · Dropdown Logistics
Prior ReviewsCR-DDL-AUDITLOG-001 · CR-DDL-AUDITLOG-002
Registry EntriesFRM-0031 (FORMULATEXT) · PTN-0020 (Governed Audit Log)
DependenciesSTD-EXCEL-001 · STD-EXCEL-002 · FRM-0031
OriginAccidentalInsight — GridTactics design session, 2026-03-28
Version History
Changes v0.1 → v0.2
SectionChangeRationale
§1 PurposeSoftened ‘automatic’ languagev0.1 overclaimed automation. Operator still declares run date, writes Event, enters Expected. Accurate: reduces dependence on memory.
§4.2 TimestampAdded Run_Date validation formulaTemplates should fail fast on bad timestamp format.
§6 ErrorsAdded Scenario 5: external data failureBroken Power Query or linked CSV is a real production scenario.
§6 ErrorsAdded Scenario 6: blank Run_DateStale or blank Run_Date silently corrupts the record.
§8 Trust ArcSnapshot behavior as Phase 2 requirementLive references acceptable at comfort phase. Frozen snapshots required at reliance phase.
§8 Trust ArcPhase 3 gate addedEvidentiary phase needs declared conditions, not operator vibes.
§10 TemplateProtection guidance addedTemplate companion needs explicit protection settings.
§1
Purpose

“The difference between a workbook that produces a result and a workbook that can defend a result.”

A DDL workbook used in production must be able to defend its results — without relying on the operator’s memory, without separate narrative documentation, and without macros.

The Governed Audit Log reduces dependence on memory by capturing formula state, results, and timestamps at each production run. It does not eliminate operator involvement — the operator still declares the run date, describes the event, and enters expected values. The LOG automates the capture of formula provenance inside a governed run process.

v0.2 note

‘Automatic’ language softened from v0.1. The LOG reduces documentation burden. It does not remove the operator from the process.

§2
Applicability
Mandatory

Applies to any workbook that meets one or more of the following conditions:

Recommended (not required)
Operator Declaration

Every workbook governed by this standard must declare its classification in the README tab:

Workbook Type:     Operational / Analytical
STD-DDL-LOG-001:   Required / Recommended / Exempt
Trust Phase:       Comfort / Reliance / Evidentiary
§3
LOG Tab Requirements
3.1 Structure
3.2 Required Columns — All Eight, Non-Negotiable
ColNameSourcePurpose
ARun_Date=Config!Run_DateFrozen operator-declared run date
BEventFree textHuman-readable description of what ran
CTarget_CellText — A1-style refIdentifies the cell being documented
DFormula_Used=FORMULATEXT(ref)Formula as readable text
EResult=ref to Target_CellValue the formula produced this run
FExpectedOperator-enteredGoverned expected value. ‘N/A’ if none
GPass_Fail=IF(E=F,“PASS”…)Automated reconciliation check
HNotesFree textContext formulas cannot capture
3.3 Column Order

Columns must appear in the order defined above. Column order is a scanner-compatibility requirement. The Anti-Pattern Scanner reads Col D (Formula_Used) by position. Reordering columns breaks scanner output silently. Any columns added beyond H must be appended to the right and documented in the README.

§4
Timestamp Governance

=NOW() and =TODAY() are explicitly banned as sole timestamp mechanisms in the LOG tab. Both are volatile — they recalculate on every workbook open, silently rewriting every historical timestamp. A log with volatile timestamps is not a log. It is a display.

4.2 Governed Method — Run_Date Named Range
SETUP:
  Config tab, cell B3 (or operator-designated cell)
  Named range: Run_Date
  Value: operator sets manually before each production run
  Format: YYYY-MM-DD text (e.g. 2026-03-28)

VALIDATION (add adjacent to Run_Date on Config tab):
  =IF(AND(LEN(Run_Date)=10,
          ISNUMBER(DATEVALUE(Run_Date))),
       "OK", "FORMAT ERROR — use YYYY-MM-DD")

USAGE IN LOG:
  Col A formula: =Config!Run_Date
  Result: all LOG rows for this run share the same
  intentional, frozen, operator-declared timestamp.
Note

If Run_Date is blank or invalid, Col A returns an error. This is intentional — the LOG should not accept a run without a declared date. See §6 Scenario 6.

4.3 Operator Ritual

Before every production run: open Config tab → update Run_Date → confirm validation reads OK → proceed. This is a deliberate governance act. The operator is declaring: “This run happened on this date.” That declaration is itself audit evidence.

§5
FORMULATEXT Dependency

FORMULATEXT requires Excel 2013 or later. This is the DDL governed baseline. Pre-2013 environments are out of scope for this standard.

Fallback for Legacy Environments

If a workbook must operate in a pre-2013 environment: document the formula manually in Formula_Used as plain text, prefix with “MANUAL: ”, note the environment limitation in Notes.

Legacy fallback is a reduced-assurance exception path. Manual entries are not equivalent to governed automated capture and are not suitable for evidentiary-phase claims without explicit exception documentation.

§6
Error Handling

Six scenarios are explicitly defined. All other error conditions should be logged as-is with a note in the Notes column.

Scenario 1 — Target cell returns an Excel error
Result:          Log the error value as-is (#N/A, #REF!, etc.)
Pass_Fail:       FAIL (automatic)
Notes:           "ERROR — investigate before relying on this run"
Operator action: Do not distribute results until resolved
Scenario 2 — Target cell contains a hardcode
Formula_Used:    FORMULATEXT returns #N/A
Log entry:       Record "HARDCODE DETECTED" in Formula_Used
Pass_Fail:       FAIL — governance finding
Notes:           "STD-EXCEL-001 violation — hardcode in production cell"
Operator action: Replace hardcode before next production run
Scenario 3 — Target cell is a spilled range
Target_Cell:     Log the anchor cell only (e.g. D7)
Formula_Used:    FORMULATEXT of the anchor cell
Result:          Value of the anchor cell
Notes:           "Spill range: D7# — [N] rows × [M] cols"
Rationale:       The anchor formula governs the spill.
Scenario 4 — Formula changes between runs
No special handling required.
Run_Date + FORMULATEXT captures formula state per run.
Version drift is visible by comparing LOG rows across runs.
This is the standard working as designed.
Scenario 5 — External data source failure
Applies to: broken Power Query, missing linked CSV,
            failed external workbook link
Result:          Log the error value returned by the target cell
Pass_Fail:       FAIL
Notes:           "EXTERNAL SOURCE FAILURE — [source name].
                 Ref ticket: [ticket ID]"
Operator action: Do not distribute. Restore source and re-run.
Scenario 6 — Blank or invalid Run_Date
Condition:       Config!Run_Date is blank, stale, or invalid format
Col A:           Returns error or stale date
Operator action: Stop. Do not proceed with the run.
                 Update Run_Date. Confirm validation reads OK.
                 Re-run from the beginning.
Rationale:       A run without a declared date cannot be
                 defended. The LOG row would be misleading.
§7
Scanner Compatibility

The LOG tab must be designed for scanner compatibility from day one. The Anti-Pattern Scanner and future Excelligence tooling will read LOG tab output to detect formula drift and provenance gaps.

Future capability

When the scanner gains LOG-reading functionality it can detect version-to-version formula drift, anti-pattern introduction across runs, and formula provenance gaps. This capability is designed in from day one.

§8
Trust-Building Arc

This standard is experimental with guardrails. It ships as a comfort layer. Trust builds through sustained use. Phases describe the operator’s relationship with the tool — they are not compliance tiers.

Phase 1 — Comfort (v0.2 default)
Use the LOG tab. Watch it capture runs. Validate it against your own memory of what ran. Live references in Formula_Used and Result are acceptable at this phase. The LOG is a comfort layer.
Phase 1 limitation

Snapshot behavior is not required at Phase 1. If a formula changes between runs, prior rows may reflect current state rather than historical state. This is a known limitation and is acceptable during the trust-building period.

Phase 2 — Reliance
After sustained use across multiple production runs, begin treating LOG output as the authoritative record. Stop relying on memory. Snapshot behavior is required at Phase 2 — after each run, Formula_Used (Col D) and Result (Col E) rows must be frozen as values before the workbook is closed.
Phase 3 — Evidentiary
Present LOG output to external reviewers as formal documentation of formula provenance. Three gates must be declared before claiming evidentiary phase: (1) minimum 3 production runs with LOG active, (2) snapshot behavior in practice across all recent runs, (3) operator has manually reviewed at least one LOG entry against actual workbook output and confirmed accuracy.

Phase progression is at operator discretion. Declare the phase in the README tab.

§9
Relationship to Existing Standards
Standard / EntryRelationship
STD-EXCEL-001The audit log is the enforcement layer for formula governance. STD-EXCEL-001 defines what good formulas look like. This standard proves that good formulas were actually used.
STD-EXCEL-002Any workbook classified as Operational must have a LOG tab. The INPUT → LOGIC → OUTPUT architecture is made traceable by making LOGIC visible and timestamped.
FRM-0031FORMULATEXT is the primary tool of the LOG tab. The LOG depends on FRM-0031 as its capture mechanism.
PTN-0020PTN-0020 remains in the registry as the reference implementation. Pattern describes. This standard mandates.
§10
Reference Implementation
Tab:          LOG
Table:        tbl_Log
Config:       Run_Date named range on Config tab
Validation:   IFERROR format check adjacent to Run_Date
Protection:   Sheet protection ON
              All columns locked
              Unlock only: active entry row (first empty row)
              Workbook protection: structure locked
Columns:      A–H per §3.2 in defined order
Scanner cols: Any additions must be appended after H
              Document in README: column name, purpose, added date

A canonical template workbook accompanies this standard. All new production workbooks should begin from the template. The template includes the LOG tab pre-configured, the Config tab with Run_Date named range and validation formula, and README tab with the operator declaration fields.