Built with · provenance footer

Source · Dan, 2026-06-18 · wired as surface baseline 2026-06-20

"'Built with' can be added to patterns as a footer behaviour — can we reveal/hide it, especially when the script list is long — do any of the scripts have references back to pattern/memory that can be linked programmatically?"

The problem

A composed page — a voiced article, an ingested clip, a generated dashboard — is the visible output of a pipeline the reader never sees: which script built it, which model transcribed it, when it ran and deployed. That provenance is real and worth keeping, but pasted raw at the foot of every page it becomes clutter, and it goes stale silently. Once the build list grows past three or four tools it dominates the footer it was meant to quietly annotate.

Worse: each surface invents its own footer markup. The wording drifts, the styling diverges, and a wording change has to be hand-applied across every page. A bolt-on footer is the opposite of a system — it's the drift that compounds. The same logic that led to the favicon control plane (one source, every surface inherits) applies here: own the footer once, in one file, and let every surface pull from it.

The element, in-page

One placeholder <div data-made-with …>, four data- attributes, one shared script at assets.gf.cx/made-with/made-with.js. The script reads the attributes and renders a compact, bordered provenance strip — wording, styling, and link targets all live in that one file, so a single edit propagates to every surface simultaneously. The demo below is a self-contained static facsimile of what the primitive produces; flip the JS tab to see the real wiring.

Where it applies

The made-with footer is one of the five surface-baseline defaults wired into the gfcx_subdomain_new.py scaffold — every new surface gets it automatically. Surfaces predating the scaffold receive it on the next sweep. Currently live on status.gf.cx, dash.gf.cx, happiness.gf.cx, and patterns.gf.cx (this very page — scroll to the foot to see it rendered by the real primitive).

For pages with a richer per-page tool ledger — a behaviour page that ran four scripts, a transcription model, and a deploy step — use the collapsible <details class="provenance"> variant inside the page body. It lists every tool, each optionally linking to its governing pattern or kb note. No JS: the <details> element carries reveal/hide natively; a CSS ::before rotates the disclosure triangle on [open]:

<details class="provenance">
  <summary>
    <span class="t">Built with</span>
    <span class="meta">4 tools · ingested
      <time datetime="2026-06-18T12:50:15Z">18 Jun 2026</time>
    </span>
  </summary>
  <ul>
    <li><a href="https://kb.gf.cx/<slug>/">
      <code>~/bin/happiness_video_ingest.py</code></a>
      — ffprobe · poster · encode · R2</li>
    <li><code>gemini-2.5-flash</code> — verbatim transcription</li>
  </ul>
</details>

.provenance > summary::before { content: "\25B8"; transition: transform .15s; }
.provenance[open] > summary::before { transform: rotate(90deg); }
.provenance > summary::-webkit-details-marker { display: none; }

The payoff for linking tools back: when a listed script has a canonical home — a pattern here, a memory note at kb.gf.cx/<slug>/ — the reader can go from what built this to why it's built this way in one click. Keep the link map in one central dict in the page builder, not hand-authored per page.

Three failure modes to avoid:

Collapse when there's nothing to collapse. One or two tools don't need a <details> — ship the list open or inline it. Collapse only when the list earns it (≥3–4 rows).
Hand-typed timestamps. The <time> element is provenance — it must be stamped by the build step, not typed, or it lies. Emit it where the page is generated.
Dead registry links. A linked kb/pattern slug that 404s is worse than no link. Apply the same external-probe discipline: a link ships only once its target resolves.

Reusable elements

Named, copyable pieces — lift any one without the others:

data-made-with placeholder — the single <div> that activates the shared primitive. Four attributes (data-repo, data-surface, data-project, data-page); the script populates everything.
assets.gf.cx/made-with/made-with.js — the one shared script. Wording, styling, and link targets all live here — the favicon-control-plane model applied to provenance. Change it once; every surface reflects the update.
<details class="provenance"> — the collapsible per-page tool-ledger variant for pages with rich ingest history. No JS; the <details> element handles reveal/hide natively.
BUILT_WITH registry map — a central Python dict in the page builder mapping tool names to their pattern or kb links. Author once; every generated page inherits linkable provenance.
# pattern: <slug> / # kb: <slug> docstring tags — the ceiling: tools declare their own provenance link in their docstring; the builder harvests it automatically. The central registry is the floor today.

Reference

Source: Dan, 2026-06-18 (first articulated) · wired as surface-baseline layer 5 of 5, 2026-06-20.
In use / example: status.gf.cx — scroll to the foot of any page; the strip shows the repo, surface name, and Cloudflare Pages deploy channel, all rendered by assets.gf.cx/made-with/made-with.js. First per-page <details class="provenance"> live example: happiness.gf.cx/behaviour/control-is-not-regulation/ (2026-06-18).
Reusable elements: data-made-with placeholder · made-with.js shared script · <details class="provenance"> ledger · BUILT_WITH registry map · docstring tags (all listed above).
Build cost: One <div> + one <script defer> per surface; the shared script caches portfolio-wide. Wording and styling changes propagate in a single file edit — zero per-surface work after the initial wire-up.