DCFN - Patents

Changelog

Currently v1.0.323. Engine updates surface here as they ship; older entries are kept for traceability of the trail of changes a buyer or evaluator can audit themselves.

DCFN-Patents — Engine Changelog

This log records changes to the DCFN-Patents engine itself — the reasoning pipeline that produces every landscape briefing, memo, and provisional draft you receive. Each entry is the substance of an engine release: what the pipeline now does, how output shape changed, what corpus or runtime capability expanded.

It exists so that IP attorneys, pharma R&D teams, intelligence aggregators, and any other institutional evaluator can audit the trail behind the artifacts directly — no marketing copy in between. If you are evaluating whether the engine is being actively developed against real technical depth, this page is the primary record.

Internal platform changes (sign-in flow, billing plumbing, page styling, hosting) are tracked separately and not surfaced here. This log is engine substance only.

Engine-only discipline starts at v1.0.150 (2026-05-22) forward. Pre-v1.0.150 entries — extending back through v1.0.1 and the v0.x era — were written before this rule was formalized and may carry platform substance (Stripe plumbing, copy edits, JDA contract assembly, admin console work, etc.) mixed in. A retroactive entry-by-entry classification of which pre-v1.0.150 entries are platform-only or mixed is recorded in PLATFORM_CHANGELOG.md under the "Retroactive audit (pre-v1.0.150)" section, for evaluators who want the engine-purity view of the history. Older entries are not being retroactively rewritten; the audit table is the artifact.

v1.0.318 — 2026-06-04 — Continuation-axis composite is now renderer-derived (kills the 16-vs-15 self-contradiction)

External review (Perplexity, on the PACKOUT/MODbox landscape run) caught a continuation memo whose verdict block read "Axis #1 (16/20)" while the ranked list + machine-readable axis_scores JSON read 15/20 — and the model had written a note admitting "the verdict-block figure references an earlier draft and should be read as 15/20… the JSON block is the source of truth." A number contradicting itself in the same artifact is exactly what a sophisticated evaluator catches.

Root cause: the four-dimensional composite (Centrality + Pressure + Void + Clarity) was authored by the model in four independent places — the verdict block, the ranked-axis list, the Survivability heading, and the JSON composite field — and they could drift.

Fix — the renderer is now the single authority: - Composite is derived, not trusted. _extract_axis_scores computes each axis's composite as the sum of its four sub-scores rather than reading the model's composite field, so the JSON is always internally consistent. - Every prose copy is reconciled. A new _reconcile_axis_composites pass overwrites each "Axis #N (M/20)" / "Axis #N — M/20" / "Axis #N (composite M/20)" in the body with that canonical value, so the verdict block, ranked list, and Survivability heading can never disagree with the radar. (Sub-scores like "Centrality 5/5" — anything ending in /5 — are untouched; verified offline against the exact failing strings.) - No more self-contradiction notes. The synthesis prompt now states the composite is renderer-derived and forbids any "earlier draft / should be read as / source of truth" reconciliation note — those are now both unnecessary and wrong.

Drift is structurally impossible; the radar, the verdict, and the ranked list always carry the same number.

v1.0.284 — 2026-06-03 — DRA assessment depth: confidence, integration-readiness, tier ROI, honesty surface

Four substantive additions to what the Data Readiness Assessment actually assesses — the "base-edge" definition of a DRA every DCFN build will specialize from. All deterministic (no LLM at scoring time).

Engine internals: scoring.py adds _score_relational / _compute_confidence / _collect_not_assessed; tier_assignment.py adds _compute_tier_levers; models.py carries the new fields; synth.py surfaces each. Format is unchanged (the locked DRA artifact standard); this is added reasoning, not restyling.

v1.0.198 — 2026-05-27 — FTO posture: engine-deterministic, with borderline-band honesty

What changes for the practitioner reading a memo. The Net FTO posture verdict at the top of every continuation memo is now computed by the engine, not by the language model writing the prose. The model's job becomes rendering the engine's verdict into a load-bearing sentence — it no longer interprets borderline similarity numbers into a CLEAR/WATCH/PRESSURE call on its own.

Why. Two runs of the same engine, against the same patents, would sometimes produce different FTO verdicts because the language model interpreting borderline data (e.g., highest claim-text similarity at 0.677 — a textbook gray-zone number) would land on CLEAR one call and WATCH the next. Both reads were defensible against the same data; both were wrong as a substrate property. Customers comparing memos from two runs of the same portfolio should see the same verdict.

What the engine does now. Four-band classification keyed on the highest per-claim similarity across all deep-comparison neighbors, with an isolation-validation override:

Why "borderline" surfaces explicitly. Picking a single verdict at the gray-zone band would have meant making the engine arbitrarily pick sides between two defensible reads — false certainty. Naming the band as borderline + surfacing the alternate reading in the verdict's load-bearing sentence is the more honest move: the engine commits to one calibrated default (WATCH, to flag monitorable filings) while telling the reader the call isn't black-and-white. A practitioner whose use case is prosecution-facing may legitimately treat a borderline-WATCH as effectively CLEAR; the engine surfaces both reads so the practitioner can choose without re-running.

What this fixes for you. Two memos produced from the same portfolio — one in retail mode, one through the API — will now show the same verdict for the same patents. The engine became consistent without becoming overconfident.

What stays LLM-interpreted. The prose around the verdict — the load-bearing reason, the alternate-reading clause when borderline applies, the connections to the other memo sections — is still LLM-rendered. Only the verdict-decision step itself moved into deterministic engine code. Style natural; calibration deterministic.

v1.0.174 — 2026-05-25 — Vocabulary-bridge inward-edge sketch at L1

Two external critiques (2026-05-25 "Critique on Its Own Terms" + "Patent Analysis Engine Critique") independently surfaced the same gap: when a convergence-delta bridge candidate's mean SIMILAR_TO similarity falls below the 0.65 mechanism-overlap threshold, the engine has historically flagged it VOCABULARY-BRIDGE CANDIDATE · INWARD EDGE UNCHARACTERIZED and routed the practitioner to a Layer 2 deep-run with no L1 structural read of what a filing into the gap would have to claim. Critic-1's verdict: "the most strategically significant candidates in that run — the bridge filings that would seal the arc between two foundational ML patents — are delivered without the inward edge characterization that makes them actionable. The outward edge (the gap exists) is named; the inward edge (what a filing into this gap must structurally claim and why) is deferred."

What changes

For every vocabulary-bridge candidate (convergence-delta, bridge_pair_mean_similarity ∈ (0, 0.65)), the L1 gap card now carries an engine-derived inward-edge sketch below the existing yellow vocabulary-bridge callout. The sketch is built deterministically from the canonical-element extracts (canonical_elements.py) + architectural-pattern extracts (architecture_extractor.py, v1.0.34) that the engine already runs against both anchor + cousin patents at L1. Three rows, each rendered with the actual extracted tokens:

A bridge filing into this gap structurally must claim the shared ground + at least some elements from each distinct surface — that's the operational definition of "bridge" at the claim-element level.

What it is not

The sketch is a deterministic structural read of pre-computed data; it is not a substitute for L2 deep-run characterization with PHOSITA teach-away reasoning. L2 still refines + stress-tests the inward edge against the prior-art neighbor set. What v1.0.174 fixes is the prior "uncharacterized → go run L2 and we'll tell you then" deferral. A practitioner now gets a starting locus at L1 deep enough to decide whether L2 is worth the click.

Mechanism-bridge candidates (mean ≥ 0.65) are unchanged — the existing green callout + L2 deep-run path already gives the practitioner an actionable read.

Engineering shape

Filed-IP angle

This is reduction-to-practice of the cross-patent claim-element graph topology mechanism (Bundle B Mech 2, App. 64/061,715) and the dual-axis architectural-pattern extraction shipped in v1.0.34. Both axes now feed not only the cluster-validation invariants (existing) but also the practitioner-facing bridge characterization (new).

Files: hypothesis_engine.py, render_arc.py, attribution.py.

v1.0.161 — 2026-05-23 — Route 4 SaaS / JDA full-bundle artifact contract

End-to-end verification of the Route 4 SaaS API surface (2026-05-23) surfaced that the contract was returning a fraction of what the engine produced. SaaS partners and JDA Route 6 private-enclave evaluators paid for a run and received a partial artifact set — a UX gap that mis-represents what the engine actually identifies. This release ships the corrected contract.

Engine output: every memo, every provisional

API contract: per-file manifest + bundle endpoint

Three bugs from the 2026-05-23 verification fixed

Phase 2 (async polling + webhook) captured separately

The blocking POST /api/v1/runs now takes ~15–25 min for a full bundle on a typical Tier 1 portfolio (3-4× the prior partial-bundle wall clock). Cloud Run's 60-min request ceiling still fits and the multi-tenancy floor (concurrency=80 × maxScale=3) absorbs SaaS-level volumes, but a long sync block is fragile for partner-side HTTP clients. Async-polling (?async=true) and webhook-on-completion are captured in memory/ROADMAP_FUTURES.md under "Route 4 / JDA — async-polling kickoff shape" — not shipped here so the bundle ship stays focused, but logged so it doesn't get lost.

JDA inherits this for free

Route 6 Track 2A private enclaves run the same engine in customer-isolated containers; the same route_4=True / jda=True flag pair triggers the uncapped auto-L2 path. No JDA-specific handler needed — the contract is mounted once and inherited at the engine layer.

Files

v1.0.166 — 2026-05-23 — audit_run uses real session_id (drop synthetic)

The audit_run hook in admin/engine_anomaly.py writes engine anomaly records to the engine_anomalies Firestore collection. Pre-v1.0.166, the run_id field on those records was a synthetic timestamp-based string (L1_YYYYMMDD_HHMMSS for L1 anomalies, L2_{target_label}_TIMESTAMP for L2 anomalies) generated inside the hook itself rather than the actual session_id of the customer-visible run.

This blocked correlation. During the 2026-05-23 CRISPR investigation I needed to find anomalies for a specific session (1daa506b69d7) and had to triangulate by timestamp because the synthetic id had no relationship to the real session_id. Forensics for production incidents shouldn't require triangulation.

v1.0.166:

What this enables

Future investigations can query engine_anomalies by session_id directly instead of timestamp-triangulating. The lef-admin dcfn_admin_substrate/detectors/patents.py detector (which reads engine_anomalies into the SR queue) can now join customer-visible session metadata onto the anomaly without ambiguity.

What this doesn't change

The audit logic itself, the SR escalation thresholds (≥3 same-pattern hits in 24h → P1 SR), the detection rules in audit_run. Purely a run_id field improvement.

Files

v1.0.165 — 2026-05-23 — Suppression-reasons fix-up (upstream short-circuit case)

Same-day fix-up to v1.0.164. Post-deploy smoke against real CRISPR session data from GCS surfaced an edge case: when the assignee gate fires upstream and prevents the engine from ever generating silent-region candidates, candidates.json writes suppressed_by_invariant: {} (empty) — the per-cluster suppression counts never populate because there were no clusters to evaluate. The v1.0.164 build_summary keyed has_suppression on by_invariant being non-empty, so the real CRISPR case (multi-assignee + 0 candidates + empty by_invariant) returned has_suppression: False — exactly the surface-failure mode v1.0.164 was supposed to close.

Fix: when input_is_multi_assignee=True AND candidate_count=0 AND no per-invariant counts populated, inject a single_assignee_cluster reason with count: None (gate short-circuited; per-cluster enumeration not applicable) so the surface still renders the WHY.

Tighter headline phrasing for the short-circuit case: instead of "Engine identified 0 candidate(s). 0 additional silent-region candidate(s) were suppressed..." (awkward double-zero), surfaces now read "Engine produced 0 proposed-patent candidates because the input portfolio spans 2 distinct assignees (BROAD INST INC, UNIV CALIFORNIA). Cross-assignee continuation isn't legally viable..."

Files

Lesson for future builds: smoke-testing engine-output surfaces against synthetic input alone is insufficient. Real session data shapes vary from textbook examples — the v1.0.164 synthetic test passed cleanly because I wrote the test data to match my code's assumptions. The real CRISPR candidates.json has a different shape (gate short-circuit) that the synthetic data missed. Future "surface engine state" work should validate against at least one real-data snapshot from production session storage before declaring done.

v1.0.164 — 2026-05-23 — Suppression-reasons surface (substrate-universal across retail + SaaS + JDA)

The 2026-05-23 CRISPR re-test (Broad Institute + UC California, 2 distinct assignees) returned 0 candidates. The engine was reasoning correctly — _invariant_single_assignee in hypothesis_engine.py suppresses silent-region candidates that would propose unifying claims across competing corporate assignees because cross-assignee continuation is not legally viable. The verdict reversal is in PLATFORM_CHANGELOG v1.0.164.

Engine correctness wasn't the gap. Customer-facing transparency was the gap. A SaaS partner who paid $185 for a run and a retail Tier 1 customer paying $9K–92K/yr both received an empty candidates list with no explanation. The L1 landscape briefing PDF surface already had render_arc.py:_build_assignee_notice (live since v0.14.17–v0.14.18), so attorneys reading the briefing saw the WHY. But the SaaS API, the JDA Route 6 API, and the retail /layer2/{sid} selection page all delivered the empty list with no narrative.

New canonical module: suppression_summary.py

Single source of truth that reads candidates.json:meta.assignee_gate (the field is historic; covers all invariants registered in hypothesis_engine.SILENT_REGION_INVARIANTS) and produces a stable shape every surface renders identically:

{
  "has_suppression": bool,
  "headline":         "Engine identified N candidate(s). M additional silent-region
                       candidate(s) were suppressed: the input portfolio spans K
                       distinct assignees (Broad Institute, UC California), and
                       cross-assignee continuation isn't legally viable.",
  "reasons": [
    {"invariant": "single_assignee_cluster",
     "label":     "multi-assignee portfolio",
     "explain":   "A single continuation can't legally merge claims across...",
     "count":     7},
    ...
  ],
  "distinct_assignees": ["BROAD INST INC", "UNIV CALIFORNIA"],
  "suppressed_count":   7,
  "candidate_count":    0
}

Per-invariant human-readable phrasing covers single_assignee_cluster, no_silent_region_in_kill_zone, and canonical_element_overlap; unknown invariants fall back to a sensible default so adding new gates doesn't require a customer-facing copy ship in tandem.

Three new surface points (substrate-universal)

  1. SaaS API — suppression_summary field added to POST /api/v1/runs + GET /api/v1/runs/{id} response. Partners scripting the API can branch on suppression_summary.has_suppression to render legally-correct 0-candidate explanations rather than treating empty as failure.
  2. JDA Route 6 — inherits for free via the same /api/v1/* router; no JDA-specific code path needed.
  3. Retail /layer2/{sid} page — when 0 candidates, the previously-opaque "No proposed patents surfaced" empty state is replaced (when has_suppression) with the headline + per-invariant explanations + a tone-balanced foot note clarifying that the Continuation Strategy Memos for filed patents remain available; suppression only applies to the silent-region proposed-patent track.

Two surfaces that already worked, not touched here

Why this is the actual launch-blocker, not the suspected "engine regression"

The 2026-05-23 investigation initially read as a regression in candidate generation. Forensic-trace via the engine_anomalies Firestore collection showed audit_run had been firing the zero_candidates_on_substantive_portfolio pattern 2–3 times per day on local-runner cluster sweeps since 2026-05-15 (the start of audit data). Closer read of hypothesis_engine.py:345-366 showed the suppression is intentional and legally correct — _invariant_single_assignee was added in v0.14.17 specifically to prevent the engine from recommending a continuation that no attorney could file. The cluster_queue.json CRISPR fixture predates the gate and is stale as a "should produce candidates" test (the fixture's own note describes it as testing "competing inventor groups," which is exactly what the gate now suppresses).

The gate-lift cannot proceed without this ship because a SaaS partner integrating during launch week would otherwise see opaque 0-candidate runs and reasonably assume engine failure. With v1.0.164 live, the engine's reasoning is visible at every surface a paying customer touches.

Files

v1.0.160 — 2026-05-23 — Continuation Memo Section 3 reorder (Strategic Choices + Survivability lead the Prosecution Decision)

The third v1.0.159 revision lands here as its own ship. The Continuation Memo's information hierarchy in Section 3 (PROSECUTION DECISION) is reordered at the prompt level — not post-process — so the model's reasoning is shaped by the new structure rather than retrofitted after generation.

What changed in the memo output

What did NOT ship and why

The Perplexity critique surfaced a third sub-finding — PHOSITA teach-away should be inlined in Section 2 (per-axis analysis) rather than appearing only in Section 4 (Examiner Forecast). Skipped: the inline teach-away already appears in Section 2's §103 sub-analysis as of v1.0.148's "decision before evidence" sequencing. Duplicating it inside the Section 2 axis block would force the model to either repeat the Section 4 reasoning verbatim (redundant) or generate a separate gloss (drift risk). Held as captured context for LEF Ai.E to revisit if its Phase 2 self-discovery flags it independently.

Files

Closes the manual engine-output revision lane. Per Z's 2026-05-23 directive, all future critique findings against engine outputs route to the LEF Ai.E hand-off backlog (LEF - Ai Engine/Pending-Self-Evolution-Backlog.md) rather than being shipped as manual Patents engine revisions. Phase 2 of the LEF Ai.E will run those discoveries locally first so the engine self-evolves the substrate it's built on, rather than instances patching it from outside. v1.0.160 is the last entry under the old discipline; the next time the Patents engine ships, the driving signal will be either platform/infrastructure work or LEF Ai.E-generated improvements that have cleared local validation.

v1.0.159 — 2026-05-23 — Kinetic-state on L1 gap cards + Cover Note restructure (Differentiation Memo → page 2)

Two of the three planned v1.0.159 revisions ship here. The Continuation Memo sub-section reorder (survivability check leads Section 3 + Strategic Choices opens Prosecution Decision + PHOSITA teach-away inlined in Section 2) was scoped to fit "these 3 revisions are quick" but the in-prompt restructure carries real risk of degrading the LLM's substance, not just sequence — no bandaids and no shortcuts (Z's framing) made the post-process shortcut unacceptable and the prompt rewrite needs its own focused ship. Moved to v1.0.160 as its own engine release.

Item 1 — Kinetic-state classification surfaces on L1 gap cards

The engine ships _classify_void_kinetic_state (v1.0.33, deep_run.py) which labels each detected void as stable-silence / decaying-silence / oscillatory / unknown. Pre-v1.0.159 the label only fired at L2 deep-run time — meaning a practitioner reading the L1 landscape gap card couldn't tell whether the void was a long-term moat or a closing window until they paid for an L2 deep-run.

Now: prior_art_check.py calls the same kinetic classifier at L1 candidate-enrichment time. Bordering patents = top-1 + top-2 of each candidate's prior-art neighbors (filing dates preserved via the v1.0.159 update to _domain_patent_to_hit). kinetic_state + colonization_window_months + kinetic_reason persist on each candidate in candidates_enriched.json.

Rendering: render_arc.py:build_candidates_html emits a labeled callout between engine_read_html and teach_away_html on every gap card. State-specific color treatment matches the v1.0.147 composition-validity flag pattern: - decaying-silence — amber border, body names colonization-window-months inline when known + names elevated filing urgency - stable-silence — green border, names open filing window without near-term pressure - oscillatory — purple border, names non-monotonic pressure - unknown — grey border, names that L2 deep-run carries the classification

Reduction-to-practice of Portfolio Topology Extensions kinetic-decay classification (App. No. 64/061,715) at the L1 layer alongside the existing L2 surface.

Item 2 — Cover Note structural restructure: Differentiation Memo moves to page 2

Pre-v1.0.159 the Cover Note opened with 1-3 pages of pre-filing instructions; the Prior-Art Differentiation Memo lived in the provisional's internal appendix at page 13. A practitioner opening the cover note in a pre-filing attorney meeting hit operational warnings (lexicon/art-unit routing, scope disclaimer, SHA-256 verification) before reaching the structural argument that drove the engine's recommendation. Per the Perplexity Critical Review: "The engine knows more than it shows first."

Now: - Cover Note page 1: banner rewritten from "PRE-FILING INSTRUCTIONS — READ BEFORE UPLOADING" to "⚠ NOT A FILING — REVIEW BEFORE THE PROVISIONAL" — operational-safety signal still lands first, but as a banner rather than three pages. - Cover Note pages 2-9: Prior-Art Differentiation Memo (moved here from the provisional's internal appendix). Includes the v1.0 intro paragraph + the differentiation_seeds count + the memo body, in the same shape it carried in the prior appendix location. - Cover Note pages 10-11: Pre-filing operational instructions (ATTORNEY_WARNING_CRITICAL + ATTORNEY_WARNING_STANDARD) with a pointer paragraph in the memo header noting where they live. - Cover Note page 12: SHA-256 file-pair manifest (unchanged) + sign-off.

Provisional change: assemble_docx no longer renders the internal appendix's Differentiation Memo block. The provisional now ends at the ABSTRACT page; the end-of-body attribution block remains on the provisional. Zero content loss — the Differentiation Memo lives in the cover note instead.

Signature change: assemble_cover_note_docx adds a differentiation_memo_text: str = "" kwarg. Legacy callers (none in-repo; all call sites updated) fall back to pre-v1.0.159 instructions-led structure.

What's not in this ship

v1.0.158 — 2026-05-22 — Landscape mode-awareness: framing tag, gap-card teach-away, orientation block

Critique-round 6 (Perplexity) surfaced a real architectural inconsistency: the Sprint D run_mode toggle (Prosecution / Clearance / Both) honored the customer's intake selection on the L2 continuation memo body, but the L1 landscape — including gap-card teach-away framing and the Artifact Set Orientation block — stayed in prosecution framing regardless. A customer who selected Clearance/FTO at intake would receive a memo correctly framed for FTO but a landscape whose gap cards and orientation block read as prosecution-strategy documents. This release closes that gap at three render-layer surfaces.

1. Landscape title-block FRAMING tag (render_arc.py). Mirrors the v1.0.157 framing tag on the continuation memo title block. Each landscape now carries FRAMING: Prosecution / FRAMING: Clearance (FTO) / FRAMING: Prosecution + Clearance as a small uppercase tag directly under the run-date line. The two artifact types (landscape + memo) now surface the same signal in the same typographic treatment.

2. Mode-aware Artifact Set Orientation block (render_arc.py). The block that orients the practitioner to "what the landscape names vs. what the L2 memo articulates" was previously hard-coded to prosecution framing ("Per-filing prosecution strategy — continuation-axis scoring, draft dependent claims, §112 enablement + priority-date verdicts, adversarial survivability checks, and PHOSITA-anchored teach-away arguments"). Now renders one of three variants: - Prosecution (default, pre-v1.0.158 text preserved): the existing language, unchanged. - Clearance/FTO: "Per-filing FTO read — claim-language overlap with each nearest neighbor, infringement-risk verdicts, design-around arguments, and shipper-perspective teach-away framing." - Both: combined intro naming both lenses.

3. Mode-aware one-sentence teach-away on each gap card (render_arc.py:build_candidates_html). New labeled block per gap card, rendered between the engine_read signal and the rationale paragraph. Each card asks the question the practitioner is actually trying to answer for the active run_mode: - Prosecution: "Teach-away question (Prosecution): Would a PHOSITA be motivated to combine the nearest neighbor with this proposed filing? ..." - Clearance: "Teach-away question (FTO): Does the nearest neighbor's claim language read on what you're shipping at the structural locus this candidate addresses? ..." - Both: both questions stacked, labeled.

The body of each variant points the reader at the rationale + composition-validity flag (engine's read at L1) and the Layer 2 continuation memo (where the mode-specific argument is articulated in full).

4. Session intake threaded into render_arc (app.py:run_l1_pipeline + render_arc.py:render_arc). Run-mode lives on session.intake; render_arc reads from data_dir. To bridge, run_l1_pipeline now writes a small _session_intake.json to the per-session data dir at L1 start carrying {run_mode, resolved_tier, mode}. render_arc.render_arc reads this with a safe "prosecution" default when the file is absent (preserves pre-v1.0.158 behavior for legacy sessions and direct CLI runs).

Deferred to v1.0.159 / future ship: the critique-bucket item "kinetic void label as a named field on gap cards" needs upstream architectural work (move _classify_void_kinetic_state from deep_run.py to fire at L1 candidate-enrichment time with bordering-patent filing-date inputs). Not surgical; held out of v1.0.158 to keep this ship narrow and risk-bounded.

Deferred to its own future sprint: Cover Note structural restructure ("Differentiation Memo at page 13 should be page 2 after the must-read instructions") — surfaced by the original Critical Review file but architecturally distinct from this ship.

v1.0.157 — 2026-05-22 — Artifact polish: memo framing indicator + sim-band orphan-page fix + filename reorder

Three small artifact-output adjustments surfaced by Z's review of recent runs.

Item 1 — Memo framing indicator on the continuation memo (continuation_memo_synth.py). The Sprint D run_mode toggle (prosecution / clearance / both) selects different framing prose inside the body, but the rendered PDF carried no visible top-of-document indicator of which mode the run was executed under. A reader could compare two memos and not know one was Prosecution and one Clearance without asking the engine.

Now: a small uppercase tag renders directly under the date line in the memo title block, reading FRAMING: Prosecution / FRAMING: Clearance (FTO) / FRAMING: Prosecution + Clearance per deep_record["run_mode"]. Typography matches the date and other small-caps elements in the title block; no new visual weight.

Item 2 — SIMILARITY-DISTRIBUTION REFERENCE no longer orphans on its own page (continuation_memo_synth.py). The wrapper around the band-chart heading carried page-break-inside: avoid, which combined with the SVG's typical near-page height was pushing the entire block (heading + chart) onto a fresh page whenever the body content above didn't leave full clearance. The result was a single-element orphan page — the chart alone, surrounded by white space.

Now: page-break-inside: avoid is dropped; page-break-before: avoid is added so WeasyPrint tries to keep the band attached to whatever closed out the memo body. If the body fully fills its page, the band can break legitimately onto the next page (with breathing room from the body, not as an orphan).

Item 3 — Artifact filenames sort by run, not by type (app.py:_compose_artifact_filename). Previous order: Landscape L1 T1 PUB - Patents - LEF Portfolio - abc12345.pdf. New order: abc12345 - Landscape L1 T1 PUB - Patents - LEF Portfolio.pdf. Files now sort by run identifier when listed in a download folder — useful when reviewing artifacts from multiple runs. Every artifact (L1 landscape PDF, L2 provisional .docx, L2 continuation memo PDF, cover note .docx) inherits automatically since they all flow through _compose_artifact_filename.

v1.0.150 — 2026-05-22 — Critique 5 follow-up (items 1/3/4/5 — engine output rendering)

The fifth round of external artifact-output critique (Perplexity, on the 10-patent + 431b844b UNFILED runs) identified 5 sequencing/legibility items in the engine's PDF output. Four are pure rendering fixes the engine should already have been getting right; the fifth (gap-card teach-away summaries) is a depth question deferred to LEF Ai.E self-evolution.

Item 1 — Landscape arc narrative leads the body uninterrupted (render_arc.py). The narrative was already in the top slot per v1.0.143, but thin_neighborhood_html and assignee_notice_html rendered BEFORE it — splitting the practitioner's first read into "warning → arc → cards" instead of "arc → cards". Moved both blocks to render AFTER the narrative. The thin-neighborhood callout still appears on page 1 for thin runs (just below the arc), but the arc now lands first uninterrupted. The single most-flagged item across 5 critique sessions is closed.

Item 3 — Vocabulary-bridge abstract visual differentiation (render_arc.py). The composition-validity callout (v1.0.147) labels each convergence-delta bridge as mechanism-bridge (green, mean ≥0.65) or vocabulary-bridge (amber, <0.65) — but the proposed abstract text below the callout rendered identically in both cases. v5 critique: "a flagged vocabulary-bridge abstract should read differently to the practitioner than a confirmed mechanism-bridge abstract; currently they are formatted identically." Now: vocabulary-bridge abstracts render with a PROPOSED COMPOSITION (vocabulary-bridge — inward edge uncharacterized): head + italicized cream-background preview + muted color, so they visually read as proposal-not-proven. Mechanism-bridge abstracts keep the original head + black-text preview.

Item 4 — Radar position post-process (continuation_memo_synth.py). Radar was at front per v1.0.143 but rendered BEFORE the verdict block; v5 critique wants verdict first (already at top of body_html per v1.0.124's prompt), then radar as the visual orientation for the verdict. Implemented as a post-process step: after markdown-to-HTML conversion, the radar SVG is injected immediately after the first </blockquote> close in body_html — which is the verdict block per the prompt's emit order. Other blockquotes in the memo (similarity scores aside, draft dependent claim block, survivability check block) come later and are unaffected. Sentinel-slot approach was rejected (variable-length FTO posture lines on CLEAR-with-asterisk runs would have broken it). Graceful fallback: if no </blockquote> is found (engine regression case), the radar prepends to body_html and a WARNING log fires.

Item 5 — Per-card downstream-artifact routing pointer (render_arc.py). The bridge-pointer blocks at top + bottom of the landscape told the practitioner that L2 memos + provisional drafts exist in sibling PDFs, but didn't say WHICH filing's memo + WHICH bridge's provisional carry the downstream analysis for THIS specific gap card. New per-card "Downstream artifacts" block: - Convergence-delta bridge cards: name the source patent (parsed from bridge-{patent_id}-{N} candidate_id) + the cousin filing. UNFILED-prefixed cards explicitly call out that no Continuation Memo exists (the filing isn't a granted/published patent) and route the practitioner to the provisional only. - Silent-region cards: explicitly call out that the provisional unifies the multi-filing rhyme + the per-filing memos discuss each parent individually but no single memo carries the whole bridge. - Forward-extension cards: route the practitioner to the parent filing's Continuation Memo.

Item 2 — gap-card teach-away summaries (NOT shipped, intentional defer). The v5 critique flagged that gap cards lack a one-sentence PHOSITA differentiation summary. Generating that requires per-card Anthropic reasoning — NEW computation work, not sequencing. Per the "reserved improvement surface for LEF Ai.E" framing, this is the kind of depth question the engine should self-discover later, not pre-implement now.

v1.0.148 — 2026-05-21 — Survivability check relocated into Section 3 (Perplexity v4 delta #5: prosecution-decision-first restructure)

Why this lands

Perplexity v4 surfaced the structural issue: in v1.0.147 and prior, a practitioner reading the continuation memo to decide whether to file had to wade through four pages of nearest-neighbor evidence (the original Section 3) before reaching the actionable prosecution content (axes ranked + draft dependent claims + survivability check on the lead axis). The neighbor walk is supporting evidence for the decision, not the decision itself — so the read-order inverted what the practitioner actually needs. v1.0.148 lands the prosecution decision first as a single Section 3 compound; Section 4 then carries the neighbor walk as the per-claim evidence the practitioner validates the recommendation against.

Bundled separately from v1.0.146/v1.0.147 because mishandling would regress memo quality on a content path that's currently working well — a prompt restructure of this size needs its own ship + Perplexity v5 verification pass before any further engine deltas stack on top.

What ships

Section reordering (continuation_memo_synth.py, USER_PROMPT_STATIC):

Old order (v1.0.147 and prior): - Section 1 — Position - Section 2 — Structural void - Section 3 — Nearest neighbors with teach-away inline - Section 4 — What the landscape implies / Net FTO posture (mode-dependent) - Section 4.5 — Survivability check on Axis #1 - Section 5 — Strategic choices

New order (v1.0.148): - Section 1 — Position (unchanged) - Section 2 — Structural void (unchanged) - Section 3 — The prosecution decision (compound: continuation axes ranked + draft claims on top-2 axes + survivability check on the lead axis, all inline as one decision block) - Section 4 — Nearest neighbors with teach-away inline (relocated from old Section 3; the evidence walk that the prosecution decision was built from) - Section 5 — What the landscape implies / Net FTO posture (relocated from old Section 4, no content change) - Section 6 — Strategic choices (renumbered from old Section 5, no content change)

Survivability Check relocated. The 4.5 Survivability Check block (v1.0.129 Sprint F1) now closes Section 3 inline, right after the PRIORITY-DATE TRAP block — keeping the lead-axis self-challenge attached to the lead-axis ranking + draft claim, all in one decision unit. The block's framing line was updated from "Before moving to Strategic Choices" to "Close out the prosecution decision...emit it inline here so the prosecution decision lands complete before the neighbor walk in Section 4."

_MODE_SECTION_3 dict updated to strip the leading 3. (and 3a. / 3b. for both-mode) prefixes — entries now render as a subsection inside Section 3, not their own numbered section.

_MODE_SECTION_4 dict updated to prefix entries with 5. (and 5a. / 5b. for both-mode) — entries are now Section 5.

Verdict block self-reference at the top of the memo updated: "Mirror the verdict from the Section 4.5 Survivability Check below" → "Mirror the verdict from the Section 3 Survivability Check below".

Axis-scores JSON narrative updated for the same falsification_integrity self-reference: "the score you assigned in the Section 4.5 Survivability Check above" → "the score you assigned in the Section 3 Survivability Check above (relocated into Section 3 in v1.0.148 per Perplexity v4 delta — was Section 4.5)".

Parser-side comment at the axis-scores parse path updated to point at Section 3 (with the v1.0.129–v1.0.147 historical footnote) so future maintainers reading the parser don't get redirected to a section that no longer exists.

Token-budget comment at the max_tokens declaration updated to preserve the Sprint F1 historical context while pointing at the new section location.

What does NOT change

Cross-build briefing (per feedback_changelog_is_cross_build_briefing.md)

For any future DCFN-X build that ships a multi-section LLM-generated artifact: the prosecution-decision-first principle ports forward. Whatever the artifact's load-bearing "what action does the practitioner take" content is, it lands BEFORE the supporting evidence walk — even if the evidence walk is genuinely interesting and supports the recommendation. A practitioner reading to decide is not a practitioner reading to learn; structure the artifact for the decision read, then let the evidence walk validate. Perplexity v4 named this on Patents; the same critique would apply to any DCFN-Research / DCFN-Bio / DCFN-Energy artifact that buries the call-to-action behind the analytical walk-through.

Verification

v1.0.147 — 2026-05-21 — Pricing raise (Standard $30K→$40K, Pro $72K→$92K) + composition-validity flag on bridge candidates

Why this lands

Two threads bundled into one ship: a final pre-walk-away pricing raise on the two retail Tier 1 firm-pool tiers Perplexity v4 flagged as most exposed to underpricing, and the composition-validity flag (Perplexity v4 delta #5) on convergence-delta bridge candidates. The pricing raise is the deliberate "final pricing for walk-away state" decision; Z's framing: "once we're done with this build im walking away from it unless needed. i dont want to need to come back to raise prices later." The composition-validity flag is engine-layer intellectual honesty per Perplexity: bridges generated from low-edge-weight pairs (vocabulary adjacency, not mechanism overlap) need to be flagged explicitly so practitioners don't act on un-validated compositional space.

What ships — Pricing

Standard: $30,000/yr → $40,000/yr (150 runs/yr, 12 member seats, same engine depth — $266/run).

Pro: $72,000/yr → $92,000/yr (400 runs/yr, unlimited member seats, same engine depth — $230/run).

Squad Run ($9K/20 runs), Starter ($11K/50 runs), Solo Trial ($2.5K/5 runs), Per-Seat ($7K/yr), Route 4 SaaS ($185/run + $10K minimum), Route 6 JDA ($300K base) all UNCHANGED. Named Partner tier (the $150-180K middle Perplexity proposed) explicitly NOT added — per Z: "we can let route 1 lic handle that."

Stripe TEST mode: created two new prices via /tmp/create_v147_prices.py: - price_1TZjrIQA8XXKXI4bdaBOzo00 — Standard $40K (attached to existing prod_UVAGPANiKjnxGe) - price_1TZjrIQA8XXKXI4bw5wsBxNf — Pro $92K (attached to existing prod_UVAGi6fmcZQeIq) - Old TEST prices ($30K Standard price_1TX8ccQA8XXKXI4bzWqv6nqg, $72K Pro price_1TX8ccQA8XXKXI4bM3cCTDZr) archived in Stripe. - LIVE-mode price IDs to be minted in Stripe Dashboard when Stripe returns to LIVE mode — comment-shadow in app.py updated to flag the prior LIVE prices as STALE.

Files touched (full audit per Z's "audit ALL sites" directive): - app.py line 4643-4644 — RUN_PACKS["standard"] and RUN_PACKS["pro"] price_cents + stripe_price_id swapped to new values, LIVE-shadow comments updated. - app.py line 4586 — comment from "$30K Firm Pool tier" → "$40K Firm Pool tier". - templates/pricing.html — Standard card price ($30,000 → $40,000), Pro card price ($72,000 → $92,000), pricing-summary header comment updated. - templates/buy_more_runs.html — 4 instances (Standard + Pro in two layout modes) updated to $40K / $92K. - LAYER_ARCHITECTURE.md — $9K-$72K range expanded to per-tier breakdown including the $40K / $92K raises.

TOS, refund-policy, privacy, signup, account, Firebase /licensing, Firebase /home all audited — none reference the Standard/Pro prices, no changes needed.

What ships — Composition-validity flag on bridge candidates

Per Perplexity v4 delta #5: convergence-delta bridge candidates are currently generated from ANY pair density regardless of whether the underlying SIMILAR_TO edge weights reflect mechanism overlap or merely thematic-vocabulary adjacency. The engine produces an abstract that fills the compositional space, but the abstract's geometric validity isn't characterized. Practitioners reading the card can't tell whether the bridge is a proven structural gap or a plausible-but-unverified compositional space.

Engine layer (hypothesis_engine.py):

Render layer (render_arc.py):

Queued for v1.0.148

Survivability check moved earlier in the continuation memo — prompt restructure that reorders Sections 3 (currently neighbors) and the axes-ranking + Section 4.5 survivability blocks so the prosecution-decision content (axes ranked + draft claims + survivability check on Axis #1) lands before the supporting evidence walk. Requires section-number threading across the prompt + careful Claude instruction so Axis #1 is defined before Survivability Check references it. Isolated to its own ship because mishandling could regress memo quality on a content path that's currently working well.

DCFN-Bridge pricing strategy captured

ROADMAP_FUTURES entry added: when DCFN-Bridge work spins up, anchor at $50K+ standalone OR $25K JDA add-on; pricing it below those undermines the JDA tier's $300K base.

v1.0.146 — 2026-05-21 — Perplexity v4 deltas (batch 1) + admin-test account allowlist

Why this lands

Perplexity's fourth critique pass against the v1.0.143 artifacts confirmed three sequencing fixes landed cleanly and surfaced four more deltas — three of which are template/data-layer changes that ship together here. The fifth (survivability reorder) is a prompt restructure that requires careful section-numbering threading; bundled into v1.0.147 instead so this ship stays surgical. Plus the admin-test allowlist for Z's three test accounts so future tier-gate work doesn't block him from running tests at max depth.

What ships

Item 1 — Bridge pointer at TOP of landscape (render_arc.py):

The v1.0.143 bottom-of-landscape bridge pointer carried the right content but landed on page 14 per Perplexity v4 — "a practitioner reading through the landscape may act on the bridge candidate without proceeding to the Layer 2 memo because they don't know that's where the inward edge lives until they reach page 14." Fix: short one-sentence orientation pointer added at the TOP of the landscape body (right after the narrative paragraph), full block stays at the bottom. The top pointer reads "This Layer 1 landscape names the structural gaps. Per-filing prosecution strategy lives in the Continuation Strategy Memo (Layer 2). The landscape names the gap; the memo articulates how to fill it."

Item 2 — Engine signal as a labeled card section (render_arc.py):

Per Perplexity v4: "the reason the gap candidate is positioned at this specific similarity band is either absent from the card or present only in the one-line engine signal note ('detected at a similarity-band void'). That reasoning is the engine's value. It should be the card's second section, not its footnote." The signal sentence was previously appended to the abstract preview text per v1.0.59's grounding fix — buried in the abstract text. Now: signal renders as its own labeled "Engine read" block (cream background, purple left border) at the top of each gap card's detail panel, immediately after the anchors line. Signal stripped from the abstract preview so the abstract reads cleanly as filing-language without the signal-text bleed.

Item 4 — §112 + Priority-date verdict pills (continuation_memo_synth.py):

Per Perplexity v4: "the §112 enablement and priority-date safety verdicts are embedded inline as sub-bullets within the axis narrative. These are binary prosecution decisions ('PASS' or 'FLAG' or 'YES' or 'PRIORITY-DATE WARNING'). They should be visually prominent — formatted as verdicts, not as supporting text." Now: USER_PROMPT instructs Claude to emit each verdict wrapped in a <span class="verdict-pill verdict-pass">PASS</span> or <span class="verdict-pill verdict-warn">FLAG</span> HTML tag. Memo CSS adds .verdict-pill styling — rounded inline pill, DM Sans uppercase 9pt bold, green/amber color variants depending on outcome. The markdown library's extra extension preserves raw HTML so the spans flow through unchanged. A practitioner skimming the memo for red flags sees the verdicts immediately without parsing the surrounding prose.

Item 6 — Admin-test account allowlist (app.py):

New _DCFN_ADMIN_TEST_EMAILS frozenset at module top with Z's three test emails: mzontonnia@gmail.com, thearchitect@livingedenframeworks.com, sales@livingedenframeworks.com. New helper _is_admin_test_user(request) checks the authed user's email against the allowlist. _has_run_access short-circuits to True for matched emails — bypasses all payment/subscription/firm-pool gates so Z can test the engine without firing real Stripe checkouts or being in an active firm pool. Same intent as BETA_FREE env var but per-account instead of global — doesn't open the floodgates for every visitor. Future JDA-depth surface gates (when those land in v1.0.147+) should also call _is_admin_test_user(request) to short-circuit to max-depth artifact output for these accounts.

Tier-split product principle captured (from Perplexity v4 + Z's follow-on questions)

Worth recording for the cross-build playbook: every DCFN build's output should split by tier in the same way.

The principle Perplexity surfaced: "The engine is not overbuilt for its retail tier. It is correctly built for its JDA tier. The retail output is just showing less of what it already knows than it should." Every future DCFN build (Bio, Energy, Legal, Materials, Nutrition, Crypto) inherits this tier split — retail = labels + reasons, SaaS = configurable context, JDA = full substrate.

Queued for v1.0.147

v1.0.145 — 2026-05-21 — L2 status/retry/download self-heal payment_verified (Tier 1 admin "stuck run" fix)

Why this lands

Z's two retail Tier 1 runs (sessions b0ee198ddcec + b91168b3831f, started 2026-05-21 23:26) appeared hung from the browser — page kept polling /layer2/{sid}/status and getting 402 Payment Required every 4s. The runs themselves were actually COMPLETE: current_step: "ready", step_label: "Briefing ready", all L1 + L2 artifacts marked status: "ready" in GCS. The problem was a stale payment_verified: null flag on the session state that the polling endpoint hard-gated on.

The /layer2/{session_id} page-render handler already had self-heal logic at lines 10479-10481 (added per the v1.0.x comment block at 10468): if the request carries account-level run access (_has_run_access(request) covers Tier 1 subs, firm-pool members, BETA_FREE), stamp payment_verified=True and continue. But this self-heal was only on the PAGE handler — not on the /status polling endpoint, the /retry endpoint, or the /deliverable/{kind}/{item_id} download endpoint. So a user whose browser polled /status before/during the page render hit a 402-loop with no escape.

What ships

Three endpoints get the same self-heal pattern from the page handler:

  1. GET /layer2/{session_id}/status (line 10584) — the polling endpoint that drives the "still generating" page indicator.
  2. POST /layer2/{session_id}/retry/{kind}/{item_id} (line 10688) — the retry button on failed deliverables.
  3. GET /layer2/{session_id}/deliverable/{kind}/{item_id} (line 10730) — the artifact download endpoint.

All three now follow the same shape: if payment_verified is False AND _has_run_access(request) is True, stamp payment_verified=True and continue. If _has_run_access(request) is False, still 402 (genuine unauthorized).

Recovery for Z's stuck sessions

Both sessions had payment_verified: null patched to true directly in GCS state via gsutil cp. After v1.0.145 deploys, future Tier 1 runs from Z's account auto-self-heal on first poll — no manual GCS patch required.

Audit point for cross-build pattern

Any payment-gated endpoint (status polling, retry, download, etc.) that hard-fails on a per-session payment_verified flag must include the same account-level run-access self-heal as the corresponding page-render handler. Otherwise a user with valid account-level access gets stuck behind a session-flag they never set because the session-flag write path (typically /select POST) wasn't part of how they navigated. The retail Tier 1 flow has this gap; same gap will exist on every future DCFN build that uses the per-session-flag pattern. Goes into the cross-build playbook alongside the Stripe-object .get() gotcha.

v1.0.144 — 2026-05-21 — Route 4 partner console: sign-in routing + Stripe billing portal

Why this lands

Two Route 4 console routing bugs Z surfaced after walking the end-to-end flow:

  1. After clicking "Sign out" in the partner console, the destination page rendered the correct Route 4 sign-in body (paste-key form, "Route 4 · Partner Console" label), but the shared base.html nav header carried a "Sign in" link pointing at retail /login. A partner expecting to sign back into Route 4 would click that nav link and land on the retail sign-in screen.

  2. The "Open Stripe billing portal →" link on the console pointed at /billing-portal — the retail handler. That handler runs _accounts_required() + _current_user(request), both of which check the retail account session cookie. Route 4 partners don't have a retail account (they have a console session cookie + a key record), so the call falls through to RedirectResponse("/login"). Same symptom as #1: paying SaaS partner lands on retail sign-in instead of their Stripe billing surface.

What ships

templates/base.html — nav Sign in link is now route-aware:

Adds a _is_route4_path = request.url.path.startswith('/route4/') check. When the current path is under /route4/*, the nav header Sign in link points at /route4/console/signin. Outside /route4/* it still points at /login (retail). No change for signed-in users or anon-access users — the new branch sits between the nav_has_anon_access and the final /login fallback.

New handler GET /route4/console/billing-portal:

Route 4-specific Stripe Customer Portal handoff. Reads the route4 console session via route4_console.current_partner_record(request), pulls stripe_customer_id off the partner's API key record, calls stripe.billing_portal.Session.create(customer=..., return_url=/route4/console), and 303s to the portal URL. Three failure modes are surfaced explicitly: missing session → bounce to /route4/console/signin; missing stripe_customer_id on the record (admin-issued keys, pre-Stripe-Checkout partners) → re-render the signin page with a clear error directing them to support; Stripe API failure → 502 with the same support pointer. No retail-auth dependency on the path at all.

templates/route4_console.html — billing portal link updated: /billing-portal → /route4/console/billing-portal. Same affordance, correctly authenticated path.

Queued for next sprint (per Z's surface of the design question)

Route 4 multi-user model — partner admin + dev team subusers — mirroring the retail firm admin + member seats pattern. Captured as a separate roadmap item; see ROADMAP_FUTURES.md.

v1.0.143 — 2026-05-21 — Perplexity legibility deltas #1, #3, #4 + webhook idempotency hardening

Why this lands

Perplexity's fourth pass on the engine artifacts (run against 10-patent runs on v1.0.137) re-surfaced three structural-legibility findings that have been flagged in every prior critique but hadn't moved. Plus a one-line idempotency-record bug discovered when v1.0.140's silent-failure poisoned Stripe webhook retries on Z's stuck subscription. Both bundled here.

What ships

Idempotency hardening (route4_webhook.py):

The webhook handler previously called _record_event(event_id, outcome="error", ...) after a handler exception, marking the event as "handled" so future deliveries would short-circuit at _event_already_handled(). That's correct behavior for permanent errors (don't retry-storm Stripe) but wrong for transient bugs (v1.0.140's .get() crash poisoned evt_1TZeoUQA8XXKXI4bA6YrDp3o so v1.0.141's resend silently skipped and the API key never minted — required manual /admin/route4/issue-key recovery). Fix: only record events with outcome != "error". Errored events stay un-recorded; Stripe's retry schedule (15s → 1m → 5m → 1h → 3 days) gets another chance to land a fixed handler. The error is still logged for visibility but doesn't lock out future retries.

Perplexity delta #1 — Landscape narrative promoted to page 1 (render_arc.py):

The synthesis paragraph produced by landscape_narrative_synth.py previously sat inside <section> The landscape</section> ~9 pages into the PDF. Per three successive critiques the narrative is the clearest writing in the artifact and serves as the practitioner's orientation read; burying it after gap cards + structural-exposure tables inverted the read. Now: rendered at the TOP of the body via a new narrative_html_top template slot, wrapped in a subtle cream-card visual container so it reads as orientation, not body content. build_landscape_html() no longer prepends narrative_html to its output when narrative_html is provided (caller renders it at top). Fallback bullet-list intro still fires when narrative_html is absent (graceful degradation when ANTHROPIC_API_KEY missing).

Perplexity delta #3 — Axis radar chart moved to front-of-FTO-memo (continuation_memo_synth.py):

The radar chart previously sat at the END of the memo as part of a "Visual Appendix" wrapper containing radar + similarity-band charts. Per Perplexity it should be Page 1 visual orientation, not Page N conclusion. Now: radar renders BEFORE body_html under a "Continuation axis profile" heading; the similarity-band stays at the back as reference under its own "Similarity-distribution reference" heading. A practitioner opening the memo cold now sees the axis profile shape first, reads the verdict block + Sections 1–5 with that shape already in mind.

Perplexity delta #4 — Bridge pointer in landscape PDF (render_arc.py):

Three-PDF artifact bundle (landscape + memo + provisional) had a discovery gap: a practitioner who opens only the landscape leaves without knowing that per-filing axis analysis, draft dependent claims, survivability checks, and PHOSITA teach-away arguments exist in a sibling memo PDF. Added a print-visible "What this Layer 1 landscape does not contain — and where to find it" block right after the corpus-scope banner, naming the four load-bearing Layer 2 deliverables and pointing at the Continuation Strategy Memo as their home.

Sequencing rationale

Three template/render-order changes shipped together because they all answer the same Perplexity verdict: "The repair is sequencing, not scope. The content is there." Each one moves load-bearing content from where the eye lands LAST to where the eye lands FIRST, without adding new analytical surface or changing engine output. Deltas #2 (one-line teach-away on gap cards) and #5 (composition-validity check on bridge abstracts) require engine-output additions and are scheduled for v1.0.144/+; this ship is sequence-only.

Audit point reinforcement

feedback_stripe_object_shape_gotchas.md should now also note: webhook handlers that wrap dispatch in try/except to return 200-on-error MUST avoid recording errored events as "handled" — otherwise a transient handler bug becomes a permanent retry lockout. Pattern applies to any future DCFN build with Stripe (or other vendor) webhook surfaces.

v1.0.142 — 2026-05-21 — Route 4 partner console pricing display sync ($125→$185, 80→54)

Why this lands

After Z completed the SaaS walkthrough and signed into the partner console with his minted key, the Usage block at the top of the dashboard showed stale pricing: PER-RUN PRICE $125.00, % of 80 runs covered, Above the 80-run cap — metered at $125/run. Same bug class as the v1.0.138 fix on route4_signup.html line 33 — backend math in api_usage.py was correctly at PRICE_PER_RUN_CENTS = 185_00 / RUNS_TO_REACH_MIN = 54, but the templates lagged. Customer-facing math contradiction in the first surface a paying partner sees post-checkout.

What ships

templates/route4_console.html: - Engine runs subtitle: % of 80 runs → % of 54 runs - Projected bill "above cap" branch: Above the 80-run cap — metered at $125 / run → Above the 54-run cap — metered at $185 / run - Per-run price stat: $125.00 → $185.00 - Per-run price subtitle: billed monthly in arrears for runs above 80 → runs above 54

templates/api_docs.html: GET /api/v1/usage example response body updated — metered_usd: 7770.0 (42 × $185) (was 5250.0 (42 × $125)), price_per_run_usd: 185.0 (was 125.0), and the prose line Above 54 runs/month, minimum_applied flips to false (was Above 80).

Firebase /licensing page (separate deploy)

Added Partner Console sign-in link next to the partnership CTA, with the invitation-gate disclaimer demoted to its own line under both:

Routes existing partners (who already have a key) directly to sign-in, while prospects coming for the first time still land at /route4/signup. Same affordance pattern as Tier 1's Sign-in / Sign-up split.

v1.0.141 — 2026-05-21 — Route 4 webhook hotfix 2 (downstream Stripe-object .get() bug)

Why this lands

v1.0.140 fixed .get() on the top-level event payload, and the webhook stopped crashing with 500. But Z's API key still didn't get minted — webhook returned 200 with no_partner_id because the _handle_payment_succeeded handler also calls stripe_client.Subscription.retrieve(sub_id) which returns a fresh StripeObject; the next sub.get("metadata") raised AttributeError, the wrapping try/except swallowed it (returns 200 to prevent Stripe retry-storm), and the key never got minted. Verified by querying the Stripe subscription directly — metadata IS populated (lef_attempt_id=rt4attempt_fdb5fb7fa7d44c); the handler just couldn't read it.

What ships

New helper _retrieve_as_dict() in route4_webhook.py — wraps any Stripe SDK retrieve call and converts the returned Stripe object to a plain dict via to_dict_recursive(). Same pattern as v1.0.140 but applied at the per-call boundary inside handlers, where v1.0.140's entry-point conversion can't reach (fresh retrieves bypass the event payload).

Patched call sites: - _handle_payment_succeeded → sub = _retrieve_as_dict(stripe_client.Subscription.retrieve, sub_id) - _handle_payment_succeeded → customer = _retrieve_as_dict(stripe_client.Customer.retrieve, sub.get("customer")) - _discover_overage_subscription_item → same pattern for the metered-overage lookup

Removed defensive branches that were trying to handle the StripeObject-vs-dict ambiguity (if isinstance(md, dict): ... else: getattr(...)). Now everything that flows through _retrieve_as_dict() is guaranteed a dict; the defensive branch was symptom-treatment of the actual problem.

Audit point reinforcement

Add to feedback_stripe_object_shape_gotchas.md: any DCFN build that uses Stripe SDK retrieve calls should wrap them in a _retrieve_as_dict() helper at every site, OR migrate the entire codebase to use attribute access. The half-fixed state (mix of .get() and getattr()) is the worst of both worlds because exceptions get caught and swallowed, leaving silent failures.

Recovery for Z's stuck subscription

Z's sub_1TZeoMQA8XXKXI4bq45Om2rn subscription is paid + active in Stripe; only the key issuance is stuck. Once v1.0.141 deploys, the same Stripe API resend (POST /v1/events/evt_1TZeoUQA8XXKXI4bA6YrDp3o/retry) will fire successfully and mint + email the key.

v1.0.140 — 2026-05-21 — Route 4 webhook hotfix (stripe-object .get() bug)

Why this lands

Z walked Route 4 end-to-end: signup + Stripe Checkout completed cleanly, but the API key never arrived by email. Webhook logs showed three consecutive 500s on /webhook/stripe/route4 with traceback ending at route4_webhook.py:98 — event.get("id", "") raising AttributeError: get.

Root cause

Stripe Python lib 15.x exposes Stripe objects via attribute access only — .get() raises AttributeError. The stripe.Webhook.construct_event(...) call returns a stripe.Event object, not a dict. The downstream code in route4_webhook.py (this file + handler functions) uses .get() and dict-bracket access extensively on the event + event["data"]["object"] nested Stripe objects, none of which works on a Stripe object.

This is exactly the feedback_stripe_object_shape_gotchas.md cross-build briefing — same gotcha bit Patents + Research on 2026-05-10 and bit the v1.0.138 product-cleanup script earlier today. I should have audited for it before wiring the webhook; ownership on me.

What ships

route4_webhook.py:handle_webhook — immediately after stripe.Webhook.construct_event(...), convert the Stripe Event object to plain Python dicts via to_dict_recursive() (falls back to to_dict() if recursive isn't present in the lib version). All subsequent .get() and event["data"]["object"] access in the file then works because everything is a regular dict from that point on. Minimal-blast-radius fix — one converter call instead of rewriting every handler.

Audit point for every DCFN build going forward

At every Stripe-touching site in a DCFN build (webhook entry, API response object handling, anywhere a Stripe SDK call returns an object), convert to a dict BEFORE using .get() or dict-bracket access. Codify in the next feedback_stripe_object_shape_gotchas.md revision so the cross-build briefing now also flags webhook-entry conversion specifically.

Recovery for Z's prior-failed attempt

Stripe auto-retries failed webhooks at increasing intervals (15s → 1m → 5m → 1h → up to 3 days). Once v1.0.140 deploys, the next retry of Z's invoice.payment_succeeded event for cus_UYmM6Ukf1KSuYD / sub_1TZeoMQA8XXKXI4bq45Om2rn should land cleanly: API key gets minted in Firestore + delivered to prewalk-test@example.com (the partner email Z used). If for some reason Stripe doesn't retry quickly, the Stripe Dashboard → Developers → Webhooks → "Send test webhook" can re-trigger from the existing event, OR /admin/route4/issue-key can mint the key manually.

v1.0.139 — 2026-05-21 — Buy-more-runs button cleanup + Purchase Seats button repositioned

Why this lands

Z review of the firm-account + buy-more-runs pages flagged three UX inconsistencies that confuse the actionable surface for partners deciding to top up runs or invite teammates.

What ships

templates/buy_more_runs.html:

templates/firm_manage.html — Purchase Seats button repositioned:

Firebase /licensing page Route 4 routing sync

(Separate deploy — same Z review, captured here so the change set is discoverable in one place.) Firebase /licensing previously routed Route 4 CTAs to mailto:sales@livingedenframeworks.com with a "Self-serve API intake under construction" hedge. The pricing page already routes Route 4 to /route4/signup (the invite gate v1.0.136 landed). Aligning the licensing page to the same destination so prospects coming in from /licensing land at the same gated self-serve flow:

v1.0.138 — 2026-05-21 — Route 4 SaaS walkthrough unblocked (Stripe TEST products + API-version pin + pricing-sync)

Why this lands

Pre-walking Route 4 surfaced three blockers that prevented end-to-end SaaS walkthrough in Stripe TEST mode:

  1. Stripe price IDs not configured. STRIPE_PRICE_ROUTE4_COMMITMENT and STRIPE_PRICE_ROUTE4_OVERAGE env vars were unset on Cloud Run; POST /route4/signup returned 503 ("Route 4 not yet open for self-serve signup"). The runbook (runbooks/ROUTE4_STRIPE_SETUP.md) was explicit that product creation awaited Z's greenlight.

  2. Pricing inconsistency in templates/route4_signup.html. The page headline correctly quoted $185/run (post Batch B raise) but the "In practice" callout on line 33 was stale at $125/run with 80-runs prepaid math. Customer-facing math contradiction.

  3. Stripe API version mismatch on metered billing. Stripe v2025-03-31.basil flipped subscriptions to billing_mode.type=flexible and started rejecting legacy usage_type: "metered" prices ("metered prices must be backed by meters"). Route 4's metered-overage reporting (route4_webhook.report_usage_to_stripe) uses SubscriptionItem.create_usage_record — the legacy reporting path. Without pinning the API version, Checkout Session creation 502'd.

What ships

Stripe TEST products + prices created. Script /tmp/create_route4_v2.py (one-shot, not committed) used the sk_test_* key from Secret Manager directly (bypassing the Stripe MCP per runbook warning about LIVE-mode risk). Created: - Product prod_UYm0MctdKAlxa5 — "Route 4 — Monthly Commitment"; price price_1TZeS1QA8XXKXI4bVNlA5rgv ($10,000/mo flat recurring). - Product prod_UYm0Q7mjXlVLjs — "Route 4 — API Run Overage"; price price_1TZeS2QA8XXKXI4bVR5Wrnyc (metered, graduated tiers: 0–54 runs @ $0, 55+ @ $185). - Both carry metadata={"lef_route": "4", ...} for future lookup.

Env vars wired on Cloud Run (revision dcfn-patents-00244-gp2): - STRIPE_PRICE_ROUTE4_COMMITMENT=price_1TZeS1QA8XXKXI4bVNlA5rgv - STRIPE_PRICE_ROUTE4_OVERAGE=price_1TZeS2QA8XXKXI4bVR5Wrnyc

app.py Stripe init updated to pin stripe.api_version = "2025-02-24.acacia" — the last release where legacy metered prices + SubscriptionItem.create_usage_record reporting work without migration to the new Meter API. Comment in code references the migration as a deferred long-term move.

templates/route4_signup.html line 33 updated to match Firebase licensing page canonical pricing: $185/run, 54 runs prepaid, 60-run example invoice = $10K + 6×$185 = $11,110.

runbooks/ROUTE4_STRIPE_SETUP.md updated end-to-end to reflect $185/54-runs pricing (was $125/80-runs). Path A Python code, Path B Dashboard steps, and Stripe shape recap all consistent with the Firebase licensing page.

Still required before SaaS walkthrough is fully bookable

Migration debt

Route 4 metered overage will need to migrate from legacy usage_type: "metered" + SubscriptionItem.create_usage_record to the new Meter + MeterEvent API. The pin to 2025-02-24.acacia is a transitional escape hatch; Stripe will deprecate that version eventually. Migration scoped at: - Create a Stripe Meter object (event_name = route4_engine_run) - Recreate the Overage price with recurring.meter=meter_id (no usage_type) - Update route4_webhook.report_usage_to_stripe to post MeterEvent instead of SubscriptionItem.create_usage_record - Test, ship, swap the Overage price env var - Remove the API version pin

Not on the current critical path; revisit before Stripe officially removes the 2025-02-24.acacia version. The pin keeps current production behavior identical to pre-v1.0.138.

Pre-walked, end-to-end (post-deploy)

v1.0.137 — 2026-05-21 — Anthropic prompt caching on continuation memo (substrate pattern for every DCFN build)

Why this lands

Tier 2 continuation memos run Opus 4.7 with ~13K input tokens and ~6K output tokens per memo. Per 5-memo Tier 2 run, input cost alone is ~$0.98 and output is ~$2.25 — output dominates, but input is the lever we can reduce without diluting analytical depth. A rank-aware Opus→Sonnet model swap was prototyped first (would have cut total cost ~60%) and walked back after re-reading three external critique docs that explicitly named the continuation-memo depth as the engine's load-bearing differentiator versus PatSnap and Perplexity. The right lever is reducing input cost via prompt caching — same model, same depth, ~10% cheaper per run, and the pattern ports straight to LEF Ai.E, DCFN-Research, and every other Claude-API-calling DCFN build.

What ships

Prompt restructured into static-prefix + dynamic-suffix in continuation_memo_synth.py:

Why this works (and what it doesn't fix)

Anthropic prompt caching marks the end of a cacheable prefix with cache_control. Any subsequent request whose prefix bytes match exactly through that point reads the cached portion at ~10% of normal input cost. Within a Tier 2 run, all 5 memos share the same mode_framing / mode_section_3 / mode_section_4 substitutions (the run carries one run_mode from intake), so the static prefix is byte-identical → memos 2..N read the cache.

Parallel execution caveat: the L2 worker pool fires memos via ThreadPoolExecutor with L2_GEN_CONCURRENCY workers. When N memos fire concurrently, all N pay the cache write cost — none can read what the others are still writing. The cache write becomes the new normal first-memo cost; reads accrue only when subsequent memos hit a populated cache. Real-world hit rate depends on the gap between memo dispatch times: serialized = full hits, fully parallel = full misses. Cross-session hits also fire when any two sessions in a 5-minute window use the same run_mode. A follow-on v1.0.137+ could add max_tokens=0 pre-warming before the parallel dispatch to guarantee reads on memos 2..N; deferred until production cache telemetry shows the actual hit-rate floor.

Cost shape per Tier 2 run (back-of-envelope)

Cross-build portability

The pattern this lands — split prompt into static-framing + dynamic-data blocks, mark static with cache_control, verify via usage.cache_*_input_tokens — is universal across DCFN builds:

The CHANGELOG entry exists to brief the next build on the move; the implementation in continuation_memo_synth.py exists as the reference.

Backward compatibility

The single rendered prompt (static block + dynamic block concatenated, byte-identically to the pre-v1.0.137 single USER_PROMPT modulo the coverage_caveat repositioning) produces the same memo content the engine has been producing. Smoke-tested locally against session 6682ca5b deep records; cache_write on call 1, cache_read on call 2 confirmed before ship.

v1.0.136 — 2026-05-21 — Route 4 invite-code gate (decoupled from Tier 1 Founding Cohort)

Why this lands

Route 4 (/route4/signup) was inheriting DCFN_SIGNUPS_GATED — the Tier 1 Founding Cohort gate. Tier 1 retail (Founding Cohort) and Route 4 SaaS are different audiences with different intake patterns; collapsing them under one gate flag blocked Route 4 prospects who weren't in the Founding Cohort. Z asked for Route 4 to have its own invite-code gate so an end-to-end SaaS walkthrough (including Stripe TEST mode) is possible without disabling the Tier 1 gate.

What ships

Two new helpers in app.py:

/route4/signup GET handler: - Replaced _signups_gated() (Tier 1 Founding Cohort) with the Route 4 invite-code check. - New ?invite=CODE query parameter passes the code via URL. - If gate is enabled AND code is missing/invalid → renders route4_invite_gate.html (200 if missing, 403 if invalid). - If gate disabled OR code valid → renders normal route4_signup.html with invite template variable.

/route4/signup POST handler: - Replaced _signups_gated() check with invite-code validation from the new invite form field. - Direct POSTs without valid code → 403 with the gate page.

templates/route4_invite_gate.html (new): - Simple code-entry form. Posts via GET to /route4/signup?invite=CODE. - Renders error message inline if previous attempt had wrong code. - Includes fallback to sales@livingedenframeworks.com for prospects without a code.

templates/route4_signup.html: - Added hidden <input name="invite"> to preserve the code through GET → POST.

Operator action

To enable the gate in production, set the env var on Cloud Run:

gcloud run services update dcfn-patents \
  --region=us-east4 --project=lef-ai-patents \
  --update-env-vars DCFN_ROUTE4_INVITE_CODE=<your-code>

To disable (open Route 4 to all):

gcloud run services update dcfn-patents \
  --region=us-east4 --project=lef-ai-patents \
  --remove-env-vars DCFN_ROUTE4_INVITE_CODE

Partners receive invitation URLs of the form: https://patents.livingedenframeworks.com/route4/signup?invite=<code>. The hidden form field preserves the code through the Stripe Checkout flow.

Verification

Offline smoke: gate disabled (env unset) accepts any input. Gate enabled rejects mismatched / empty / None inputs; accepts matching code with whitespace stripped. Constant-time comparison via hmac.compare_digest.

End-to-end walkthrough is the production verification — Z sets the env var, walks /route4/signup?invite=... → form → Stripe TEST Checkout → webhook → API key issuance → console signin → API call → artifact retrieval.

What this is NOT

v1.0.135 — 2026-05-21 — Hotfix: production L1 failure (date-suffixed Haiku model name)

What happened

Z fired two verification runs on v1.0.134 (session c66b5aeaf56c, both Memo Framing modes). Both failed at the landscape_narrative pipeline step with the humanized "Engine generation failed" message. No retry button on the L1-generating page made the failure UX worse — refresh landed back on the run page without a retry CTA.

Diagnosis

Telemetry from /admin/lookup?q=c66b5aeaf56c showed the landscape_narrative stage rolled up to 1 call · 0 input tokens · 0 output tokens · 1 error · 112ms duration · error_class BadRequestError:400. Zero-token + 400-status + 112ms-fast-fail is textbook "model name invalid" — Anthropic rejects the request at validation before processing.

Root cause: four modules carried the date-suffixed Haiku model name claude-haiku-4-5-20251001. The date-suffixed variant was apparently deprecated by Anthropic; the bare name claude-haiku-4-5 still works (verified via domain_scan.py:969 which had already migrated and was running successfully in the same pipeline before landscape_narrative fired).

Pipeline order is ... domain_scan (bare name, OK) → hypothesis → prior_art → memo_pitch_synth (date-suffix, soft-fail-allowed, likely silent fail) → landscape_narrative_synth (date-suffix, hard-fail, killed the run) → .... The asymmetry between soft- and hard-fail at the same root cause hid the bug from the earlier silent-fail stage.

What ships

Bare model name claude-haiku-4-5 in 4 modules: - memo_pitch_synth.py:38 - landscape_narrative_synth.py:29 - render_arc.py:1414, 1424, 1436 (3 call sites)

The pricing dict in app.py:4070 keeps both entries (bare + date-suffixed) so historical telemetry records using the old name still resolve to correct cost estimates. The _model_pricing helper already normalizes date-suffixed variants to bare-name lookup with the YYYYMMDD-strip pattern; that fallback works regardless.

What this is NOT

Verification

Offline: AST clean. Bare model name confirmed in all 4 modules; no date-suffixed reference left in landscape_narrative_synth.py, memo_pitch_synth.py, or render_arc.py Haiku call sites. The price dict + comment in app.py retain the date-suffixed string for telemetry-back-compat lookups only.

Production verification: Z retries his run on v1.0.135.

v1.0.134 — 2026-05-20 — SaaS payment-failed / sub-cancelled API key gating

Why this lands

Z's Batch C #4 answer: on Stripe payment_failed after retries exhaust → gate API keys; on subscription_cancelled → end-of-period gate. Before this commit, the Stripe webhook handler updated firm subscription status (past_due / cancelled) but did NOT touch Route 4 API keys — meaning a partner whose subscription was cancelled or whose payment had failed kept full API access until manually revoked. This closes that commercial-readiness gap.

What ships

api_auth.py — three new helpers:

  1. gate_keys_for_subscription(stripe_subscription_id, reason, note) — marks ALL active Route 4 API keys for a given Stripe subscription as gated. Status becomes gated_payment_failed or gated_cancelled (validates reason). Idempotent: skips keys already in a non-active state (won't overwrite revoked → gated). Returns count of keys updated.

  2. reactivate_keys_for_subscription(stripe_subscription_id, note) — un-gates keys for a subscription whose payment status has recovered. Only flips gated_payment_failed back to active. Does NOT touch gated_cancelled (cancellation is intentional; recovery requires re-subscription + new key issuance) or revoked (manually-revoked is final). Preserves prior gating event in previous_gating audit field.

  3. get_gating_status(api_key_lookup_id) — for request-time error handlers to produce a useful 402 response naming the gating reason instead of a flat 401 from verify_bearer's existing status check.

app.py — webhook handler wiring:

Existing verify_bearer behavior

Unchanged. It already rejects any status != "active", so gated_payment_failed and gated_cancelled are naturally rejected. The new get_gating_status helper is the surface for upgrading 401 → 402-with-reason in caller-friendly error handlers (downstream work, not in this commit).

What this is NOT

Verification

Offline: AST clean on api_auth.py + app.py. Helpers smoke-test: invalid reason raises ValueError; empty sub_id returns 0 without touching DB. Production verification requires a real Stripe webhook event — defer until a real Tier 2 partner exists (or send a TEST-mode webhook from Stripe's CLI for full validation).

v1.0.133 — 2026-05-20 — Hotfix: revert billing@ collapse + fix internal verifier_email

Why this lands

Z called v1.0.132's email consolidation a bandaid in the billing@ context. The original billing@livingedenframeworks.com references were all genuinely billing-context (invoice/PO arrangements, refund inquiries, Stripe subscription cancellation contact) — collapsing them to support@ erased the semantic distinction the customer needed. The right move is to keep the semantically-correct address and add it as a Workspace alias.

What ships

What stays (the legitimate v1.0.132 changes)

Z action: create these aliases in Google Workspace

Currently configured: sales@, support@, licensing@, TheArchitect@, noreply@ (outbound).

Need to be created: - billing@livingedenframeworks.com — for invoice/PO arrangements, refund inquiries, Stripe subscription cancellation. Used in 4 customer-facing surfaces.

That's the only must-create. Other addresses (hello@, partnerships@, legal@ for non-JDA legal context) can be added later if traffic warrants.

v1.0.132 — 2026-05-20 — Batch A surface text edits + email alias consolidation

Why this lands

Z surfaced a batch of customer-facing text edits from his marketing-page walk plus an email-alias audit (only sales@, support@, licensing@, TheArchitect@ exist in Workspace; code referenced six other addresses that would bounce). v1.0.132 ships the consolidation + the text edits as one focused commit.

What ships

Email consolidation (live aliases only): - billing@livingedenframeworks.com → support@ (app.py, firm_create, account_delete, refund_policy) - legal@livingedenframeworks.com → licensing@ (JDA crypto-erasure attestation + renewal templates — formal contract context) - admin@livingedenframeworks.com → sales@ on Route 4 prospect-facing signup; → support@ in api_docs.html + app.py (customer/operator-support contexts) - noreply@ kept (outbound-only)

Patents intake form (templates/index.html): - Patent-numbers placeholder: removed "— or — one per line" segment per Z direction; placeholder now shows only semicolon-separated and comma-space-separated examples - Landing page "Real patent corpus, not a language guess" cards: added "When resources allow we plan to open this directly to Tier 1 users." italic note to both International Corpus + NPL cards - NPL card body text trimmed (~50 words removed) to approximate the International Corpus card's length

Patents pricing page (templates/pricing.html, Route 4 card): - "Or start a conversation if you have questions first" mailto secondary link PULLED — self-serve signup is the only path now - 30-day SaaS billing language clarified: "$10,000 USD/30-day-window minimum commitment... Billing windows are anniversary-based 30-day cycles (e.g., 3/1/26 — 4/1/26), not calendar-month billing." - Full artifact delivery note added: "SaaS partners receive every produced artifact for a run at once (L1 landscape + every L2 memo + every provisional + cover note). Retail Tier 1 customers click through to select which L2 artifacts to purchase; Route 4 partners get the full set."

Patents buy-more-runs page (templates/buy_more_runs.html): - Bundle name eyebrow labels surfaced above each pack card: Solo Trial (+5), Squad Run (+20), Starter (+50), Standard (+150), Pro (+400). Applied to both layout branches (solo_first + ladder). The /account landing page already shows which bundle the user signed up for; this surfaces the name on the purchase decision too.

Engine logic untouched

No prompts changed, no memo/landscape rendering changed, no auth changed, no Stripe wiring changed. Pure surface text + email consolidation.

Architecture doc updates (no code; captured in ~/Desktop/Runs on LEF Patents/LEF Ai.E — Engine Architecture & Product Reality.md)

What this is NOT

v1.0.131 — 2026-05-20 — memo synth max_tokens 6000 → 8000

Why this lands

Z asked why runs felt slower after the Sprint F1 + verdict-block 4th line work. Telemetry from /admin/costs confirmed: per-call output sat at 5,500–5,990 tokens — essentially at the v1.0.119 6,000-token cap. The Survivability Check (v1.0.129) added ~400–700 required output tokens; the verdict block 4th line (v1.0.130) added another ~30–50. The cumulative budget pressure was forcing memos to compose to budget, and at least one observed memo:* stage ran 5 calls instead of 4 — consistent with an axis_scores JSON truncated before the closing fence forcing a retry.

What ships

Single-line change in continuation_memo_synth.py: max_tokens=6000 → max_tokens=8000. Comment block updated with the v1.0.131 rationale + telemetry context. The bump removes cap pressure on the longest memos without changing typical output length — substantive memo content has its own natural cap that's below the budget.

What this is NOT

Not a prompt change. The Survivability directive, verdict-block 4th line, kinetic_state schema, and structural void callout all stay exactly as v1.0.130 ships them. The bump just gives Claude room to compose them without compression.

Verification

Offline: AST clean; max_tokens constant verified at 8000. Production verification on next L2 run: confirm no truncated-axis_scores retries; confirm per-call output averages stay in the 5,500–6,500 range rather than crowding to budget.

Cost impact

Marginal. Opus output bills at $75/MTok; the bump permits up to 2,000 additional output tokens per call IF Claude uses them. Real-world impact: Claude composes to substance, not to budget — typical L2 memos should continue emitting 5,500–6,000 tokens with the new cap just acting as headroom. At worst +$0.15/memo if a particularly dense filing uses the full new headroom.

v1.0.130 — 2026-05-20 — Survivability surfaces in verdict block + charter rule for Sprint F+

Why this lands

An outside critic stress-tested v1.0.129's Survivability Check and named the failure mode the work risked walking into: "Each Sprint F+ addition risks becoming more complete and less readable simultaneously if the load-bearing conclusion only lives in the deeper section." v1.0.129's Survivability Check was correctly at Section 4.5 — but the CONCLUSION (does Axis #1 survive? YES / WEAK / NO) was load-bearing enough that an attorney reading the verdict block in the first 90 seconds should see it without scrolling.

v1.0.130 surfaces the conclusion at the verdict layer + codifies the discipline as a charter rule going forward.

What ships

Verdict block grows from 3 lines to 4:

> FTO posture: ...
> Structural void state: ...
> Lead continuation axis: Axis #1 (N/20) — ...
> Survivability: YES / WEAK / NO — one short clause   ← NEW

The new Survivability line mirrors the verdict from Section 4.5's Survivability Check (same falsification_integrity score, one-clause restatement of survives-or-doesn't). The full strongest-attack reasoning + integrity score 1-5 stays in Section 4.5 as supporting evidence. The conclusion lands at the verdict layer where the practitioner's first-90-seconds eye lands.

Charter rule for Sprint F2-F4 going forward

Every Sprint F+ analytical addition lands its CONCLUSION at the verdict layer and its DERIVATION in supporting sections. Without this discipline, each engine-depth increment ships as "more complete and less readable simultaneously" — re-creating the pre-v1.0.124 buried-reasoning failure mode at a deeper architectural layer.

Applied concretely to queued Sprint F work:

What this is NOT

Not a refactor of the four sections behind the verdict block. The body content stays where it lands today; only the verdict-block summary grows. The pattern is summary at the top, full reasoning in the section — not duplicate content, but extracted conclusion.

Verification

Offline: all three run_modes format cleanly with the new 4-line verdict block. AST clean. Production verification on next L2 run: confirm the Survivability line appears as the 4th line of the verdict block, mirroring the Section 4.5 verdict.

v1.0.129 — 2026-05-20 — Sprint F1: Adversarial Survivability Check on lead axis

Why this lands

Critique 2 named the engine's deepest underdeployment: "the adversarial traversal mode disclosed in App. 64/061,710 (Cross-Engine Topological Dynamics) outputs a falsification-integrity score." The engine's teach-away arguments were rigorous but operated in confirmation mode — the engine asserts a void survives without explicitly constructing the strongest attack against it. v1.0.129 begins surfacing operation #4 (observer-state) in adversarial-traversal form: the engine actively challenges its own lead continuation recommendation.

Mechanism described in App. No. 64/061,710 is genuine engine work (contradiction-graph traversal under falsification-anchor termination); v1.0.129 ships the artifact-layer surface — the customer-facing survivability check — at prompt level. Literal graph implementation deferred to follow-on engine work if/when artifact-side surface motivates it.

What ships

  1. New Section 4.5 — SURVIVABILITY CHECK on Axis #1. Lands immediately after the ranked continuation axes (Section 4), before Strategic Choices (Section 5). Format prescribed in the prompt:
  2. Strongest attack: 2-3 sentences constructing the most damaging argument an examiner or opposing-counsel would mount against the lead axis. Names the specific obviousness combination, §103 motivation, prior-art reference, or §112 written-description challenge. No hedging — written as the examiner would write it.
  3. Survives? YES / WEAK / NO with one short sentence.

  4. Falsification integrity: 1-5 score (5 = survives cleanly; 1 = does not survive, lead recommendation should be reconsidered).

  5. falsification_integrity field on rank-1 in axis_scores JSON. Optional field (only emitted for the lead axis; absent on rank 2/3/4 since survivability check is performed only on the axis the attorney will actually file against).

  6. Parser threads it through. _extract_axis_scores accepts the new field; clamps to 1-5; defaults to None when missing (backward-compat with pre-v1.0.129 axis_scores blocks); out-of-range values clamp rather than reject.

What the practitioner now sees

Section 4 ranks the continuation axes. Section 4.5 immediately makes the engine challenge its own rank-1 recommendation: here's the strongest attack a skeptical examiner would make against Axis #1, and here's whether the axis survives. Converts the lead recommendation from "we think you should file here" to "we think you should file here AND here's why this position survives the strongest attack we can construct against it."

That's the load-bearing differentiator versus AI-generated recommendations that assert without challenging — which is exactly what App. 64/061,710's adversarial traversal mechanism describes.

What this is NOT

Verification

Offline: all three run_modes (Prosecution / Clearance / Both) format cleanly with the new Section 4.5 prompt directive. Parser threads falsification_integrity for rank-1 (defaults to None on rank-2+); out-of-range values clamp to [1,5]. AST clean.

Production verification: fire a real L2 run; confirm Section 4.5 lands between Section 4 (axes) and Section 5 (Strategic Choices) with the Strongest attack / Survives? / Falsification integrity structure populated by Claude.

Sprint F sequence

This is F1 (Adversarial Survivability). Remaining F work: - F2: Full void-kinetics (App. 64/061,715) — monotonic-decay detection over a real rolling window; replaces the 2-point heuristic the closing limits line currently names as a limit. - F3: Cross-engine reasoning protocol (App. 64/061,710 Mechanism 1) — NPL bridge that converts "recommend a parallel human NPL sweep" hand-off into a specific engine-derived target list. - F4: Provenance-weighted gravity (App. 64/043,294) — neighbor edges weighted by source-document evidence quality (granted vs published, examined vs unexamined, litigated vs untested) instead of flat cosine.

v1.0.128 — 2026-05-20 — L1 nearest-competitor callout promoted to top

Why this lands

Per critique 4 (2026-05-20): "The 'Nearest Competitor to Your Portfolio' callout — the single patent that lands closest to any filing and therefore represents the highest-urgency claim-by-claim comparison trigger — appears as a two-sentence paragraph on page 5 of the Landscape. This is the one piece of landscape data most likely to drive an immediate attorney conversation. It deserves a prominent callout block at or near the top, immediately after the portfolio summary."

v1.0.128 promotes it.

What ships

  1. New _build_nearest_competitor_callout function in render_arc.py — produces a prominent left-accent callout block naming the closest external patent across the entire portfolio: which user filing it sits closest to, the cosine similarity (both numeric and percentage), and a one-clause band classification (real overlap pressure / thematic adjacency / loose word-level overlap).

  2. Band-aware color coding — accent color and background tint shift with the similarity band: red accent + faint red bg above 0.70 (pressure), amber accent + cream bg in 0.50–0.70 (adjacency), purple accent + lavender bg below 0.50 (loose). Practitioner reads urgency at a glance.

  3. Always-on rendering — unlike the kill-threshold callout (which fires only above pressure) and the thin-neighborhood callout (which fires only below adjacency), this callout fires unconditionally whenever nearest_competitors data exists. Practitioner always sees their closest competitor regardless of where it sits in the band system.

  4. Injected at top of L1 — right after assignee_notice_html, above candidates_html (the proposed-patent cards moved up in v1.0.126). Page-1 visibility, no scrolling required.

What stays

The existing in-body "Nearest competitor" paragraph (inside build_landscape_html) stays for now — it provides longer contextual narration about how the closest competitor relates to the surrounding cluster. The new top-of-page callout is the prominent verdict; the in-body paragraph is the expanded reasoning. Future pass may dedupe.

The kill-threshold callout (above 0.70 pressure with DON'T-PURSUE prescriptive framing) is unchanged — different semantics (action signal, not data signal).

What this is NOT

Not the full L1 two-tier PDF split (peel Layer 2 second-order adjacency tables + cluster tables into sibling appendix PDF). That's a multi-file refactor risking customer-artifact breakage; deferred until Z's review of the cumulative v1.0.125–128 state lands. Queued as v1.0.129+.

Verification

Offline: builder isolated against stub data confirmed three band classifications fire correctly (0.41 → loose overlap, 0.62 → thematic adjacency, 0.78 → real overlap pressure). Empty-data path returns "" cleanly (no callout when no nearest_competitors). AST clean on render_arc.py.

Production verification on next L1 run: confirm the prominent callout block lands at the top of page 1 between the assignee notice and the proposed-patent cards.

v1.0.127 — 2026-05-20 — Radar (a) evolution: kinetic-state encoded on axis polygons

Why this lands

The axis radar in the L2 memo visualizes the 4-D composite score per continuation axis. It surfaces operation #1 (forward traversal) and operation #2a (convergence manipulation candidates). It did not surface operation #5 (kinetic state). The radar was showing which axes have the highest composite scores but not which axes are time-pressured vs. which sit in stable defensive moats — a load-bearing distinction the reader needs to read the chart correctly.

v1.0.127 layers the kinetic-state signal onto the existing chart without redesigning it.

What ships

  1. axis_scores JSON schema extended — each axis now carries an optional kinetic_state field whose value is one of the engine's exact kinetic labels: stable-silence, decaying-silence, oscillatory, unknown, or the new no-void for axes that address prior-art pressure rather than void instantiation. The USER_PROMPT now requires Claude to emit this field per axis, anchored to the void the axis is targeting (same value as the Structural Void Callout in Section 2).

  2. _extract_axis_scores parser tolerates missing field — pre-v1.0.127 axis_scores blocks (no kinetic_state) still parse cleanly; missing field defaults to unknown. Backward-compat preserved.

  3. _axis_radar_svg encodes kinetic-state visually:

  4. Polygon outline: solid for stable / decaying / unknown; dashed (8,4) for oscillatory (window uncertain)
  5. Legend glyph + label: ◷ decaying (clock-with-quarter; time pressure), ◇ stable (diamond; defensive moat), ∿ oscillatory (tilde-wave; variability), no glyph for unknown / no-void
  6. The per-axis hue palette (cyan / violet / orange / emerald) is preserved so legend's color-coding still works — kinetic state is layered ON TOP as additional signal, not a replacement of color.

What the practitioner now sees

Before: a radar showing four colored polygons with composite scores (Axis #1 — 16/20, Axis #2 — 14/20, etc.). Reader has to cross-reference Section 2 to know which axis is time-pressured.

After: same radar with kinetic encoding embedded. Reader sees at a glance: "Axis #1 ◷ decaying" means file this one quickly — a competitor is approaching the void. "Axis #2 ◇ stable" means defensive moat; can take time on the prosecution conversation. The radar surfaces void-kinetics alongside composite scoring rather than just composite scoring alone.

Verification

Offline: parser threads kinetic_state per axis correctly (including default-to-unknown fallback when field missing). Radar SVG renders oscillatory polygons with stroke-dasharray="8,4" and solid for the others. Legend glyphs ◷ / ◇ / ∿ appear next to their respective composites. Backward-compat with pre-v1.0.127 axis_scores blocks (no kinetic field) confirmed: chart still renders, legend just omits the kinetic suffix.

Production verification on next L2 run: confirm at least one axis polygon shows the dashed-oscillatory or has the kinetic glyph in legend.

Not in this release

(b) Multi-radar small-multiples (one radar per projection angle — kinetic / provenance / bridge), (c) interactive radar (Sprint F+). Two-tier PDF split for L1 (Layer 2 reference appendix) — separate v1.0.128. Observer-marker centroid showing user-filing position — needs source data not currently computed; deferred.

v1.0.126 — 2026-05-20 — L1 landscape information hierarchy restructure

Why this lands

Per critique 4's information-hierarchy findings on the L1 landscape: the report was "essentially a disclaimer page" at the top (corpus scope banner + methodology signal), with the practitioner-facing actionable content (proposed-patent cards, cascade-failure verdict, nearest-competitor signal) buried on pages 6-12 of a 15-page report. Same inversion pattern the L2 memo had — the engine's load-bearing reasoning was being gated by Layer 3 disclosure rather than leading.

What ships

  1. Proposed-patent cards moved to the top. {candidates_html} (the "What Should Come Next" cards generated by silent-region candidate processing) now renders immediately after the assignee notice, before the detailed per-cluster landscape walk. Practitioners who submitted a portfolio land on the gap identification + proposed filings as the first substantive content.

  2. Portfolio cascade-failure exposure moved up. {portfolio_exposure_html} now sits right under the proposed-patent cards, before the detailed landscape body. A practitioner whose entire portfolio shares a load-bearing mechanism that could be invalidated sees that signal immediately rather than after working through cluster characterizations.

  3. Top-of-page disclaimer block dismantled. The corpus-scope banner that previously sat as a styled block above all content has been split:

  4. Methodology signal paragraph (encoder model, threshold language, Layer 2 trigger explanation) — stripped entirely. Lives on /methodology page (shipped v1.0.125), linked from the footer.

  5. Corpus-scope paragraph (US-only at launch + Route 6 JDA partnerships hook) — compressed to one paragraph, moved below the body content. This is product-positioning content, not Layer 3 methodology, so it stays in the artifact but no longer gates the read.

  6. Cluster tables stay in {landscape_html} body for now. The "No Competitor Action Needed" tables (per critique 4) belong in a Layer 2 appendix; that tuck moves them into a sibling appendix PDF in v1.0.127. v1.0.126 doesn't strip them — it just moves the actionable content above them.

Verification

Offline: render_arc.py AST clean. Section-order check confirms {candidates_html} < {portfolio_exposure_html} < {landscape_html} < corpus-scope-banner in the rendered template.

Production verification on next L1 run: confirm "What Should Come Next" cards land within the first 1-2 pages instead of pages 7-12; corpus scope appears as a footer-adjacent note instead of a top-of-page disclaimer.

What this is NOT

v1.0.125 — 2026-05-20 — Layer 3 strip + /methodology page

Why this lands

The three-layer artifact framework (Layer 1 = engine's load-bearing reasoning; Layer 2 = audience-specific reference; Layer 3 = engine internals / metadata) called for engine-internals content (encoder description, threshold calibration, TIS definition, neighbor / cousin definitions, corpus scope) to move out of every customer-facing artifact and onto a single public page that the artifact footer links to. v1.0.125 does the strip + builds the page.

The Methods block previously rendered at the end of every L1 landscape PDF, every L2 continuation memo PDF, every provisional draft DOCX, and the export-report DOCX. Five paragraphs of engine internals padding the back of every deliverable. Per the three-layer triage test ("could a paying customer act on this in the first read?"), all five answer no. Out.

What ships

  1. Methods block stripped from all four artifact paths — continuation_memo_synth.py (HTML PDF render + dead DOCX path), provisional_synth.py (provisional draft DOCX), render_arc.py (L1 landscape HTML), export_report.py (export DOCX). Each now renders zero Methods content in the artifact body.

  2. Footer link added in its place — attribution.write_html_footer_block and attribution.write_docx_footer_block both accept a new methodology_link=True kwarg that adds one line: "Engine methodology disclosure: patents.livingedenframeworks.com/methodology". All five artifact paths pass methodology_link=True. Legacy callers without the kwarg get the prior footer behavior unchanged.

  3. /methodology public page (new GET /methodology route + templates/methodology.html). One canonical page hosting the five paragraphs from attribution.METHODS_BODY_PARAGRAPHS plus a Definitions block (cluster neighbor, cousin, structural void, kinetic state, encroachment probability, composite axis score) plus a "what this page does NOT cover" section that names the patented mechanisms (convergence manipulation, bridge discovery, observer-state perturbation, temporal drift, provenance-weighted gravity) without disclosing their operational mechanics. Public route; no auth gate.

What this is NOT

The two-tier PDF split (lean _memo.pdf + reference _appendix.pdf) is deliberately separate work — v1.0.126. v1.0.125 is just the Layer 3 strip + the methodology page. The two-tier split needs its own commit to surface what Layer 2 content actually moves to the appendix sibling file.

Verification

Offline: AST clean on all five modified files. write_html_footer_block(methodology_link=True) produces the link line; methodology_link=False (legacy) doesn't. The actual rendered memo HTML no longer contains the Methods block (<div class="methods-block"> absent, encoder description absent) while the methodology footer link is present.

Production verification on next live artifact: render an L2 memo, confirm it ends with the attribution block carrying the methodology link rather than the full Methods paragraphs.

Charter implication

The three-layer framework moves from "captured concept" to "operational discipline." Every future artifact in every DCFN domain (Patents now, Research next, Bio / Energy / Legal as they mature) follows the same layering: Layer 1 in the artifact body, Layer 2 in a sibling appendix file (v1.0.126), Layer 3 on the site's /methodology page. Charter §13 reference implementation is now continuation_memo_synth.py + attribution.py + templates/methodology.html.

v1.0.124 — 2026-05-20 — Layer 1 hierarchy reorganization

Why this lands

Four external critiques converged on the same finding: the engine's sharpest reasoning (FTO posture, structural void with kinetic state, ranked continuation axes with draft claims, PHOSITA-anchored teach-away arguments) was buried in the back half of every memo. A practitioner reading cold worked through methodology disclosure, similarity-score legends, position prose, and a neighbor-by-neighbor walk before reaching a single actionable conclusion. The "engine is underdeployed within its own artifacts" was the punchline. v1.0.124 reorganizes the memo so the engine's load-bearing reasoning leads.

What ships

  1. Verdict block at the top. Every memo now opens with a three-line markdown blockquote — FTO posture (CLEAR / WATCH / PRESSURE), Structural void state (using the engine's exact kinetic_state label: stable-silence / decaying-silence / oscillatory / unknown / no-void-detected), and Lead continuation axis (#1 composite + axis title + one-sentence draft claim summary). The verdict is the first substantive content the practitioner encounters, before any prose, before any legend, before any section header. Applies to all three run_modes (Prosecution, Clearance, Both) — the FTO posture sentence was previously available only in Clearance mode's Section 4; it now leads in every mode.

  2. Structural void callout (new Section 2). Standalone callout block BEFORE the neighbor walk, naming the void's similarity band, its kinetic state (engine label + plain-language translation), the colonization-window estimate when decaying-silence applies, and one sentence on what the kinetic state implies for filing timing. The void was previously surfaced mid-Section 3 after the practitioner had already worked through the neighbor characterizations.

  3. Teach-away embedded per-neighbor (Section 3). Each neighbor's PHOSITA-anchored teach-away argument is now produced INLINE in that neighbor's passage rather than buried in a separate "differentiation" subsection or appendix. Teach-away is each neighbor's load-bearing differentiation argument; the prompt now requires it to surface in the same passage that introduces the neighbor.

  4. Layer 1.5 — context-conditional corpus-thin acknowledgment. When the filing's domain is corpus-thin (food chemistry, quantum hardware, biotech with NPL-dominated literature, international-first fields), the verdict's FTO posture clause now carries an explicit caveat — e.g., "CLEAR — but corpus-thin domain; CLEAR posture is not a defensible professional opinion without a supplemental human NPL sweep." Honors the signal already produced by _compute_coverage_caveat. The void state label still uses the engine's exact kinetic_state value; the corpus-thin context lives in the FTO posture clause, not as a substitute state.

  5. Conclusion-extraction discipline. Where a Layer 3 explanation accompanied a Layer 1 conclusion in the prior prompt, the conclusion now leads and the derivation moves down. The colonization-window number (e.g., "6 months") leads; the derivation chain (void_width / cluster_velocity) lives in the Visual Appendix references, not in body prose. Per Perplexity's refinement to the three-layer framework.

  6. Similarity-score legend compressed and demoted. The "How to read similarity scores" legend was previously a multi-bullet block at the top of every memo. It now renders as a single quoted aside under 60 words, placed AFTER the verdict block (not before it). Repeat readers can skim past it; first-time readers still encounter it before the body.

  7. Cross-assignee suppression count stripped (render_arc.py). The "X cross-assignee silent-region recommendations suppressed" line in the L1 landscape was a log entry, not practitioner output. The one-sentence "Cross-assignee continuation is not legally viable" notice in multi_assignee_block remains and is the actionable signal.

What is deliberately NOT in this release

The two-tier PDF output (lean _memo.pdf + reference _appendix.pdf), the standalone /methodology page on the site, and the run-provenance footer page strip are all customer-facing file-structure changes that require Z's review before shipping. v1.0.125 will address them.

Verification

Offline: all three run_modes (Prosecution, Clearance, Both) format cleanly with str.format(). No brace-escape regression (v1.0.115 bug). All new markers present in each mode's rendered prompt. AST clean on continuation_memo_synth.py, render_arc.py, app.py. Cross-assignee suppression count line confirmed removed from render_arc.py.

Production verification on the next live customer run: open the memo PDF, confirm the verdict block leads, void callout is in Section 2 before the neighbor walk, teach-away is inline in each neighbor's passage, the landscape report no longer shows the suppressed-count line.

Charter implication

The three-layer framework (Layer 1 = engine's load-bearing reasoning; Layer 2 = audience-specific reference; Layer 3 = engine internals / metadata) is a substrate-level pattern, not a Patents-specific fix. Every downstream DCFN build (Research, Bio, Energy, Legal) should adopt the same hierarchy when its L2 artifacts mature. v1.0.124 is the reference implementation. Charter §13 update queued.

v1.0.123 — 2026-05-19 — Visual Appendix layout: page-stay + chart bleed

Why this lands

The Visual Appendix block (axis radar + similarity band map) was rendering with two layout problems: the "VISUAL APPENDIX" heading could break across page boundaries from the chart it was labelling, and both charts felt small relative to the page they sat on.

What ships

All changes are scoped to the two SVG container divs in continuation_memo_synth.py and the visual-appendix-heading wrapper. No engine logic changed.

v1.0.122 — 2026-05-19 — Sprint D: Memo framing toggle (Prosecution / Clearance / Both)

Why this lands

Until now, the Continuation Strategy Memo had a single framing: the reader is the patent owner deciding their next continuation. That framing serves the prosecution-side reader well, but misses an equally important second posture: the operator who already owns (or licenses) the patent and needs to evaluate whether the neighbors in the landscape threaten their freedom to ship the technology.

The same landscape data answers both questions; only the framing differs. v1.0.122 adds a customer-selectable toggle at intake.

What ships

  1. Intake form — new "Memo framing" radio group on /run (templates/index.html). Three options: Prosecution (default, current behavior), Clearance (FTO), Both. Selection is persisted on the session intake dict and flows through every downstream memo synth invocation.

  2. continuation_memo_synth.py — three new prompt-fragment dictionaries (_MODE_FRAMING, _MODE_SECTION_3, _MODE_SECTION_4) plus a _normalize_run_mode helper that maps customer values (including aliases: "fto" / "freedom-to-operate" → "clearance"; "dual" / "all" → "both") to one of the three canonical modes. synthesize_continuation_memo accepts a run_mode kwarg that overrides the deep_record's embedded value.

  3. Prosecution mode — unchanged Section 3 ("Where the defensive edges should sharpen") + Section 4 ("What the landscape implies about next filings"). Pre-Sprint-D intakes default to this mode, so existing artifacts are identical.

  4. Clearance mode — Section 3 becomes "Where the FTO pressure concentrates" (for each axis: which neighbor creates pressure, what feature triggers overlap, three options — design around / license / accept-with-rationale). Section 4 becomes "Net FTO posture": CLEAR / WATCH / PRESSURE classification with one load-bearing reason.

  5. Both mode — runs prosecution + clearance treatments as parallel subsections (3a + 3b, 4a + 4b). Longer memo, both surfaces visible to the reader.

  6. App.py wiring — _inproc_continuation_memo_synth accepts an optional run_mode parameter; both production memo workers (the customer payment path and the new admin regenerate path) read session intake's run_mode and pass it through. Backward-compat preserved: an empty/missing value falls back to prosecution-mode silently.

Verification

Offline: - _normalize_run_mode handles canonical values, aliases (fto, dual), and all unknown / empty inputs (default to prosecution). - All three modes format the master USER_PROMPT cleanly with their respective framing/section blocks. - Mode-distinguishing markers verified present per-mode: "Continuation Strategy Memo" for prosecution, "Freedom-to-Operate" + CLEAR/WATCH/PRESSURE for clearance, "dual Continuation + Freedom-to-Operate" for both. - AST clean on continuation_memo_synth.py + app.py.

Production smoke after deploy: load /run and verify the "Memo framing" radio group renders.

v1.0.121 — 2026-05-19 — Admin Operations: lookup, regenerate, costs, refunds, code revoke

Why this lands

DCFN-Patents reached v1.0.120 with a sophisticated paying-customer pipeline but threadbare operator tooling. When a customer emailed "my memo didn't generate, session abc123," the operator's only path was direct Firestore console queries. Refunds went through the Stripe Dashboard with no link back to the engine run that motivated them. Stuck mid-pipeline runs required CLI re-fires from a developer laptop.

v1.0.121 ships the five operations-tier admin surfaces a working SaaS needs.

What ships

  1. /admin/lookup — single search field that auto-routes to one of three resolvers based on input format: 12-hex → session record (with per-stage telemetry rollup); cus_... → Stripe customer → firm record; 12-char A-Z2-9 → invitation code → redemption + firm context. Page renders all matched detail blocks inline. Read-only; the load-bearing operator workflow ("find them, then do something") starts here.

  2. /admin/session/{sid}/regenerate — re-fire memo synth (by patent ID) or provisional + cover-note synth (by candidate index) without re-doing the upstream deep_run. Refuses if the upstream JSON is missing locally and cannot be hydrated from GCS — those cases would silently cost real Anthropic dollars, so they're routed to the explicit /run entry point instead. Available as inline forms on the session-lookup detail page.

  3. /admin/costs?window=24h|7d|30d — cost dashboard reading usage_events Firestore. Aggregates total Anthropic spend (with per-model pricing baked in: Opus $15/$75/Mtok, Sonnet $3/$15, Haiku $1/$5; cache-read rates 1/10th input), BigQuery spend (on-demand $6.25/TiB), error rate, top-20 sessions by spend, full per-stage breakdown, and error-class distribution. Estimates are operator-facing approximations, not Anthropic-billing truth.

  4. /admin/refund — issue a Stripe refund against a PaymentIntent (operator pastes pi_... from Stripe Dashboard), with optional session-ID for audit linkage, partial-amount support, and Stripe-accepted reason codes (duplicate / fraudulent / requested_by_customer). Writes a refund_log Firestore entry tying the refund back to the run that motivated it. Linked from every session-lookup detail page.

  5. /admin/codes/ui + POST /admin/codes/{code}/revoke — HTML companion to the existing JSON /admin/codes list, with per-row Revoke buttons that call discount_codes.invalidate_code. Confirmation prompt + status-aware UI (Revoke button only shows for unused codes).

Verification

Offline: - Query classifier handles all valid input shapes (12-hex session, cus_ prefix, 12-char A-Z2-9 code) and rejects invalid forms (codes containing I/O/0/1, wrong-length hex, malformed customer IDs). - Model-pricing helper resolves bare model names + date-suffixed variants (e.g. claude-haiku-4-5-20251001) and falls back to Sonnet-ish pricing on unknown models. - app.py AST parses cleanly through all five new route blocks.

Production smoke after deploy: load /admin/lookup with a real session ID and verify the telemetry rollup table populates.

Operator workflow

The five surfaces compose into a single load-bearing flow: 1. Customer reports a problem. 2. /admin/lookup finds them by whatever identifier they provided. 3. Detail page shows current state + per-stage telemetry + cost. 4. Operator picks the right action: regenerate (artifact stuck), refund (billing issue), revoke code (compromised), or open report (just inspecting).

v1.0.120 — 2026-05-19 — Sprint C: cryptographic file-pair manifest + radar cosmetics

Why this lands

Cover Note and Provisional Draft are delivered as a paired set. Until now, an attorney receiving the pair had no engine-side way to confirm the draft they're filing is the exact file the engine emitted — no chain-of-custody mark, no integrity check. v1.0.120 closes that gap with a one-way cryptographic manifest (option a per the 2026-05-19 review): the cover note carries the draft's SHA-256 hash, the expected filename, and platform-split recompute instructions.

What ships

  1. Cover Note → Draft SHA-256 manifest block. The cover note now ends with a CRYPTOGRAPHIC FILE-PAIR MANIFEST block citing the draft's SHA-256, the expected filename, and verification commands for macOS / Linux (shasum -a 256 …) and Windows PowerShell (Get-FileHash -Algorithm SHA256 …). If the recomputed hash diverges from the manifest value, the draft has been modified after the engine emitted it.

  2. One-way pairing by design. Cover note witnesses the draft; the draft does not carry its own SHA. (A file cannot embed its own file-hash without self-reference paradox, and the one-way chain is sufficient — recomputing the draft against the cover note's manifest value detects any modification on the load-bearing artifact.)

  3. Memo Visual Appendix — single heading. Prior versions emitted "Visual appendix" twice when both the radar chart and similarity-band map rendered (one heading per visual). The heading now renders once, above the pair.

  4. Radar legend — line-segment removed. The legend marker was a colored circle followed by a short colored line segment, then Axis #N — composite/20. Combined with the em-dash inside the label the row read as two link-glyphs back-to-back (● ─ Axis #1 — 16/20). The em-dash alone carries the visual link; the line-segment is gone.

  5. Radar palette flipped to light theme (Variant C2). Background was a dark navy panel (#1A1F2E) which inverted against the white memo page — fine on screen, jarring in print. Chart now renders on white (#FFFFFF) with darker grid + ring labels (#64748B slate-500 dashed crosshairs at 1.0px so print rendering keeps them; #1F2937 slate-800 bold ring numbers). Per-axis colors darkened in parallel — cyan #0891B2, violet #7C3AED, orange #EA580C, emerald #059669 — so they keep contrast against white. The radar now belongs on the page instead of standing apart from it.

Verification

Offline: paired-document signature on assemble_cover_note_docx() now accepts draft_sha256 + draft_filename, manifest block renders conditionally on a non-empty hash (legacy callers without the kwargs still get pre-v1.0.120 output). Hash compute happens after assemble_docx() writes the draft, then is passed in for the cover note assembly. Real-run verification after deploy on a 1-patent test shape — expect manifest block at the bottom of the cover note + only one "Visual appendix" heading in the memo + clean legend rows.

Sprint sequence

Sprint A (v1.0.114) → Sprint B parts 1+2 (v1.0.115 + v1.0.119) → Sprint C (v1.0.120) → Sprint D (FTO framing + run_mode toggle) → Sprint E (closeout verification of #2 kinetic-state crispness + #4 barcode chart presence).

v1.0.119 — 2026-05-20 — Sprint B Part 2: radar chart actually rendering

Why this lands

v1.0.118 re-verified the brace-escape hotfix (all 3 memos generated) + confirmed claim-draft preview blocks on Axes #1 + #2 with correct "attorney review required before filing" wording. BUT the radar chart was still missing from the Visual Appendix — only the Similarity Band Map barcode appeared.

Root cause (most likely): Claude was emitting the closing italic limits line as the last memo content + treating that as end-of-task, skipping the axis_scores JSON block that follows. OR hitting the 4500 max_tokens before reaching it.

Three fixes shipping together

  1. Prompt restructured — JSON block instruction now appears BEFORE the italic-close, not after. Closing italic limits line gets explicit instruction to come AFTER the JSON block. Removes the "Claude treats italic close as end-of-task" failure mode.

  2. Prompt language tightened — JSON block flagged as REQUIRED, not optional. Explicit reminder that missing block = missing radar = incomplete artifact.

  3. Parser made tolerant — regex now accepts fence-tag variations Claude emits in practice:

  4. ```axis_scores (canonical)
  5. ``` axis_scores (extra whitespace)
  6. ```json (language-tag default)
  7. ``` json axis_scores (both)

  8. Also tolerant of missing trailing newline before the closing fence.

  9. max_tokens 4500 → 6000 — leaves ~1500-token headroom for the JSON block on top of typical 3500-4200-token memo body. Prevents truncation cutoff on the longest memos.

Verification

Offline: regex matches all 4 fence variants. USER_PROMPT.format() still runs clean. Real-run verification after deploy with the 3-patent test shape.

Sprint sequence

Sprint A → Sprint B (parts 1+2 = v1.0.115 + v1.0.119) → Sprint C (#7 SHA file-pair manifest) → Sprint D (FTO framing + run_mode toggle) → Sprint E (closeout verification).

v1.0.118 — 2026-05-20 — Patent-numbers input copy update (accept multiple separators)

Why this lands

Z 2026-05-20 noticed: the intake textarea label + placeholder + hint all said "semicolon-separated," but the underlying JS parser actually accepts three separators (semicolons, comma+whitespace, or newlines). Z had been running with just numbers and no commas — the engine handled it correctly, but the help copy didn't reflect what was really accepted, making the input feel stricter than it is.

Changes

No engine or JS behavior change — copy-only edit on templates/index.html. The parser at line 527 (raw.split(/,\s+|;|\n/)) was already accepting all three; the input UI just hadn't been telling users that.

v1.0.117 — 2026-05-20 — "Alpha Stress Testing" → "Founding Cohort" relabel

Why this lands

Z 2026-05-20: "Alpha Stress Testing" label (shipped in v1.0.107 gating) read as "the engine is still in alpha" — contradicting the production-ready posture demonstrated by the USPTO tag + competing-with-legacy-entities critique read. "Founding Cohort" replaces it: same scarcity-gate semantics, prestige framing, doesn't undercut engine maturity.

Research stays "In Development" — that label is accurate for that build.

Surfaces swept

Out of scope (deliberate)

v1.0.116 — 2026-05-20 — Sprint B hotfix: USER_PROMPT brace-escape bug

Why this lands

v1.0.115 Sprint B added a JSON example block + brace-explainer prose to USER_PROMPT. Both contained literal { and } characters that Python's str.format() interpreted as field placeholders, causing KeyError: '\n "axes"' on EVERY memo synth call.

Caught by the post-deploy smoke test: 3/3 memos in the validation run failed identically.

Fix

Verification

Offline: format() runs without KeyError, output 12,061 chars, JSON example block + paranthetical render correctly. Real-run verification lands after deploy (re-firing the 3-patent test).

Lesson

Any addition to USER_PROMPT must escape literal { } characters. Pre-existing field placeholders ({patent_id}, {title}, {claims}, {neighbor_count}, {expansion}, {neighbors}, {integration}, {differentiation}, {coverage_caveat}) stay single-braced. Everything else must double. A pre-commit lint that validates USER_PROMPT.format(**field_keys) succeeds before commit would catch this class of bug — queued as a housekeeping follow-on.

v1.0.115 — 2026-05-20 — Claim-draft previews + radar chart (Sprint B)

Why this lands

Sprint B of the 5-sprint plan. Closes critique item #3 (dependent claim draft previews on top-2 ranked axes) plus the chart Z + Perplexity converged on (radar overlay of all axes' 4-D composite breakdown). The combined effect converts the Continuation Memo from "ranked advisory text" → "ranked advisory text + draft starting-point claim language + visual axis-shape comparison" — closer to what DeepIP / Patlytics ship at the attorney-grade tier.

What ships

Claim-draft previews (#3): - USER_PROMPT extended with a "DRAFT DEPENDENT CLAIM PREVIEW" block that fires on Axis #1 and Axis #2 only (Axes #3 / #4 stay text-only to avoid diluting the actionable surface) - Block structure: numbered dependent claim language (2-3 sentences in proper patent register) + three metadata lines (Anchored to / §112 enablement / Priority-date safe) - Framing language: "attorney review required before filing" — matches Cover Note voice (per Perplexity's note about workflow-instruction vs watermark-disclaimer reads) - §112 enablement self-assessment by the LLM at memo-synth time; the deterministic §112 stress-test on auto-drafted provisionals stays a future sprint - Priority-date-safe flag aligns with the existing PRIORITY-DATE WARNING the memo already raises on the axis itself; the warning's presence reduces Strategic-clarity score, which lowers composite ranking

Radar chart: - New _axis_radar_svg(axes) renderer in continuation_memo_synth.py. Single chart, all top-4 axes overlaid as outline polygons (no fill — Perplexity's call; fills muddy the overlap). Dark navy background, high-contrast per-axis palette, composite-in-legend labeling (Axis #1 — 17/20) - Single SVG source serves both PDF (WeasyPrint inline) + web (/layer2/{sid}/result embed when wired) - New _extract_axis_scores(markdown_text) parses a fenced ```axis_scores JSON block Claude emits at memo end. Defensive against malformed JSON / missing block — silently omits the radar rather than crashing memo render - Fenced block stripped from PDF body so it doesn't appear as raw JSON

Prompt update: - USER_PROMPT now ends with a "MACHINE-READABLE AXIS SCORES" section that instructs Claude to emit the JSON block matching the inline rendered sub-scores exactly. The constraint is load-bearing: divergence between inline numbers and JSON misleads the radar viewer

Verification

Offline parse + render test (no API spend) confirmed: - 4-axis JSON block parses cleanly; produces 6.3KB SVG with correct geometry - Missing JSON block → empty axes list → radar omitted silently (no crash) - Malformed JSON inside block → empty axes list → radar omitted silently (no crash) - Stripped markdown no longer contains the fenced block

Real-run verification lands after deploy — fire a 2-3 patent memo run, inspect the PDF for both the DRAFT DEPENDENT CLAIM blocks under Axis 1+2 AND the radar in the Visual Appendix.

Sprint sequence

Sprint A (v1.0.114) → Sprint B (this) → Sprint C (#7 SHA file-pair manifest) → Sprint D (FTO framing + run_mode toggle) → Sprint E (closeout verification).

v1.0.114 — 2026-05-19 — TIS inversion bug fix (Sprint A)

Why this lands

Per the 2026-05-19 Perplexity critique §1.1 "single most addressable technical artifact flaw": Textual Isolation Score reported as 0 for filings with empty neighbor lists. Maximum isolation should read HIGH not zero — the engine's own memo body acknowledges this ("no comparison set was assembled rather than a substantive signal") but the structured output field carried the inverted reading.

Sprint A of the multi-sprint plan greenlit 2026-05-19 (Sprints A through E close items #1, #2-verify, #3, #4-verify, #7 + FTO framing from the critique's Prioritized Revision Roadmap).

What ships

Verification

Offline-test sweep (no API spend) confirmed: - expansion_value=0 + empty neighbors + no seeds → genuine_isolation=True, isolation_class="highly_isolated" ✓ (was: "crowded" — the bug) - expansion_value=1 with neighbors → genuine_isolation=False, isolation_class="crowded" ✓ (legitimate crowded case unchanged) - expansion_value=15 with sparse neighbors → genuine_isolation=False, isolation_class="highly_isolated" ✓ (existing high-isolation path unchanged)

A push test against a known single-filing edge case (single patent in sparse CPC subclass) will land after deploy to confirm production behavior matches offline.

Patent claim alignment

Closes the 64/043,294 Consolidated Supplemental §2.10 corpus-relative percentile mechanism for the boundary case the v1.0.102 implementation missed. The multiplicative structural-exposure formula from 64/061,715 Claims 5-6 (Portfolio Topology Extensions) is queued as a follow-on enrichment for cases where neighbors DO exist — Sprint A scope is the bug fix only.

v1.0.113 — 2026-05-19 — buy-pack/solo_trial 500 fix + copy sweep

Why this lands

Z's morning QA pass after v1.0.106-onward shipped surfaced four items.

/buy-pack/solo_trial 500 (real bug)

Root cause: RUN_PACKS["solo_trial"]["stripe_price_id"] pointed at price_1TYVSCQA8XXKXI4bTNrrAuLP — a LIVE-mode-only Stripe price that doesn't exist in TEST mode. v1.0.93 swapped Squad Run / Starter / Standard / Pro to LIVE prices but Solo Trial (added in v1.0.91) was never replicated to TEST. v1.0.105 flipped server keys to TEST without backfilling Solo Trial.

Same gap for SEAT_EXPANSION (price_1TYVSSQA8XXKXI4bPaUOFWKM — LIVE-only).

Fix: minted matching TEST-mode products + prices via Stripe API: - Solo Trial → price_1TYwNwQA8XXKXI4biL6x7f25 ($2,500 one-time, prod_UY2SJ9Irs2zx2X) - Seat Expansion → price_1TYwNwQA8XXKXI4bh7e70rdH ($1,000 one-time, prod_UY2STfvQqd78sA)

RUN_PACKS + SEAT_EXPANSION updated. LIVE price IDs preserved in code comments for swap-back when Stripe Dashboard flips to LIVE.

Copy fixes

v1.0.112 — 2026-05-19 — Global typography 80% → 90%

Z 2026-05-19: prior 80% scale (v1.0.19) was too tight on certain pages — pricing cards + account dashboard density read cramped on the higher-resolution display Z runs. Root font-size lifted from 12.8px (= 80% of 16px browser default) to 14.4px (= 90%). All rem-based sizing inherits; px-based card max-widths + image dimensions stay fixed. Mobile breakpoint (@media max-width: 480px) now matches the desktop scale instead of restoring to 14px — keeps the visual feel consistent across viewports.

Single-line CSS change in static/css/site.css. No structural HTML edits.

v1.0.111 — 2026-05-19 — Alpha-framing banner contrast lift

Per Z 2026-05-19: the v1.0.107 Alpha framing banner (founder quote + 20-admin-seat explainer above the TIER 1 H2) was rendering as a thin purple-left-border on plain prose — insufficient contrast against the "What the engine produces" cards above and the Tier 1 pack ladder below.

Re-rendered as an edge-to-edge coral-fill (#F2B6B0) banner with centered typography, bolded scarcity sentence, underline on the "20 admin accounts" anchor, and centered + italicized founder quote. Body text now sits at #2A2440 (engine navy) for readability against the coral.

CSS-only change. No layout reflow on the pricing page beyond the banner block itself.

v1.0.110 — 2026-05-19 — Legal-page audit pass (TOS + Privacy)

Why this lands

Audit pass on Terms of Service, Privacy Policy, Refund Policy after the v1.0.107–v1.0.109 retail / Route-4 / Route-6 changes. Two real inaccuracies surfaced and got fixed. Refund Policy was already current; no change there.

Fixes

Confirmed clean (no change)

v1.0.109 — 2026-05-19 — Route 4 per-run price $125 → $185

Why this lands

Per Z 2026-05-19: raising the Route 4 SaaS per-run price from $125 to $185 (54% discount off the $400/run Solo Trial retail rate, clean B2B wholesale-to-partner posture). $10K/month floor unchanged. Bend point shifts from 80 runs/mo to 54 runs/mo.

Constant + computation changes

Display copy changes

Stripe-side: NOT changed (deliberately)

Safety posture

Display + projection-math only. No partner is currently signed up at the old $125 rate (Route 4 hasn't shipped self-serve billing yet, and Alpha gating blocks new signups). No live Stripe price ID change. Zero customer-facing rate change in any signed agreement.

v1.0.108 — 2026-05-19 — Route 4 + Route 6 Alpha gating + JDA price update

Why this lands

Z 2026-05-19: gate the Route 4 SaaS + Route 6 JDA CTAs on the pricing page (mirroring the Tier 1 retail gating that v1.0.107 shipped), and update the Route 6 Annual Access Fee tier prices to the new figures.

JDA price update

Tier Old New
Modern CDE $250K/yr $350K/yr
Legacy Standard $350K/yr $475K/yr
Legacy Heavy $400K/yr $550K/yr

Surfaces updated: templates/pricing.html (Route 6 card), templates/jda_stub.html (Annual Access Fee block).

Route 4 + Route 6 Alpha Stress Testing gating

NOT changed (deliberately)

Only the public-facing Annual Access Fee display strings on pricing.html + jda_stub.html were changed.

v1.0.107 — 2026-05-19 — Alpha Stress Testing gating + vestigial-language cleanup

Why this lands

Two streams in one release: 1. Patents-only gating directives per Z's 2026-05-18 PDF: Alpha Stress Testing badges on all signup CTAs + founder quote + 20-seat scarcity explainer. Un-gated "Have an invitation code?" path preserved. DCFN_SIGNUPS_GATED=1 env var set on Cloud Run. 2. Vestigial Tier-0-era language cleanup ($385 / 3-day window / $85 / 30-day window) on customer-visible surfaces.

Gating shipped

Vestigial-language cleanup

Out of scope (deferred)

Anniversary-bill bug

Roadmap entry stale — fix already shipped in v1.0.91's anniversary refactor (reset_firm_period_counter zeros run pool at anniversary per the use-it-or-lose-it model). No code change required.

v1.0.105 — 2026-05-18 — Stripe back to TEST mode (Z run-pack verification)

Why this lands

Temporary flip so Z can buy run packs end-to-end without burning real cards. RUN_PACKS reverts to the pre-v1.0.93 TEST price IDs (recovered from git history); GCP secrets stripe-secret-key + dcfn-stripe-webhook-secret rotated to point at TEST values (v3 of each secret = latest, copy of the v1 test values; v2 LIVE preserved for the swap-back).

To revert to LIVE: bump VERSION + restore the LIVE price IDs (preserved in code comment-shadow above each test ID line) + add a new secret version copying v2 to make latest=LIVE again + redeploy.

Solo Trial + SEAT_EXPANSION price IDs unchanged (those were created during the test era; same IDs work in both modes since they were never re-minted in LIVE).

v1.0.104 — 2026-05-18 — Graduated temperature for reproducibility

Why this lands

The v1.0.102 parallel smoke test surfaced that two runs with identical patent inputs produced byte-identical engine outputs but slightly different memo prose (Anthropic generation is non-deterministic at default temperature). For institutional-evaluator reproducibility, Z asked for graduated temperature: lock formulaic call sites at 0.0, allow controlled variation on judgment-heavy sections.

Per-call-site settings

Call site Temperature Rationale
portfolio_domain (CPC classification) 0.0 Same CPCs → same domain label every time
landscape_narrative (Section 1 framing) 0.0 (already pinned) Pre-existing per v0.x; kept
bridge_abstract (Haiku tagline preview) 0.0 Short formulaic line; stable per bridge candidate
continuation_memo 0.3 Judgment-heavy; tight envelope keeps conclusions stable while allowing nuance
provisional_synth (streaming + adaptive thinking) 1.0 (forced by API) Anthropic extended-thinking requires temperature=1; can't pin

What this does NOT change

The boilerplate-critique risk Z asked about — "same across the board" — isn't a temperature problem; it's a prompt-quality problem. The 2026-05-18 critique already validated the memo prompts as the OPPOSITE of templated ("explains why it made each judgment call," "transparency mirrors how a senior patent strategist thinks"). Temperature=0.3 on memos preserves that nuance; it doesn't collapse to formula because the input data varies across customers.

Safety posture

Additive. Default temperature on call sites that didn't specify one was effectively 1.0; pinning to 0.0/0.3 narrows the sampling envelope but does not change the underlying signal the engine produces.

v1.0.103 — 2026-05-18 — Telemetry coverage closure + Landscape PDF micro-refinements

Why this lands

v1.0.102's parallel smoke test surfaced two gaps Z asked to close before he fires his own runs:

  1. Telemetry coverage gap. v1.0.100 wrapped call_with_retry() to capture every Anthropic call routed through it. Two call sites bypass that wrapper:
  2. provisional_synth._call_claude_for_section uses client.messages.stream() (streaming + adaptive thinking + system-prompt caching) — every provisional draft section was uncounted.

  3. render_arc._claude_bridge_abstract uses client.messages.create() directly (single-shot Haiku call for the bridge-abstract preview) — uncounted. Both now record duration + token usage to usage_events on both success + failure paths. Best-effort; never raises.

  4. Landscape PDF micro-refinements per Z's spot-check of the v1.0.102 artifacts:

  5. The "• N cross-assignee silent-region recommendation(s) suppressed." bullet under "Input spans multiple assignees" was left-indented as a UL item. Re-rendered as centered prose so it reads as a single-line summary metric rather than a detached list.
  6. The "Auto-builder · second-order adjacencies surfaced for {pid}:" block carried a purple background + left-accent card style. Background + border pulled; the bold heading carries the visual weight now. Matches the broader pull-the-boxes posture from v1.0.101.

Safety posture

All three are additive. Telemetry wrappers swallow their own exceptions per the v1.0.100 contract. PDF CSS edits don't change content, only presentation.

v1.0.102 — 2026-05-18 — Phase-2 HIGH-IMPACT (A) + DEEPER architectural (H/I/J)

Why this lands

Pre-Tier-1-retail closing pass on the Perplexity 2026-05-18 critique. Phase-1 (v1.0.101) closed the formatting + MEDIUM items; this release closes the structural items the critic flagged as engine-level fixes drawable from our own pending patent portfolio.

(A) Cluster label degradation — vocabulary-artifact detection upstream

domain_scan.analyze_clusters now computes each cluster's intra-cluster mean pairwise cosine similarity. When that mean sits below 0.45 (the loose-overlap band), the cluster is flagged is_vocab_artifact=True, the label is re-prefixed to "Mixed vocabulary: {top-2 keywords}" instead of pretending the surface vocabulary is a mechanism, and a label_quality_note carries the engine's confidence rationale. CTE ORPHAN-entropy logic (App. No. 64/002,205) applied at the cluster scale.

L1 PDF renders a "⚠ Vocabulary-driven grouping" badge + the engine's note on every flagged cluster card. The memo prompt sees the re-labeled cluster, so the caveat surfaces at first-read in the Landscape PDF, not as a memo-body acknowledgment after the fact (the Perplexity critique §1.1 / §2.3 single biggest trust-erosion fix).

(H) Corpus-relative isolation percentile

deep_run.py now emits, alongside the absolute expansion_value: - expansion_value_normalized — density-corrected scaling based on the neighbor distribution's mean max-claim-similarity - neighbor_density_mean — the corpus-density signal driving the normalization - isolation_class — highly_isolated / isolated / normal / crowded from the normalized read

continuation_memo_synth._compute_coverage_caveat triggers on the corpus-relative isolation_class when available, falling back to the absolute threshold for legacy deep_records. The Coverage Caveat narration now names the density signal explicitly (e.g., "calibrated against this density, not against a fixed absolute threshold") so readers see the isolation read isn't being compared to a wrong yardstick. Consolidated Supplemental §2.10 disclosure (App. No. 64/043,294) made operational.

(I) Continuation axes ranked via CTE Golden Token composite

USER_PROMPT in the continuation memo now instructs Claude to present the 2-4 continuation axes as a NUMBERED ranked list, each axis carrying a four-dimensional composite score (Centrality + Pressure + Void resolution + Strategic clarity, each 1-5). The composite (4-20) leads each axis entry; the reader uses the ranking to decide which axis to discuss with the attorney first. PRIORITY-DATE WARNING flags now explicitly reduce the Strategic-clarity sub-score, so a risky axis ranks below cleaner ones. CTE Golden Token pathfinding (App. No. 64/002,205) made operational at memo-output time (programmatic pathfinder integration over the engine's structural-void graph is the follow-on).

(J) QECO encroachment probability replaces binary ENCROACHMENT DETECTED

deep_run._qeco_encroachment_probability (new) computes a calibrated [0.0, 1.0] encroachment probability from four signals: recency of most-recent border filing, span ratio between most-recent and oldest borders, border count, and assignee diversity (default 1 pending data wiring). Weighted composite: 0.40 recency + 0.20 span + 0.20 count + 0.20 diversity.

_classify_void_kinetic_state retains the existing kinetic_state bucket (stable-silence / decaying-silence / oscillatory / unknown) for legacy consumers but adds encroachment_probability + encroachment_signals on every classified void. The memo prompt now surfaces the probability with the kinetic state ("ACTIVE ENCROACHMENT — encroachment probability: 0.68") and the supporting signals, replacing the prior binary "ENCROACHMENT DETECTED" label. Memo authors are instructed to cite the probability explicitly so the attorney sees how aggressively to move, not just whether to move at all. QECO Entropy-Driven Synchronicity Weaver (App. No. 63/993,979) made operational.

Safety posture

All four are additive. Existing fields stay; new fields are appended. Memo prompts adjust narration without restructuring section flow. If is_vocab_artifact / isolation_class / encroachment_probability are absent on a legacy record, the code falls back to the v1.0.101 behavior.

v1.0.101 — 2026-05-18 — PDF artifact formatting pass + Coverage-Caveat dedup + Layer-2-triggering explanation + Cover-Note draft reference + 3-day access window pulled

Why this lands

Pre-Tier-1-retail polish pass driven by (a) Z's PDF formatting directives + (b) outstanding items from the 2026-05-18 Perplexity critique (Sections 1.2, 1.4, 2.3) that hadn't been closed yet.

PDF — Continuation Memo

PDF — Patent Landscape Analysis

Critique fixes (MEDIUM)

Free-tier access window pulled

Safety posture

PDF rendering changes are CSS + template edits — no engine behavior changes. Cover-note draft-reference addition reads from existing deep_record + filename; never raises. Coverage-Caveat prompt edit shifts where Claude renders the note (end of Section 1 vs top); the content stays equivalent.

v1.0.100 — 2026-05-18 — Foundational telemetry instrumentation (per-call Anthropic + BigQuery usage events)

Why this lands

Ships the Audit-Catalog item A.1: per-call token-usage telemetry. Locked ordering principle from LEF - Ai Engine/Audit-Catalog.md says token-usage telemetry + quality-regression harness must exist before any cost-optimization audit acts — otherwise "let's swap Opus for Sonnet at stage X" is a guess. This release is the telemetry half of that foundation.

What ships

What this enables

Safety posture

Additive only. No engine behavior change. If telemetry.py import fails or Firestore is unreachable, the engine prints one stderr line and continues unchanged. Don't-break-anything constraint honored.

v1.0.87 — 2026-05-17 (overnight ship) — Provenance bug fix + Run ID on every artifact + Auto-L2 for partners + Architecture-axis exposure + Vocab expansion + API JSON candidate fields + Local-runner guard

Why this lands

Z surfaced seven distinct concerns over the 2026-05-17 walk-through after smoke-verifying v1.0.85 + auditing the broader engine surface. Each concern landed as either an engine fix or a structural improvement that materially changes what artifacts read like. v1.0.87 ships all seven in one bundle.

Concern 1 — Provenance chain returned empty on convergence-delta candidates (v1.0.85 BUG)

Smoke verification on the 4-patent semiconductor + KG portfolio surfaced that all 3 convergence-delta candidates returned provenance=[] — every gap card's "Provenance:" section rendered with zero entries. Root cause: the v1.0.85 helper walked edges directly incident to the seed CLAIM node, but for convergence-delta candidates the seed claim (e.g., claim #1) often has zero cross-patent SIMILAR_TO edges itself; the densest convergence is at the PATENT-PAIR level. The seed claim is the bridge candidate, not necessarily the most-connected claim.

hypothesis_engine._top_provenance_for_seeds rewritten to walk edges via the seed claim's PATENT-SET. Algorithm: collect source patent_ids from seed claims → walk ALL SIMILAR_TO edges where one endpoint is in source_patents AND the other is in a different patent → optional cousin_patent_hint (convergence-delta sets this) boosts edges into the actual cousin patent → dedupe by cousin-side CLAIM node, keeping highest similarity. Verified against existing graph (no $ spent): all 3 convergence-delta candidates now return top-2 provenance with real edge weights (0.80 / 0.76 range).

Concern 2 — Run ID on every artifact (Route 4 partners + JDA prospectors had no way to match L1 ↔ L2)

Z surfaced: "for API SaaS, there currently is not that I'm aware of a way to know which landscape goes with which L2 artifacts." Every artifact in the same run now carries a visible Run ID: <sid> line in its attribution footer:

attribution.write_docx_footer_block + attribution.write_html_footer_block both gained an optional session_id kwarg; each artifact synthesizer derives the session id from the artifact path's parent dir (the same convention production + local_run.py use). Customers can now match landscape ↔ memo ↔ provisional ↔ cover note by reading the footer.

Concern 3 — Auto-L2 for route_4 / JDA partner runs (no "click your L2 selections" handshake)

Z surfaced: "make sure SaaS is getting the full L1 L2 output. Not needing to click through what to pick. The same will need to be done for JDAs." Route 4 partners pay $125/run for the full Tier 1 deliverable set; the retail "human picks selections" handshake doesn't apply to programmatic flows.

New _maybe_auto_kick_l2_for_partner(session_id) helper. Called at the end of run_l1_pipeline's success path when intake.route_4 is True OR intake.jda is True. Reads candidates_enriched.json + patents.json to construct a sensible default L2 selection:

Writes l2_selection on session state with auto_kicked=True + auto_kicked_reason for audit. Sets payment_verified=True (partner billing flows via Stripe metered subscription / JDA contract, not the retail $385 cookie). Fires _kick_memo_generation + _kick_provisional_generation against the same async paths the retail layer2-submit handler uses. Failures swallowed (logged but don't fail L1) — partner's L1 artifact + anchor provisional remain valid even if the auto-L2 kick errors downstream.

Concern 4 — Architecture-axis disconnect in Structural Exposure (silent code-not-wired finding)

Z asked tonight "are there other cases like exposure_scoring.py has zero references to architectural_pattern / architecture_extractor that we may be overlooking?" The diagnostic sweep found 4 real disconnects. The single biggest: exposure_scoring.compute_portfolio_exposure() only checked verb__object canonical_elements overlap. The architecture_extractor (shipped v1.0.34, used by hypothesis_engine.py for sub-cluster decomposition) was never wired into exposure scoring. The Structural Exposure table rendered "No exposure detected" on portfolios that genuinely share architecture (graph reasoning + recursive reasoning + diagnostic engines).

exposure_scoring.py rewritten to compute TWO axes in parallel:

Each exposure row carries an axis tag. render_arc exposure table adds a small colored badge above each canonical identifier: blue MECHANISM for verb__object lemmas, purple ARCHITECTURE for noun-phrase patterns — practitioners immediately see whether shared signal is at the mechanism layer (mechanism-specific prosecution moves) or the architectural layer (cross-domain prior-art density). Sort prioritizes (severity, then architecture-axis-first within ties) so newer-signal architecture rows surface alongside mechanism rows. Summary text now distinguishes the two axes: "3 HIGH-exposure shared 2 mechanism + 1 architectural pattern detected across the 5-patent portfolio" instead of the prior single-axis framing.

Concern 5 — Architecture-extractor vocabulary too narrow (cross-domain LEF portfolio reported "no exposure")

After wiring in the architecture axis, the LEF 10-patent portfolio + the KG/RL 8-patent portfolio STILL produced zero patterns each because the extractor's regex vocabulary is a 57-item curated set focused on ML/AI/biotech architectural primitives (attention_mechanism, graph_transformer, lipid_nanoparticle, etc.). It didn't cover the broader system-level architectural shapes DCFN-domain portfolios actually exhibit.

architecture_extractor._PATTERNS_RAW extended with 11 system-level architectural patterns covering reasoning-engine, knowledge-graph, query-system, recursive-reasoning, diagnostic-engine, traversal-architecture, governance-layer, entity-profile, self-optimization, pathway-recommendation, and cross-engine-protocol families. Vocabulary size 57 → 68.

Verification against the existing three smoke graphs:

Combined with the axis-wiring fix above, this closes the v1.0.85 Items 1 + 4 + 6 "code in place but not exercised" finding. Items 1 + 4 + 6 now exercise on portfolios that share LEF-domain architectural patterns.

Concern 6 — /api/v1/* JSON responses missing fields the rendered artifacts surface

Tonight's audit found 3 fields rendered in the HTML/DOCX artifacts but NOT exposed via the /api/v1/* JSON surface:

SaaS partners scripting against the API surface previously couldn't read these without parsing the rendered files. New _build_candidate_summaries(run_id) helper in api_v1.py reads candidates_enriched.json from session storage and returns a structured array. Both POST /api/v1/runs and GET /api/v1/runs/{id} responses now include a candidates array surfacing all four fields plus gap_type + title + rationale + classification + seed_claims.

Concern 7 — local_run.py L2 chain crashed when L1 emitted zero candidates

ROADMAP item closed. Per the LEF 10-patent smoke verification: the local L2 chain crashed with IndexError: candidate_index 0 out of range (0--1) when L1 emitted zero candidates (mechanistically distinct portfolios). That made the L1 outputs look like a failed pipeline. Production-safe (the layer2 UI prevents this) but customer-visible at the local dev surface. local_run.py:main() now validates the candidate index against candidates_enriched.json BEFORE invoking deep_run.py. Out-of-range indices skip with a clean message naming what the L1 actually emitted + suggesting a multi-patent portfolio for cross-patent gap analysis.

What this means for partners + retail Tier 1 customers

Patent claim mapping

Files added

Files modified (engine substance)

v1.0.85 — 2026-05-17 — Perplexity build-order sweep + N=1 hang guard

Why this lands

Z routed the Perplexity 2026-05-17 prioritized-build-order list back through the engine: 16 items grouped by render-layer / engine-layer / architecture-layer / commercial-track. v1.0.85 ships the six items that are cleanly within the v1.0 surface — five Perplexity-flagged + one already-queued ROADMAP bug — in one bundle. Perplexity's strongest catch (the kinetic-decay 2-point heuristic over-claiming monotonic decay) got fixed by adding a label-honesty caveat in the artifact itself, not just by silently keeping the existing classification.

Items shipped

Item 6 — Auto-builder ≥0.70 threshold-boundary warning (render_arc.py) When a second-order adjacency's cosine similarity to the user's filing crosses the ≥0.70 pressure threshold, the auto-builder section now renders an explicit ⚠ Crossing pressure threshold callout: "second-order neighbor at ≥0.70 similarity to your filing. Treat as a near-competitor for prosecution strategy, not as a loose adjacency." Without this escalation, an attorney scanning the auto-builder section reads 0.788 as "adjacency" in the same visual register as 0.504. Perplexity reference: Set 1B at 0.788–0.790 with no escalation signal.

Item 14 — Artifact-internal disclaimer rewrite (continuation_memo_synth.py) The Coverage Caveat box LLM prompt now frames the US-corpus + NPL gap as capability gates (Route 6 JDA for international families; DCFN-Bridge or Route 6 JDA for NPL) rather than "the engine does not ingest" language. The customer-facing public surfaces already used this framing as of v1.0.84; v1.0.85 closes the gap inside the engine's own generated artifacts.

Item 4 — Kinetic-state render translator + label-honesty caveat (continuation_memo_synth.py + hypothesis_engine.py) Two coordinated changes: - Each structural void in the Continuation Strategy Memo now surfaces its kinetic_state (computed in deep_run.py:_classify_void_kinetic_state since v1.0.33) with a plain-English label: ENCROACHMENT DETECTED (with optional colonization_window_months estimate), STABLE SILENCE, VARIABLE, or UNCLASSIFIED — instead of the raw "pair density signal {N}" the v1.0.79 selection_logic surfaced. - A label-honesty caveat appended whenever kinetic state is rendered, explicit about the limitation: "each void's label derives from the filing dates of the two bordering patents… the 2-point heuristic detects bordering recency, not full trend monotonicity — treat ENCROACHMENT DETECTED as a near-window signal, not a proven monotonic decay." Per Perplexity's catch that the existing label semantically over-promised vs the underlying evidence. Full κ(V,t) rolling-window with N≥3 monotonic detection remains queued for v1.1+.

Item 2 — Edge-weight provenance chain on candidates (hypothesis_engine.py + render_arc.py) New provenance: List[dict] field on the Candidate dataclass. Populated at candidate-emit time by a new _top_provenance_for_seeds(G, claim_by_id, seed_node_ids, top_k=2) helper that walks the graph's incident SIMILAR_TO edges for each seed claim, capturing the cross-patent neighbor's {patent_id, claim_number, text_short, similarity}. All three gap-type branches (silent-region, lpa-forward, convergence-delta) populate provenance at emit time. render_arc.py adds a _provenance_block(cand) helper rendering the provenance chain as a styled sub-section on each gap card's detail panel, between the rationale and the selection-logic line. Investigation finding (the reason this fit in v1.0.85): edge weights are already persisted as similarity attributes on graph edges by semantic_bridges.py:147. No traversal refactor required — purely a read at candidate-emit time.

Item 1 — Lemmatized stems → exemplar claim phrase (exposure_scoring.py + render_arc.py) The Portfolio-Wide Structural Exposure table now surfaces an exemplar_claim_phrase under each canonical mechanism identifier — actual claim language from one of the patents that uses the element, with citation. New _find_exemplar_phrase(canonical_element, patents_using_element, claims_by_patent) helper in exposure_scoring.py parses the verb__object compound and searches the patent's claims for one whose text mentions both halves; falls back to verb-only match, then to first-claim of first-patent, so the field is never empty. Practitioners no longer need a Layer 2 run to reverse-map compute compris to actual claim language.

Hypothesis Engine N=1 Hang guard (hypothesis_engine.py) Added an early-return guard at the top of generate_candidates(G, ctx): when distinct patent_ids in the graph < 2, the function logs a clear [hypothesis-engine] N_internal=1 — single-patent input line, narrates the "submit a multi-patent portfolio" path, and returns ([], gate_state) with a single_patent_short_circuit: True flag — instead of entering the per-signal loops and emitting zero candidates after a multi-minute hang. Pipeline returns fast and honest on single-patent inputs. Closes the bug Z hit 2026-05-13 on a combined-PDF upload that read as 1 internal patent.

Items deferred to v1.0.86+

Surface change (not engine)

templates/account.html Upcoming Engine Revisions panel evolved to show LIVE · v1.0.85 (green) vs UPCOMING (purple) status pills per item. Four items transitioned to LIVE this release; four remain upcoming (Stress-tested gap recommendations, Cluster-density-aware similarity bands, Higher-precision similarity calibration, Dependent-claim pressure). LIVE items rotate out approximately 30 days after they ship; new horizon items take their slot.

Patent claim mapping

v1.0.82 — 2026-05-17 — Tier 1 402 self-heal on /layer2/result + cover-note dedup

Why this lands

Z hit two engine bugs on consecutive runs as a Tier 1 admin (mzontonnia):

  1. 402 on /layer2/868fdf0cd322/result while L2 deliverables were generating. Message: "Payment not verified for this session. Complete checkout first." Z is a logged-in Tier 1 admin with an active Run Pack subscription — the message is wrong + the gate is wrong. Other concurrent runs under the same admin worked, ruling out a true payment issue.

  2. Per-provisional cover notes. In sessions with N provisionals, the engine generated N duplicate "Provisional Cover Note.docx" files (one sibling per provisional draft). Content is identical across them — same lexicon warnings, same scope disclaimer, same standard advisory. Customers expect ONE cover note per session, present whenever at least one provisional draft is present.

Fix #1 — 402 self-heal for logged-in Tier 1 users

/layer2/{sid}/result previously gated strictly on state.payment_verified. That flag is set by the /select handler when _has_run_access(request) returns True. But the flag lives on session state — if a request lands on /result via a path that didn't go through /select (refresh after stuck deliverable, "back to artifacts" workaround, deep link), the flag is False and the user 402s.

Fix: before raising the 402, give the request one more chance via _has_run_access(request). That helper already recognizes Tier 1+ subscriptions, firm-pool membership, and BETA_FREE — all of which moot the per-session payment_verified flag. When account-level access is present, the handler self-heals: stamps payment_verified=True on the session state and continues to the deliverables page.

Net behavior: a Tier 1 admin who navigates to /layer2/{sid}/result after their L2 selection — via any route, including refresh, deep link, or workaround — gets the page they paid for instead of a misleading "Complete checkout first" error.

Fix #2 — Cover note collapsed to one per session

_provisional_cover_copy_rel(candidate_id) previously returned a per-candidate session-store slot (__provisional_cover_{candidate_id}.docx). Each provisional's synthesize_provisional() call wrote its own cover note to its own slot, and _pre_run_provisional archived each to Drive separately. Sessions with 3 provisionals = 3 identical "Pre-Filing Instructions" documents in the customer's deliverables + 3 in Drive.

Two coordinated changes: - _provisional_cover_copy_rel() now ignores its candidate_id parameter and returns the stable session-scoped path __provisional_cover_note.docx. The N writes per session are idempotent overwrites of the same slot — only one file lands. (Signature preserved so existing callers don't break.) - The Drive archival path adds a cover_archived session-state flag: the first provisional uploads the cover with item_id="session" (stable, not candidate-keyed), subsequent provisionals see the flag and skip the upload.

The per-provisional __title_validation_warning content is the only thing that could differ across provisionals in a session, and that's rare. The first generated cover wins; if a later provisional in the same session has its own title warning, it gets logged in the engine output but the cover note doesn't reproduce it. Acceptable tradeoff for the dedup win.

Non-engine change landing alongside

Firebase Website/public/licensing/index.html Route 4 section — added a worked-example walkthrough beneath the existing commercial-structure bullets. Two scenarios: (A) partner runs 50 calls/mo → $10,000 invoice (minimum applies, 30 unused prepaid runs do not roll over); (B) partner runs 85 calls/mo → $10,000 + 5 × $125 = $10,625 invoice. Frames the $10K monthly fee as access-gate pricing that covers the first 80 runs, with metered overage at $125/run beyond — same model the engine implements, more vivid customer-facing framing.

Not in this release (captured for next session)

v1.0.81 — 2026-05-17 — Route 4 API auth-error JSON shape fix

Why this lands

v1.0.80 smoke test surfaced that HTTPException(status_code=401, detail=dict) was rendering as {"detail": "{'error_code': 'AUTH_MISSING', ...}"} — the dict was getting stringified inside the detail field by the FastAPI default handler. Partners doing response.json()['error_code'] would have to first parse the stringified dict, which is not a stable API contract.

What changed

api_v1.py introduces an internal _AuthError exception class that carries a pre-built JSONResponse with the right status_code + nested-object content. _require_bearer raises _AuthError instead of HTTPException. A global exception handler registered on the parent FastAPI app at startup catches _AuthError and returns its .response verbatim, producing the clean shape:

{"error_code": "AUTH_MISSING", "message": "Authorization header required. Format: ..."}

Same contract for AUTH_INVALID. Partners can now reliably parse response.json()['error_code'] without first re-parsing a stringified dict.

What also lands (non-engine)

Header CTA on templates/base.html changed from "License DCFN →" routing to a stale Google Doc, to "License DCFN - Patents →" routing to the canonical licensing surface at https://livingedenframeworks.com/licensing/#route-4. UI copy + URL routing only — does not affect the engine pipeline or any API contract.

v1.0.80 — 2026-05-17 — Route 4 API surface (Phase 1: endpoints, auth, manual key issuance)

Why this lands

Route 4 (API / SaaS Module Partnership) has been a mailto: link on the public licensing surface since launch. v1.0.80 ships the first programmatic surface so a qualified Route 4 prospect can integrate during the sales conversation rather than waiting for the full self-serve flow to land. Phase 1 covers the engine + auth + admin-side key issuance; Phase 2 (Stripe-gated auto-issuance), Phase 3 (partner console), and Phase 4 (public docs + pricing-page wiring) will follow in subsequent releases.

What's new

/api/v1/* endpoint surface — mounted via app.include_router at startup:

Authentication — Authorization: Bearer lef_live_<12-char-lookup_id><24-char-secret>. Keys are issued via api_auth.issue_key(); the lookup_id is queryable in Firestore while the secret is bcrypt-hashed (so a leaked DB doesn't leak keys). Verification is a two-step: lookup_id index hit → bcrypt verify against the stored hash. Errors return a stable error_code shape (AUTH_MISSING, AUTH_INVALID, BODY_INVALID, PIPELINE_FAILED, ARTIFACT_NOT_READY, ARTIFACT_NOT_FOUND, INTERNAL_ERROR).

Usage tracking + billing model — each successful run increments a Firestore counter in route4_usage keyed by (partner_id, period) where period is YYYY-MM UTC. Billing computed via api_usage.compute_billing(runs):

(Translation: 0–80 runs/mo bill at the $10K minimum; 81+ runs/mo bill at runs × $125. The 80-run break-even is MONTHLY_MINIMUM_CENTS / PRICE_PER_RUN_CENTS.) Phase 2 will report the period total to Stripe metered usage at month-close.

Admin key issuance — POST /admin/route4/issue-key (auth: DCFN_ADMIN_KEY) mints a key for a named partner deployment, returns the plaintext key ONCE in the response (the bcrypt hash is what's persisted), and emits a warning field reminding the architect to hand the plaintext to the partner via secure channel. Sibling routes: GET /admin/route4/keys (list with bcrypt hash stripped), POST /admin/route4/revoke-key.

Pipeline integration

Route 4 runs flow through the same create_session + run_l1_pipeline path the human /analyze handler uses, but the intake carries route_4=True + route_4_partner_id. The pipeline's firm-pool / per-seat quota counter logic (record_run at completion, firm_inflight increment/decrement) is gated on pending_counter_tier and firm_id — neither of which Route 4 sets — so Route 4 runs cleanly bypass the human-tier billing path. Route 4 has its own usage counter via api_usage.increment() fired from the API handler on success.

Patent claim mapping

What's not in this release

Files added

Files modified

v1.0.79 — 2026-05-17 — Gap-card selection logic + provisional title routing-hazard guard (Perplexity 2026-05-17 in-lane fixes)

Why this lands

The 2026-05-17 Perplexity 8-doc council critique (5 Council + 3 Critique Convo) converged on exactly two in-lane fixes after all the false-positive critiques (figure generation, examiner analytics, international corpus) dissolved against the JDA + HITL architecture. The two survivors are both engine-internal legibility patches — neither adds a new mechanism, both surface already-computed information so the artifact reads as engine output instead of black-box recommendation.

This release lands both.

Fix #1 — Gap-card selection logic surfaced

Every silent-region, lpa-forward, and convergence-delta candidate the hypothesis engine emits is the survivor of a filtering pass: other candidate claims in the same patents had at least one cousin and were dropped; other claims sat in less-dense pairs and ranked below the surfaced one; other LPA claims had cousin counts above the threshold and were treated as already-supported. The filtering criterion was internally computed but not visible on the L1 gap card. Perplexity's review surfaced this as the single most material legibility gap.

hypothesis_engine.py now attaches a selection_logic: str field to every Candidate, carrying a one-sentence criterion describing what THIS candidate passed that others did not:

render_arc.py surfaces the field as a "Selection logic:" line directly under the rationale on each gap card. A new _selection_logic_line(cand) helper renders empty when the field is absent (legacy candidates from pre-v1.0.79 pipeline state), so the render path is safe on rerun against stored artifacts.

Fix #2 — Provisional title routing-hazard validation

The single Perplexity-flagged title self-inconsistency: "METHOD AND APPARATUS FOR MANAGING FILE NETWORK IN A WIRELESS NETWORK" was generated for an ADS-reconciliation distributed file-system invention whose seed claims carry zero wireless / radio / cellular content. The engine's own pre-filing instructions warn about USPTO Art Unit lexicon mismatches, but the title generator itself didn't self-correct against the warning.

provisional_synth.py adds a _validate_title_against_claims() pass that checks every domain-routed title against the seed claim text. When a template qualifier ("IN A WIRELESS NETWORK", "IN AN AUDIO SIGNAL") is in the title but no supporting keyword (wireless / radio / cellular / wifi / 5g / lte / antenna / etc. for wireless; audio / acoustic / speech / sound / voice / spectrogram / waveform / speaker for audio) appears in any seed claim, the title is rewritten to the domain-neutral fallback (SYSTEM AND METHOD FOR {kw}) and a warning is captured on the candidate dict.

The pre-filing instructions packet (assemble_cover_note_docx) now surfaces this warning as a "TITLE VALIDATION NOTICE — ENGINE-CAUGHT ROUTING RISK" block at the top, so the attorney sees both (a) the engine caught the hazard, (b) the engine corrected it to the neutral template, (c) what the original engine draft was, and (d) that they can substitute a domain-specific title if they confirm the underlying claims do support one.

Refactored _uspto_title() from a multi-return shape into a single-exit shape so the validator runs against EVERY domain-routed title path (wireless, audio, biotech, hardware, etc.), not just the final fallback. Wireless and audio qualifiers route to geographically-distinct USPTO Art Units and are the most acute hazards if claims don't support them.

What changed in the artifacts

Patent claim mapping

Source

memory/feedback_no_silent_engine_degradation.md posture: when a domain template can't be supported by the data, the engine doesn't silently emit it; it falls back to the neutral template AND flags what it did so the artifact remains honest about what it could and could not claim.

v1.0.77 — 2026-05-17 — SBERT load is now thread-safe (root cause of L2 cold-start failures)

Why this lands

Z ran two parallel L1+L2 sessions on v1.0.76. Both L1 pipelines ran on separate Cloud Run instances (multi-tenancy verified). L2 on the first session got stuck producing zero deliverables until Z hit "back to artifacts" to free the instance; the second session's L2 then ran fast on a fresh instance. Log trace pulled inst-C (the L2 instance for the stuck session):

19:17:27.319 C [provisional worker] Loading SBERT...
19:17:27.877 C [memo worker] Loading SBERT...        (558ms later)
19:17:27.640 C [sbert-load] meta-tensor even with low_cpu_mem_usage=False; recovery chain.
19:17:27.727 C [sbert-load] meta-tensor even with low_cpu_mem_usage=False; recovery chain.
19:17:28+ C [sbert-load] context-manager load failed (same error, both threads)
19:17:47.694 C [provisional cand=0 deep_run] transient failure detected; in-process auto-retry once after 5s
19:17:47.752 C [memo pid=10936551 deep_run] transient failure detected; in-process auto-retry once after 5s

Two L2 worker threads (provisional + memo) entered get_sbert_model() within 558ms of each other on a cold Cloud Run instance. Both saw the empty _MODEL_CACHE, both passed the cache check, both proceeded into SentenceTransformer(...). Torch's internal global state doesn't tolerate two concurrent meta-tensor inits in the same Python process — both racing inits corrupted each other, both fell into the recovery chain, both hit the same error in the recovery chain, both raised "transient failure," both got auto-retried, both failed again. Deliverables permanently stuck.

The v1.0.66 fix (model_kwargs={"low_cpu_mem_usage": False}) handled single-threaded cold-start loads correctly — same-window L1 pipelines on inst-A and inst-B loaded SBERT cleanly with that fix and that log line. The race condition was an orthogonal bug none of the v0.14.43 / v1.0.60 / v1.0.65 / v1.0.66 patches addressed because they all assumed a single caller.

Fix

Classic double-checked locking. _l1_shared.py:

Per-process lock, per-Cloud-Run-instance. Multi-tenancy unaffected: different instances each have their own _LOAD_LOCK and their own _MODEL_CACHE.

Behavior delta (per feedback_surface_ux_deltas_before_shipping)

No customer-visible UX delta. No new GCP cost. No infrastructure change.

Verified before commit

What this does NOT change

v1.0.76 — 2026-05-17 — Restore generating.html + per-card progress UX (v1.0.75 silently dropped them)

Why this lands

v1.0.75 fixed multi-tenancy by holding the HTTP request open for the entire pipeline duration — the architectural primitive itself is sound and verified. But the way it held the request open (await asyncio.to_thread(run_l1_pipeline, ...) then RedirectResponse) meant the browser sat on a blank loading spinner for ~6 min, never reaching generating.html's named-steps + elapsed-clock UX. Same shape on the L2 result page: cards rendered in their final state on first paint instead of flipping progressively as deliverables settled.

I dropped UX that Z hadn't asked me to drop and disclosed it only in a CHANGELOG line, not in chat. Z had to discover the regression on his own. This release restores the UX while keeping the multi-tenancy guarantee.

The pattern

Stream the template HTML as the response body, then hold the connection open with periodic keep-alive comments until the work completes. The browser receives the full template immediately, parses it, runs the existing per-page polling JS for progress display. Cloud Run sees the request as in-flight for the entire work duration — containerConcurrency=1 continues to route concurrent customer sessions to fresh instances, each with its own GPU + singleton SBERT.

/analyze POST handler. Returns StreamingResponse(_generating_stream(), media_type="text/html"). The generator: 1. Renders generating.html with the same context the legacy /report → generating.html path used. Prepends a <script>history.replaceState({}, '', '/report/{sid}');</script> so the URL bar reads the canonical /report/{sid} location (refresh / bookmark / share-link works). 2. Yields the rendered HTML as the first chunk. Browser paints generating.html immediately — named steps, elapsed clock, the engine-is-thinking feeling. 3. Launches the pipeline via asyncio.create_task(asyncio.to_thread(run_l1_pipeline, sid)). The sync pipeline runs in a thread pool so the event loop stays responsive. 4. Loops on pipeline_task.done(), sleeping 15s between checks and yielding a <!-- ka --> comment each cycle to keep proxies from buffering / timing out the stream. 5. On completion, the generator returns and the connection closes naturally. The browser's polling JS on the page (already running since first paint) detects status == 'ready' within its next ~5s poll and calls window.location.reload(), which navigates to /report/{sid} (now rendering the completed report because the URL bar was rewritten in step 1).

If the user closes the tab mid-stream, the pipeline task continues running in the background (it was created with asyncio.create_task, detached from the request lifecycle). When the user returns to /report/{sid} later, the completed state is there. Cloud Run sees the connection close → instance becomes idle from its routing view → another session can land there. Brief multi-tenancy vulnerability for that user's remaining pipeline time; acceptable for a rare-user-closing-tab edge case.

layer2_result GET handler. Returns StreamingResponse(_result_stream(), media_type="text/html"). Restored fire-and-forget thread dispatch for _kick_memo_generation and _kick_provisional_generation (the synchronous=True parameter introduced in v1.0.75 still exists on those functions but is no longer used on the customer path — kept for any future call-site that wants synchronous dispatch). The generator renders layer2_result.html once at the top with whatever the current per-deliverable state is, yields it as the first chunk, then loops on _compute_deliverable_status until everything settles (or the 25-min ceiling fires). The browser's existing per-card polling JS updates each card live as deliverables flip ready.

What I kept from v1.0.75

The architectural primitive — long-poll request lifecycle keeps Cloud Run aware that the instance is busy, so containerConcurrency=1 routes concurrent sessions to fresh instances — is unchanged. Verified via /test-concurrency?seconds=60: two concurrent invocations land on two different Cloud Run instance IDs (logged previously: 0007b734d9b0a48de2fe98ab... and 0007b734d92a8c2adc7bf5e2...).

Cloud Run service timeout stays at 3600s.

What I'm not doing

I am NOT firing concurrent customer L1 runs to ground-truth the customer-path under live load. That spends API + BigQuery on Z's accounts. The architectural primitive is verified. The L1 and L2 handlers use the same await asyncio.sleep + streaming pattern as /test-concurrency. Honest acknowledgment that this is one logical step removed from a customer-path concurrent-load proof — deferred to Z's discretion.

Verified before commit

v1.0.75 — 2026-05-17 — Multi-tenancy ACTUAL fix (Shape C) — handler-held request lifecycle replaces background-task dispatch

Why this lands

Z's two-concurrent-run regression test (this session) proved that v1.0.71's "multi-tenancy restored" claim was wrong on the substance. The smoke I ran for v1.0.71 was code-shape only (lock definition removed, with-block usages removed) — never a concurrent-load test, exactly the third pattern from memory/feedback_engineering_honesty_discipline.md. Under actual concurrent load the symptom persisted: two pipelines on the same Cloud Run instance, the same Python process, the same singleton SBERT, sharing one GPU, degrading each other.

Root cause traced through git: the May 16 v1.0.67 commit moved L2 generation in-process to solve a real GPU OOM, and disclosed the throughput trade-off in its own message ("_INPROC_ENGINE_LOCK serializes engine work across sessions for GPU correctness ... Cross-session throughput drops"). Three and a half hours later I shipped v1.0.71 and removed the lock without understanding what it was protecting. Removing the lock removed the explicit serialization but left the implicit contention (one Python process per Cloud Run instance, shared singleton SBERT, shared GIL).

The deeper architectural cause sits in the trigger surfaces: L1 was kicked via FastAPI BackgroundTasks and L2 via fire-and-forget daemon threads, both of which return from the HTTP handler immediately. Cloud Run's containerConcurrency=1 only counts in-flight HTTP requests — it never sees the background pipeline as work. After the handler returns, Cloud Run marks the instance idle, and the next customer's POST lands on the warm "idle" instance, sharing GPU + singleton SBERT with the in-flight background work.

Fix: tie request lifecycle to pipeline lifecycle (Shape C from this session's design discussion)

The HTTP handler now holds the request open for the entire duration of the work it kicked off. Cloud Run sees the instance as in-flight for the whole pipeline. containerConcurrency=1 then correctly routes concurrent customer sessions to fresh instances — each with its own GPU, its own singleton SBERT, its own Python process. Genuine parallelism, not the v1.0.71 contended-singleton illusion.

L1 — /analyze POST handler. Replaced background_tasks.add_task(run_l1_pipeline, session_id) with await asyncio.to_thread(run_l1_pipeline, session_id). The sync run_l1_pipeline runs in a thread pool so the asyncio event loop stays responsive to /status polling from other browser tabs while this request holds. POST stays open ~6 min, then 303-redirects to /report/{session_id}.

L2 — _kick_memo_generation + _kick_provisional_generation. Added synchronous: bool = False kwarg to both. When True, runs the worker pool inline on the calling thread instead of dispatching to a daemon thread. The layer2_result handler now invokes both via asyncio.gather(asyncio.to_thread(..., synchronous=True), asyncio.to_thread(..., synchronous=True)) after Stripe verification — parallel pool execution AND request-held-open lifecycle.

L2 — layer2_result handler render-path await. The /select endpoint's BETA_FREE / has-cookie branch still uses fire-and-forget kicks (returns JSON ack quickly to the browser, which then navigates here). The layer2_result handler now polls session state until every deliverable settles before rendering — single source of truth that any path into this page holds Cloud Run aware. 25-minute upper bound on the wait prevents a stuck worker from pinning the request forever; on timeout the page renders with whatever state we have and the existing frontend polling JS continues to update cards as they complete.

Cloud Run service config. Request timeout bumped from 300s (5 min) to 3600s (1 hour). L1 baseline is ~6 min; the prior 300s ceiling would have failed a long-poll POST immediately. 1-hour ceiling accommodates a 3-deliverable L2 pool worst case with headroom.

Architectural smoke endpoint

Added /test-concurrency?seconds=N (default 30, capped 90). Holds the HTTP request via await asyncio.sleep(N) and returns the instance's hostname + pid. Two concurrent requests should land on different Cloud Run instances if and only if the long-poll-request pattern is being honored correctly by Cloud Run's routing under containerConcurrency=1. Cheap (no engine, no API costs) so we can ground-truth the architectural primitive without burning customer-billable work.

Multi-tenancy / cost / quality / deploy-survival impact

Dimension Change
Multi-tenancy Restored for real this time. Concurrent customer sessions route to fresh Cloud Run instances per containerConcurrency=1. Each instance has its own GPU + singleton SBERT — no contention. Verified via the /test-concurrency smoke pre-customer-load.
Per-run cost None. Same code paths under the same Anthropic + BigQuery accounts.
Customer-visible UX changes: L1 form POST takes ~6 min before the 303 redirect to /report; the existing in-page "generating..." polling page is gone from the wait period. L2 result page holds for ~5-10 min on first arrival from Stripe before rendering; cards appear in their final state on first paint instead of progressively flipping ready. Substantive output identical.
Quality No engine output change. Architecture-only refactor.
Deploy-survival Cloud Run timeout bumped to 3600s. No infrastructure cost change at idle (instances scale to zero between bursts as before); under concurrent load, Cloud Run spins up additional instances (cold start + own GPU + own singleton) instead of contending a single instance — slight cost increase per concurrent run, expected and correct.

Verified before commit

NOT verified before commit (deferred to post-deploy)

v1.0.73 — 2026-05-17 — Perplexity Pass: cover note split out · thin-neighborhood callout · encoder/threshold methodology signal on page 1

Why this lands

Three artifact-shape changes surfaced by Perplexity's second-pass critique of the v1.0.71 output. Each lands on a different evaluator-trust dimension; bundled here because they ship as one engine release.

Change 1 — Cover note delivered as a separate file (no longer embedded as page 1 of the provisional)

The pre-filing instructions block (lexicon / art-unit routing warning, scope disclaimer, file-only-the-draft instruction, standard advisory) previously rendered as page 1 of the provisional .docx with a "DELETE THIS PAGE BEFORE FILING" header. Customers had to remember to strip the page before USPTO upload, and USPTO guidance penalizes machine-generation disclaimers inside filed bodies — a missed deletion meant examiner-scrutiny risk on a paid artifact.

The cover note now renders as a sibling .docx delivered alongside the provisional. The customer sees two clearly-labeled cards at L2 results:

The provisional .docx now begins directly with PROVISIONAL PATENT APPLICATION — no cover page preceding it. The cover .docx is a standalone file with the same lexicon/scope/file-only/advisory content but reframed for the new delivery model (header is now PRE-FILING INSTRUCTIONS — READ BEFORE UPLOADING; warning item 3 is now FILE ONLY THE PROVISIONAL DRAFT instead of DELETE BEFORE UPLOAD).

Both files are bundled in the same delivery package: same payment gate, same selection gate, both archived to Drive (Drive snapshot now captures both artifacts independently per _KIND_TO_ARTIFACT["provisional_cover"] registration). On the rare partial-write edge case where the provisional .docx writes but the cover doesn't, the customer still gets the provisional and the cover card surfaces a failed state with a retry pointer; on provisional failure, the cover card is suppressed entirely (a single provisional retry regenerates both files).

Implementation: - provisional_synth.py: cover_note_path_for(provisional_path) derives the sibling path. assemble_cover_note_docx(deep_record, cover_path) builds the standalone cover .docx. synthesize_provisional now writes both files and returns both paths. - app.py: _provisional_cover_copy_rel(candidate_id) provides the session-scoped slot. _pre_run_provisional copies the cover sibling and stores cover_path alongside path. _compute_deliverable_status emits the cover card with lifecycle mirroring the provisional. Download endpoint handles kind == "provisional_cover" with the same gating as the provisional. - publish.py: provisional_cover registered in _KIND_TO_ARTIFACT + _KIND_TO_LAYER_TIER for Drive archival. - templates/layer2_result.html: kind labels reframed; new 📑 icon for the cover-note card.

Change 2 — Page-1 thin-neighborhood callout in the landscape report (conditional)

Previously, when all of a filing's cluster neighbors fell under the 0.50 thematic-adjacency threshold, the caveat about sparse/unreliable neighborhood data only surfaced inside the Textual Isolation Score explanation in the Layer 2 memo — buried on page 2+ of a downstream artifact the L1 reader may never reach.

The landscape report now carries a conditional page-1 callout that lists any input filing whose nearest external neighbor scores below 0.50. Bordered red block, "⚠ THIN NEIGHBORHOOD DETECTED" header, filings listed with their best-neighbor scores. Renders only when the condition fires — not a permanent fixture.

Spec-vs-implementation note (on record for any future reviewer): Perplexity's spec reads "all top-5 neighbors for any filing score below 0.50." The L1 engine stores per-filing best neighbor in domain_analysis.json["nearest_competitors"], not top-5. The conservative-equivalent implementation tests against the best neighbor: if a filing's BEST external neighbor is < 0.50, then by definition every top-N is too — so the callout fires on exactly the same filings the spec targets, without re-walking the similarity matrix at render time. Filings with one meaningful adjacency (best ≥ 0.50, rest below) do NOT trigger the callout — correct behavior, since the engine has a real signal to read against in that case.

Implementation: _build_thin_neighborhood_callout(da) in render_arc.py walks nearest_competitors, dedups by your_patent, and emits HTML inserted into the landscape template via a new {thin_neighborhood_html} format key positioned directly after the corpus-scope banner and before the <div class="container"> cluster breakdown.

Change 3 — Static encoder + threshold methodology signal on page 1

The corpus-scope banner now carries a methodology-signal sub-block disclosing the embedding model and similarity thresholds the engine uses to interpret scores. Static string (no logic), positioned directly below the existing corpus disclosure, monospace font, separator dotted line above:

Similarity computed via SentenceTransformer all-mpnet-base-v2 (768-dim cosine); thresholds: ≥0.70 pressure · 0.50–0.70 adjacency · <0.50 loose overlap.

This complements v0.14.14's Methods disclosure block (which lives at the end of the report) by surfacing the encoder identity + threshold scale at the point the reader first encounters similarity scores. Pairs with Change 2's callout — readers who see "thin neighborhood (best 0.42)" now have the threshold context (0.42 falls in the loose-overlap band) without scrolling to the appendix.

Multi-tenancy / cost / quality / deploy-survival impact

Dimension Change
Multi-tenancy No impact. No new locks; no shared mutable state.
Per-run cost No impact. No new LLM calls; cover note uses already-generated content.
Customer-visible Three new artifacts: (a) cover note as separate downloadable file, (b) conditional thin-neighborhood callout on landscape page 1, (c) static methodology signal on landscape page 1. Existing artifacts unchanged in substance — only the cover note's location changes (still ships, now alongside not inside).
Quality Stronger. Read-first vs file-as-is roles are distinguished at the download step; thin neighborhoods are flagged on page 1 instead of page 2+ of a downstream artifact; methodology signal lives where the reader needs it.
Deploy-survival No new infra. New session slot (__provisional_cover_<cid>.docx) handled by the existing session_store adapter (GCS on Cloud Run, disk locally). Drive archival registers a new provisional_cover kind in the existing maps.

Verified before commit

v1.0.71 — 2026-05-17 — Multi-tenancy restored (engine-lock dropped) + LLM-driven bridge-patent abstracts (Perplexity Option 2)

Why this lands

Two changes in one ship, both ground-truthed against the Lic Doc v7.5 commercial context Z surfaced in memory/DCFN_COMMERCIAL_CONTEXT.md:

  1. _INPROC_ENGINE_LOCK dropped from _run_engine_inproc_with_transient_retry. v1.0.67 added a cross-session lock that solved GPU memory fragmentation by preventing concurrent SBERT model duplication — correct fix at the singleton layer (kept) — but ALSO serialized all engine work across customer sessions within a container, violating Charter §11 multi-tenancy (Tier 0 + Tier 1 share Cloud Run; concurrent sessions must run in parallel). Z surfaced this on 2026-05-16 as "not acceptable" after two parallel L2 sessions each took 20+ minutes queueing behind the lock. The lock removal restores concurrent throughput; SBERT inference (model.encode()) is thread-safe and PyTorch's CUDA backend naturally serializes kernel launches at the GPU layer (the correct place for serialization — the GPU is the contended resource, not the Python interpreter). Lock object + all with _INPROC_ENGINE_LOCK: usages removed; one comment block retained documenting the removal for future-instance context.

  2. LLM-driven bridge-patent abstract synthesis for convergence-delta candidates (Perplexity 2026-05-16 critique 2, Option 2). The prior _draft_abstract convergence-delta path was pure-template — concept tokens wrapped in a fixed sentence shape, reading as boilerplate to evaluators. Perplexity's Option 2 grounds the abstract in BOTH the actual claim text of both convergence-pair filings AND the engine-computed structural-void quantitative coordinate (pair_density signal). Per Z's 2026-05-17 greenlight: Option 2 chosen over Option 1 minimum-fix because it uses data the engine already computed at no incremental cost per call.

Implementation — bridge abstract synthesis

hypothesis_engine.py — Candidate dataclass extended. Two new fields, populated only for convergence-delta candidates: - cousin_patent_id: str — the missing-mirror side patent (first of missing_sides) - pair_density_signal: int — SIMILAR_TO edge count between source patent and cousin (the structural-void quantitative coordinate)

Backward-compat preserved: silent-region + lpa-forward candidates default both fields to "" / 0; no consumers downstream require them.

render_arc.py — new _synthesize_bridge_abstract(cand, patents_lookup) helper. Looks up source claim text (already on cand.seed_claims[0]), cousin's first independent claim text (via patents_lookup[cousin_patent_id]), pair_density_signal, and concept tokens; builds a focused Haiku 4.5 prompt that asks for 3-5 sentences describing what the bridge patent would CLAIM as a method/system/composition; returns the LLM response or None on any failure (missing data, missing API key, Anthropic call failure).

render_arc.py — _draft_abstract extended with optional patents_lookup=None kwarg. For convergence-delta candidates with patents_lookup provided AND _synthesize_bridge_abstract returning non-None, the LLM output replaces the template path. ALL other paths (silent-region template, lpa-forward template, convergence-delta template fallback) unchanged — defense in depth: any LLM failure path falls through to existing template, abstract still renders, never blank.

render_arc.py — build_candidates_html loads patents.json once at top of render and builds {patent_id: patent_dict} lookup; passes into every _draft_abstract call. Same data the existing portfolio rendering reads; no extra file I/O cost.

Cost envelope verified before ship

Per-call cost (Haiku 4.5): - Prompt ~1500 tokens × $0.80/M = $0.0012 - Output ~300 tokens × $4/M = $0.0012 - ~$0.0024 per convergence-delta candidate call

Per-L1 cost increase: - Tier 0 caps at 3 candidates total; Tier 1 at 5; Tier 2 at 10 — convergence-delta is typically a subset - 3-10 candidates × $0.0024 ≈ $0.007–$0.024 per L1 - Well under Z's $0.10/L1 cap and the $0.25/L1 ceiling

If Sonnet 4.5 used instead (10x cost): ~$0.027–$0.09/L1 — still under cap, would deploy as v1.0.72 if test runs show Sonnet materially better on bridge-abstract quality.

Multi-tenancy / cost / quality / deploy-survival impact (per DCFN_COMMERCIAL_CONTEXT.md pre-decision checklist)

Aspect Impact
Multi-tenancy ✅ RESTORED to Charter §11 floor (engine lock removed; cross-session parallelism returns)
Per-run cost +$0.007–$0.024/L1 for convergence-delta synthesis (well under cap)
Customer-visible Bridge abstracts read as engineered prose grounded in actual claim text + structural coordinates, replacing template boilerplate Perplexity flagged. Tier 0 quality floor strictly improved on the licensing-evaluator surface
Quality floor Stronger — defense-in-depth fallback ensures abstract never goes blank if Anthropic unavailable
Deploy survival LLM calls stateless; in-flight L1 hitting a deploy fails at Anthropic call (caught by existing retry wrapper). Same risk as pre-v1.0.71

Verified before commit (per engineering-honesty discipline)

End-to-end verification (real Anthropic call with realistic data) requires production — first L1 with convergence-delta candidates after deploy will exercise the path. If anything surfaces, fallback path keeps the abstract rendering.

VERSION → 1.0.71.

v1.0.70 — 2026-05-16 — Build List Item 36: missing JDA contract sections 4/5/6/8/9/10/11/13/14

Why this lands now

The 2026-05-16 Item 28 audit flagged the JDA contract assembler as missing nine sections — jda/contract_assembler.py emitted only §§ 1, 2, 3, 7, 12, 15 + Signatures, while the numbering convention implied a 15-section contract. The audit listed this as HIGH-priority-if-real (couldn't determine from source whether the missing sections were in a static DocuSign overlay or genuinely absent from generated output). Z confirmed: build them.

Sections added

Nine new sections in assemble_contract_html:

§15 General expanded with 7 standard subsections (Governing Law, Entire Agreement, Amendment, Notices, Assignment, Severability, No Waiver) instead of the single Governing Law clause that was there.

Verified before commit

End-to-end DocuSign render verification requires production env — first real Route 6 JDA will surface any partner-counsel-flagged issues.

VERSION → 1.0.70. Carries v1.0.67 + v1.0.68 + v1.0.69.

v1.0.69 — 2026-05-16 — Build List Item 34: Bidirectional Brand Display Addendum (Schedule B)

Why this lands now

The 2026-05-16 Item 28 audit flagged the Bidirectional Brand Display License Addendum as MED priority missing. The §2.1 attribution-on-artifacts requirement has been BEHAVIORALLY codified in attribution.write_html_footer_block() since v1.0.42 (2026-05-01), but the standalone contractual document partner counsel would actually read and sign didn't exist — every JDA went out with the §2.1 behavior in code but no signed addendum binding Partner to it.

New module — jda/brand_display_addendum_assembler.py

Same assembler pattern as Schedule A (license_schedule_assembler.py, v1.0.63). Six sections:

Per feedback_lef_ai_is_the_patent_substrate.md: "Built on the LEF Ai Engine" on Partner-facing marketing surfaces; "Powered by DCFN-Patents" on customer-facing outputs. Both made contractually non-removable by §2.1.

DocuSign envelope — now tri-document (JDA + Schedule A + Schedule B)

jda/docusign_envelope.py:send_envelope_for_intake now: - Renders all three documents (master JDA + Schedule A License Schedule + Schedule B Brand Display Addendum) - Uploads each to GCS via contract_paths.preview() / contract_paths.schedule_a() / new contract_paths.schedule_b() - Attaches all three to the envelope (documentId 1, 2, 3) - Adds tri-document signature anchors to BOTH signers — partner and LEF each get [SIGNATURE_*] + [DATE_*] for the JDA, [SIGNATURE_*_SCHEDULE_A] + [DATE_*_SCHEDULE_A] for Schedule A, and [SIGNATURE_*_SCHEDULE_B] + [DATE_*_SCHEDULE_B] for Schedule B - Envelope emailBlurb mentions all three documents

All three documents arrive in the same DocuSign envelope. Partner counsel reads all three before either signs. Partner signs all three on one DocuSign session.

Verified before commit

End-to-end DocuSign verification requires production env — surfaces in first real Route 6 JDA execution.

VERSION → 1.0.69. Carries v1.0.67 (GPU OOM in-process refactor) + v1.0.68 (Renewal Addendum generator).

v1.0.68 — 2026-05-16 — Build List Item 35: Renewal Addendum generator (EXTEND path self-serve)

Why this lands now

The 2026-05-16 Item 28 audit flagged the Renewal Addendum generator as MEDIUM priority. v1.0.56 shipped the renewal-intent intake (jda/renewal_requests.py + /jda/renewal-request form), but the admin queue's "prepare addendum" link had no generator behind it — every EXTEND renewal request routed through Z to assemble the addendum manually. Now self-serve.

New module — jda/renewal_addendum_assembler.py

Same pattern as contract_assembler.py and license_schedule_assembler.py (v1.0.63). Builds a Renewal Addendum HTML/PDF tied to a specific renewal request + active JDA. The addendum confirms the EXTEND election, names the renewed Cycle dates (12-month window starting at next anniversary), affirms that JDA + Schedule A terms carry forward unchanged, and surfaces any §3 modifications (rate adjustments per LS §8.5 cap, partner notes from the renewal request).

Public surface: - assemble_renewal_addendum_html(renewal_record, active_jda, rate_adjustment_pct=None) → str - render_renewal_addendum_pdf(renewal_record, active_jda, rate_adjustment_pct=None) → bytes

rate_adjustment_pct is optional and must be ≤ 5% (License Schedule §8.5 cap); raises ValueError if exceeded. Default None means no commercial rate changes — all terms carry forward.

DocuSign wiring — jda/docusign_envelope.py

New send_renewal_envelope_for_request(req_id, rate_adjustment_pct=None) → dict. Pulls the renewal request from Firestore, fetches the active JDA for partner metadata, renders the Renewal Addendum PDF, archives to GCS at intakes/{jda_id}/renewals/{req_id}/addendum.pdf, sends a DocuSign envelope to partner + LEF with renewal-specific signature anchors ([SIGNATURE_PARTNER_RENEWAL] etc. — same shape as the v1.0.63 Schedule A pattern). Raises ValueError on EXTEND-only validation (MODIFY routes to re-intake, DECLINE routes to crypto-erasure attestation per the existing renewal request UI).

Returns envelope_id + status + addendum PDF GCS URI + any rate adjustment applied. Does NOT mutate the renewal request status — that's the admin route's job.

Admin route — app.py /admin/jda-renewals/{req_id}/send-extend-envelope

POST handler that ties it together. Admin-key-gated. Accepts an optional rate_adjustment_pct form field (numeric, capped via the assembler validation). On success:

  1. Calls send_renewal_envelope_for_request (envelope fires to DocuSign)
  2. Adds an internal note to the renewal request capturing envelope_id + any rate adjustment + GCS PDF URI
  3. Flips request status to in_progress (matches existing renewal state machine)
  4. Redirects back to the admin queue

Error paths: ValueError → 400 with the assembler's message (e.g. "exceeds License Schedule §8.5 cap"); RuntimeError from DocuSign API → 502 with the DocuSign error body.

Admin template — templates/admin_jda_renewals.html

The placeholder text "prepare addendum" (line 76) replaced with a real form: optional rate-adjustment text input + "Send EXTEND envelope" button. Form posts to the new route with the admin_key passed through. Visible only when renewal status is submitted or reviewing — once envelope is sent (status in_progress), shows "addendum sent" instead.

Verified before commit

End-to-end DocuSign verification requires production env (real DocuSign account credentials + an active JDA in Firestore + partner-side click-through). Will surface in first real EXTEND renewal.

What this is NOT

This does NOT handle MODIFY renewals (those route to re-intake, separate flow) or DECLINE renewals (those route to crypto-erasure attestation, already wired in v1.0.54). EXTEND is the most common renewal path; MODIFY + DECLINE remain admin-manual until a partner actually needs them.

VERSION → 1.0.68.

v1.0.67 — 2026-05-16 — GPU OOM architectural root-cause fix: L2 generation moves in-process

Why this lands now

Per Z's "actually fix them, not surface bandaids" directive. v1.0.65's GPU OOM ship had three components: expandable_segments:True PyTorch flag (fragmentation mitigation), L2_GEN_CONCURRENCY 3→1 (concurrent-load mitigation), and OOM classifier patterns (retry-on-transient surface management). All three are mitigations, not architectural fixes. The actual root cause is the subprocess model itself: every L2 deliverable was spawning python deep_run.py + python provisional_synth.py (or python continuation_memo_synth.py) as separate processes. Each subprocess loaded its own SBERT model into GPU memory (~3–4 GB resident per copy). On a shared L4 (24 GB), 3–5 concurrent generations could fragment the memory pool despite total usage well under cap. Z's 2026-05-16 ~7:30 PM OOM report: Process 1490 has 3.31 GiB. Process 1537 has 3.72 GiB... — exactly this pattern.

The architectural fix replaces subprocess spawning with in-process function calls. The _l1_shared._MODEL_CACHE singleton has existed since v0.14.43; moving the L2 callers into the same Python process means it becomes a genuine singleton across the container lifetime. SBERT loads once, every L2 generation reuses the same instance, GPU memory footprint becomes O(1) in the number of concurrent sessions instead of O(N).

Refactor — deep_run.py

Extracted two callable entry points from main():

Both do exactly what main() did via argparse, but as plain function calls — load JSONs, run the candidate/patent traversal, write the output JSON, print summary, fire the audit hook. main() becomes a thin argparse shim that delegates to these. The CLI path (python deep_run.py --patent X ...) still works identically for local debugging and any legacy invokers.

Refactor — app.py

New helpers (added just before _pre_run_provisional):

Two subprocess-spawning sites replaced with in-process calls:

The v1.0.62 subprocess wrapper _run_engine_subprocess_with_transient_retry is preserved unchanged for any future caller that genuinely needs subprocess isolation, but it has no active callers in the L2 flow as of v1.0.67.

Trade-offs (honest)

Verified before commit

End-to-end verification (actual L2 generation against real session data) requires production environment — happens on next L2 run after deploy.

VERSION → 1.0.67.

v1.0.66 — 2026-05-16 — Meta-tensor root-cause fix + prompt-template pre-commit smoke

Why this lands now

Per Z's 2026-05-16 directive: "its not about hiding or giving excuses for errors. we do need to actually fix them." That landed. v1.0.60 / v1.0.65 had been adding fallback chains and humanized error messages — symptom management dressed as fix. The actual root cause of the meta-tensor errors is that recent transformers versions default low_cpu_mem_usage=True when accelerate is installed, which triggers meta-init in the underlying model constructor. Every fallback I'd built was working around that default rather than disabling it.

Root-cause fix — _l1_shared.get_sbert_model

SentenceTransformer(...) accepts a model_kwargs parameter that pipes through to the underlying transformers from_pretrained() call. Setting model_kwargs={"low_cpu_mem_usage": False} disables the meta-init pathway at the source. v1.0.66 promotes this to the PRIMARY load path. The v1.0.60 / v1.0.65 fallback chain stays as defense in depth (extracted into a _recovery_chain_from_meta_tensor helper for clarity), but the primary path now actually prevents the bug rather than recovering from it.

Verified locally before commit (per the "actually verify" lesson): primary load against installed sentence-transformers==5.2.0 succeeds, encodes a test string to a correct 768-dim embedding, fallback chain doesn't fire. Production has >=2.7,<4.0 so the model_kwargs parameter is supported (introduced in ST 2.3+); if a future combo doesn't accept it, the TypeError-catch falls through cleanly to legacy paths.

Pre-commit smoke — scripts/check_prompt_templates.py

The v1.0.65 promise. New script that walks every prompt-template dict in the engine (SECTION_PROMPTS today; designed to accept additional dicts as they get factored out of inline f-strings) and calls .format(**realistic_kwargs) on each. Exit 0 = safe; exit 1 = bug.

Tested both directions: (a) on current source, all 6 SECTION_PROMPTS pass cleanly; (b) on a synthetic re-introduction of the v1.0.57 {N} bug, the hook correctly raises KeyError: 'N' and refuses (exit 1). If this hook had existed at v1.0.57 commit time, the bug would never have shipped.

RELEASE_PROCESS.md step 2b now requires running the hook before commit when the diff touches prompt-template modules. The script is also installable as a .git/hooks/pre-commit symlink for automatic enforcement (documented in the script's own docstring + RELEASE_PROCESS.md).

What this is NOT

This is not a fix for the GPU OOM root cause. That requires architectural refactor (in-process work queue replacing subprocess workers, eliminating per-process model duplication) and remains queued for a Z-decision conversation rather than a unilateral ship.

VERSION → 1.0.66.

v1.0.65 — 2026-05-16 — L1 step error humanization + GPU OOM mitigation + stronger meta-tensor fallback

Why this lands now

Z's 2026-05-16 ~7:30 PM report: continued engine failures on L1 runs, now showing two distinct error surfaces:

"Engine step 'semantic_bridges' failed: 1 GiB memory in use. Process 1490 has 3.31 GiB memory in use. Process 1537 has 3.72 GiB memory in use..."

"Engine step 'semantic_bridges' failed: Cannot copy out of meta tensor; no data! Please use torch.nn.Module.to_empty()..."

Three distinct gaps in prior shipments:

  1. The "Engine step 'X' failed: {raw stderr}" message at app.py:1457 (L1 inline-step error path) was NOT going through v1.0.62's _classify_engine_subprocess_error — that wrapper only covered L2 subprocess paths. Raw stderr (with PyTorch internals and traceback fragments) was reaching the customer UI.
  2. GPU OOM — multiple subprocess SBERT loads sharing the L4 attached to one container were fragmenting the GPU memory pool. Despite total usage well under the 24 GiB cap, individual allocations were failing because PyTorch couldn't find contiguous space.
  3. Meta-tensor errors persisted despite v1.0.60's device='cpu' fallback — turns out even the CPU parameter path can trigger meta-init in some torch + transformers + accelerate combos.

Fix — four bundled changes

1. L1 step error humanization (app.py:1457). The L1 step orchestrator now wraps the raw stderr through _classify_engine_subprocess_error (the same humanizer the L2 subprocess wrapper uses). Result: meta-tensor errors → "Engine substrate is warming up..."; GPU OOM → "Engine GPU memory was momentarily exhausted by concurrent workloads...". Customer never sees Process 1490 has 3.31 GiB memory in use or Cannot copy out of meta tensor; no data! again.

2. GPU OOM mitigation (Dockerfile + app.py). - New Dockerfile env: PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True. PyTorch-recommended setting for multi-process workloads sharing a GPU. Reduces fragmentation pressure without changing workload concurrency. - Default L2_GEN_CONCURRENCY dropped from 3 → 1. L2 deliverables now generate sequentially by default rather than 3-in-parallel. Slower aggregate latency, but eliminates the GPU contention that was producing OOMs. Z can override per-deployment via the DCFN_PATENTS_L2_GEN_CONCURRENCY env var if a less GPU-constrained environment makes parallelism safe.

3. Stronger meta-tensor fallback (_l1_shared.py:get_sbert_model). v1.0.60 used device='cpu' parameter on the fallback. v1.0.65 routes through with torch.device("cpu"): context manager instead — this sets the default device for all tensor allocations during the SentenceTransformer constructor, bypassing the meta-init pathway entirely. Three-attempt fallback chain now: (1) primary device=device, (2) torch.device("cpu") context manager + transfer, (3) legacy v1.0.60 device='cpu' parameter as last resort before raising. Each attempt logs visibly to Cloud Run so operational visibility is preserved.

4. New OOM classifier patterns. _classify_engine_subprocess_error now recognizes out of memory, OutOfMemoryError, cuda...memory, and the multi-process Process X has Y GiB memory in use pattern. All classified as transient, so auto-retry kicks in for the subprocess wrapper paths and the humanized message reaches the L1 surface via the §1 fix above.

Verified before claiming

Per the lesson from earlier today: smoke tests run BEFORE the commit, not after a customer hits the bug.

The pre-commit hook from v1.0.65 plan is still queued (deferred for production-down fix priority); it would have lived alongside these smokes as a structural prevention. Will land as v1.0.66.

VERSION → 1.0.65.

v1.0.64 — 2026-05-16 — Provisional brace-escape fix (v1.0.57 Q8 regression) + v1.0.63 carried forward

What broke

Z's 2026-05-16 ~7 PM run report: provisional generation hitting "Engine generation failed. Click Retry to attempt again." on every retry across multiple L2 sessions (/layer2/f1baf42088dd/result, /layer2/d8bd92492ddf/result). v1.0.62's auto-retry wasn't kicking in because the failure didn't match any known-transient pattern. Cloud Run logs revealed the actual stderr:

File "/app/provisional_synth.py", line 878, in _generate_section
    user_prompt = prompt_template.format(...)
KeyError: 'N'

Root cause — my own bug from v1.0.57 (Q8 figure placeholder prompt addition)

When I added the Q8 figure-placeholder prompt block to the detailed_description template, I wrote Figure {N} as literal example text — without escaping the braces. Every str.format() call on that template now tries to substitute {N} as a parameter, finds no N kwarg, raises KeyError: 'N'. Deterministic — fails every retry the same way. v1.0.62's transient-retry wrapper correctly doesn't classify KeyError as transient, so the customer sees the v1.0.62 generic fallback ("Engine generation failed") rather than the raw traceback, BUT the fallback's "Click Retry" instruction is misleading because no retry will ever succeed against this deterministic failure mode.

Existing prompts in provisional_synth.py already use the {{kwargname}} double-brace escape for literal braces — examples at lines 173 ({{void_band}}) and 176 ({{alternative_embodiments}}). I knew the pattern. I missed applying it on the Q8 addition because the prose context was different (writing example text for the LLM, not template metadata). Lesson for the next instance: any literal brace character in a string that downstream code calls .format() on must be doubled. Smoke test for this: walk SECTION_PROMPTS with re.findall(r'(?<!\{)\{([a-z_]+)\}(?!\})', tmpl) and assert every placeholder is in the expected-kwargs set.

Fix

Single-character fix (well, four-character: {N} → {{N}}) at provisional_synth.py:166. Added a parenthetical instruction line below clarifying that {N} in the example is template-escaped — the LLM substitutes sequential integers in its output. Doesn't change any other prompt semantics.

Smoke-tested with re.findall over SECTION_PROMPTS — all six section prompts now resolve cleanly to their expected kwarg sets (no stray placeholders).

Bundled — v1.0.63 (License Schedule) carried forward

Since git is cumulative and v1.0.63's image hadn't been deployed yet, this ship carries v1.0.63's License Schedule work (Schedule A assembler + DocuSign envelope wiring + GCS archival path) AND the brace-escape fix. One build cycle instead of two — gets Z's stuck session unstuck faster.

Recommended follow-on (not in this ship)

Add a pre-commit hook that runs the re.findall smoke over SECTION_PROMPTS and refuses commits that introduce unescaped placeholders. Same pattern would catch this class of bug at edit time rather than first-customer-failure time. Queue as a Phase 1 hygiene item.

VERSION → 1.0.64.

v1.0.63 — 2026-05-16 — License Schedule (Schedule A) — closes Item 28 audit HIGH-priority gap

Why this lands now

The 2026-05-16 Item 28 audit (~/Desktop/Item 28 — JDA Addenda Audit — 2026-05-16.md) flagged the License Schedule as HIGH-priority missing. Customer-facing surfaces — templates/jda/path_2b.html, templates/jda/crypto_erasure_attestation*.html, templates/jda/royalty_submission.html, templates/jda/renewal_request_sent.html, templates/terms.html, and jda/contract_assembler.py:30 code comment — all referenced "the License Schedule" as the operative document defining Substrate-Derived Revenue, Outcome Bonus mechanics, audit rights, termination clauses, and renewal-addendum boilerplate. The document did not actually exist anywhere — partner counsel asking "show me the Schedule I'm signing" would get pointed at nothing.

Fix

New jda/license_schedule_assembler.py module — analogous to jda/contract_assembler.py. Two public functions:

Schedule structure (9 sections):

Locked Schedule constants exposed as module-level: ROYALTY_RATE_PCT=12, OUTCOME_BONUS_RATE_PCT=10, REPORTING_CADENCE="quarterly", PAYMENT_DUE_DAYS=30, AUDIT_NOTICE_DAYS=30, AUDIT_MAX_FREQUENCY_PER_YEAR=1. Changes to these require Z sign-off + version bump + CHANGELOG entry.

Wired into the DocuSign envelope flow

jda/docusign_envelope.py:send_envelope_for_intake now:

The Schedule arrives in the same DocuSign envelope as the JDA, with separate signature anchors. Partner counsel reads both before either signs.

What this does NOT yet fix

The other 4 audit gaps remain queued (per Build List items 34, 35, 36, 37):

VERSION → 1.0.63.

v1.0.62 — 2026-05-16 — Auto-retry transient engine failures + hide raw tracebacks from L2 cards

Why this lands now

Z's 2026-05-16 6:16 PM screenshot of an in-flight L2 run showed 4 provisional cards in the "0 of 7 artifacts ready · ELAPSED: 2m 37s" state, each displaying a raw Python traceback as the error message:

"deep_run failed: Traceback (most recent call last): File '/app/deep_run.py', line 1104, in main() File '/app/deep_run.py', line 1046, in main record = run_candidate( ^^^^^^^^^^^^^^ File '/app/deep_run.py', line 427, in run_candidat"

Z's note: "i can wait them out and eventually they do retry and self heal. but thats not what we want buyers to see."

Two distinct failures in the customer-facing UX: 1. The "Failed" cards exposed /app/deep_run.py line 1104 to the buyer. Buyers seeing raw source-file paths and tracebacks lose confidence in the product immediately. 2. The "self-heal" mechanism only kicks for stuck items (state-absent), not items that explicitly failed. Z's "they eventually retry" pattern is actually Z manually clicking Retry on each card — the engine itself doesn't auto-retry transient failures.

Fix — two helpers in app.py

_classify_engine_subprocess_error(stderr) -> (user_message, is_known_transient)

Maps known error signatures in subprocess stderr to user-facing messages. Patterns covered: - Meta-tensor SBERT cold-start (meta tensor / to_empty / cannot copy out of meta) — "Engine substrate is warming up — the AI model is cold-starting..." - Anthropic 529 / overloaded — "Anthropic's Claude API was overloaded..." - BigQuery / Cloud Storage 503 — "An upstream Google Cloud service returned a transient error..." - Anthropic 429 / rate-limited — "Anthropic's API rate-limited this request..." - Network timeouts / connection errors — "A network connection to an upstream service timed out..." - Generic fallback — "Engine generation failed. Click Retry to attempt again." (never the raw traceback)

All five recognized patterns are marked is_known_transient=True; the generic fallback is False.

_run_engine_subprocess_with_transient_retry(cmd, ..., label) -> (CompletedProcess, user_msg_or_None)

Subprocess wrapper that auto-retries ONCE on a known-transient failure after a 5-second warm-up pause. If the retry succeeds the customer never sees the failure card. If the retry also fails (typically meaning the underlying upstream outage persists), the user-facing message is surfaced and the customer is invited to retry manually.

Why one retry and not more: two consecutive transient failures is the signal that something is genuinely persistent (real outage, real bug, real configuration drift) — at that point the customer should be looped in rather than the engine spinning indefinitely. The wrapper logs both fallback events visibly so Cloud Run logs surface the "auto-retry succeeded" pattern explicitly for future triage.

Wired into both surfaces

Provisional pre-run path (_pre_run_provisional, app.py:~700-810). Was previously dumping r1.stderr[:250] raw — exactly the Z-reported screenshot pattern. Now routes through the wrapper for both deep_run.py and provisional_synth.py subprocesses.

Memo generation path (_process_one_memo, app.py:~7036-7227). v1.0.18 had inline humanization for overloaded/529 but no auto-retry; v1.0.62 supersedes with the wrapper that handles all five transient classes AND retries. Dead-code branch (the post-_user_msg-raise if r.returncode != 0: block) removed.

What this does NOT fix

The L2 result page's "Failed" badge is still rendered for any failure surfacing past the wrapper. Z's screenshot would, with v1.0.62, show either (a) zero "Failed" cards because the cold-start was auto-retried successfully, or (b) "Failed" cards with the user-readable message (no traceback). A separate UX iteration could introduce a "Retrying" badge that visually distinguishes transient-in-flight from genuine-failure; that's a frontend change for a future ship and not in scope here.

The v1.0.60 meta-tensor fix at the SBERT load layer remains the proper root-cause fix. v1.0.62 is defense in depth for any path that bypasses the centralized _l1_shared.get_sbert_model or any new transient class we haven't catalogued yet.

VERSION → 1.0.62.

v1.0.61 — 2026-05-16 — Billing-portal Stripe email-lookup fallback + diagnostic chain

Why this lands now

Z reported on 2026-05-16 that the /billing-portal route returns 400 "No active subscription on file" across all accounts he's tested, not just unconfigured test accounts. The v0.13.69 code path (per-seat sub → firm-pool admin fallback) is correct on paper but produces the 400 when both Firestore lookups return empty stripe_customer_id, with no signal pointing at which check failed or whether the Firestore cache is just stale.

Diagnosis path

The lookup chain in app.py:/billing-portal reads: 1. accounts.get_active_subscription(user["id"]) — queries subscriptions collection filtered by user_id + ACTIVE_SUB_STATUSES. If found, pulls stripe_customer_id. 2. If empty, accounts.get_user_firm(user["id"]) + is_firm_admin check, then pulls firm.stripe_customer_id. 3. If both empty, raise 400.

Z's "across all accounts" symptom suggests either (a) every account's Firestore subscriptions doc has empty stripe_customer_id, (b) every account's firms doc has empty stripe_customer_id, or (c) the Firestore cache is stale relative to Stripe's actual customer records (Stripe customers created out-of-band by Z's manual workflow without writing the customer_id back to the user/firm doc).

Without diagnostic visibility on the failing chain, can't tell which.

Fix

Two changes to the /billing-portal handler:

1. Diagnostic chain logging + surfaced error message. Each check (per-seat sub, firm-pool admin, email fallback) appends a one-line status to a diag list. On failure, the full chain is printed to Cloud Run logs ([billing-portal] FAIL for user=... chain: ...) AND surfaced in the 400 response message itself. Next time Z hits the error, the response text tells him exactly which check failed (e.g., "per-seat sub: none | firm: none | stripe email lookup: no customer for x@y.com").

2. Stripe email-lookup fallback. New step between the firm-pool check and the 400. If both Firestore checks fail AND the user has an email, query stripe.Customer.list(email=user_email, limit=1). If Stripe has a Customer record for that email, use that customer_id directly. Recovers the "Firestore cache is stale" case automatically. Logs the recovery so backfill can happen later (the user/firm doc should eventually get the customer_id written back, but the portal works in the meantime).

Why email-lookup is safe: Stripe Customer Portal sessions are scoped to a single Customer; opening one for the user's-email-matched Customer can only reveal billing for products they've purchased under that email. No cross-tenant leak. The Firestore cache is meant to avoid a Stripe API call per request; the fallback adds one Stripe call on cache miss, which is acceptable.

What this does NOT fix

If the Stripe Customer Portal itself is not configured in the Stripe Dashboard (a known Stripe gotcha — the Portal must be configured under Settings → Billing → Customer portal before stripe.billing_portal.Session.create() works), the route returns a 500 from the Stripe API call further down. Different error path; if Z's diagnostic chain shows a customer_id was found but the portal creation fails, that's the Dashboard-config issue and needs to be enabled manually at https://dashboard.stripe.com/settings/billing/portal.

VERSION → 1.0.61.

v1.0.60 — 2026-05-16 — Meta-tensor SBERT load fallback (production retry-storm fix)

Why this lands now

Z reported a production run on 2026-05-16 where the semantic_bridges engine step failed with the meta-tensor error the v0.14.43 fix was supposed to prevent: "Cannot copy out of meta tensor; no data! Please use torch.nn.Module.to_empty() instead of torch.nn.Module.to() when moving module from meta to a different device." Same error surface fed into deep_run.py retries on multiple L2 sessions (/layer2/82351ea38b42/result, /layer2/caf57162cc4f/result, /layer2/cb3ef0b0c64c/result). Engine retries did eventually land — Z's pool wasn't charged — but every failed attempt costs container time and shows the customer a "Generation failed" surface they have to wait through.

Root cause analysis

The v0.14.43 fix passed device=device to the SentenceTransformer constructor on the theory that an explicit device parameter would force eager weight load. That holds when the SentenceTransformer constructor controls its own initialization end-to-end. It does NOT hold when transformers' internal low_cpu_mem_usage codepath triggers meta-tensor init before SentenceTransformer's final self.to(device) call — which happens automatically in recent transformers versions when accelerate is installed (which it is in our Cloud Run image, indirectly via torch+sentence-transformers deps). Result: meta-init weights, then the closing to(device) fails copying from meta.

The error surface tells you exactly what to do: "use torch.nn.Module.to_empty() instead". But to_empty() creates new empty tensors on the target device — it doesn't preserve weights, so naively calling it would yield an unusable model. The HuggingFace pattern is to_empty() followed by load_state_dict(), but we don't control SentenceTransformer's internal load path.

Fix (_l1_shared.py:get_sbert_model)

Wrapped the primary SentenceTransformer(name, device=device) call in a try/except that catches the specific meta-tensor error (NotImplementedError / RuntimeError carrying "meta tensor" / "to_empty" / "cannot copy out of meta" in the message) and falls back to a two-step load:

  1. SentenceTransformer(name, device="cpu") — the CPU path does not trigger meta-init in any known torch + sentence-transformers combo, so weights load eagerly with real data.
  2. model = model.to(device) — standard PyTorch move on a model with non-meta weights; this is the operation to_empty() was meant to replace, but it works correctly here because the weights are real.

If the manual transfer step ALSO fails (extremely rare), the model stays on CPU rather than entering a worse fallback. Honest signal: the engine ran on CPU instead of the attached GPU on Cloud Run for this session; measurably slower but not a quality compromise (same weights, same model, same outputs).

Per feedback_no_silent_engine_degradation.md: this fallback preserves model identity and output quality. It is NOT a silent degradation. Diagnostic logging surfaces both fallback events ([sbert-load] meta-tensor init detected... falling back to CPU-first load) and unrecoverable transfer failures ([sbert-load] CPU→{device} transfer failed... model staying on CPU) so failure modes are visible in Cloud Run logs rather than silently degrading.

What this does NOT fix (surfaced to Z separately)

Two other issues from Z's 2026-05-16 run report need diagnostics before fixes:

VERSION → 1.0.60.

v1.0.59 — 2026-05-16 — Phase Q completion: Q1, Q2, Q4, Q5 engine artifact-quality lifts

Why this lands now

Per Z's directive ("do the build fixes Perplexity gave us first so I can do a deep-dive run on improved artifacts"), this ship closes out the remaining Phase Q items from the Build List so the next external-critique pass operates on the upgraded engine output. All four use mechanisms already disclosed in the patent portfolio (App. 64/002,205 CTE / App. 64/043,294 Consolidated Supplemental / App. 64/061,710 Cross-Engine Topological Dynamics / App. 64/061,715 Portfolio Topology Extensions) — the work here is operationalizing existing inventions in the surface artifacts.

Q5 — L2 memo: inline truncation flagging (continuation_memo_synth.py)

Why: Perplexity 2026-05-16 critique flagged that when upstream truncation hits a neighbor's claim text (_nbr_truncated was already passed to the LLM prompt context), the LLM was tending to consolidate the limitation into the closing Limits italic line at the end of the memo. Readers forming neighbor-by-neighbor conclusions in Section 2 didn't see the partial-visibility caveat next to the neighbor it applied to.

Fix: Section 2 prompt amended with explicit "INLINE TRUNCATION FLAGGING" instruction. When the neighbor data block carries the truncation note, the prompt now requires per-neighbor inline framing immediately after the similarity score: "(Engine note: the upstream claim text for this neighbor was truncated at the 25,000-char ceiling — the analysis below reads the visible claim portion; dependent-claim scope beyond the truncation point is not in view.)" The closing Limits line still summarizes; the per-neighbor flag is the new fidelity layer.

Q1 — L1 ORPHAN-entropy tiered confidence reading (render_arc.py)

Why: Perplexity flagged that when all portfolio filings landed in no-competitor clusters, the engine surfaced the correct ORPHAN-entropy reading but listed three possible interpretations without primary classification. L1-only readers (i.e., not buying upward to L2) couldn't distinguish "genuinely novel" from "corpus blind spot" without resolution. The v1.0.42 L2 Coverage Caveat already implemented exactly this discrimination — Q1 ports the same logic forward to L1.

Fix: new tiered classifier inline in the solo-cluster interpretation block. Detects the portfolio's CPC fingerprint via the existing _portfolio_cpc_from_output_path + _detect_cpc_domain helpers (imported lazily to avoid circular import risk), looks up NPL-heavy status against the existing _NPL_HEAVY_DOMAINS map (shared with continuation_memo_synth's Coverage Caveat). Two outcomes:

The L2 deep-run remains as the deeper-resolution path; the L1 now gives an executive reader a primary read without forcing a paid upgrade for basic disambiguation.

Q4 — L2 inline similarity-band visualization (continuation_memo_synth.py)

Why: Perplexity flagged that void coordinates and neighbor positions were stated with precision in memo prose but never visualized. An executive stakeholder reading the memo at speed couldn't form a spatial intuition for where the neighbors actually sit on the similarity axis without reading every paragraph.

Fix: new _similarity_band_svg(deep_record) helper emits an inline 680×200 SVG with the three color-banded similarity regions (loose word overlap < 0.50 / thematic adjacency 0.50–0.70 / real overlap > 0.70), tick marks at the canonical thresholds (0.00, 0.25, 0.50, 0.70, 0.85, 1.00), and a labeled circle marker for each neighbor positioned at its maximum claim-text similarity score. Markers cap at 8 for legibility; label rows alternate vertical position to prevent overlap. Wrapped in a "Visual appendix" block (purple-on-white, page-break-inside: avoid) appended between the memo body and the Methods block in the PDF output. _render_memo_to_html now accepts deep_record as optional parameter so the SVG can pull from the same data the memo prose was generated from.

Visualization is metadata-only — no new LLM calls, no new pipeline computation. Pure render-time derivation from data the engine already produces.

Q2 — L1 gap-proposed abstract structural-signal closing clause (render_arc.py)

Why: Perplexity flagged that the gap-proposed abstract templates ("A computer-implemented system and method that unifies... configured to bridge previously-isolated mechanism layers...") read as commercially thin boilerplate. An examiner or litigation opponent would notice the template language; sophisticated readers form a "this is generated, not engineered" impression.

Fix: new _structural_signal_clause(cand) helper appends an engine-grounded closing sentence to each gap-proposed abstract, grounding the prose in the specific structural signal that surfaced the candidate. Per gap-type:

No new LLM calls — pure metadata extraction from the candidate object the engine already builds. Wired into the L1 abstract render at render_arc.py:1384 so every L1 carries the closing clause when a gap-type signal is available.

Source-code verification for Q7 (v1.0.57) holds

The v1.0.57 Q7 work (differentiation memo trigger-basis line) is verified consistent with the v1.0.59 changes: provisional_synth.py:1163+ continues to always emit the memo with the "INTERNAL APPENDIX" framing, and the new header line surfaces the trigger basis. No regression.

VERSION → 1.0.59.

v1.0.58 — 2026-05-16 — International corpus reframed as Route 6 partnership hook

Why this lands now

Perplexity follow-up (International Add-on.rtf 2026-05-16) reframed the international-corpus question architecturally. The original v1.0.57 Q3 banner framed US-only scope as a limitation requiring a parallel human sweep. The honest architectural read is that the international gap is a deployment constraint of the public retail engine, not a substrate limitation — the Cross-Engine Reasoning Protocol (App. 64/061,710 Mechanism 1) is literally designed for a Route 6 partner to bring EPO / CNIPA / KIPO corpora into their enclave deployment. The engine doesn't need to own the international corpus; it traverses whatever graph the enclave exposes.

That makes the corpus disclosure a partnership recruitment hook, not a disclaimer. Three surfaces updated so the framing is consistent across the engine output, the landing page, and the pricing page.

render_arc.py — Q3 banner reframe

Before (v1.0.57): "...For domains where foreign families or NPL prior art are material, a parallel human prior-art sweep is required for completeness." — limitation framing.

After (v1.0.58): "US patent corpus native at launch. International filings (EPO, CNIPA, KIPO) and non-patent literature aren't part of the default scan — bring-your-own-corpus extensions are available via Route 6 Private Enclave JDA partnerships, where the engine traverses whatever graph the partner enclave exposes, including international or domain-specific corpora a partner brings to the deployment. For retail use in domains where foreign families or NPL prior art are material, a parallel human sweep remains prudent." — partnership-hook framing with Lic Doc Route 6 cross-link, preserving the prudent-reader disclosure for retail-tier customers.

templates/index.html — Data Sources gains a third card

Added a third card next to the existing "US Patent Corpus" and "Your Cluster" cards:

International Corpus Want DCFN to ingest an international corpus (EPO, CNIPA, KIPO) or a domain-specific dataset your organization already licenses? The engine traverses whatever graph the partner enclave exposes — available via the Route 6 Private Enclave JDA Partnership. Badge: Route 6 JDA

This converts what was an invisible partnership opportunity (institutional buyers had to read the Lic Doc to discover the bring-your-own-corpus posture exists) into a surface-level recruitment hook on the engine's primary landing page. Aligns the landing page with the Q3 banner reframe and the pricing page JDA card.

templates/pricing.html — JDA card adds the bring-your-own-corpus bullet

The v1.0.57 Route 6 JDA card on the pricing page covered Private TEE deployment + DRA + Base Integration Fee + royalty + attestation, but omitted the strongest selling point for institutional buyers per the Perplexity reframe: that a Route 6 partner can bring their own corpus (international or domain-specific) into the enclave. New bullet added directly under the TEE deployment bullet:

Bring-your-own-corpus extension — engine traverses any graph the partner enclave exposes, including international patent corpora (EPO, CNIPA, KIPO) or domain-specific data the partner brings to the deployment (Cross-Engine Reasoning Protocol, App. 64/061,710 Mech 1)

Patent app number cited inline so the prospect immediately sees this is a patent-protected capability, not a future roadmap claim.

VERSION → 1.0.58.

v1.0.57 — 2026-05-16 — Lic Doc v7.5 alignment sweep + Q3/Q7/Q8 artifact quality

Lic Doc v7.5 cleanup bundle (Sprint A items L1–L5)

Why this lands now: the v7.5 Licensing Guide locked the route taxonomy (Tier 1 retail under Route 3 + Routes 1/4/6 partnerships; Routes 2 + 5 retired; Route 6 = enclave only, Route 4 = API). The retail-side legal docs (terms.html, privacy.html, refund_policy.html, pricing.html, base footer) still described the retired three-tier model (Tier 0 / Tier 1 / Tier 2). Leaving the mismatch in place lets a launch-cohort prospect's counsel surface "your TOS doesn't match your published licensing structure" as a legitimate first-call objection.

Fix: - terms.html §3 rewritten end-to-end against v7.5: Tier 0 references removed; retail tier framed as Route 3 (Deployment / Product License); cross-links to the live livingedenframeworks.com/licensing/ page for Routes 1, 4, and 6. - terms.html §5.2 / §5.3 stale Tier 0 / Tier 1 references replaced with "retail-tier" framing. - terms.html §5.4 renamed from "Tier 2 Private Deployment posture" to "Route 6 Private Enclave JDA posture"; substrate language updated from "Docker image in VPC" to "signed, attested workload inside Confidential Space / Nitro Enclaves / Azure CVM" (matches the 2026-05-13 Confidential Computing pivot in DEPLOYMENT_RUNBOOK.md); cross-link to Licensing Guide §Route 6 added. - terms.html §8 termination consequences rewritten to remove Tier 0/1/2 framing and reference retail subscription posture + Route 1/4/6 License Schedules. - privacy.html §1 + §9 stale (Tier 0: 3 days; Tier 1+: per the subscription term) clauses replaced with retail-tier 12-month framing. - privacy.html §5 + §6: data-handler list factual fix — Render (which the engine does NOT use) replaced with Google Cloud Platform (Cloud Run + BigQuery + GCS), with proper privacy-notice cross-link. Render's default disk encryption corrected to Google Cloud's default disk encryption. (Bundled local from earlier in the session.) - refund_policy.html §4 "2 free Tier 1-equivalent runs" → "free runs" (Tier 1-equivalent framing was stale). - refund_policy.html §5 "Tier 2 / JDA partnerships" renamed to "Route 6 Private Enclave JDA partnerships"; cross-link to Licensing Guide §Route 6 added. - pricing.html §1 corpus-size language (~3,000 at Tier 0; up to 10,000 at Tier 2) updated to (~3,000 at retail tiers; up to 10,000 under Route 6 Private Enclave deployments). - pricing.html Partnerships row restructured from 2 cards (JDA + Bridge) to 3 cards (Route 4 + Route 6 + Bridge). The previous JDA card conflated Route 4 (API) and Route 6 (Enclave) under one offering — "IP Aggregator integration via API" sat alongside "Partner-side single-tenant deployment", which are now separate routes per v7.5. New cards: Route 4 · API / SaaS Module ($125/run + $10K/month minimum, no royalty) + Route 6 · Private Enclave JDA (enclave-only, $50K DRA + $300K base + $75K/yr + 12% royalty) + DCFN-Bridge (unchanged). Heading "Tier 2 & partnerships" → "Routes 4 & 6 — Partnerships" with section lede pointing to the public Licensing Guide. - base.html footer Licensing link added between Refund Policy and Service request, pointing at the canonical livingedenframeworks.com/licensing/ surface.

The TOS §5.5 redistribution clause shipped earlier in the session is preserved and now reads alongside the §5.4 Route 6 rename consistently.

Q3 — L1 Landscape persistent corpus-scope banner (render_arc.py)

Why: Perplexity critique 2026-05-16 flagged that the US-only corpus limitation is disclosed in the §1 Scan-scope paragraph and the Methods footer, but a fast executive reader who skims the headline number can miss both and form a strategic posture under the wrong premise.

Fix: persistent header-level banner injected directly after the header block (lines ~1914+). Yellow #FFF8E1 background, #B8860B left border, 12px DM Sans — visually weighted enough to register but not so heavy it overshadows the analysis. Body text:

"Corpus scope: This engine scans the US patent corpus only. International filings (EPO, CNIPA, KIPO), academic literature, and non-patent prior art are NOT covered. For domains where foreign families or NPL prior art are material, a parallel human prior-art sweep is required for completeness."

Existing §1 Scan-scope text and Methods-footer disclosure remain unchanged — the banner is additive, not a replacement.

Q7 — Provisional differentiation memo trigger-basis header line (provisional_synth.py)

Why: Perplexity's original critique characterized the prior-art differentiation memo as "inconsistent across drafts." Source-code verification (provisional_synth.py L1304 section loop + L1163 .docx rendering) confirmed the engine ALWAYS generates and ALWAYS renders the memo for every provisional, labeled "INTERNAL APPENDIX · NOT PART OF FILED DOCUMENT." The original critique was a sample-set misread driven by memo content density varying with how many neighbors crossed the 0.55 similarity threshold.

Fix: one new paragraph inserted after the existing intro paragraph in the memo's docx section, surfacing the trigger basis explicitly:

"Generated against {N} prior-art neighbor[s] above the 0.55 similarity threshold from the engine's deep-run analysis."

A future external reviewer (or future-Z six months from now) reading a provisional with a thin memo now immediately understands why. Forecloses the same misread. Original Q7 ("standardize via Replication-Statement Extraction") downgraded from 1–2 sessions to 10 minutes once source-code verification proved the gap didn't exist.

Q8 — Provisional figure placeholders in Detailed Description (provisional_synth.py)

Why: Perplexity flagged that provisional drafts contain no figure references or placeholders. While provisionals technically don't require drawings, enabling disclosure for system-architecture inventions is substantially strengthened by labeled figure placeholders that tell a human drafter where drawings would land for prosecution readiness.

Fix: new prompt block added to the detailed_description section prompt instructing the LLM to insert 2-4 italicized figure placeholder lines inline at natural reference points in the prose. Format: *Figure {N} — [Brief description naming key elements and the relationship being shown, referencing the element numbers used inline.]*. Engine does NOT generate the figures themselves — placeholder lines only, inline guidance for the human drafter rather than filed-document structure (no separate "Brief Description of the Drawings" section).

Sprint coverage

Sprint A items closed by this version: L1, L2, L3, L4, L5, Q3, Q7, Q8 (per Build List - REVISED 2026-05-16.md). Sprint B reduces to Q5 truncated-neighbor flag. Sprint C (Q1/Q2/Q4) and Sprint D (L6/L7) remain queued pending threshold/format decisions and Lic Doc bundle completion.

VERSION → 1.0.57.

v1.0.56 — 2026-05-16 — JDA Renewal Request flow (Item 25)

jda/renewal_requests.py (new module) + /jda/renewal-request + admin queue

Why this lands now: every Tier 2 JDA cycle is 12 months. At cycle end, partners need a structured path to declare intent for the next cycle. Without a renewal-request endpoint, the first JDA approaching cycle-end has no self-serve path — Z gets emailed.

Fix: Three renewal types, each routing to the appropriate next-step flow: - EXTEND — same terms, sign a renewal addendum, new 12-month cycle begins - MODIFY — terms change (scope, CDE tier, royalty rate negotiation), re-intake required; desired_changes field becomes mandatory - DECLINE — exit cleanly, partner routed to the v1.0.54 cryptographic-erasure attestation flow

Backed by Firestore collection jda_renewal_requests/{id}. Status state machine: submitted → reviewing → in_progress → completed, plus cancelled branch.

Partner-facing surface: - GET /jda/renewal-request?jda_id=... — form with JS-driven conditional sections (changes field hides for EXTEND, surfaces for MODIFY/DECLINE) - POST /jda/renewal-request — validates renewal_type-specific requirements, persists Firestore record, renders confirmation page with type-specific next-step explanation

Admin surface (DCFN_ADMIN_KEY-gated): - GET /admin/jda-renewals — queue with status + type filter chips; columns: submitted timestamp, JDA ID, type, signatory, status (inline dropdown), changes/note preview, action shortcut (decline → direct link to crypto-erasure attestation form pre-filled with the JDA ID) - POST /admin/jda-renewals/{id}/status — update status

v0 scope explicit: this is the renewal-intent SIGNAL collection layer. The state-machine extension to model the renewal flow inside the JDA intake state machine itself (RENEWAL_PENDING / RENEWAL_REQUESTED / RENEWAL_DOCUSIGN_SENT states + transitions) is queued for a later sprint. v0 keeps renewal records adjacent rather than embedded.

VERSION → 1.0.56.

v1.0.55 — 2026-05-16 — Four Assessment Deliverable .docx Skeletons (JDA Half B #2)

jda/assessment_templates.py (new module) + admin route to stream skeletons

Why this lands now: every Tier 2 JDA begins with a paid Data Readiness Assessment producing four bound .docx deliverables (Scored Assessment, Gap Analysis, Formatting Blueprint, CDE Tier Assignment). Until the on-VM DRA Engine v1 (Item 8) is built, Z manually authors all four per partner. Without pre-formatted skeletons, each assessment is built from scratch in Word — slow, inconsistent format across partners.

Fix: New module produces 4 .docx skeletons with LEF branding, partner metadata cover blocks, canonical section structure matching the JDA Prospectus, and [TODO — …] placeholders Z fills in. Each skeleton renders in ~5ms via python-docx. Admin route GET /admin/jda/{intake_id}/assessment/templates/{kind} streams the skeleton with the partner's legal name + intake ID pre-filled.

Skeleton structures: - Scored Assessment — 12-dimension scoring rubric (Source Identity / Authority / Temporal / CPC / Claims / Assignee Harmonization / Family / Update Cadence / Schema Stability / Volume / Access / Compliance) + composite score + recommended CDE tier - Gap Analysis — BLOCKER / MAJOR / MINOR gap enumeration + remediation sequence + hours roll-up + CDE tier mapping - Formatting Blueprint — 11 required fields (patent_id, publication_number, title, abstract, claims_text, cpc_codes, filing/publication/priority dates, assignee_name, country_code) + 5 optional fields (ipc_codes, inventor_names, family_id, citations, kind_code) + normalization rules + connector code generation scope - CDE Tier Assignment — tier choice + rationale + tier definitions (Modern Systems $95K / Legacy Standard $225K / Legacy Heavy $450K) + what's included / out-of-scope + next-step credit-window framing

Z downloads the skeleton, fills in the TODO placeholders, re-uploads via the existing complete-manual flow at /admin/jda/{intake_id}/assessment/complete-manual. Saves ~30-60 min of formatting work per partner + standardizes output format across all Tier 2 deliverables so every assessment reads as having come from the same engine.

VERSION → 1.0.55.

v1.0.54 — 2026-05-16 — Cryptographic-Erasure Attestation v0 (JDA Half B #5)

crypto_erasure_attestations.py (new module) + /jda/crypto-erasure-attestation + admin verification queue

Why this lands now: JDA termination requires partner attestation that the TEE-deployed substrate + connector + persisted state have been cryptographically erased (key destruction renders ciphertext irrecoverable). Without an attestation endpoint, the first Tier 2 partner that completes a JDA cycle has no path to close it cleanly. This is Half B #5 of the substrate-side JDA build.

Fix: Backed by Firestore collection crypto_erasure_attestations/{id}. Status state machine: partner_attested → lef_verified → closed, with a disputed branch.

Each attestation record captures: jda_id, firm_id, partner-signatory triple (name + email + role), tee_platform (aws_nitro_enclaves / gcp_confidential_space / azure_confidential_vm / other), attestation_text (the partner's legal statement, minimum 30 chars), attestation_certificate_hash (optional — SHA-256 of an external TEE attestation document), supporting_note. The submission produces an integrity_hash — SHA-256 over the canonical-JSON serialization of every captured field — that's the tamper-evident audit trace for both parties.

Partner-facing surface: - GET /jda/crypto-erasure-attestation?jda_id=... — form with sections for signatory, deployment details, attestation statement - POST /jda/crypto-erasure-attestation — creates the Firestore record, computes integrity hash, renders confirmation page that displays the hash for the partner's records

Admin surface (DCFN_ADMIN_KEY-gated): - GET /admin/crypto-erasure-attestations — queue with status filter chips - POST /admin/crypto-erasure-attestations/{id}/verify — admin one-click verify (moves to lef_verified) - POST /admin/crypto-erasure-attestations/{id}/close — admin one-click close (after verified)

v0 scope explicit: attestation v1 captures the legal record + LEF-side acknowledgment. Attestation v2 (queued for later sprint) adds the actual cryptographic-erasure VERIFICATION — LEF posts a proof challenge to the TEE attestation surface; partner responds with proof of ciphertext-irrecoverability. v1 is the audit trail that makes v2 possible.

VERSION → 1.0.54.

v1.0.53 — 2026-05-16 — Royalty Submission Endpoint v0 (JDA Half B #6)

royalty_submissions.py (new module) + /jda/royalty-submission partner form + /admin/royalty-submissions queue

Why this lands now: Tier 2B Platform JDA partners remit a Running Royalty of 12% of Substrate-Derived Revenue paid quarterly, plus an Outcome Bonus of 10% of quantified value above an agreed baseline paid annually (per JDA Prospectus v4). Without a submission endpoint, the first Tier 2B partner that signs has no path to remit. This is Half B #6 of the 7-component substrate-side JDA build.

Fix: Backed by Firestore collection royalty_submissions/{id}. Status state machine: submitted → reviewing → approved → invoiced → paid → closed, with a rejected branch from any pre-invoiced state.

Each submission record stores: - quarter_label (e.g., "2026-Q3") - substrate_derived_revenue_cents (partner-reported) - royalty_rate_applied (0.12 — locked at submission time so future rate changes don't retroactively re-price old quarters) - royalty_amount_cents (auto-computed) - outcome_baseline_cents + outcome_actual_cents (optional, annual — typically Q4) - outcome_bonus_rate_applied (0.10) + outcome_bonus_cents (auto-computed when both annual fields supplied) - submitter_email + submitter_user_id - supporting_note (partner free-form context) - status + internal_notes (admin-only)

Partner-facing surface: - GET /jda/royalty-submission — form (auto-suggests current quarter via UTC date math; pre-fills nothing else); auth-gated (firm-pool member required) - POST /jda/royalty-submission — creates the Firestore record, computes royalty + (when applicable) outcome bonus, renders confirmation page with the computed amounts

Admin surface (DCFN_ADMIN_KEY-gated): - GET /admin/royalty-submissions — queue table with status filter; columns: submitted-at, quarter, firm, revenue, royalty (12%), bonus (10%), status, action (inline status update dropdown) - POST /admin/royalty-submissions/{id}/status — update submission status

Helper cumulative_for_year(firm_id, year) aggregates a firm's quarterly submissions for annual outcome-bonus computation audit trail.

v0 scope explicit: Stripe-invoice auto-creation is queued for the JDA bookkeeping engine sprint (Item 7 of the 32-item list). For v0, an admin reviews + manually invoices via Stripe Dashboard; the submission record carries the data to make that one-click in Stripe.

VERSION → 1.0.53.

v1.0.52 — 2026-05-16 — Service-Request Triage v0 (Admin Layer Walkthrough #1)

service_requests.py (new module) + /service-request customer-facing + /admin/service-requests admin queue

Why this lands now: Admin Layer Walkthrough #1 of the 5 surviving Admin Layer walkthroughs (per ROADMAP_FUTURES "Admin Layer scope reduction 2026-05-13"). Most-likely-to-be-touched walkthrough during the next 30 days — any Tier 1 customer reporting a bug or asking for a scope change hits this surface.

Fix: Backed by Firestore collection service_requests/{id}. Status state machine: new → triaging → in_progress → resolved → closed. Categories: bug, scope_change, content_question, billing_question, other.

Public surface: - GET /service-request — form (email, category, description, optional attachment_text, optional session_id; email pre-fills from logged-in user) - POST /service-request — creates the Firestore record, surfaces a confirmation page with the request reference number - Footer link "Service request" added to templates/base.html for discovery from every page

Admin surface (DCFN_ADMIN_KEY-gated): - GET /admin/service-requests?status=new — triage queue with status filter chips (all / new / triaging / in_progress / resolved / closed) - GET /admin/service-requests/{req_id} — full request detail view + status update form + internal-notes thread + add-note form - POST /admin/service-requests/{req_id}/status — update status - POST /admin/service-requests/{req_id}/note — append internal note (author + timestamp + body, persisted to the request record's internal_notes array)

v0 scope explicit: no auto-triage, no LLM classification, no customer-comm drafts auto-sent. Manual triage flow is the durable substrate; the auto-triage layer is a later sprint that reads this queue, classifies, applies config flips from the pre-approved menu, and drafts customer comms. Z reviews drafts initially; loosens as patterns prove out (per Admin Layer BuildMe §1.3 escalation boundary).

VERSION → 1.0.52.

v1.0.51 — 2026-05-16 — Self-serve account deletion (Item 15)

/account/delete two-step flow (app.py, new templates/account_delete.html, accounts.py)

Why this lands now: explicit on the customer-facing surface that users can leave the system at any time, on their own initiative, without contacting support. Closes the last "must email LEF to do X" loop on the public account surface.

Fix: New cascading-deletion helper accounts.delete_user_and_owned_firm(user_id) atomically removes: - The user record (users/{id}) - If user is firm admin: the firm record + every firm_members/* row + every firm_invites/* row tied to that firm - If user is firm member (not admin): just their member row (firm stays active for other members) - All password_resets/* rows for the user - Marks subscription rows as status="deleted_by_user" (Stripe-side cancellation is a separate step the user is directed to handle via billing@livingedenframeworks.com)

Cryptographic-audit-only record persisted to a new deletion_audit collection: stores the SHA-256 hash of {user_id}|{email}|{deleted_at}|account_deletion, the deletion timestamp, and the summary counts (firm deleted, member count, invite count). No personal data retained — the hash is one-way; only useful as a tamper-evident proof that "a deletion happened on this date" if a future compliance inquiry asks.

Two-step UI flow: - GET /account/delete renders the confirmation page with: what gets deleted (depends on admin-vs-member role), what does NOT happen (no refund per Refund Policy §2; Stripe subscription cancellation is separate; downloaded artifacts remain yours per TOS §5), and the audit-trail explanation - POST /account/delete/confirm validates the user typed DELETE, calls the cascading helper, clears cookies, redirects to /?deleted=1

/account page gets a small Delete account link in the logout row.

VERSION → 1.0.51.

v1.0.50 — 2026-05-16 — JDA pricing public + pattern-share opt-in + cycle wording + refund cancellation + stub cleanup

Five customer-facing items shipped together as the public-surface readiness pass before the launch-cohort emails go out.

Item 1 — /jda overview cards + /jda/path-2a + /jda/path-2b detail pages (jda/routes.py, templates/jda/landing.html, new templates/jda/path_2a.html, new templates/jda/path_2b.html)

Decision (Z 2026-05-16): prospects should see the full JDA financial picture before contacting sales — no price shocks. JDA contract paths now match the Tier 1 pricing posture: every flat fee, milestone schedule, royalty rate, and outcome bonus is public.

Fix: /jda redesigned as a short-summary two-card overview with linked "See full Path 2A pricing →" / "See full Path 2B pricing →" CTAs per card. Detail pages render the full JDA Prospectus content — flat fees ($50K DRA + $300K/$650K base + CDE tier + maintenance + retainer + change-order), milestone schedule (30/40/20/10%), royalty mechanics (12% Substrate-Derived Revenue for 2B), outcome bonus (10% above baseline for 2B), warranty period (30-day hypercare), IP posture (Layer 1 LEF-owned + Layer 2 perpetual paid-up license to partner).

Item 2 — LEF Ai Engine substrate-pattern-sharing opt-in flag (accounts.py, app.py, templates/firm_manage.html)

Decision (Z 2026-05-16): every JDA partner explicitly acknowledges whether their TEE-deployed substrate contributes HMAC-hashed structural signals to the LEF Ai Engine meta-learning pattern library. Default OFF — partner explicitly opts in.

Fix: New firm-record field lef_ai_engine_pattern_share (default False on create_firm). New helper set_firm_lef_ai_pattern_share(firm_id, share) writes the flag + lef_ai_engine_pattern_share_updated_at. New POST route /firm/lef-ai-pattern-share toggles the flag (admin-only). New section on /firm/manage (admin view only) with checkbox + positive-framing copy explaining what flows ("HMAC-hashed structural signals; no raw data egresses") and what the partner is enabling (engine self-improvement). The actual signal-emission pipeline is queued for a later sprint — this is the durable flag + UI.

Item 3 — Pricing page wording fix (templates/pricing.html)

Problem: Each pricing card carried the line "Runs expire after 12 months and do not carry over" — ambiguous because a customer who buys top-ups mid-cycle could read it as "those new runs get a fresh 12 months." The paragraph above the cards had similar ambiguity.

Fix: Removed the line from every pricing card (4 occurrences). Rewrote the paragraph above the cards: "Each bundle sign-up grants your account a 12-month access window. Runs expire on your initial signup anniversary year; additional runs purchased within a 12-month cycle do not create a new expiry date/year and do not carry over. Re-up any time to extend the window to the next anniversary; top-ups add runs to your current pool without changing the expiry." The "anniversary year" + "date/year" phrasing closes the technical-loophole reading.

Item 4 — Refund Policy carries cancellation paragraph (templates/refund_policy.html)

Fix: Added new Section 2 "Cancellation behavior" with two paragraphs: (a) mid-cycle cancellation preserves access + current runs through the natural end of the 12-month cycle; no refund; (b) mid-cycle top-up purchases follow the same posture (no portion refunded). Sections 3-7 renumbered accordingly; cross-reference in Section 6 updated.

Item 5 — Stale /jda placeholder route removed (app.py)

The v1.0.4 jda_landing_stub route at app.py:~2253 was dead code — superseded by the v1.0.11 mounted jda_router.get("/jda") handler via route-registration order. Removed cleanly. The /partners alias (a redirect helper, not a duplicate route) is preserved.

VERSION → 1.0.50.

v1.0.49 — 2026-05-16 — Refund Policy page + TOS §4 alignment

/refund-policy (new route + templates/refund_policy.html) — explicit posture

Decision (Z 2026-05-16): The prior TOS §4 said Tier 1 refund policies are "governed by their respective subscription agreements or License Schedules" — vague enough that prospects couldn't tell from the public surface what was refundable. A dedicated Refund Policy makes the posture legible and protects standard pricing perception (refund-on-whim erodes pricing trust at Tier 1 scale).

Fix: Explicit posture per Z's directive: 1. Monetary refunds are issued only for accidental duplicate orders (e.g., a customer charges the same run-pack twice within a short window believing the first didn't complete). 14-day request window; refund issued via Stripe to the original payment method within 5–10 business days. Any other refund reason — changed-mind, didn't-use-it, output-not-as-expected — is not eligible. The engine is the product; we do not refund for output you don't like. 2. Failed runs auto-refund to the firm's run pool (run-count refund, not dollar refund). Triggered when upstream infrastructure fails: Anthropic API outage, BigQuery timeout, Cloud Run instance failure, or any engine dependency degradation. No customer action required. Aligns with v1.0.26's no-silent-degradation posture — engine fails clean rather than substituting a lower-capability model, AND the consumed run becomes available again. 3. Launch-program free runs (2 per redeemed code from v1.0.39) carry no refund obligation. They expire with the 12-month access window or account dissolution. 4. Tier 2 / JDA refund terms negotiated per contract — Refund Policy explicitly defers to the JDA's refund clause for those customers.

TOS §4 alignment (templates/terms.html)

The TOS section 4 text was updated to mirror the Refund Policy's explicit posture (replacing the vague "governed by subscription agreements" line) and adds a direct link to /refund-policy for the complete posture, mechanics, and exceptions.

Footer link (templates/base.html)

Added a Refund Policy link to the footer legal-line, placed after Privacy and before Send feedback per Z's directive 2026-05-16. Surface order is now: Terms · Privacy · Refund Policy · Send feedback · v{VERSION}.

VERSION → 1.0.49.

v1.0.48 — 2026-05-16 — Signup: relocate "Have a launch code?" + pricing-grid orphan-card centering

Signup page: "Have a launch code?" moves below "Already have an account?" (templates/signup.html)

Decision (Z 2026-05-16): Code-redemption is a side path, not the primary signup flow. The disclosure toggle had been sitting above the email/password fields, which gave it more visual weight than the standard signup deserved. Relocating it below the "Already have an account? Log in" line restores the visual hierarchy: primary signup → secondary "already have" → tertiary "have a code."

Fix: The <details> block (containing the "Have a launch code?" summary + the <input name="code">) is removed from inside the form and re-rendered below the "Already have an account?" paragraph. The form gets id="signup_form"; the relocated code input uses HTML5's form="signup_form" attribute to associate with the form despite living outside it, so submissions still POST the code as part of the standard signup payload. The launch-code-applied banner at the top of the page (when ?code=... URL param validates) is preserved — it's a confirmation, not a CTA.

Pricing grid: orphan-card centering at tablet widths (static/css/site.css)

Problem (Z 2026-05-16): On the /pricing page in the 769px–1099px tablet range, the .pricing-grid defaults to 2 columns. Row layouts with an odd card count — e.g., .pricing-row-3 with 3 cards — leave the last card alone on row 2 at the viewport's left edge. The orphan card looked visually wrong; a centered solo card matches the design vocabulary of the dedicated .pricing-row-solo layout at desktop widths.

Fix: New media query (@media (min-width: 769px) and (max-width: 1099px)) with the selector .pricing-grid > .pricing-card:last-child:nth-child(odd) — matches the last card only when its grid index is odd (i.e., it's a row-2 orphan in a 2-col layout). The orphan spans both columns (grid-column: 1 / -1), capped at 460px max-width, and centered horizontally. Even-count layouts (e.g., row-4 at tablet width yields a clean 2×2) are unaffected because :nth-child(odd) doesn't match their last-child.

Handles all common card counts gracefully: 3 cards (3rd centers), 5 cards (5th centers), 1 card (alone-centers, same as the desktop row-solo behavior). 2-card and 4-card layouts unchanged.

VERSION → 1.0.48.

v1.0.47 — 2026-05-16 — Launch program: pull $5K Solo Trial discount; codes grant 2 free runs only

Discount-pricing branches removed from every checkout path (app.py)

Decision (Z 2026-05-16): Protect Solo Trial standard pricing perception against Tier 1 prospects who will pay full $9,000. The launch program now grants 2 free Tier 1-equivalent runs to redeem the code at signup; the Solo Trial 20-run pack reverts to standard $9,000 pricing on every purchase path going forward.

Fix: Removed the price_data override branches from: - /subscribe/run_pack/{slug} initial-signup checkout (was: $5,000 override when trial flag active for solo_trial slug) - /buy-pack/{slug} top-up checkout (same pattern) - /firm/create/invoice Pay-by-Invoice flow (same pattern)

Every checkout now uses the fixed Stripe SKU at pack["stripe_price_id"]. The dcfn_trial_discount_applied metadata field is no longer emitted; webhook branches for tier_1_initial_signup, topup_pack, and tier_1_initial_invoice no longer call accounts.mark_trial_discount_used() (the flag was the gating signal for the price override that's now gone).

/buy-more-runs + firm_create_invoice_sent.html (templates/buy_more_runs.html, templates/firm_create_invoice_sent.html)

Removed the trial_active conditional that rendered the $5,000 / $9,000 struck-through pricing on Solo Trial cards. Both blocks (the solo_first layout's prominent card + the ladder_first layout's smaller below-the-fold card) now render at standard $9,000. The "Launch discount applied" banner on the invoice-sent confirmation page is removed.

Signup banner copy (templates/signup.html)

The Launch-code-applied banner on the signup page no longer mentions the Solo Trial pack discount. New copy:

"Launch code applied: 2 free Tier 1 runs at signup. Solo Trial pack and all subsequent purchases at standard pricing."

accounts.grant_trial_to_firm (accounts.py)

No longer sets trial_discount_active=True when applying a code redemption. The field stays on the firm record as False for audit-trail compat (anything that read it in the past now consistently reads False). Only trial_runs_grant=2 is the active signal — the engine intake gate (_resolve_firm_context + /analyze consume-trial-run path) continues to function unchanged.

What this does NOT change

Audit fields retained

trial_discount_code is still written on the firm record at redemption so post-hoc audits can trace which code unlocked which firm. trial_granted_at ISO timestamp also stays. These are no longer read by any active code path but remain for traceability.

VERSION → 1.0.47.

v1.0.46 — 2026-05-16 — /health endpoint version drift fix + obsolete ping cleanup

/health returns live attribution.VERSION (app.py)

Problem: Smoke testing of v1.0.45 surfaced that /health was reporting "v": "0.14.11" while the live engine was at v1.0.45 — a 32-version lag. The string was hardcoded at the v0.14.11 deploy and never updated as VERSION incremented. Customers / monitoring tools reading /health for the engine version were reading a stale constant, not the actual running build.

Fix: Source the version from attribution.VERSION (single source of truth across attribution.write_html_footer_block(), the changelog header, the L1 PDF stamp, etc.). /health now reads the same constant every other version-aware surface reads, so drift becomes structurally impossible.

Removed /admin/ping-v14-11 (app.py)

The endpoint was a one-off deploy-verification ping for v0.14.11; the version name in the URL itself encoded its obsolescence. Nothing referenced it across the codebase. /health now carries live version info and /admin/smoke (admin-key-gated) carries the structured post-deploy validation, so this dead route is removed cleanly.

VERSION → 1.0.46.

v1.0.45 — 2026-05-16 — Cross-Portfolio Pattern Transfer Report (Fix 10)

New L1 section + cross_portfolio_transfer.py (new module)

Problem (Perplexity Convo 4, 2026-05-15): Consolidated Supplemental App. No. 64/043,294 Claim 5 (Domain-Agnostic Structural Fingerprint Transfer) was operational at the clustering layer (canonical-element extraction is domain-independent) and at the title/abstract synth (v1.0.30/35 CPC-fingerprint routing), but the customer-facing artifact never surfaced the mechanism. A customer who owns multiple filings across different technical domains had no surface telling them "the claim architecture in your genomics dispatching patent structurally mirrors the claim architecture in your scheduling-state-machine patent — a single continuation could claim the compositional bridge between them."

Fix: New cross_portfolio_transfer.py module walks the graph's internal PATENT nodes, computes pairwise canonical-element Jaccard + architectural-pattern Jaccard + CPC subclass overlap, and ranks bridge candidates by max(canonical_jaccard, arch_jaccard) × (1 - cpc_overlap). The (1 - cpc_overlap) term rewards CROSS-DOMAIN bridges (different CPC subclasses) — same-CPC pairs are continuation candidates the engine surfaces elsewhere, not cross-domain transfer opportunities.

Bridge criteria: - At least one structural overlap (canonical OR architectural) ≥ 0.20 - CPC overlap < 1.0 (otherwise same-domain — surfaces as continuation candidate, not a transfer-report bridge)

Top-5 bridges render as a new L1 section "Cross-Portfolio Pattern Transfer" with the shared canonical elements + architectural patterns named explicitly per pair, the CPC subclasses of each filing surfaced inline, and the bridge-signal / canonical-Jaccard / architectural-Jaccard / CPC-overlap diagnostic line at the bottom of each row. Patent grounding cited explicitly in the section preamble: "reduction-to-practice of Consolidated Supplemental App. No. 64/043,294 Claim 5."

Empty section (zero rows rendered) when the portfolio has fewer than 2 internal patents or when no pair meets the structural-overlap floor.

Customer surface: new artifact section no competitor produces. Directly monetizes the cross-domain transfer capability the patent already protects. Most impactful on multi-domain portfolios (the typical Tier 1 firm-pool client's workload) where the engine can name specific cross-domain continuation opportunities the attorney would not find without walking the portfolio pair-by-pair.

VERSION → 1.0.45.

v1.0.44 — 2026-05-16 — Run Provenance Log (Fix 9 — cryptographic-integrity audit record)

run_provenance.py (new module) + L1 render integration (render_arc.py)

Problem (Perplexity Convo 4, 2026-05-15): Every artifact carried the engine version number and corpus scan date, but a large firm's IP counsel had no way to verify that a run from six months ago used the same operational parameters (encoder model, threshold configuration, corpus snapshot) as a run today. Without that audit trail, AI-assisted prosecution output can't pass institutional trust review.

Fix: New run_provenance.py module emits a structured provenance record at L1 completion time. Fields: - run_id: session id - engine_version: attribution.VERSION at run time - encoder_model: SBERT model name (e.g. sentence-transformers/all-mpnet-base-v2) - encoder_dim: embedding dimensionality - bq_corpus_table: BQ source table identifier - corpus_snapshot_hash: SHA-256 of the per-session domain_patents.json content (binds the audit to the corpus the engine actually read, not to the BQ table at hash time — different CPC filters produce different hashes) - user_portfolio_hash: SHA-256 of patents.json (the user portfolio that produced this run) - thresholds: canonical dict of every operational threshold the engine uses (silent-cluster threshold, retry step, retry floor, agglom distance threshold, canonical/architectural-pattern overlap thresholds, auto-builder depth/k_first/m_second/floor/top_out, void-detection gap-multiplier, claim text cap, abstract cap, etc.) - generated_at: ISO-8601 timestamp - integrity_digest: SHA-256 over the canonical-JSON serialization of every field above. Any post-run mutation invalidates the digest.

The record is persisted as run_provenance.json in the per-session data directory (audit-trail sidecar). The L1 PDF renders a one-line footer block below the attribution: Run provenance · corpus SHA-256 {first16}… · integrity {first12}… · v{engine_version} · {generated_at}.

HMAC signing via the v1.0.10 identifier_hashing primitive is the natural v1.x extension once large-firm compliance audits demand cryptographic counterparty verification rather than integrity-only. For now, plain SHA-256 integrity is sufficient for the "verify same parameters six months later" audit case the critique named.

Re-runs of the same L1 are idempotent — compute_run_provenance() only writes the sidecar JSON the first time per session; subsequent renders load the existing record so the audit hash stays stable across artifact regenerations.

VERSION → 1.0.44.

v1.0.43 — 2026-05-16 — Sprint 2 (first half): output-density enhancements (Fixes 5–8)

Four bounded enhancements that extend how much of the engine's structural analysis flows cleanly into the customer-facing artifacts. Territory expansion in the Engelbart-lineage sense (per Z 2026-05-16): not shifting who decides, just mapping more of the landscape before the attorney takes over. All sourced from Perplexity DCFN-Patents critique (Convos 3–4, 2026-05-15).

Fix 5 — Hypothesis-to-embodiment routing in provisional drafts (provisional_synth.py)

Problem: The hypothesis-mutation mechanism (Consolidated Supplemental, App. No. 64/043,294) generates structural alternative angles during void-band positioning — each void band, differentiation-seed neighbor, and integration-seed neighbor implies a distinct structural variation. These angles were used internally for claim shaping and then discarded; the Detailed Description's "alternative embodiments" mention was generic.

Fix: New _format_alternative_embodiments() helper builds an explicit angles block from three sources — structural voids (each void band → operate-in-lower-half angle), differentiation seeds (each high-similarity neighbor → distinguish-against-X angle), integration seeds (each moderate-similarity neighbor → integration-of-X-element angle). Up to 5 angles total (Embodiment A–E). The Detailed Description prompt now contains a {alternative_embodiments} slot with explicit instructions to materialize each angle as a numbered Embodiment with one structural difference + one named technical advantage preserved.

Fix 6 — Abstract domain-conditioning for silent-region + lpa-forward (render_arc.py)

Problem: v1.0.30 + v1.0.35 shipped 8-domain templates for convergence-delta abstract bodies. Silent-region and lpa-forward abstract paths remained domain-neutral keyword-driven, producing near-identical opening clauses across all domains ("A computer-implemented system and method for…"). Perplexity 2026-05-15 flagged this as a formulaic-output pattern.

Fix: Extend _draft_abstract() to route silent-region and lpa-forward through the same per-domain templates (biotech / wireless / hardware_devices+automotive_robotics / media_imaging / speech_audio / ml_ai_software / default). Each domain's silent-region opening frames the unification in the structurally appropriate shape ("An engineered composition…" for biotech, "An apparatus and method that unifies …sensing-control primitives…" for hardware/automotive, etc.); each domain's lpa-forward opening frames the profile-maintenance arc with domain-appropriate vocabulary.

Fix 7 — Teach-away bifurcation in differentiation memos (provisional_synth.py)

Problem: Every prior-art reference in the differentiation memo received the full PHOSITA teach-away treatment regardless of CPC domain distance. Cross-domain references surfaced by the flat-embedding retrieval (where a PHOSITA would never look at the reference) consumed teach-away word budget without carrying meaningful argument — vocabulary artifacts dressed as substantive analysis.

Fix: New _cpc_distance() classifies each reference's CPC distance from the target as NEAR (same subclass, e.g., G06N vs G06N), ADJACENT (same class, e.g., G06N vs G06F), or FAR (more than 2 levels — e.g., G06N vs H04L). _format_prior_art() emits the distance label per reference. The differentiation_memo prompt bifurcates: NEAR/ADJACENT references get full per-reference analysis including teach-away; FAR references collapse to a one-sentence dismissal naming the CPC mismatch ("No PHOSITA designing in [target_domain] would consult a [reference_domain] reference. No further analysis required."). Sharpens the §103 analytical surface; preserves teach-away word budget for references where PHOSITA argument actually carries weight.

Fix 8 — Obviousness Combination Flag (§103 pairwise) (deep_run.py, provisional_synth.py)

Problem: The differentiation memo's §103 analysis evaluated each prior-art reference individually. The most common §103 rejection pattern — combining reference A + reference B to argue the target is obvious even when neither reads on it alone — was unaddressed.

Fix: New _compute_obviousness_pairs() in deep_run.py pairs the top-5 neighbors (each above 0.45 individual similarity) and produces a ranked list of high-combined-signal pairs (top 3). Each pair carries patent IDs, titles, individual similarities, and a combined signal score. New §103 COMBINATION ANALYSIS section in the differentiation memo prompt names each flagged pair explicitly and instructs the LLM to articulate why a PHOSITA would not be motivated to combine them — different from per-reference teach-away because the pair, taken together, may cover more of the target than either alone.

VERSION → 1.0.43.

v1.0.42 — 2026-05-16 — Sprint 1 trust-boundary fixes (Perplexity DCFN-Patents critique)

Four bounded fixes that define where the engine's authority ends and the attorney's begins — per Engelbart-lineage framing: not "human-in-the-loop oversight," but making the handoff point legible so attorney exercises independent judgment with complete information. All sourced from Perplexity DCFN-Patents critique (Convos 1–3, 2026-05-15).

Fix 1 — Claim text full ingestion (deep_run.py, continuation_memo_synth.py, memo_pitch_synth.py)

Problem: Independent-claim text was being truncated mid-sentence at multiple synth-input sites: 1200/1500/3500/600 char caps across deep_run + memo_pitch + continuation_memo. The engine then self-flagged the truncation with "claim truncated mid-sentence" disclaimer language, which compromised attorney usability — a memo qualified against its own input data cannot be relied on at the prosecution-strategy standard.

Fix: Lift all synth-input claim-text caps to 25,000 chars (handles 4,000-word independents, well above the USPTO 99th-percentile). New ceiling fires a [claim-truncation] warning if actually hit, and the synth context flags it explicitly to the LLM ("NOTE: claim text exceeded engine ceiling; analysis applies to visible portion only"). Per-record flags (text_truncated, neighbor_claim_truncated) propagate the signal for downstream consumers. Abstract caps held at 2,000 (USPTO abstract ceiling); display-only excerpts at 300–600 chars unchanged.

Fix 2 — Similarity scores on auto-builder adjacency cards (render_arc.py)

Problem: v1.0.29 auto-builder surfaced second-order adjacencies on L1 showing patent number + title + a rounded surface percentage only. Attorney couldn't calibrate whether a 38% surface was meaningfully different from a 52% surface — sub-percentage precision matters in the 0.30-0.45 cosine band where most second-order adjacencies live.

Fix: Render now shows BOTH the rounded percentage AND the raw cosine score (4-decimal precision the auto-builder already records on every adjacency) for similarity-to-user-filing AND seed-to-adjacency. The via-seed patent ID is also Google-Patents-linked. No engine computation change — pure render-surface upgrade routing precision the engine already produces.

Fix 3 — Coverage Caveat at Section 1 of continuation memos (continuation_memo_synth.py)

Problem: When the engine's structural read was likely incomplete (high textual isolation, no near neighbors, or NPL-heavy technical domain), the warning surfaced in Section 3-4 of the memo. A practitioner reading at speed could reach an incorrect conclusion from the isolation score before seeing the caveat.

Fix: New _compute_coverage_caveat() helper detects three triggers — Textual Isolation Score > 8, zero neighbors above 0.50 similarity, or portfolio CPC domain in the NPL-heavy set (ml_ai_software / media_imaging / biotech / automotive_robotics / speech_audio). When any trigger fires, a Coverage Caveat block is injected at the TOP of the prompt with the specific reason(s) + a named literature cluster the human should sweep (e.g., "arXiv cs.LG / cs.CL / cs.AI, NeurIPS / ICML / ICLR proceedings" for ML). The memo's similarity-score legend and Section 1 landscape narrative both render BELOW the caveat. CPC domain detection reuses the v1.0.30 fingerprint helpers.

Fix 4 — Inline lexicon flagging in provisional drafts (provisional_synth.py)

Problem: The provisional cover note named flagged term categories (medical/diagnostic routing, LLM/generative AI, biometric, V2X, modern compression, post-quantum crypto) at the start of the document, but the body itself was un-annotated — a fast reader could miss the in-context occurrences of those terms.

Fix: New _highlight_flagged_lexicon() deterministic post-pass runs after the docx body is built. Every case-insensitive whole-word match of the flagged lexicon list is wrapped in bold + square brackets inline (e.g., [medical], [V2X], [transformer model]). String-match only — no LLM call, sub-millisecond per document. First ~3 paragraphs (cover-note region) skipped to avoid circular flagging. Lexicon covers: medical/diagnostic (medical, diagnostic, therapy, clinical, patient, disease, etc.), LLM/generative (large language model, LLM, generative AI, transformer model, foundation model), biometric (biometric, iris recognition, facial recognition, fingerprint), V2X (V2X, V2V, V2I, vehicle-to-everything), modern compression (JPEG XL, AVIF, HEIF, AV1, VVC, H.266), post-quantum crypto (Kyber, Dilithium, FALCON, SPHINCS).

Sequencing note

Per Perplexity 2026-05-15: Fix 1 is upstream of everything; validating it first ensures truncated claim input no longer corrupts the outputs of Fixes 2, 3, 7 (where the synth's analysis quality depends on full claim visibility). All four fixes are bounded, fail-safe, and operate on render/render-input layers — no engine-reasoning behavior change.

VERSION → 1.0.42.

v1.0.41 — 2026-05-16 — Self-serve Pay-by-Invoice (PO/Wire) automation + minor render fixes

Pay-by-Invoice automation (app.py, templates/firm_create.html, templates/firm_create_invoice_sent.html)

Problem: The Pay-by-Invoice path on the firm-create page rendered a static modal telling prospects to email billing@livingedenframeworks.com with their org details; a human manually sent the Stripe Invoice within one business day. Two issues: (1) prospects who want to wire from an operating account drop off if they don't want to wait, (2) every DCFN engine build must reach walk-away self-serve — the Admin Layer's purpose is automation, not human-in-the-loop oversight (Z 2026-05-16 architectural principle).

Fix: Replace the modal copy with a form (AP contact email, billing address, optional PO number, optional internal reference). Server creates Stripe Customer + InvoiceItem (price_data override at $5,000 when launch-code trial discount is active, else $9,000 at the standard SKU) + Invoice (collection_method="send_invoice", days_until_due=30, custom_fields=[PO Number, Pool Name], auto_advance=True). Stripe auto-emails the AP contact a hosted invoice with NET-30 terms accepting wire/ACH/card. Webhook invoice.paid event (when dcfn_purchase_type=tier_1_initial_invoice) routes to the same firm-activation path as checkout.session.completed for the card/ACH flow — synthetic sub ID flat_inv_<invoice_id>, set_firm_subscription, seed usage doc, mark trial_discount_used (if applicable), send welcome email. Identical end-state regardless of payment path. Stripe auto-reminders + auto-void handle the rest. Zero-human flow.

Confirmation page (firm_create_invoice_sent.html) summarizes what was sent, surfaces the launch-discount banner when applicable, links to the Stripe-hosted invoice URL for the admin's reference.

L2 footer button order + Done-button color (static/css/site.css)

On narrow viewports (≤680px), the L2 selection page's sticky footer stacked Done above Generate (since DOM order is Done first for wide-screen left-alignment). v1.0.41 applies CSS order: 1 to #l2Checkout and order: 2 to .l2-back-to-run inside the existing narrow-viewport media query so Generate sits at the top of the stack on phones. Done button rendered in coral orange (#FF7F50, hover #E5613A) to visually distinguish it from the primary Generate action (purple). Wide viewports unchanged.

Cap-warning banner: drop premature five_left stage (app.py, templates/account.html)

The cap-warning banner on /account fired at 5 runs remaining out of 20 with hardcoded "Down to 5 runs" copy that stayed at "5" regardless of actual remaining count. v1.0.41 drops the five_left trigger entirely (Z 2026-05-16: at 5/4/3 runs remaining of a 20-run pool, the Pool counter "Pool: 18 / 20" already carries the math at a glance; a yellow urgency banner adds noise without information). Banner now only fires for the genuinely critical states (1 left, exhausted) where the admin-nudge framing earns its visual weight.

VERSION → 1.0.41.

v1.0.40 — 2026-05-16 — Self-healing firm inflight counter + cap raised to 25

Firm concurrent-run cap: 5 → 25 (app.py)

Problem: FIRM_CONCURRENT_CAP = 5 was set in v0.13.24 before the v1.0.37 architectural shift to containerConcurrency=1 (each run on its own GPU instance). With per-run isolation, there is no engine-quality degradation regardless of how many runs a firm fires simultaneously — the only ceiling is GCP's GPU quota (currently 3 → 10 after approval). The 5-cap was therefore inappropriately blocking legitimate burst usage (Z surfaced this 2026-05-16 hitting the cap during prospect-testing with admin + member parallel runs).

Fix: Raise to 25 — well above any realistic per-firm concurrent need, low enough to catch runaway scripts firing 100+ requests in a loop. Cross-tenant fairness (preventing one firm from monopolizing GPU slots when multiple firms are active) becomes a concern only when 3+ firms are actively running simultaneously — re-evaluate with a tier-aware cap once the first paying cohort surfaces real contention.

Stuck-counter self-heal on the firm-pool concurrency cap (accounts.py, app.py)

Stuck-counter self-heal on the firm-pool concurrency cap (accounts.py, app.py)

Problem: The firm-pool concurrent-run hard cap (FIRM_CONCURRENT_CAP = 5) is enforced against a Firestore counter (firm.in_flight_runs) that increments on /analyze submission and decrements in a finally block when the run terminates. When the Cloud Run instance dies before the finally runs — instance migration, OOM, abrupt shutdown — the decrement is lost. Over enough crashed runs across days, the counter drifts upward and eventually pins the firm at the cap, blocking legitimate new runs with "Your firm has 5 runs in flight (cap: 5). New runs become available when one finishes…" even when zero runs are actually in flight. Z hit this 2026-05-16: LEF Ai Engine firm counter at 4 from past crashed runs; admin + member double-run pushed to 6 → blocked.

Fix: increment_firm_inflight now stamps in_flight_last_change_at on every counter movement. The /analyze cap-check, before rejecting, calls reset_firm_inflight_if_stuck — if the counter is >0 and the last movement was more than 60 minutes ago, the counter is treated as leaked from crashed/migrated workers and reset to 0. A real run completes in ~5 minutes, so a counter pinned at cap with no movement in >60 min is structurally stuck, not legitimately busy.

The self-heal is bounded and idempotent: it operates only on Firestore state, never touches per-session GCS artifacts. Legacy rows without a timestamp field get a one-time reset to start the timestamp tracking cleanly. The reset reason is recorded on the firm doc (in_flight_last_reset_reason) for audit.

Defense-in-depth — the original finally-block decrement is unchanged; this is a recovery net for crashes that escape the finally. Combined with the Cloud Run containerConcurrency=1 change tonight (each run gets its own instance, eliminating cross-run pollution), counter drift should become rare.

Validated locally by manually resetting the leaked counters on Z's three firms (4 → 0, 1 → 0, 0 → 0) and confirming subsequent /analyze submissions accept normally.

VERSION → 1.0.40.

v1.0.39 — 2026-05-16 — Launch discount-code program (2 free runs + $5K Solo Trial)

The DCFN-Patents launch program lets each prospective IP firm receive two free Tier 1-equivalent runs at signup and purchase the Solo Trial 20-run pack at $5,000 (vs. the standard $9,000) the first time. The discount evaporates after a single successful purchase — subsequent run-pack purchases price at the standard SKU. Codes are minted into a Firestore collection in advance of outreach; the email contains a per-code signup URL.

discount_codes.py (new module) + Firestore discount_codes collection

What landed: A code-management module with mint / get / redeem / list / invalidate primitives. Codes are 12-char strings drawn from a 32-char unambiguous alphabet (60 bits of entropy). Each code carries free_runs_grant, trial_pack_slug, trial_pack_price_cents, and a redemption state. Redemption is implemented as a Firestore transaction so two simultaneous signup attempts against the same code cannot both succeed.

CLI for ops use: python3 discount_codes.py mint --count N --description "...". Twenty codes were minted into production Firestore for launch cohort A immediately ahead of this release.

Signup flow integration (/signup GET + POST, signup.html)

What landed: The signup form gained an optional "Have a launch code?" disclosure that accepts a code value. Codes can be supplied via URL parameter (?code=...), in which case the form pre-validates and renders a confirmation banner explaining what the code unlocks; or typed into the disclosure field directly. The POST handler validates the code, creates the admin user, atomically redeems the code, creates the firm under the trial pack slug, and applies the trial grant — all in one signup transaction. A bad or already-redeemed code surfaces an inline error without leaving a half-created account behind.

The signup gate (_signups_gated) — which normally blocks new-account creation during a maintenance window — bypasses for valid launch codes. Launch-allocated trial accounts are explicitly-allocated and treated like firm invites: the gate is for blocking organic acquisition, not invited prospects.

Firm-side state (accounts.py)

What landed: Three helpers + four new firm fields:

Helpers: grant_trial_to_firm(firm_id, free_runs_grant, discount_code) (applies at signup), consume_trial_run(firm_id) (atomic decrement used by /analyze), mark_trial_discount_used(firm_id) (flips the discount-used flag after Stripe settles the purchase).

Engine run-gate consumes trial grant before the standard usage check

What landed: /analyze now performs a consume_trial_run against the firm's trial_runs_grant BEFORE the standard usage_tracker.check_run_allowed gate. When a trial run is consumed, the usage-tracker gate is skipped (otherwise it would reject the firm — no active Stripe subscription yet). _resolve_firm_context was widened to also return the firm dict when trial_discount_active is true and trial_runs_grant > 0, even when the firm's Stripe subscription status is still pending.

After the trial grant is exhausted, the firm naturally falls through to the standard payment-gated path on subsequent runs.

Buy Runs price gating + Stripe checkout switch

What landed: The /buy-more-runs page renders the Solo Trial pack at $5,000 with the $9,000 struck through whenever trial_discount_active && !trial_discount_used. Both /subscribe/run_pack/solo_trial (first-time signup checkout) and /buy-pack/solo_trial (top-up checkout) detect the same firm condition and create the Stripe Checkout Session with a price_data override at $5,000 instead of the fixed SKU at $9,000. Metadata on the checkout includes dcfn_trial_discount_applied=1 so the webhook can correlate the consumption back to the firm.

After the first successful purchase that carried the discount flag, the Stripe webhook calls mark_trial_discount_used and the firm's subsequent visits to /buy-more-runs see the standard $9,000 price. Server-side gating, never client-side — the price is computed on every render and every checkout-session create.

Admin endpoints (/admin/codes, /admin/codes/mint)

What landed: Two admin-keyed endpoints for ops. GET /admin/codes lists every minted code with its status (unused / redeemed / invalidated) and, for redeemed codes, the firm + email it bound to. POST /admin/codes/mint mints additional codes when launch cohort B is ready. Same DCFN_ADMIN_KEY header auth pattern as /admin/smoke.

Test posture

The code paths are bounded and fail-safe by design: a Stripe webhook flip can be re-fired safely (idempotent), trial-run consumption is transactional (no double-consume), code redemption is transactional (no two firms redeem the same code), and the discount-applies gate is server-side at every render. Live end-to-end smoke against the launch-cohort codes will run on Z's first prospect submission.

VERSION → 1.0.39.

v1.0.38 — 2026-05-15 — Self-healing L2 status: re-kick stuck-generating provisionals and memos

L2 worker recovery for instance-migration race (app.py)

Problem: v1.0.37 added self-heal to the L1 /status endpoint, recovering sessions where the L1 worker died after writing artifacts but before flipping terminal state. The same instance-migration pattern bites the L2 lazy-generation path: when a customer pays for a deliverable and the worker thread for _kick_provisional_generation or _kick_memo_generation dies before writing even its initial "generating" sentinel into state, the result-page polling loop shows the deliverable stuck on "generating" indefinitely with no retry button (the Retry endpoint only surfaces on status=failed, not absent state). Z 2026-05-15 hit this on session dac4f921bcfd: third paid provisional (bridge-11308350-9) had no entry in provisionals_pre_run at all — worker silently never produced state.

Fix: The /layer2/{session_id}/status endpoint now self-heals on each poll. Items in the paid selection that have no entry in their respective state map (provisionals_pre_run for provisionals; l2_deliverables for memos) are treated as workers that died before recording state, and generation is re-kicked. A log line surfaces the recovery for Admin Layer visibility. After re-kick, the session state is re-read so the response reflects the now-generating items rather than the stale absent state.

Effect: a customer who hits a stuck-generating deliverable simply waits for the next poll cycle (4s) and the worker re-fires automatically. No retry button required, no operator intervention. Defense-in-depth — the orchestrator's primary kick path is unchanged; this is a recovery net.

Validated locally via inspection of the recovery branch on a state dict where a paid provisional has no pre_run entry — re-kick fires; on a state where all items have entries — no-op pass-through.

VERSION → 1.0.38.

v1.0.37 — 2026-05-15 — Self-healing /status: recover stuck-pending sessions when artifacts are present

Status-poll recovery for instance-migration race (app.py)

Problem: Z 2026-05-15 ran two L1 jobs in parallel on Cloud Run and one hung indefinitely on "Inferring your portfolio's domain label…" at 51% progress. Investigation showed the L1 actually completed: every artifact (landscape PDF, narrative HTML, candidates_enriched.json, portfolio_domain.txt) was present in the durable session store, total_pipeline_seconds was persisted, but the terminal status="ready" flip never landed in the state file. Root cause: the Cloud Run instance was migrated mid-finalize — the worker thread wrote artifacts and the pipeline-timing field, then died before reaching the terminal-state update at the end of the orchestrator. v1.0.23's force-flush handles the case where the state-sync timer dies before flushing a terminal state that was set; it does not handle the case where the worker thread itself dies before setting the terminal state in the first place.

This was paired tonight with a Cloud Run config change (containerConcurrency: 2 → 1 + max-instances: 3 → 3) so two parallel runs no longer share one GPU instance; each run gets its own. That removes the root cause going forward, but does not heal sessions that hit the race before the config change — and does not protect against any future instance-migration event for other reasons.

Fix: The /status/{session_id} endpoint now self-heals on poll. When the durable state shows status=pending AND the canonical L1 report artifact (__report.pdf or __report.html) is present in session_store, the L1 has completed regardless of what the state field says. The status handler flips the state to ready with the proper terminal fields (l1_ready=True, current_step="ready", step_label="Briefing ready.", progress_pct=100.0) plus a recovered_from_stuck_pending=True audit flag, and force-flushes to GCS. A log line surfaces the recovery for Admin Layer visibility. The orchestrator's finalize block is unchanged — this is a recovery net, not a replacement for the primary path.

Effect: any session that hit the instance-migration race (past or future) recovers on the next status poll instead of staying stuck indefinitely. Customers reload the page or wait one poll cycle (~5s) and the L2 page becomes accessible. Z's hung session b31328d429a1 recovers automatically on first poll after deploy.

Validated locally via unit-test of the recovery path: synthetic state with status=pending + present report artifact triggers heal-to-ready; state with status=pending + absent artifact passes through unchanged (still pending, as it should be); state with status=ready is a no-op.

VERSION → 1.0.37.

v1.0.36 — 2026-05-15 — Convergence-delta title pulls keywords from seed claims when internal title is bare

Title-keyword fallback to seed_claims (provisional_synth.py)

Problem: v1.0.30 routed convergence-delta titles per CPC domain ("APPARATUS AND METHOD FOR {keyword}" on automotive_robotics, "ENGINEERED COMPOSITION AND METHOD FOR {keyword}" on biotech, etc.); v1.0.35 added the matching abstract-body templates pulling from seed-claim text. The 2026-05-15 AV re-run confirmed both landed — abstract body reads as AV trajectory/obstacle method — but the title still rendered "APPARATUS AND METHOD FOR BRIDGED OPERATIONS" because the keyword extractor only fired when the candidate's internal diagnostic title carried a trailing keyword (e.g., "Convergence delta: trailer maneuver assist"). When the internal title is bare ("Convergence delta"), the extractor returned empty and the fallback string "BRIDGED OPERATIONS" was substituted into the domain template. Title and abstract body were drawing from different keyword pools.

Fix: When the primary keyword extractor returns empty on a convergence-delta candidate, the title routing now pulls a noun-phrase keyword from the candidate's seed_claims — the same source the v1.0.35 abstract templates already use. Top-3 most-frequent content tokens (stop-word filtered) joined into a noun phrase. Result: title and abstract draw from the same keyword pool. When seed_claims are also absent, the old "BRIDGED OPERATIONS" fallback is preserved — fail-safe.

Effect on the AV re-run candidate (Convergence delta candidate, seed claims about trajectory planning in obstacle-populated environments): title rendered "APPARATUS AND METHOD FOR BRIDGED OPERATIONS" → renders as a noun-phrase title derived from the actual claim content (e.g., "APPARATUS AND METHOD FOR OBSTACLE CELLS TRAJECTORY"). Existing convergence-delta candidates whose internal title already carries a keyword (e.g., "Convergence delta: trailer maneuver assist") are byte-identical to v1.0.35.

Validated locally across four cases: AV seed_claims fallback produces an AV-domain noun-phrase title; existing named-keyword path produces v1.0.35-identical output; biotech seed_claims fallback produces a biotech-domain noun-phrase title; no-seed_claims case preserves the v1.0.35 default fallback.

VERSION → 1.0.36.

v1.0.35 — 2026-05-15 — AV-run review: domain-routed abstract previews + memo synth sees auto-builder adjacencies

Z's reviewer of the 2026-05-15 AV (autonomous vehicle) portfolio run on v1.0.34 surfaced two outstanding items the prior eight versions had not closed. v1.0.35 closes both.

Fix A — Domain-routed convergence-delta abstract preview (render_arc.py)

Problem: v1.0.30 fixed the convergence-delta title via CPC fingerprint routing (the AV title rendered correctly as the default fallback rather than the prior software-only template), but the L1 abstract preview body still bled "dynamically measuring and adapting routed actions / receives outcome data / computes effectiveness scores per action type" on every domain. That preview was generated by a separate hardcoded template that v1.0.30 did not touch.

Fix: The convergence-delta abstract preview now routes through eight domain templates (biotech / wireless / automotive_robotics / hardware_devices / media_imaging / speech_audio / ml_ai_software / data_business_software / default). Each template frames the bridge candidate in the structural shape appropriate for the CPC family — biotech as "engineered composition bridging mechanism layers," automotive as "apparatus integrating control and sensing primitives," wireless as "method and apparatus bridging protocol-stack layers." silent-region and lpa-forward templates were already domain-neutral keyword-driven; only convergence-delta carried the software-routing bias.

The portfolio CPC domain is detected once per render via the same fingerprint helpers introduced in v1.0.30 and passed to every candidate card. Failure of detection falls back to the default template — never the prior software bleed.

Fix B — Continuation memo synth consumes auto-builder adjacencies (deep_run.py)

Problem: v1.0.29's auto-builder (Consolidated Supplemental, App. No. 64/043,294, Claim 8) writes second-order adjacencies into the cluster record. The L1 PDF correctly surfaced them — the AV run's L1 displayed "Auto-builder · second-order adjacencies surfaced for 10809719" with six real patent numbers. But the per-patent continuation-memo path built its neighbor list from first-pass cluster neighbors only, missing the auto-builder output. The downstream memo synth therefore wrote "the engine returned a cluster neighbor count of 0" on the same patents whose L1 page showed real adjacencies. Claim 8 explicitly requires subsequent operations to see the mutated graph; the memo synth is a subsequent operation.

Fix: The per-patent path now also reads cluster.second_order_adjacencies[patent_id] and appends those adjacencies to the neighbor list. Each appended record carries an auto_builder_provenance field (via_seed, sim_to_user, via_seed_sim_to_adjacency) for audit + narrative use; the classification flow treats them identically to first-pass cluster neighbors for similarity comparison. The log line distinguishes the count: "Found N cluster neighbors (K surfaced by auto-builder recursive graph mutation, Claim 8)". The memo synth reads deep_comparisons (built from the neighbor list) so the auto-builder output flows into memo prose automatically — no memo-synth change required.

Fix C — automotive_robotics CPC family added (provisional_synth.py)

The v1.0.30 domain map covered seven families (biotech / wireless / media-imaging / hardware / speech-audio / ml-ai / business-software). The AV portfolio fell through to "default" because B60W / G05D / B62D were not in any family. v1.0.35 adds an automotive_robotics family (B60W, B60T, B60K, B60R, B60Q, B62D, G05D, G05B, G01C, G01S, B25J, B64C, B64D, G08G) so AV / robotics portfolios route to the apparatus-and-method title template and the automotive-routed abstract preview. B25J moved from the prior hardware_devices family to automotive_robotics — robotic manipulators sit closer to AV control than to semiconductor / display hardware.

Validated locally on the 2026-05-15 AV portfolio Z ran: title routes to "APPARATUS AND METHOD FOR TRAILER MANEUVER ASSIST" (was the default fallback); abstract preview body no longer bleeds "routed actions / effectiveness scores"; continuation memos for the singleton-cluster filings now see six auto-builder adjacencies each. Render-side regression smoke on the archived v1.0.8 ml_ai_software run confirms the software-domain framing is preserved byte-for-byte where the prior template was the right one.

VERSION → 1.0.35.

v1.0.34 — 2026-05-15 — Architectural-pattern extractor as second cluster-validation axis (Bundle B Mechanism 2 v1.1)

Second axis on Cross-Patent Claim-Element Graph Topology (architecture_extractor.py new + hypothesis_engine.py)

Problem: The v1.0 canonical-element extractor captures the engine's OPERATIONAL signal — verb-object compounds pulled from independent-claim text (predict__congestion_wav, track__morphological_chang). This is the verb-object axis of Bundle B's Cross-Patent Claim-Element Graph Topology (U.S. Provisional Application No. 64/061,715, Claim 5). It fails on the Multi-Aspect Claim Scope class of inventions: three filings sharing an identical spatio-temporal dual-attention graph transformer architecture across AV traffic / MRI tumor tracking / financial systemic-risk produced pairwise verb-object Jaccard of 0.000 — architectural shape identical, verb-object vocabulary divergent per domain. Gemini's Test 3 surfaced this failure mode in the 2026-05 critique loop.

Bundle B Mechanism 2 explicitly allows a multi-dimensional graph topology — multiple independent label dimensions per node. v1.0.34 implements the second axis: noun-phrase architectural patterns.

Fix: New architecture_extractor.py module pulls architectural-pattern slugs via curated regex matching against a vocabulary of 57 canonical patterns across ten taxonomy clusters: Transformer family (transformer, graph_transformer, dual_attention, multi_head_attention, self_attention, cross_attention, encoder_decoder, sequence_to_sequence, sparse_attention, vision_transformer), Graph neural networks (graph_neural_network, graph_convolutional_network, graph_attention_network, message_passing, graphsage), Recurrent / sequential (lstm, gru, recurrent_neural_network, state_space_model), Generative (variational_autoencoder, generative_adversarial_network, diffusion_model, normalizing_flow, autoencoder), Convolutional (convolutional_neural_network, residual_network, pooling_layer), Optimization (reinforcement_learning, policy_gradient, q_learning, gradient_descent, backpropagation), Retrieval / embedding (embedding_space, retrieval_augmented_generation, vector_database), Federated (federated_learning, distributed_training), Spatial-temporal / multi-modal (spatio_temporal_model, temporal_convolution, multi_modal_fusion), Compression (quantization, pruning, knowledge_distillation), Reasoning (cognitive_traversal, graph_traversal, symbolic_reasoning), Diagnostic (anomaly_detection, ensemble_method, feature_extraction), and Cross-domain primitives (crispr_cas, guide_rna_system, base_editing, lipid_nanoparticle, ofdm, beamforming, mimo).

Schema-parallel to canonical_elements. Per-claim text → set of canonical slugs.

The cluster-validation invariant now passes on EITHER axis above the overlap threshold:

A new pass in run_inline builds the per-patent architectural-pattern map and threads it into candidate generation alongside the canonical-element map. Failure of the extractor module is non-fatal — the invariant short-circuits on the arch axis only and the canonical-element axis remains active.

Validated locally on the synthetic Multi-Aspect Claim Scope claims: all four canonical patterns (spatio_temporal_model, graph_transformer, dual_attention, transformer) extract from all three domain claims; architectural-pattern Jaccard = 1.000 across all three pairs while verb-object Jaccard remains ~0.000. The dual-axis invariant lets the cluster pass where the canonical-element-only invariant would have suppressed it. Negative test: a pure-biology CRISPR claim produces {crispr_cas, guide_rna_system} with no false-positive on AI/ML vocabulary.

Vocabulary growth is intended; additions land via quarterly review based on coverage telemetry (claims producing zero patterns flag candidates for expansion).

VERSION → 1.0.34.

v1.0.33 — 2026-05-15 — Kinetic-decay void classification (Bundle B Mechanism 1 first-cut)

Voids as kinematic entities (deep_run.py)

Problem: The structural-void detector (v1.0.7 Fix 4 first-cut) identified topological gaps in the prior-art similarity distribution and reported each as a static structural entity — gap magnitude, similarity band, position in distribution. Bundle B Mechanism 1 (U.S. Provisional Application No. 64/061,715, Claim 1) extends the primitive: voids are kinematic entities with computable decay properties. A void surrounded by stable adjacent-cluster density across a rolling temporal window is a long-term defensive moat (stable-silence); a void surrounded by monotonically encroaching density is a closing strategic-opportunity window (decaying-silence). The two cases require different downstream treatment — a decaying-silence void should trigger a continuation-filing recommendation with a colonization-window estimate; a stable-silence void doesn't. Through v1.0.32, all detected voids were functionally equivalent.

Fix: A new helper classifies each detected void by inspecting the filing dates of the two patents bordering the void's similarity band:

Filing-date pattern Kinetic state
At least one bordering filing within last 6 months decaying-silence
Both bordering filings ≥ 24 months old stable-silence
Intermediate range oscillatory
No filing-date data available unknown

The void detector signature is extended with an optional neighbor_filing_dates parallel-array kwarg. When supplied, each detected void record carries kinetic_state, kinetic_reason, and (for decaying-silence voids) a colonization_window_months estimate. When the kwarg is omitted the function returns the prior v1.0.7 shape — backward-compatible for callers that haven't been wired yet.

Both void call sites in deep_run.py are wired: the candidate-provisional path threads filing_date through from domain_patents.json per candidate; the per-patent continuation-memo path builds a parallel array by looking up each neighbor's filing_date from the in-scope domain map.

First-cut classification framing

This is a rougher classification than the patent's preferred embodiment (a full kinetic-encroachment metric κ(V, t) computed over the rolling-window adjacent-cluster density function). The first-cut uses only the two bordering patents as the temporal signal, which catches the most common kinetic distinction (both old vs at least one recent) without re-architecting the data flow. Full-window calculation requires propagating the entire adjacent-cluster's filing-date distribution through the pipeline; queued as a follow-on once the rougher signal has been exercised in production. Claim 1 accommodates both — the rolling-window calculation is preferred embodiment, not required.

Validated locally on synthetic filing dates covering all four kinetic states. Render-side surfacing of kinetic_state is deferred — voids flow into the memo synth's differentiation-seeds slot and the LLM picks up the new keys without prompt changes. Explicit kinetic-state callouts in the L1 render are a follow-on once production runs surface enough decaying-silence cases.

VERSION → 1.0.33.

v1.0.32 — 2026-05-15 — Biotech / wireless CPC-family expansion at corpus pull (Consolidated Claim 5)

Domain-fingerprint expansion at BigQuery filter (session_corpus_pull.py)

Problem: The session corpus pull derived BQ-filter subclasses from the user's portfolio at 4-character subclass granularity (e.g., C12N, H04L, G06N) and queried directly on those. For software-domain portfolios this works — G06N captures the bulk of AI/ML structurally-relevant prior art. For biotech and wireless portfolios it under-pulls: an RNA-therapy portfolio anchored on C12N misses A61K drug-formulation neighbors, C07K peptide neighbors, C12P enzyme-process neighbors, and G01N biomarker-assay neighbors that complete the structural landscape. Gemini surfaced this as the RNA Therapeutics under-pull failure in the 2026-05 critique loop.

The Consolidated Supplemental (U.S. Provisional Application No. 64/043,294) Claim 5 — Domain-Agnostic Structural Fingerprint Transfer — already protects the primitive of treating a domain as a fingerprint rather than a set of isolated subclass tokens. v1.0.32 exercises Claim 5 at the corpus-pull layer (in addition to the clustering layer, where canonical-element extraction has always been domain-independent).

Fix: Two domain families defined for v1.0.32:

Family Member subclasses
biotech A61K, A61P, A61B, A23L, C07K, C07H, C07D, C12N, C12P, C12Q, C12M, G01N
wireless H04L, H04W, H04B, H04J, H04R, H04M

The CPC-subclass deriver first extracts the user-portfolio subclasses (existing behavior, top-N by frequency). It then checks each base subclass against the family map; when any base belongs to a family, the rest of that family is appended (deduped, capped at the existing max). Software-domain portfolios pass through unchanged because no software family is defined — G06N / G06F / G06Q already capture the landscape at subclass granularity. Adding a software family would expand corpus pulls unnecessarily on AI/ML portfolios where the existing filter works.

Effect: an RNA-therapy portfolio anchored on C12N now pulls a corpus spanning C12N + C07K + C12P + A61P + C07H + A23L + A61B + C07D + C12Q + A61K, restoring the structural neighborhood the prior single-subclass filter missed. A 5G wireless portfolio anchored on H04L now also includes H04W + H04B + H04J + H04R + H04M, capturing the protocol-stack neighbors.

Validated locally on synthetic portfolio inputs covering biotech expansion, wireless expansion, software pass-through, mixed-domain priority (biotech wins on C12N + G06N input), and cap enforcement (15 base subclasses correctly capped at the existing max). Software-domain portfolios are byte-identical to v1.0.31.

VERSION → 1.0.32.

v1.0.31 — 2026-05-15 — Narrative non-determinism pinned via temperature=0 (Consolidated Claim 4)

Deterministic synth output on identical input (landscape_narrative_synth.py, memo_pitch_synth.py)

Problem: The landscape-narrative and memo-pitch synths had been calling Claude with the model's default temperature (typically 1.0), producing repeat-run variance in framing on identical portfolios. Perplexity surfaced the failure mode explicitly in the 2026-05 critique loop: same media-processing portfolio, three repeat runs, three different framings ("pipeline" / "optimization pair" / "paired system"). Repeat-run framing variance breaks legal-defensibility audits where an attorney must be able to reproduce engine output for review.

The Consolidated Supplemental (U.S. Provisional Application No. 64/043,294) Claim 4 — Internal Structural Self-Calibration — names traversal-internal structural signals as the engine's supervisory labels: golden-path membership, node betweenness centrality, forward-cascade reach, entropy-node status. Given identical input the supervisory signal is identical; LLM sampling at temperature > 0 was breaking the deterministic chain at the synth boundary.

Fix: Pin temperature=0.0 on both customer-facing narrative synths — landscape narrative (L1 corpus-position prose) and memo pitch (per-patent strategy memo pitch). Same input → same output is now the engine's guarantee for these two surfaces.

The provisional and continuation-memo synths (which use adaptive-thinking on Opus and have not surfaced this failure mode) are intentionally left at default sampling for now; they can be pinned in a follow-on pass if reproducibility audits surface the same gap there.

VERSION → 1.0.31.

v1.0.30 — 2026-05-15 — Domain-routed provisional title via CPC fingerprint (Consolidated Claim 5)

Per-domain title templates on convergence-delta bridges (provisional_synth.py)

Problem: The provisional synth had been stamping the same software-domain title — "SYSTEM AND METHOD FOR CLOSED-LOOP ROUTING WITH EFFECTIVENESS-DRIVEN ADAPTATION" — on every convergence-delta bridge candidate regardless of portfolio domain. CRISPR composition-of-matter bridges, wireless-protocol bridges, hardware bridges, media-processing bridges — all got the same title. Both Gemini and Perplexity flagged this as the loudest cross-domain failure mode in the 2026-05 critique loop: a CRISPR provisional titled "Closed-Loop Routing" is an instant credibility kill for a pharma reader.

Consolidated Supplemental (U.S. Provisional Application No. 64/043,294) Claim 5 already protects this: "extracting a topological fingerprint from a first concept graph constructed from a first domain corpus, wherein said fingerprint comprises abstract structural metrics independent of domain-specific entity records ... applying said topological fingerprint to a second concept graph constructed from a second, unrelated domain corpus to identify isomorphic structural patterns." The fingerprint primitive was present at the clustering layer; the title/abstract synth ignored it.

Fix: A static CPC-subclass → domain-key map covers seven domain buckets: biotech (C12N / C07K / A61K and adjacent), wireless (H04L / H04W / H04B), media/imaging (H04N / G06T / G06V), hardware devices (H01L / B25J / G09F), speech/audio (G10L / G10K), ML/AI software (G06N / G06F), data/business software (G06Q). The convergence-delta gap-type title is now routed per domain:

Domain Title template
biotech ENGINEERED COMPOSITION AND METHOD FOR {keyword}
wireless METHOD AND APPARATUS FOR {keyword} IN A WIRELESS NETWORK
hardware_devices APPARATUS AND METHOD FOR {keyword}
media_imaging METHOD AND SYSTEM FOR {keyword}
speech_audio METHOD AND SYSTEM FOR {keyword} IN AN AUDIO SIGNAL
ml_ai_software SYSTEM AND METHOD FOR {keyword}
data_business_software COMPUTER-IMPLEMENTED METHOD AND SYSTEM FOR {keyword}
default SYSTEM AND METHOD FOR {keyword}

The domain key is resolved by counting CPC-subclass matches across the user's portfolio (read from patents.json); on ties, priority biotech > wireless > hardware > media > speech > ml/ai > business resolves it. When patents.json is missing or no subclass matches, the domain key falls back to default — the domain-neutral framing, safe across any technology area and a strict improvement over the prior hardcoded software-only template. Silent-region and lpa-forward titles already worked across domains and are unchanged; only the convergence-delta software-bias is corrected.

Effect: a CRISPR portfolio (C12N / C12P / A61K) now produces "ENGINEERED COMPOSITION AND METHOD FOR {keyword}" — appropriate for biotech composition-of-matter claims navigating the Myriad/Alice §101 boundary. A wireless-protocol portfolio produces "METHOD AND APPARATUS FOR {keyword} IN A WIRELESS NETWORK". A media-processing portfolio produces "METHOD AND SYSTEM FOR {keyword}".

Validated locally on synthetic CPC inputs covering all seven domain bucket resolutions including empty input, mixed-domain priority tie-breaking, and unrecognized CPC codes. Against the archived v1.0.8 end-to-end run the domain helper extracts G06N / G06Q / G16H / G06F and correctly resolves to ml_ai_software.

VERSION → 1.0.30.

v1.0.29 — 2026-05-15 — Auto-Builder recursive graph mutation (first-cut, depth=1, default off)

First implementation of the recursive graph mutation mechanism claimed in the Consolidated Supplemental (U.S. Provisional Application No. 64/043,294, Claim 8). Until this release, the engine ran the cluster pass once at depth=0 — first-pass AgglomerativeClustering on canonical-element Jaccard / SBERT cosine, stop. Foundational and dense-anchor patents whose claim vocabulary is architecturally specific enough that first-pass embedding retrieval missed the surrounding existing art landed in singleton clusters and the engine correctly reported zero domain peers — but the patent claim explicitly allows for a deeper pass: "executing a targeted deep-traversal analysis at a configurable depth, wherein depth zero corresponds to no auto-builder execution and increasing depth corresponds to chasing newly-discovered gaps deeper into the lattice; writing newly-discovered edges, entropy gaps, and theoretical nodes resulting from said deep-traversal analyses back into the concept graph as persistent additions."

Recursive graph mutation (auto_builder.py new + domain_scan.py + render_arc.py)

Fix: New auto_builder.py module implements depth=1 second-order adjacency expansion on first-pass output. For each user filing that landed in a singleton cluster (an internal-only cluster — the user's filing with zero domain peers above the AgglomerativeClustering threshold), the auto-builder:

  1. Takes the user filing's top-K most-similar domain patents globally (K defaults to 8) — first-order seeds.
  2. For each first-order seed, takes its top-M most-similar domain patents globally (M defaults to 6) — second-order candidates via that seed.
  3. Filters second-order candidates to those above a configurable similarity floor (default 0.30) relative to the original user filing — the structural void-detection invariant that prevents noise patents (generic high-degree patents connected to everything) from surfacing.
  4. Filters out any candidate that was already a first-order seed (those are first-pass nearest, not second-order discoveries).
  5. Composite-scores by 0.7 × user_to_candidate_sim + 0.3 × seed_to_candidate_sim, dedupes by patent id, takes top-N (default 6).
  6. Writes the resulting list back into the cluster record as second_order_adjacencies keyed by user patent id — the "writing newly-discovered edges back into the concept graph as persistent additions" Claim 8 specifies.

The pass is purely structural over first-pass artifacts — it does not re-encode any text or invoke any external service. Compute cost is O(U × K × M) array lookups against the existing similarity matrix.

Integration in domain_scan.run_inline: the auto-builder hooks in after analyze_clusters produces the first-pass cluster structure and before find_nearest_domain runs. Failure of the module is non-fatal — pipeline proceeds with first-pass output unchanged.

Render surface in render_arc.py: when a singleton cluster carries second_order_adjacencies, the L1 adds an "Auto-builder · second-order adjacencies surfaced for {patent}" block alongside the existing solo-cluster bullet, listing each surfaced patent with similarity-to-user percentage and the first-order seed that bridged to it. The ORPHAN-entropy interpretation paragraph (v1.0.27) remains — it now describes the three possible readings even when second-order adjacencies surface, because the second-order pass is one channel of resolution, not the only one.

Default-off shipping discipline

The auto-builder is shipped default-off via a depth-controlling env var; depth=0 is the no-auto-builder condition per Claim 8's explicit language. When unset (or set to 0), the auto-builder is a complete no-op and production behavior is byte-identical to v1.0.28. The operator opts in by setting depth=1 when ready to enable the pass in production. Depth > 1 is reserved (the patent allows recursive application — "chasing newly-discovered gaps deeper into the lattice") but the first-cut clamps to 1 for safety until a future pass adds convergence-detection guards against combinatorial blow-up.

What this addresses

The "Transformer 10,452,978 / Broad CRISPR 8,697,359 / multi-modal ranking 10,642,887 / PageRank 6,285,999 zero-neighbor" failure mode that surfaces on any portfolio containing a foundational anchor whose claim vocabulary diverges from the corpus's mature naming conventions. The same first-pass retrieval still misses on those anchors — but the depth=1 expansion follows the convergence gradient through nearer neighbors to surface adjacencies the first pass couldn't reach. CRISPR, Transformer, PageRank are test cases that un-veiled the substrate-wide gap; the auto-builder is the mechanism the patent already protects, now exercised.

Validated locally on synthetic similarity matrices against the depth=0 no-op, the first-order seed selection, the second-order candidate filtering, and the top-N composite ranking. Render-side integration smoke against archived v1.0.8 artifacts with a hand-injected second_order_adjacencies field confirms the L1 render block surfaces correctly. End-to-end live validation deferred to first production opt-in — gated by the env var so any regression is reversible in seconds.

VERSION → 1.0.29.

v1.0.28 — 2026-05-15 — Granted-vs-application reframing on the kill callout (Consolidated Claim 12)

Corpus-relative confidence threshold on kill callout (render_arc.py)

Problem: The kill callout previously used identical language whether the user's filing in the high-similarity pairing was a granted patent or a pending application. For a granted filing that framing is structurally wrong: the granted claims are unaffected — they are the issued filing — and the engine's prior-art density signal applies only to future continuation strategy, not to a prosecution decision the user has not made.

Consolidated Supplemental (U.S. Provisional Application No. 64/043,294) Claim 12 — Corpus-Relative Confidence Thresholds — names this: a granted patent and a pending application sit in different confidence corpora for the Don't-Pursue framing.

Fix: Detect which corpus the user's filing belongs to and route the kill-callout copy:

Heuristic boundary noted: the granted-vs-pending distinction is inferred from patent_id shape because USPTO kind codes (B1/B2 = granted; A1/A2 = published application) are stripped during the engine's patent_id normalization, so the upstream signal is unavailable at the kill-callout layer. The 6–8 digit / not-year-prefixed rule covers the vast majority of granted utility patents in the current corpus while not false-positive-ing on pre-grant publications.

VERSION → 1.0.28.

v1.0.27 — 2026-05-15 — Constitutional Runtime Governance + Scope Honesty render pass

Two engine-substance principles surfaced into the L1 artifact's render layer. No mechanism changes — what landed here is the engine more fully expressing what the substrate already protects.

Constitutional Runtime Governance (Tesseract Supplemental, App. No. 64/045,185 Claim 11) — render_arc.py

Problem: The Tesseract Composition Supplemental's Constitutional Runtime Governance claim binds the engine to an invariant: outputs are reports of potentials, never prescriptions directed at individuals. Several display strings in prior releases read as prescriptions: "Already covered" (verdict); "Don't pursue — face near-certain prior-art rejection at the USPTO" (prosecution authority claim); "Expansion Value" (implied commercial expansion certainty).

Fix: Reshape into reportive framing:

Scope Honesty render pass — render_arc.py, continuation_memo_synth.py

Problem: When the engine produces no candidates, the prior render said "the engine identified 0 proposed patents" — read by first-time landscape readers as engine-didn't-work rather than as a structural signal. Per the Consolidated Supplemental's Structural Void Detection (U.S. Provisional Application No. 64/043,294, Claim 1), absence of a clearable void IS an outcome — the engine ran the convergence-gradient scan and found no uninstantiated topological centers meeting the corpus-relative void-confidence threshold.

Fix: Surface absence as a reading rather than as silence:

These render changes do not alter what the engine computes. They make the artifact carry the structural truth the engine already produces.

VERSION → 1.0.27.

v1.0.26 — 2026-05-15 — AI substrate retry + no-silent-degradation posture · Sonnet 4.6 bump

Two engine-substance changes paired in this release.

AI substrate resilience (claude_retry.py new)

The engine now wraps every Anthropic Claude API call through call_with_retry() — exponential-backoff retry on the standard transient-failure status codes (408, 425, 429, 500, 502, 503, 504, 529). Schedule: 0s → 2s → 5s → 12s → 30s across 5 attempts. Covers the Anthropic 529 OverloadedError class that produced the 2026-05-14 elevated-error cluster (≈99.07% uptime over the trailing 60 days).

No-silent-degradation posture (locked). When retries exhaust, the engine fails clean with an honest "AI substrate temporarily unavailable" message and logs a service_request for Admin Layer visibility. The engine never falls back to a smaller Claude model, a heuristic shortcut, or a partial output to mask the outage. The artifact a customer receives IS the engine they bought, not a quieter version of it. Customer run-counter is refunded on dependency-side failures (Anthropic outage, GCS rate-limit, BigQuery timeout) so customers do not pay for runs killed by upstream infrastructure.

This is an architectural commitment, not a marketing claim. It is the reason a Tier 1 institutional buyer can audit the trail in this log and trust the engine output: when the substrate is degraded, the engine declines work rather than ship degraded analysis.

Sonnet 4.5 → Sonnet 4.6 (claim-rewrite preprocessor)

Per Anthropic's 2026-05-14 deprecation notice, the claim_rewrite_preprocessor.py model default bumped from claude-sonnet-4-5 to claude-sonnet-4-6. Free quality lift at the same price point; 4-5 remains supported for callers that pin the older model. Affects only the long-tail vocabulary path — the deterministic seed-ontology pass (v1.0.9) still handles the common cases without an API call.

v1.0.10 — 2026-05-14 — HMAC-SHA256 identifier hashing primitive

Foundational privacy infrastructure backing the engine's data-handling posture for Tier 0 and Tier 1 customers. Every identifier that would leave a portfolio run as learning signal — patent IDs, attorney names, firm names, account IDs — must route through a single hashing module before any persistence or transmission.

What landed

identifier_hashing.py (new): HMAC-SHA256 primitive that pulls a 256-bit key from GCP Secret Manager (dcfn-patents-hmac-key-{YYYY-QN}), keyed by current quarter. Identifier kind is mixed into the HMAC input so a raw value hashed as a patent ID produces a different digest than the same value hashed as a firm name — closes a cross-kind correlation gap.

Fail-closed posture. If the current-quarter key cannot be loaded from Secret Manager, the module raises IdentifierHashingUnavailable rather than silently passing through raw identifiers. The privacy posture is not allowed to degrade on infrastructure failure.

Quarterly rotation. Keys are rotated at quarter boundaries via a Secret Manager versioning model. Previous quarters' keys are retained 90 days then deleted — long enough for in-flight signal-correlation, short enough that the "we don't retain key history" posture holds at the 90-day horizon.

Process-local 1-hour TTL cache. Rotation events propagate to running instances within an hour without a redeploy.

Why this lands now even though no learning-signal emission is active yet

The public Tier 0 + Tier 1 data-handling notice describes what happens to identifiers when extracted signal leaves a run. Shipping the public notice without the primitive in place would mean the description doesn't match what the engine could do — even if no emission paths are wired today. The primitive now exists as the only path forward emission code can take.

Customer-visible impact

None directly from the hashing primitive. Establishes the technical foundation the Tier 0 + Tier 1 data-handling notice describes. When cross-portfolio learning extraction ships in a future release, every identifier will route through this module before any retention.

Artifact footer consistency (paired)

Restored per-page running NV business-license stamp on landscape briefings to match the continuation-memo pattern that institutional buyers prefer. Every page now shows the same paired bookend — "Generated by DCFN - Patents · …" at the top, "NV Business License · Built on the LEF Ai Engine · 10 U.S. Patents Pending" at the bottom-left, "Page X of Y" at the bottom-right — in matching font and hue. Previously the landscape only stamped the NV line on page 1; later pages had an empty bottom-left margin. Customers print or re-share extracts of single pages and expect the trust signal to travel with the page.

v1.0.9 — 2026-05-14 — Fix 1 full first-cut (curated canonical ontology + deterministic preprocessor)

Completes the 4 Gemini-convergent fixes' first-cut shipping. Fix 1 (Unified Taxonomy Normalization) full first-cut adds a curated seed ontology of ~52 idiosyncratic → canonical USPTO vocabulary mappings + a deterministic preprocessor that runs BEFORE the Claude API rewrite from Fix 1 simplified (v1.0.1).

Architecture

canonical_ontology.py (new): seed mappings of partner-idiosyncratic patent vocabulary to USPTO canonical equivalents. Covers: - LEF / DCFN portfolio mechanism terms (topological velocity → rate of change in topology; kinetic encroachment → rate of convergence; qualia entanglement → qualitative correlation; etc.) - Common AI/ML mechanism vocabulary observed in production-run Claude rewrites - Diagnostic / educational vocabulary (LEF Ed lineage) - Generic patent-language standardizations (made up of → comprising; characterised by → wherein; etc.) - Verb-form variant canonicalization (is comprised of → comprises)

Mappings are case-insensitive on lookup; replacements preserve the original text's capitalization pattern. Regex pre-compiled with longest-phrase-first ordering for greedy matching.

claim_rewrite_preprocessor.py updated: deterministic preprocessor runs first; if any seed mapping fires, return immediately (zero API cost). Only invokes Claude API when the deterministic pass produced zero substitutions — Claude handles long-tail vocabulary not yet in the ontology.

Impact

Evolution path

Seed ontology is intended to grow over time. The Data Readiness Assessment module (planned LEF Ai Engine VM work) will eventually feed observed canonicalization opportunities back automatically. Until then, manual growth: when a Claude rewrite produces the same canonicalization repeatedly, promote it into the ontology to avoid the API call.

This is the FIRST-CUT of Fix 1 full. The complete Fix 1 (structural template matching at extraction time, full canonical-element classifier replacing verb-object compounds) remains multi-week post-funding work per memory/ROADMAP_FUTURES.md.

VERSION → 1.0.9.

v1.0.8 — 2026-05-14 — Synth integration for Fix 4 voids + memo_pitch_synth missing-data fix

Two follow-on fixes after v1.0.7's Fix 2 + Fix 4 first-cuts. Both surface previously-computed data into customer-facing outputs.

Synth integration: structural voids surface in provisional drafts + continuation memos

Problem (v1.0.7): Fix 4 first-cut added structural_voids + structural_void_score to deep_run.py output, but neither provisional_synth.py nor continuation_memo_synth.py read those fields. The topological-gap signal was computed but never reached the customer-facing prose.

Fix: Added _format_structural_voids() formatter in provisional_synth.py that appends void records to the differentiation_seeds prompt slot when present. Same pattern in continuation_memo_synth.py. The LLM now sees structural-void context and can weave specific differentiation language targeting the lower half of each void's similarity band — even when the candidate is PRIOR-ART-CONVERGENT, structural voids surface as actionable filing angles.

Touches no prompt template fields directly; the void info rides into the existing differentiation_seeds placeholder via formatter append. Backward-compatible: when structural_voids is empty, output is identical to v1.0.7.

memo_pitch_synth missing-data fix

Problem: memo_pitch_synth.py skipped every patent with "missing data" on v1.0.7 and earlier. Root cause: neighbor IDs in domain_analysis.json come from the CACHED static corpus (data/domain_corpus_embeddings.npy — older 2025-era patents) while neighbor_lookup was built from the SESSION-FRESH domain_patents.json (2026-era patents from session_corpus_pull). Zero overlap → every patent skipped.

Fix: domain_scan.py now inlines nearest_abstract, nearest_key_claim, and nearest_cpc_codes directly onto each nearest_competitors record. memo_pitch_synth.py falls back to those inline fields when the session-corpus lookup misses. Synth still functions when the corpus mismatch occurs (which is now — until the cached embedding corpus is refreshed).

VERSION → 1.0.8.

v1.0.7 — 2026-05-14 — Fix 2 first-cut (sub-clustering) + Fix 4 first-cut (Structural Void Detection) + semantic_bridges restored

Three engine changes addressing the cascading bugs surfaced during Z's 2026-05-14 local-run validation of v1.0.6. v1.0.6 fixed the single-assignee invariant for unfiled-mode portfolios; this commit completes the multi-domain-portfolio path so the engine surfaces real proposed patents instead of refusing entirely.

Fix 2 first-cut — Canonical-Element Sub-Clustering for silent-region candidates (hypothesis_engine.py)

Problem: When a silent-region cluster contains patents that don't share canonical mechanism elements pairwise, the canonical_element_overlap invariant correctly suppressed the cluster as "Frankenstein." But the engine had no fallback — it just refused. Result: multi-domain portfolios (any portfolio that spans distinct mechanism families) produced zero proposed patents.

Fix: Added _decompose_cluster_by_canonical_overlap — when the canonical-element invariant rejects a silent-region cluster, decompose into maximal-clique sub-clusters in the canonical-element overlap graph. Each viable sub-cluster passes the invariant by construction and emits as its own silent-region candidate.

Algorithm: 1. Build pairwise canonical-element overlap graph (nodes = patents in cluster, edges = pairs sharing ≥1 element) 2. Use networkx.find_cliques to enumerate all maximal cliques 3. Filter cliques to size ≥ MIN_CLUSTER_SIZE 4. Emit each clique as a separate candidate with origin-context narrative

Validated locally on Z's 10-patent portfolio: where previous v1.0.6 produced 0 candidates (one 10-patent silent-region cluster suppressed), v1.0.7 produces 3 coherent sub-clusters (6, 5, 5 patents) by mechanism family.

This is the narrow slice of Bundle B v1.0 needed for Tier 1 market-readiness. Full Bundle B v1.0 (canonical-element graph as PRIMARY clustering substrate replacing flat SBERT) remains multi-week post-funding work per memory/ROADMAP_FUTURES.md.

Fix 4 first-cut — Structural Void Detection (deep_run.py)

Problem: Existing expansion_value formula was single-dimensional (count of integration_seeds × 2 + count of differentiation_seeds). Didn't surface topological gaps in the prior-art neighborhood where the engine could recommend differentiation.

Fix: Added _compute_structural_voids() — detects significant gaps in the sorted prior-art similarity distribution using relative-gap detection. A gap is significant if it exceeds 3× the median between-neighbor gap (adapts to distribution density; CPC-filtered corpora are naturally tight with ~0.005 typical gaps).

Each detected void surfaces with location band (lower/upper similarity), gap magnitude, position in distribution, and interpretation narrative for the synth.

Augments expansion_value with void-derived score (+ int(void_score * 10) where void_score is total gap magnitude × 2.0, capped at 2.0).

Wider sampling: deep_prior_art now retains top 100 neighbors for void analysis (synth still uses top 20 — unchanged for backward compat). The dense top-20 typically has sub-0.05 gaps; real structural voids live in the longer tail.

Validated locally on Z's candidate-0: 3 structural voids surfaced in the prior-art neighborhood, turning a "PRIOR-ART-CONVERGENT" classification into actionable differentiation guidance.

Full Fix 4 (Portfolio Topology Extensions edge-convergence math, second-hop edges, convergence centers) remains multi-week post-funding work.

semantic_bridges.py restored to L1_STEPS

semantic_bridges.py (adds SIMILAR_TO cross-patent claim edges via SBERT cosine ≥ 0.55) was missing from BOTH app.py:L1_STEPS and local_run.py:L1_STEPS. With zero SIMILAR_TO edges, Signal C (convergence-delta candidates) was permanently dead and hypothesis_engine fell back to treating ALL claims as white-space (every claim has zero "cousins"). Restored to both pipelines with --data-dir parameterization so it works in per-run scratch dirs.

VERSION → 1.0.7.

Known follow-ups (filed for next session): - memo_pitch_synth skipping all patents with "missing data" — neighbor_lookup ID format mismatch (separate bug, not Fix 2/4 related) - RuntimeWarning: divide by zero in matmul warnings during prior_art_check + deep_run — investigated, can't reproduce in direct encode test; possibly intermittent

v1.0.6 — 2026-05-14 — Fix zero-proposed-patents on unfiled-mode portfolios (synthetic uniform assignee)

Bug: unfiled-mode runs (where users upload PDFs of unfiled inventions as a portfolio) were producing zero proposed patents because the silent-region cluster invariant _invariant_single_assignee in hypothesis_engine.py was suppressing every silent-region candidate. Confirmed live via Z's 2026-05-14 test #1 — 10-patent unfiled batch surfaced a silent-region cluster of all 10 records, then got suppressed with "Cross-assignee continuation is not legally viable; cannot merge claims across distinct corporate assignees" — but all 10 records were Z's own portfolio.

Root cause: synthesize_unfiled_record.py never set an assignee field on the synthesized record, so all unfiled records flowed downstream with assignee="". The invariant treats unknown ("") as "distinct for safety" — correct for filed-mode (missing assignee = unknown corporate entity), wrong for unfiled-mode (user explicitly uploaded a unified portfolio under a single session).

Fix: synthesize_unfiled_record.py now stamps a synthetic uniform assignee UNFILED-PORTFOLIO-{short_id} on every record in the same session. All records share the same string → invariant sees single-assignee → passes cleanly. Cross-session safety preserved (different sessions get different short_ids).

Downstream impact: unfiled-mode portfolios that previously hit "zero proposed patents" on L1 (and zero provisionals offered on L2) should now produce silent-region candidates → proposed patents → provisional drafts. Resolves one of the four hypotheses in memory/ROADMAP_FUTURES.md's Zero-Proposed-Patents Pattern entry (hypothesis (b): "module-conflict invariant is suppressing more than intended").

Validated locally (no production engine fire) via focused unit test against _invariant_single_assignee: synthetic-uniform-assignee case passes, empty-string case still suppresses (pre-fix bug reproduces), cross-assignee filed-mode case still suppresses (legal posture preserved).

Not yet addressed — separate investigation needed: filed-mode runs of user's own filings may still hit zero-proposed-patents if BigQuery's assignee_harmonized field returns different string variants for the same human/entity across multiple filings. Z's 2026-05-14 test #2 (6 filed US patents, 5 continuation memos, ZERO provisionals offered) likely hit this filed-mode variant of the same problem.

v1.0.1 — 2026-05-13 — Fix 1 simplified (canonical-vocab preprocessor) + Fix 3 basic (entropy-triggered recursive branching)

Two of the four Gemini-convergent engine fixes, each mapping to a filed LEF patent claim

External 2026-05-13 critique from Gemini converged on four architectural fixes the engine needs. Each fix lined up against a claim already in LEF's filed patent portfolio — implementation is reduction-to-practice of the claim. v1.0.1 ships the two whose simplified versions are bounded enough to land tonight; Fix 2 (DAG Traversal + Provenance Gravity — Bundle B v1.0) and Fix 4 (Structural Void Detection — edge-convergence math) are multi-week roadmap entries captured in memory/ROADMAP_FUTURES.md.

Fix 1 (simplified) — Canonical-vocab preprocessor. Maps to CTE Diagnostic Engine Phase 1 (Data Normalization).

New module claim_rewrite_preprocessor.py exposes rewrite_to_canonical(text). The preprocessor calls Claude Sonnet with a terminology-only system prompt that rewrites idiosyncratic noun phrases ("topological velocity", "kinetic-encroachment", etc.) to their nearest USPTO-canonical terminology before embedding. The pipeline integration point is prior_art_check._candidate_reference_text() — each candidate's seed-claim text passes through the preprocessor before being compared against the pre-encoded corpus. Failure modes (missing API key, network error, dramatically shortened rewrite) fall back to the original text so historical pipeline behavior is preserved on degraded paths. Process-local cache keyed by SHA-256 of input text.

Why: sentence-transformers mean-pool token embeddings, so idiosyncratic inventor vocabulary produces token embeddings that don't align with the corpus's USPTO terminology even when the underlying mechanism is identical. Normalizing terminology before embedding pulls the similarity comparison into the same lexical neighborhood as the corpus. Full version (multi-week roadmap): curated canonical ontology + structural template matching, replacing the Claude-rewrite hack with deterministic mapping.

Fix 3 (basic) — Entropy-triggered recursive branching on zero-neighbor silent-region clusters. Maps to CTE Layer 3 Entropy Navigator + QECO perturbation claims.

In hypothesis_engine.py, the white-space union-find that produces silent-region clusters previously returned zero clusters silently when no cross-patent pair met SILENT_CLUSTER_THRESHOLD (0.50). v1.0.1 wraps the union-find in a retry loop: on zero clusters, widen the threshold by SILENT_THRESHOLD_RETRY_STEP (0.05) and retry. Up to SILENT_RETRY_MAX (3) retries, with a hard floor at SILENT_THRESHOLD_FLOOR (0.30) below which "silent" is no longer a meaningful qualifier. Each retry emits a structured log line. Exhaustion emits an explicit Silent-region exhausted recursive branching log line and proceeds with zero candidates (the historical behavior, now explicit instead of silent).

Why: the prior "zero candidates returned silently" behavior was a structural-blindness failure mode — the engine had no way to distinguish "the corpus has no silent region" from "my calibrated threshold is too strict for this corpus." Entropy-triggered widening + bounded retry gives the engine recursive room to find structural overlap that exists at slightly looser similarity bands while preserving the hard floor that prevents pulling in noise. Full version (multi-week roadmap): LoRA self-update path that seeds successful-retry telemetry back to LEF Ai Engine for cross-instance parameter refinement.

Files touched: - claim_rewrite_preprocessor.py (new) — canonical-vocab rewriter with cache + graceful fallback. - prior_art_check.py — _candidate_reference_text() now passes each seed-claim text through rewrite_to_canonical. - hypothesis_engine.py — silent-cluster union-find refactored into _silent_clusters_at_threshold helper; entropy-triggered retry loop added with new thresholds SILENT_THRESHOLD_RETRY_STEP, SILENT_RETRY_MAX, SILENT_THRESHOLD_FLOOR. - attribution.py — VERSION → 1.0.1.

JDA / IP angle: each fix shipped becomes documented reduction-to-practice of the corresponding patent claim. Convergence between an external critic (Gemini) and already-filed LEF claims is itself a marketing artifact for JDA pitches — the patents-as-architectural-North-Star thesis is validating itself.

v0.14.45 — 2026-05-13 — Tier-aware portfolio cap (Tier 0=7, Tier 1=10, Tier 2=unlimited)

Per-tier portfolio size cap

Moved the hardcoded 7-patent portfolio limit out of app.py intake checks + client-side JS and into tier_config.TIER_CONFIGS[tier]["max_patents_per_portfolio"]:

Server-side intake (both patents-mode and unfiled-upload branches) reads the cap from tier_config.resolve_tier(request=request) at request time. Client-side JS reads the value from {{ portfolio_cap }} rendered by the / route handler. Visible copy on /pricing + / hero + /account upgrade pitch updated.

Cost math: going 7 → 10 on Tier 1 adds ~$0.50-1.50 Anthropic API per run (synth scales linearly with N). Against $180-$450 Tier 1 revenue per run, margin holds strongly.

v0.14.43 — 2026-05-13 — Meta-tensor crash fix on GPU-attached Cloud Run

Explicit device selection at SentenceTransformer init

After L4 GPU was attached to the production service on 2026-05-13, Tier 1 runs began crashing with Cannot copy out of meta tensor; no data!. Root cause: recent torch + sentence-transformers can initialize the model on the "meta" device (lazy weight load), then downstream code's implicit .to(device) fails.

_l1_shared.get_sbert_model() now passes device= explicitly (cuda if torch.cuda.is_available() else cpu), forcing eager weight load on the target device and bypassing the meta-tensor path. deep_run._load_sbert() and semantic_bridges also rerouted through the shared loader so they inherit the fix.

v0.14.39 — 2026-05-13 — mpnet-base-v2 pre-baked in Docker image

Eliminate first-request HuggingFace download stall

The Dockerfile's pre-download step still loaded all-MiniLM-L6-v2 (legacy from before v0.14.35). After the encoder swap, runtime calls to SentenceTransformer("all-mpnet-base-v2") forced a fresh ~420 MB download from huggingface.co on every cold-start instance — observed as multi-minute hangs on first request after deploys. Pre-download now bakes mpnet into the image cache; first-request latency drops to model-load only (~5-10s).

v0.14.35 — 2026-05-13 — Encoder swap MiniLM-L6-v2 → mpnet-base-v2 (Gemini falsification)

Substrate-grade encoder upgrade

Gemini's 2026-05-12 patent-artifacts critique flagged all-MiniLM-L6-v2 (6 layers, 384-dim, 22M params) as too shallow for patent-claim semantic retrieval — predicted recall deficiency and false-negative zero-neighbor outcomes.

Falsification A/B run (scripts/encoder_eval.py, 5K-corpus × 7 LEF targets) confirmed:

Engine swapped: - _l1_shared.SBERT_MODEL_NAME → "all-mpnet-base-v2" (12 layers, 768-dim, 110M params) - hypothesis_engine.py, prior_art_check.py, domain_scan.py, semantic_bridges.py, deep_run.py, embedding_store.py all re-pointed - attribution.py methods-block updated to cite mpnet + the falsification context - data/domain_corpus_embeddings.npy regenerated at 768-dim via scripts/regen_corpus_embeddings.py

Encoder swap raises Tier 1 customer recall ceiling. Bundle B v1.0 (canonical claim-element graph) remains the architectural next step for the lexical-moat / function-equivalence ceiling that no sentence-transformer alone bridges.

v0.13.47 — 2026-05-05

Engine intake: optional supplied-claims overlay for patents mode

Patents-mode users can now optionally paste their actual claim text alongside the patent numbers. The engine overlays it on top of what BigQuery returns for matching patents. Addresses four real cases:

  1. BigQuery has incomplete or stale claim text for a recently-granted patent
  2. User has amended claims (Office Action response) that haven't propagated to BQ
  3. User wants the engine to read EXACT current claim language for a scope test
  4. One of the user's "patents" is a provisional BQ doesn't carry at all

Format — patent number wrapped in === / --- / ## markers, then numbered claims:

===PATENT 9,373,038===
1. A computer-implemented method comprising: ...
2. The method of claim 1, wherein ...

===PATENT 8,402,033===
1. A system comprising: ...

Header variants accepted (case-insensitive). Patent number can be any format the existing intake accepts (9,373,038 / US-9373038-B2 / 16/123,456); normalize_input() handles them uniformly.

Implementation: - fetch_user_patents.py adds parse_supplied_claims() (parses the user's pasted block into a {normalized_number: claim_text} dict), _patent_matches_supplied_key() (matches against publication / application / patent_id), and overlay_supplied_claims() (overlays text + re-parses claims[] using the existing parse_claims_text helper). Records get claim_format: "user_supplied" to distinguish from BQ-sourced claims downstream. New --supplied-claims-json CLI flag. - app.py adds patents_supplied_claims: str = Form("") to /analyze. Parses on submit, stores on the intake dict (so it survives session create + carries to the L1 worker). At fetch step, writes the dict to session_data/supplied_claims.json and passes the path to the subprocess. - Same TOS §5.1 auto-delete contract as unfiled-mode uploads — the user-pasted file is deleted from disk after the run completes. Overlaid text inside patents.json is preserved (it's part of the engine's structured corpus the downstream pipeline already consumed). - Frontend: optional textarea below the patent-numbers field with ? help button + modal explaining when + how to use it. Submits via the same form as the patent numbers (no separate API call).

Caps: no explicit per-claim length cap; the existing 60K total-chars-per-form-submit guardrail bounds runaway input.

What this does NOT do: does not add patents to a run that aren't in the patent_numbers field. The overlay matches against BQ-fetched records by number; if the user supplies claims for a patent BQ didn't return, a warning fires (supplied_unmatched) but the run continues with the BQ records that did match. Adding fully-user-described patents to a patents-mode run is a separate intake mode (unfiled-mode handles that path).

v0.13.46 — 2026-05-05

Engine intake: restored .docx / .pdf upload variant for unfiled mode

Tier 1 attorneys evaluating the engine on Firm Pool walks have drafted .docx provisionals in hand — forcing them to re-prose 7 provisionals into a textarea kills the demo. Restored the upload path as a parallel option alongside the paste textarea.

Two sub-tabs inside the unfiled panel: - Paste description (existing) — for inventors with idea-in-flight - Upload draft (.docx / .pdf) (NEW) — for portfolios with drafted provisionals

Shape: - New intake_mode = "unfiled_upload" on POST /analyze alongside existing "patents" and "unfiled" - Multi-file upload (cap 7, 5 MB per file, .docx + .pdf only) - _extract_docx_text() uses python-docx (already a dep) — extracts paragraphs + table cells (provisional drafts often carry claim-comparison tables with real signal) - _extract_pdf_text() uses pypdf (new dep — pure-Python, no system deps; added to requirements.txt) - Extracted text concatenated with the existing ---PATENT--- multi-invention sentinel and handed to the same downstream pipeline as paste - Intake dict shape is identical to paste (mode='unfiled', unfiled_idea_text=<combined>) — TOS §5.1 auto-delete carve-out applies without any other change - Frontend: form gets enctype="multipart/form-data"; sub-tabs swap the hidden intake_mode value between unfiled and unfiled_upload; selected files surface with name + size

Caps: 7 files per run, 5 MB per file, 60K combined extracted chars (same total as paste).

Trade-secret warning: the existing red banner above the unfiled panel applies to BOTH sub-tabs. Engine path is identical post-ingest; risk profile is the same as paste mode.

Why it doesn't replace paste:

Submitter state Right tool
Idea-in-flight, no draft yet Paste textarea
Drafted .docx / .pdf provisionals Upload (no rewrite)
Privacy-conscious (no file metadata to server) Paste (or Tier 2)
Quick iteration / try a different framing Paste

v0.13.45 — 2026-05-04

Engine + platform: 5 deferred items shipped together

Five items pulled off the deferred list, each independently small but together representing real engine-quality and customer-experience improvements.

1. Nearest-competitor dedup (domain_scan.find_nearest_domain). When two of the user's internal patents share the same closest external neighbor, the previous output listed that neighbor twice across the per-internal-patent entries. Downstream landscape narrative rendered top-3 nearest competitors and showed the same patent number duplicated when two of the user's filings shared a closest neighbor — false sense of crowdedness. Now deduped: the same external neighbor appears once with all internal patents that share it listed under your_patents[]. Backward-compat — old your_patent / your_title single-patent fields still populated with the strongest pairing.

2. Engine /analyze tier-from-JWT bug (_resolve_user_and_tier). The JWT cookie carries a tier claim set at signup BEFORE payment — so a user who immediately tries /analyze after upgrading sees the engine running at their old tier (lower caps, reduced engine depth). Fixed by adding a Firestore subscription lookup in _resolve_user_and_tier, mirroring the v0.13.22 fix for /landing. Costs one Firestore read per authenticated /analyze but the alternative (running paid users at the wrong tier) is worse.

3. Per-member usage breakdown on /firm/manage. _tier1_firm_pool_record() now optionally accepts actor_user_id and bumps a per-member subcounter (by_user.{user_id}) on the firm usage doc. record_run() threads the actor through. /firm/manage template renders a "Runs (period)" column on the member table so admins see who in the firm is actually consuming the pool, not just the firm-level total.

4. L2 timeout / poll-failure root cause fix (_check_session_access + templates/generating.html). Two-layer fix: - _check_session_access previously called _current_user() which makes a Firestore round-trip. When Firestore blipped (Cloud Run cold start, brief network hiccup), it returned None, which was misread as "user not authenticated" → 403 bounce. Fixed by decoding the JWT payload directly for ownership check (uid is signed in the JWT, no Firestore needed). Firestore is only called for firm-pool membership checks now. - generating.html poller previously surfaced failed fetches as "Recent Download History" entries in Chrome (browser misclassifies same-URL JSON XHR failures as failed downloads). Fixed by cache-busting the URL with a timestamp param + adding silent retry-with-backoff on transient failures, only showing user-visible error after 3+ consecutive failures.

5. local_run.py --l2 flag. Charter §15 local pipeline runner now optionally chains L2 (deep_run + provisional_synth or continuation_memo_synth) onto the L1 output. Use cases: portfolio-strategy runs where Z wants the unifying provisional draft for a silent-region candidate without going through the customer-facing /layer2 flow on production. Single command, one scratch dir, no GCS / Stripe / customer-state pollution.

# Trigger L2 on the engine's top silent-region candidate (umbrella claim):
python3 local_run.py --upload ~/Desktop/Runs/10-patents-richer-input.txt --l2 candidate=0

v0.13.44 — 2026-05-04

Tier 0 sampler-scale + Tier 2 add-on price nudges + Licensing Guide bridge

Three customer-facing changes responding to 2026-05-04 external feedback (Perplexity analysis on Run 3) + Z's pushback on Tier 0 generosity:

1. Tier 0 capped at 2 Layer 2 selections per session. Previously: unlimited L2 deliverables for $385 / 3-day window. Risk surfaced by Z: $7K/yr Tier 1 attorneys see Tier 0 customers getting the same deliverable suite for 18× less, conclude DCFN-Patents is positioned as a consumer tool, and walk. Constraining Tier 0 to "sampler scale" (2 L2 artifacts per session, any combination of provisional drafts + Continuation Strategy Memos) protects Tier 1 perception. Institutional evaluators wanting full-depth demos route through /contact-sales to the Licensing Guide path (Step 1 NDA → Step 2 Intent Letter → Step 3 First Call), not Tier 0.

Implementation: tier_config.TIER_CONFIGS["tier_0"]["max_l2_selections"] = 2. Tier 1 + Tier 2 set to None (no cap). Server-side enforcement in app.py /layer2/{session_id}/select returns 400 with clear "Tier 1 unlocks the full deliverable suite" message when exceeded. UI surfaces the cap on the L2 selection page and the landing-page L2 description.

2. Tier 2 add-on price nudges. Engine Bridge: From $50K → From $60K. Strategic Run: $65K → $85K. Both reflect actual delivered value better; previous prices reverse-signaled (M&A buyers expect serious capability = serious price). Public stickers updated; existing/early-adopter pricing honored on case-by-case basis (sales discretion).

3. Bridge from pricing page to Licensing Guide. New "Beyond End-User Access" section on /pricing directs institutional inquiries (embed, resell, license, bespoke runs) to a dedicated /contact-sales?inquiry=licensing flow → LEF Licensing Guide path. Closes the gap where customers wanting Routes 1-6 (non-exclusive field, exclusive field, DCFN product, API/module, Strategic Run, Engine Bridge output) had no clear path from the customer pricing surface.

Files: tier_config.py (cap definition), app.py (cap enforcement + new "licensing" inquiry label), templates/index.html (L2 description), templates/pricing.html (Tier 0 description, price nudges, Licensing Guide bridge), templates/layer2.html (cap surfaced in UI).

v0.13.43 — 2026-05-04

Engine: domain-coherence fit-confidence (cluster-level honesty)

Surfaced 2026-05-04 by Z's 8-portfolio re-run on v0.13.42. The engine clustered the user's Tesseract Composition filing into a cluster labeled "Multi-page demo and website section editing tools" because the Tesseract description used structural words ("page", "section", "demo", "faces", "sides") that SBERT matched against website-builder tool patents. The cluster was real (the embedding distance was within threshold), but the substantive fit was weak — overloaded vocabulary, not subject-matter overlap. External validation: Perplexity flagged the same pattern on a different cluster ("computational diagnostic systems for automated medical claim and fault analysis" pulling the user's diagnostic core toward medical-device art units).

This release adds per-internal-patent fit-confidence scoring against each cluster's domain centroid:

  1. domain_scan.analyze_clusters() now accepts the SBERT embedding matrix emb and computes, for each internal patent in a cluster, the cosine similarity between the patent's embedding and the centroid of the cluster's domain members (NOT all members — the internal patent's own embedding is excluded so the comparison is honest). Below WEAK_FIT_THRESHOLD = 0.45 (in-domain pairs typically land 0.55+), the patent's entry in your_patents[] gets weak_fit: true, fit_score, and a weak_fit_reason string. A cluster-level has_weak_fit flag is derived for downstream renderers.

  2. render_arc.build_landscape_html() surfaces the flag as a visible "⚠ Low confidence fit" badge + amber callout note on cluster cards where any internal patent is flagged. Charter §21 — engine shows its work, doesn't hide low-confidence matches. Customer sees: the engine surfaced the cluster, AND the engine's own confidence on the match.

  3. landscape_narrative_synth._build_covered_block() passes the weak-fit flag into the LLM context. The narrative can describe weak-fit clusters in plain language ("exploratory, not a real adjacency") rather than as a confident finding.

Pattern-level fix, not just a Tesseract patch. The same flag fires anywhere the engine clusters on overloaded vocabulary — the medical art-unit case Perplexity flagged would surface the same way once the threshold catches it.

Threshold (0.45) is empirically tuned. Will iterate on Z's 8-portfolio re-run: verify Tesseract gets flagged, verify legitimate clusters (Computational diagnostic, Distributed ML, Causal inference, Population-scale longitudinal) don't get false-positive flags. If false positives → raise. If misses → lower.

Backward compat: weak_fit / fit_score / weak_fit_reason are new optional fields on your_patents[] entries in domain_analysis.json. Downstream code that doesn't read them keeps working.

v0.13.42 — 2026-05-04

L1 PDF: cover page + License Addendum §2.1 attribution footer

Two L1 PDF improvements addressing customer-facing surface concerns:

  1. Cover page. The L1 PDF's first page is now title + scan scope + brand stack only — body content (The landscape, cluster grid, Layer-2 deep-run callout, proposed patents) starts on page 2. Privacy benefit: when the PDF sits on someone's desk, the cover reveals nothing about portfolio specifics, cluster positioning, or proposed filings. Implemented via header { page-break-after: always } inside the existing @media print block in render_arc.py. Single CSS rule, no structural change.

  2. License Addendum §2.1 attribution footer. The L1 PDF previously carried only "Page N of M" in the @page footer. The Bidirectional Brand Display License Addendum (effective 2026-05-01) requires every output artifact to carry the canonical Generated by / Powered by [load-bearing patent app numbers] / Part of the N-patent LEF Ai Engine portfolio block. Implemented by injecting attribution.write_html_footer_block(VERSION, include_attorney_disclaimer=False) into the L1 HTML body just before the close. include_attorney_disclaimer=False because L1 is informational; the disclaimer stays L2-only on file-ready deliverables.

Code uses the same attribution helpers added in v0.13.40 for L2 memos, so L1 + L2 share the styling and the canonical text. Single source of truth in attribution.py.

L2 result page: explicit "Back to deliverables" link

After downloading a deliverable on the L2 result page, the only way back to the selection page was browser-back. If the user had spent time reading and the session-ownership check had drifted, browser-back would land on a session-error page with no explanation. Added an explicit ← Back to deliverables link pointing at /layer2/{session_id} (the selection page is still live and re-entrable).

This addresses the navigation half of Z's L2-flow concern. The deeper "auto-kick on long reads" issue — whether _check_session_access is firing for stale auth state — is still under investigation; will fix once the actual gating reason is captured from a live repro.

v0.13.54 — 2026-05-05

PDF formatting alignment — Landscape + Memo unified header/footer + cover-page drop + section-box removal

Z's walk surfaced multiple PDF-formatting items across both customer-facing artifact types. Fixed in one ship to keep the two output formats coherent:

1. Per-page header + footer unified across Landscape and Memo. - @top-center on every page: Generated by DCFN - Patents · patents.livingedenframeworks.com (was DCFN - Patents · Patent Landscape Analysis or DCFN - Patents · Continuation Strategy Memo per artifact — now identical so customers reading both see the same brand attribution). - @bottom-left on every page: NV Business License #NV20263528439 · Built on the LEF Ai Engine · 8 U.S. Patents Pending [linked to livingedenframeworks.com]. Implemented via WeasyPrint's position: running() + content: element() pattern so the embedded <a> tag stays clickable inside the margin box. - @bottom-right on every page: Page N of M. Page-bottom margin lifted to 1.0in to accommodate the two-region footer.

Previously the NV License stamp only appeared at the document end (in the License Addendum §2.1 attribution block) — it now also renders on every page for brand visibility + auditability.

2. Landscape cover-page-break dropped. v0.13.42 had introduced header { page-break-after: always } on the L1 PDF — title block + brand stack rendered on a blank page 1, body content forced to page 2. Privacy framing was the original justification, but Z surfaced that the result reads as a wasted page; the Memo PDF doesn't do this and reads cleaner. v0.13.54 drops the page-break — the L1 header now flows directly into the body (matches Memo). The 2px purple horizontal rule below the header still visually separates title from body.

3. Section box around Landscape body content removed in print. v0.13.42's @media print .section { border: 1px solid #ECEFF1 } was creating a visible card border around each body section that constrained content width and contributed to the PRIOR-ART overlap issue (item 4 below). Print mode now zeros the section background / border / padding so content breathes at page-margin width. Box-shadow already hidden in print.

4. PRIOR ART patent-number overlap fix. .pa-row was using display: flex; align-items: center with min-width: 125px on the patent-number column. When the title text wrapped (which happens often at page-margin width), the patent number sat vertically centered against the wrapped block — read as overlap. Switched to align-items: baseline + flex-shrink: 0 + white-space: nowrap on the number column. Number now claims its width cleanly and the title wraps below it without colliding.

5. Cover-page meta line stripped of redundant "Generated by" prefix. The .run-meta line on the L1 cover used to read Generated by DCFN - Patents · {N} claims across {M} filings · Scanned against {K} domain patents. The "Generated by DCFN - Patents" prefix is now in the @top-center page header on every page — repeating it inline was redundant. Cover-page meta now reads just the scan scope.

Files touched: - render_arc.py — L1 PDF - continuation_memo_synth.py — Memo PDF - attribution.py — version bump

v0.13.40 — 2026-05-04

Engine output: Continuation Strategy Memo format switched from .docx to .pdf

Layer 2 has two deliverables — provisional drafts and Continuation Strategy Memos — and they have different customer workflows:

PDF for CSM matches the L1 landscape briefing format-language (visual fidelity locked across customer environments, header/footer + page-N-of-M enforced via @page CSS, industry standard for IP/legal deliverables).

Implementation: - continuation_memo_synth.py adds an HTML rendering path. Markdown → HTML (via markdown lib) → WeasyPrint → PDF. The python-docx rendering helpers are dormant (kept on disk for reference but no longer called). - attribution.py adds write_html_footer_block() and ATTRIBUTION_HTML_CSS — parallel of the existing write_docx_footer_block(), same content (HR + generation line + license line + Built-on line + L2 attorney disclaimer). - app.py: memo path renamed to continuation_memo_{pid}.pdf; download endpoint branches media_type by deliverable kind (PDF for memo, DOCX for provisional). - Customer-facing copy updated on the landing + L2 selection pages.

Sample memo (/static/samples/sample-continuation-memo.docx) still on disk in DOCX format — not auto-regenerated. Will swap to PDF the next time a sample memo is generated; the link wording already tells customers what they'll download.

v0.13.39 — 2026-05-04

Hotfix #2: Dockerfile missing WeasyPrint OS deps + PDF cache miss

Two bugs surfaced together in Z's first real run on v0.13.37:

  1. WeasyPrint imported but couldn't initialize at runtime. Pip-installing weasyprint brings the Python wrapper but not its OS-level dependencies (Pango, Cairo, GDK-PixBuf, shared font libs). Both render_arc.py and app.py's /report?format=pdf regen path silently fell into the except branch with the message "WeasyPrint could not import some external libraries." Effect: the L1 PDF was never produced, and every download attempt returned 500. v0.13.36 + v0.13.37 deploys both shipped this bug. Fix: add libpango-1.0-0, libpangoft2-1.0-0, libcairo2, libgdk-pixbuf-2.0-0, libffi-dev, shared-mime-info, fonts-dejavu-core to the Dockerfile's apt-get install list.

  2. PDF was never copied from session_data/ into the canonical session_store slot. The HTML render had a copy step (patent_arc.html → __report.html); the PDF didn't. Even with WeasyPrint working, the /report?format=pdf endpoint would have hit the slow regen-from-HTML path on every download instead of serving the pre-rendered PDF. Fix: parallel copy step in the L1 finalize block (patent_arc_report.pdf → __report.pdf).

Lesson: when adding a new system-dependency-bearing Python package, the Dockerfile change is part of the same release. Pip-success ≠ runtime-success for libraries with native bindings. Caught by Z's first real run, not by syntax check or local CI.

v0.13.37 — 2026-05-04

Hotfix: render_arc.py PDF export crashed all v0.13.36 runs

Surfaced 2026-05-04 on the first user run after v0.13.36 deploy. Caught by Z's re-run with the richer 8-patent input — the engine pipeline ran clean; the failure was at the very last step.

Lesson recorded as engine principle (Charter §21 candidate): "When introducing a new module-level import inside a function whose name collides with an existing module-level symbol, alias the import. Python's local-scope rule treats the name as local for the entire function regardless of where the import line sits."

v0.13.36 — 2026-05-04

Engine output: L1 landscape briefing format switched from .docx to .pdf

Dependency: weasyprint>=62.0,<65.0 added to requirements.txt for HTML→PDF rendering. htmldocx retained for the L2 path.

v0.13.25 — 2026-05-04

Engine output: per-session DOCX export now reads session data + writes to session dir

Surfaced 2026-05-03 during Run A diagnosis when the engine ran cleanly but no Drive artifacts appeared. Two-layer bug: stale-input reads + wrong-output-location writes. Both layers fixed in this release.

v0.13.34 — 2026-05-04

Engine output: L2 deliverable generation now runs up to 3 in parallel

v0.13.31 — 2026-05-04

Engine output: prose patent-count now matches the header

Surfaced in the BD Tier 1 run alongside v0.13.30's parser fix:

v0.13.30 — 2026-05-04

Engine input handling: claim parser now tolerates BQ's spaced punctuation

This bug had been silent since the granted-patents intake path was first written. It only surfaced when external reviewers compared the engine's "I refuse to fabricate" honesty against the actual BQ-side data and asked "wait, is the data really missing or did you just fail to parse it?"

v0.13.4 — 2026-05-03

Engine input handling: patent-number parser strips kind-code suffix

(v0.13.5 — v0.13.23 were platform-only releases; see PLATFORM_CHANGELOG.md.)

v0.13.3 — 2026-05-03

Bug fix: Unfiled-mode multi-invention uploads no longer collapse to a single record

v0.13.2 — 2026-05-03

Quality fix: landscape narrative no longer hallucinates corpus size

v0.13.1 — 2026-05-02

Three production-readiness fixes (tested by Z on live deploy)

v0.13.0 — 2026-05-01

Feature: Tier 1 Firm Pool ($30K/yr, 200 shared runs/yr)

v0.12.4 — 2026-05-02

Bug fix: BETA_FREE bypass now applies to run-counter (signup → run flow no longer 402s)

v0.12.3 — 2026-05-02

Stale pricing trace cleanup — code now matches locked pricing memo

v0.12.2 — 2026-05-01

Tier-indicator badge on every customer-visible surface

v0.12.1 — 2026-05-01

Public pricing page at /pricing

v0.12.0 — 2026-05-01

Server-side run counter + overage billing for Tier 0 / Tier 1

v0.11.0 — 2026-05-02

Customer accounts + Stripe Tier 1 subscription (AUTH_FLOW Phases 1+2)

v0.10.0 — 2026-05-02

Drive filename naming convention + archival policy

v0.9.1 — 2026-05-02

Stale customer-output URL — dcfn-patents.onrender.com → patents.livingedenframeworks.com

v0.9.0 — 2026-05-01

Durable session storage — sessions survive Cloud Run instance recycling

v0.8.0 — 2026-04-30

GPU compute path — Dockerfile switched to PyTorch+CUDA base image; SBERT auto-detects GPU when present

v0.7.4 — 2026-04-30

Cloud Run hot-fix #2 — landing page no longer infinite-reloads on "Pro tier ready. Reloading…"

v0.7.3 — 2026-04-30

Cloud Run hot-fix — landing page no longer loops on "Polling tier status — unknown"

v0.7.0 — 2026-05-01

Attribution module + canonical end-of-body footer block on every .docx; site footer cleanup co-shipped with DCFN-Research v0.3.11

v0.6.4 — 2026-05-01

Public site copy + footer cleanup (Z directives from CRISPR retest)

v0.6.3 — 2026-05-01

Pricing locked decision finally shipped

Z locked the Tier 0 pricing change 2026-04-30 ($85/30day → $175/3day, no L2 gate) but the prior instance only documented the lock without shipping the engine change. Result: Z's CRISPR retest charged the old $85 + an additional $20 ($15 provisional + $1 × 5 memos) at the L2 gate. This ship makes the live pricing match the documented lock.

The _verified_stripe_sessions orphan bug (cookie issued before a Render redeploy may not survive into the post-deploy session set) is tracked separately as a follow-on; the new 402 path keeps unpaid users from accidentally being charged the old per-deliverable amounts even if cookies orphan in the future.

Render image rebuild

GitHub Actions workflow auto-publishes a fresh ghcr.io/syntaricodex/lef-dcfn-patents:v0.6.3 image on tag push. Tier 2 customers who pulled :v0.6.1 should pull :v0.6.3 to pick up the price update (relevant only if they enable the Stripe gate in their private deployment, which is uncommon for Tier 2 — usually disabled per ADR).

v0.6.1 — 2026-05-01

Tier 2 container infrastructure (foundational ship)

Tier 2 Private Deployment requires a container customers can pull. Until v0.6.1, the deployment runbook + license templates existed but the actual Docker image did not — meaning a Tier 2 customer signing the contract would have hit a "wait, where's the container?" gap. Closes that gap.

What's still per-customer (lives in DCFN Admin Layer scope when that instance comes online): registry credential provisioning, per-customer setup runbook generation from DEPLOYMENT_RUNBOOK.md template, customer onboarding email automation, "Used by" public-site queue.

For first Tier 2 conversation: the foundational image is ready to publish; Z + active instance handle per-customer provisioning manually until Admin Layer instance is online. Bridges the gap.

v0.6.0 — 2026-05-01

Tier-config framework — per-tier engine knobs (Cap Audit Doc 5)

New module tier_config.py centralizes per-tier engine cap configuration. Tier resolution at request time via resolve_tier(): env var (DCFN_TIER, used by Tier 2 baked Docker images) → session state → cookie → default. The TIER_CONFIGS dict holds three tier profiles: tier_0 (current production), tier_1 (boutique IP firms), tier_2 (private deployment).

Caps now read from the resolved config (with module-level constants as fallback for CLI / no-context invocations):

Two engine-depth feature flags also land at the tier level (gated to Tier 1+):

Default behavior unchanged. Tier 0 caps match prior production constants exactly. Local validation confirmed via Charter §15: resolve_tier() returns tier_0 with no DCFN_TIER env / no session state, and every cap read returns the original constant value.

The two depth-feature flags are wired but the corresponding engine code paths are not yet implemented. Flags exist so the tier-config framework is complete; engine implementation follows when first Tier 1 / Tier 2 customer signals demand.

v0.5.9 — 2026-04-30

Pipeline timing instrumentation (Charter §16)

v0.5.8 — 2026-04-30

Layer 2 CTA cleanup

v0.5.7 — 2026-04-30

Landscape narrative tells the truth about which corpus it scanned

After v0.5.5 + v0.5.6 unblocked the per-session corpus pull (Pattern B), the CRISPR re-test produced a real biotech corpus scan — 405 CRISPR-relevant patents, 37 clusters, nearest competitor at 87% match — but the landscape narrative still said "This scan ran against a 37-cluster corpus weighted toward AI, educational technology, and adaptive systems—a significant misalignment with your portfolio's biotechnology focus." That was a hardcoded fallback string in landscape_narrative_synth._infer_corpus_theme() that fired regardless of whether the per-session pull had actually run.

Fix: _infer_corpus_theme now reads session_corpus_meta.json (written by session_corpus_pull.py) and characterizes the corpus honestly — naming the actual CPC subclasses pulled and the patent count. Static-fallback (Tier 0 / sampler) language preserved as the no-meta-file branch. The narrative's "Honest caveat" section will now reflect the real scan, not a stale boilerplate that contradicts what the engine actually did.

v0.5.6 — 2026-04-30

Schema fix: per-session corpus matches domain_scan.py reader

After v0.5.5 unblocked the BQ auth and the per-session corpus pull actually fired, the next step (domain_scan.py) crashed with TypeError: list indices must be integers or slices, not str. session_corpus_pull.py was writing the corpus as a bare JSON list; domain_scan.load_data does domain["patents"] expecting the wrapped object format the static data/domain_patents.json ships with. Now writes {"patents": [...]} to match. Re-encode-on-cache-miss path in domain_scan.py already handles the absent .npy cache (slower first scan, correct results).

v0.5.5 — 2026-04-30

Critical fix: per-session corpus pull (Pattern B) now actually fires in production

The Charter §12 Pattern B per-session BigQuery corpus pull, shipped 2026-04-30 as commit 8d03b61, has been silently falling back to the static LEF-tuned diagnostic-AI corpus on every paid run since deploy. Confirmed today via Render log of the CRISPR re-test (session efb40c18) and the unfiled-CGM run (fd5a9325):

[corpus_pull] stderr:
  ERROR: BQ client init failed: Your default credentials were not found.
[corpus_pull] Failed (rc=4); falling back to static corpus.

Root cause: domain_ingest.get_bq_client() — which session_corpus_pull.py imports — only handled gcloud Application Default Credentials. Render uses a different precedence: the service account JSON is set inline in the GOOGLE_SERVICE_ACCOUNT_JSON env var. fetch_user_patents._get_bq_client() already handled this; domain_ingest.get_bq_client() didn't. Fix unifies the auth path — both clients now check GOOGLE_SERVICE_ACCOUNT_JSON first, with ADC as the local-dev fallback.

User-visible effect: paid runs will now actually score the user's portfolio against a CPC-matched corpus pulled fresh per session (typical: 3000 patents in the user's actual subclasses, ~$0.05–$0.25 BQ cost per session) instead of falling back to the static 22-patent LEF-Engine portfolio — the misalignment Perplexity flagged 2026-04-29 finally closes.

v0.5.4 — 2026-04-30

Bug fix: unfiled-idea submit validation

The intake form's submit handler was always validating the patent_numbers field, regardless of which intake tab was active. Users on "Analyze an unfiled idea" couldn't submit without entering a patent number — even though the unfiled-idea path doesn't use one. Backend was correct (already accepted both intake_mode=patents and intake_mode=unfiled); the JS submit guard was the bug. Now branches on the active mode: patent-numbers count rules (max 7, min 1) apply only on the patents tab; unfiled tab requires only a non-empty invention description.

v0.5.3 — 2026-04-30

Pricing-language leak closed

v0.5.2 — 2026-04-30

Patent attribution accuracy

The footer's "Built on" line was undercounting the LEF portfolio: said "7 U.S. Patents Pending" (8 since the Tesseract Composition supplemental on 2026-04-20) and named only CTE while the engine actually rides multiple substrate patents. Fixed:

Same correction applied to the Firebase brand site's per-build cards (DCFN-Patents card now lists CTE + QECO + Consolidated Supplemental + Tesseract Composition with their app numbers, plus the "part of the 8-patent LEF Ai Engine portfolio" reference).

The audit caught one other gap: prior-version footers across DCFN-Research and DCFN-Bio had similar undercounting (Research said "6", Bio had no attribution at all). All three deployed-site footers now use the same unified attribution shape so a buyer comparing builds sees consistent and accurate IP framing.

v0.5.1 — 2026-04-30

Quality fix on the Unfiled Idea intake

The v0.5.0 ship took an unstructured-input failure mode for granted: real users describe inventions in many shapes (one-paragraph ideas, bullet lists, partial draft specs, stream-of-consciousness explanations), and the engine's CPC-derivation + claim-synthesis quality scales directly with how structured the user's writing is. Without scaffolding, garbage-in / garbage-out silently teaches prospects the engine is weak — when actually the engine is correctly reading what was given to it.

Three layers added (per Charter §14, codified same day as a Day-1 standard for any DCFN build with free-text intake):

The placeholder is a soft suggestion, not enforcement — users who want to paste a single paragraph still can. The scaffolding lifts the floor on input quality without forcing the user to know what the engine wants.

v0.5.0 — 2026-04-30

Unfiled Idea intake mode

A second intake mode on the landscape-scan form: paste the description of an unfiled invention idea instead of granted-patent numbers. The engine treats the upload as a "virtual patent" and runs the same L1 pipeline — landscape positioning, nearest-neighbor scoring, silent-region detection, candidate generation — against your idea instead of your filings.

How it works: - Toggle at the top of the intake form: Analyze granted patents (default) / Analyze an unfiled idea - For the unfiled-idea path: paste your invention description (max 60K chars). The engine calls Claude once to propose 3-5 CPC subclasses and parse-or-synthesize Claim 1 from the upload. Those become the synthetic record that feeds the standard L1 pipeline. - Adds ~10 seconds (one extra Claude API call) to L1 runtime relative to the granted-patents path.

What you can use this for: - Validating an early-stage invention idea against the patent landscape before you commit to drafting a provisional - Stress-testing claim scope: see how close your idea sits to existing prior art in the same CPC subclasses - Identifying the silent-region opportunities the engine surfaces when it analyzes your idea in landscape context

What you should NOT use this for: trade-secret material. The upload passes through Anthropic, Render, and Google APIs during analysis. We auto-delete your text from our systems after your run completes (per Terms §5.1 carve-out, shipped in v0.4.1), but third-party processing is outside our control. A red disclaimer above the upload field calls this out unmissably; users with strict end-to-end confidentiality requirements should ask about Tier 2 Private Deployment in their own VPC.

Auto-delete is mechanical, not aspirational: when the L1 run completes, the engine's cleanup pass deletes unfiled_upload.txt from session storage AND scrubs the _uploaded_text field from the synthetic patents.json record. The session's downstream artifacts (article, briefing, deliverables) are derived analysis — they stay. The raw upload doesn't.

v0.4.1 — 2026-04-30

Terms of Service

v0.4.0 — 2026-04-30

A commercial-readiness pass driven by deep-research reviews of the engine's output by Gemini and Perplexity. Per the Perplexity verdict on this version: "This version is commercially ready for a pilot with an IP firm or in-house counsel." Per Gemini: "the Patents build is ready to be put in front of AmLaw 100 IP partners today."

Output

Pricing display

Terms of Service + Privacy Policy

v0.3.0 — 2026-04-29

Pricing model

Engine

Three-tier deployment

v0.2.0 — 2026-04-22

v0.1.0 — 2026-04-12

Initial deployment. Single-page intake → BigQuery patent fetch → concept graph → cluster scan → silent-region detection → provisional draft + continuation memo generation. Domain-Wide Delegation impersonation for Drive uploads. Verify-on-demand Stripe checkout (no webhooks). FastAPI + Jinja2 inline.