Wave R14 — Continuous Web-Property Update + Sugiyama-Layered Async Sync

The problem

FDRP runs across roughly twenty subdomains: a public dashboard, a research blog, client landings, methodology pages, technical reports, case studies, and presentations. Until now there was no systematic way to detect a stale page, no way to know which other pages depend on it, and no way to coordinate updates that propagate through a graph of references. Pages drifted out of date silently. A new paper version did not pull its dashboard, methodology page, and roadmap entry along with it.

The Sugiyama insight

Sugiyama's 1981 work on hierarchical graph drawing gave us a frame: organise nodes into layers such that edges flow downward, and you get a tractable substrate for both rendering and reasoning. We borrowed the discipline. Pages live in one of four layers:

• Layer 1 — canonical. The FDRP paper, master plan, indexed memory.
• Layer 2 — derived. Dashboards, methodology pages, technical reports.
• Layer 3 — referencing. Blog posts, case studies, client subdomains.
• Layer 4 — outbound. Tender drafts, sent emails, client report templates.

Edges flow downward: a Layer 1 paper revision propagates to its Layer 2 dashboard and Layer 3 case study; a Layer 4 outbound tender pulls evidence from Layer 1 but never the other way around.

What ships in Wave R14

Four tables, three views, three daemons, one update template:

• web_page_inventory — every tracked page, its layer, its staleness threshold, current status.
• web_page_dependencies — typed edges (cites, derived_from, references_concept, reuses_data, propagation_target) with a propagation policy and an evidence note.
• web_page_review_queue — work-to-do, with reason, priority, assigned agent, and outcome path.
• sugiyama_sync_barrier — cascades only advance when every page in the current layer is complete.

The staleness detector runs every six hours, refreshes mtimes, marks pages older than their threshold as stale, and enqueues up to fifty per cycle (anti-flood) with a twenty-four hour re-queue rate limit. The dependency cascade fires on update completion and walks the edge table forward, respecting each edge's propagation policy. The barrier-sync daemon runs every fifteen minutes, recomputes layer completion, advances current_layer when ready, and alerts on layers that stall beyond four hours.

Composition

Wave R14 sits on top of three earlier waves. R7 inventoried the property roster. R10 shipped multi-account orchestration with limit-stall recovery and per-page-update cost attribution — we now know which page costs what to update. R11 introduced the bidirectional mirror (any agent leading; any agent verifying). R12 and R13 cover routing and pattern catalogues that a future page-update specialist will draw on. R14 is the substrate that lets all of that flow through every web property, every day, without any single page rotting in silence.

What this changes operationally

In practice we now answer questions like “which pages reference v21 of the paper?” or “what propagates if I revise the methodology section on convergence?” or “is the antimatter case study still aligned with the latest evidence?” The schema makes those queries a single SELECT.

Drafts written by sub-agents go through review by Liviu before publishing (BIND-040). The cascade enqueues work; humans approve before publication. The system is autonomous in detection and assembly; it is deliberate in delivery.

FDRP principles reinforced

• BIND-040 explicit send gate — the cascade enqueues; the human approves. This very post sat as a draft until Liviu released it.
• BIND-043 IMPLEMENT_LOW — the substrate is tables and views, deterministic and cheap, auto-applied with evolution-log entry.
• Composition over reinvention — R14 reuses R7 (inventory) and R10 (orchestration) rather than re-implementing them. The Sugiyama discipline is the new piece; everything else is a wiring layer.

← All research notes