06-reference/research

fde proof point companion public artifact

2026-08-16·research-brief·source: deep-research·by Ray Data Co (deep-research synthesis)
fdeproof-pointstarter-kitpositioningsanitizationpublic-artifact

No companion starter kit — ship inspectable receipts instead, because the shippable layer is the commodity layer

The question

Verbatim: "Does the FDE proof-point write-up need a companion public artifact (e.g. the Ray-Starter-Kit / 'coo-in-a-box' sanitized portable layer) to satisfy the 'show your work' credibility bar?"

This is open follow-up #3 of [[2026-06-19-phdata-experiment-fde-positioning-proof-point]], which recommended publishing the FDE proof point and then asked whether the piece should link to a packaged, installable version of the harness as the "here is the portable layer" exhibit.

What we already know (from the vault)

Direct observation this run (checks, not citations)

Run 2026-08-16 against the live GitHub org and local disk:

What the web says

Convergences and contradictions

Synthesis for RDCO

Recommendation: NO companion starter kit. Ship the write-up with an inspectable-receipts appendix instead. Confidence: HIGH on rejecting the kit; MEDIUM-HIGH on the receipts substitute being sufficient.

The central argument is the inverse correlation, and it is not a cost argument. Sanitization is not a tax you pay to ship the good thing — sanitization is the removal of the good thing. [[2026-05-10-harness-moat-two-layers-portability]] already did this accounting: Layer 1 is ~90% of the mechanism and is, by its own words, "teachable in an afternoon" with "no time-arbitrage advantage"; Layer 2 is the ~10% that makes it Ray. A sanitized kit ships Layer 1 with [[OPERATOR]] placeholders where Layer 2 used to be, into a category that now contains OpenClaw, Orkas, Avelina and monthly-updated awesome-lists. So the kit is simultaneously the most expensive artifact RDCO could build and the least differentiated one it could publish. The write-up is the opposite: it is about Layer 2 — this rule exists because of this failure, this correction was logged on this date, this ledger row is predicted not observed — which is uncopyable, cheap to produce, and publishable as narrative even though it is not publishable as code. The proof point does not need the kit because the kit does not contain the proof.

What actually satisfies "show your work" here is receipts, not a runtime. The web mechanism is a stranger inspecting concrete specifics and concluding competence can't be faked. That is satisfied by embedding four to six hand-picked artifacts verbatim inside the piece: one real SKILL.md with its ugly conditionals intact, one real feedback_*.md memory file with the date and the failure that produced it, the actual cron table, a screenshot of a real morning brief, the leak-gate grep command with its real output, and the one-line correction where a critic caught the founder's own agent over-claiming. That is stronger evidence than a placeholder-filled template, because a template is by construction the version with the specifics removed — the exact opposite of "publish the model numbers." It also costs roughly an afternoon rather than 13-18+ hours, adds zero installable surface, carries zero maintenance obligation, and has a narrower confidentiality footprint: hand-picked quoting is selective, a repo push is bulk export from a machine that also carries ~/Projects/phdata-private and ~/Projects/phdata-sales-process. Per feedback_employer_client_content_boundary and [[2026-06-23-phdata-confidentiality-redaction-checklist]], every receipt still passes the constraint-class gate and the existing plain-grep leak scan with an independent fresh-eyes pass, per feedback_git_grep_skips_binary_files.

The maintenance argument independently kills the kit even if the leak risk were zero. Two of the top three B2B trust drivers are consistency and dependability, and the open-source guidance is blunt that a stagnant project hurts the brand more than it helps. RDCO would be publishing a starter kit onto an org where ray-skills has been untouched since April and ray-plugins still advertises itself as a /hello-command example while the 13 real plugins stay private. A reader who follows the write-up's link lands on that. The write-up's core claim is "I run this system every day"; the surrounding evidence would read "and I abandoned the last two things I published." Before any new public artifact, the cheaper and more credible move is to fix the two that already exist — refresh ray-skills to current, or archive it with an honest banner, and either distribute brigade-house to ray-plugins or re-describe the public repo as the example it actually is.

One correction the write-up needs more than it needs a companion. [[2026-08-02-locked-down-corporate-deployment-playbook]] established that the phData second deployment never happened, which means the parent brief's bridge story is currently borrowed against an event that did not occur. A companion artifact cannot fix that and would draw attention to it. The fix is a re-anchor: the measured, months-long, receipt-bearing deployment RDCO actually has is the customer-zero system itself — an always-on agent the founder has run for himself continuously, with a dated audit trail of failures and the rules they produced. That is his to publish, it clears the employer boundary cleanly (it is personal, not phData work), and it makes the "show your work" pressure evaporate, because under that framing the receipts are the work. The phData-side portability ledger can still appear, correctly labelled predicted, as a forward-looking section rather than as the load-bearing claim.

Calibration, stated plainly. Two of the pillars above are reasoning, not measurement. First, nobody in this vault knows what the market wants from a solo founder in this niche; the four-repo zero-traction result is real data but it is under-determined between "artifacts don't matter" and "nobody saw them," and I have not resolved that. Second, the "receipts read as credibly as a repo" claim is a mechanism argument from published trust-signal guidance, not an A/B result — it is the more defensible bet given the cost asymmetry (an afternoon versus 13-18+ hours plus indefinite maintenance plus leak exposure), but it is a bet. What I am HIGH-confidence on is narrower and better supported: building coo-in-a-box as a prerequisite for publishing the write-up is wrong, because it converts a two-week publish into a multi-week build, strips the differentiated layer in the process, adds a maintenance liability to an org already carrying two neglected ones, and gates a positioning artifact on an engineering project that three prior briefs have each declined to start.

Next actions (build tasks, not research): (1) re-anchor the write-up on the customer-zero system and demote the phData ledger to a predicted-labelled section; (2) assemble the 4-6 verbatim receipts and run them through the redaction checklist plus the plain-grep leak gate with a fresh-eyes verifier; (3) decide ray-skills — refresh or archive-with-banner — before the write-up ships, and resolve the ray-plugins description drift; (4) pick the single publish surface per [[2026-05-05-rdco-vs-naval-get-rich-framework]]'s "don't disperse" rule rather than fanning it across three.

Why this is in the vault

This closes open follow-up #3 of [[2026-06-19-phdata-experiment-fde-positioning-proof-point]] with a NO, which unblocks the write-up: the proof point can ship on its own timeline instead of waiting behind a never-started ~13-18h repo build, and the answer removes coo-in-a-box from the FDE-positioning critical path for the third time in three months. It also supplies a fact the publish decision depends on and that no prior brief checked — RDCO's four existing public repos sit at 0 stars / 0 forks / 0 watchers with ray-skills four months stale — which converts "should we ship a companion repo" into the prior question of whether the two already-shipped public surfaces should be fixed or retired before anything new links to that org.

Open follow-ups

  1. Is artifact form or distribution the binding constraint on RDCO's public credibility? Four public repos at zero traction cannot distinguish "shipped artifacts don't move the needle for a solo operator" from "no launch was ever run." Until this is separated, every artifact-form decision is being made blind. Needs a measurement design, not another artifact.
  2. Do practitioner write-ups with embedded verbatim receipts convert differently from write-ups linking a clonable repo? The receipts recommendation rests on a mechanism argument. Find comparable cases — practitioners who published harness/system write-ups both ways — and look at what actually followed.
  3. Does a credibility proof point need an operator other than its author? The customer-zero framing has n=1 by construction. Establish whether the buyer-side trust literature's "peer validation over technical superiority" finding implies a written proof point is discounted until a second, independent person has run the system.
  4. How saturated is the personal-agent starter-kit category, and on what axis? OpenClaw, Orkas, and Avelina were surfaced from search summaries only. If a Claude-Code-native, vault-backed harness kit is genuinely differentiated on an axis those miss, the calculus changes — but that has to be verified against their actual repos, not against listicles.

Related

Sources

Vault (all also linked under Related):

Direct observation this run (checks, not citations):

Web:

Sourcing discipline note: the dev.to and ToolJet pieces were fetched and read this run. The Forrester figures, the CMU fake-stars study, and the OpenClaw/Orkas/Avelina descriptions are from search-result summaries and are cited as corroborating context, not primary-text verification — the CMU study in particular is explicitly unverified here and should not be quoted downstream as checked. No paywalls hit this run.