Project Initiation Documentation

The 22 October baseline (P1 Argentina, P2 Wales records, P3 Parcel A tour, P4 reopening) is superseded: P2 and P4 are now Project A and spin-off A1, P1 is Project C, P3 is Project D with its scope limited to public places, and Project B is new. Detailed tasks and their progress stay on the task board.

• Task records 2,065
• Completed 1,121 · 54%
• Open 944 · 847 not started · 43 in progress · 54 waiting
• Snapshot 00:41 UTC · all owners

The delivery queue holds 2,065 task records: 1,826 to-dos and 239 email-type records (queue records, not proof of Gmail drafts or sent mail). 722 open records carry a recorded due date in the past; planning placeholders are common in this queue, so that count is not a list of missed obligations. The 22 October baseline (551 records) used different coverage, so no like-for-like movement is published. Current queue priorities: historical property records custody requests; independent pre-publication draft reviews; deadline and preservation-clock reconciliation; parcel evidence tagging.

Master highlight report with controls and gaps · Machine-readable snapshot

Purpose: preserve and reconcile surviving records about Great House Farm / Tŷ Mawr; develop a feasible, source-led museum proposal in Argentina; and create an accessible, evidence-graded AR tour for Llandough Parcel A and its historic setting.

Independence: P1 can begin source grading, interpretation and concept planning; P3 can begin route mapping, source-location checking and wireframe specifications; P2 continues retrieving and preserving material in Wales. New records update P1/P3 through versioned change control. P2 is complementary, not a blanket start condition.

Historical accuracy: all interpretation distinguishes established source facts, testimony/recollection, regional context, inference and hypothetical reconstruction. The Roman villa/farm reported south of the church must not be shown as on Parcel A without site-specific evidence. The early ecclesiastical/monastic attribution must be source- and location-checked before it is depicted as an established structure.

Authority: publishing this working baseline is not Executive acceptance, spending authority, permission to acquire land/build, permission to publish private witness material, or authority to file legal proceedings. Each project needs explicit gates, tolerances, acceptance tests and approvals.

Full master mandate and brief · Master plan and milestones · Current highlight report

Purpose: reconstruct the Welsh family estate, Williams/Buckler matriarchy, landholding, people, history and heritage around Great House Farm / Tŷ Mawr / Llandough-juxta-Penarth; establish parcel by parcel what each person owned or occupied, by what instrument or legal interest, when it changed and what rights or heritage survive. Investigate documented institutional decisions and potential failures without presuming negligence, incompetence, concealment, fraud, scandal or government involvement. The proposed Patagonia Great House Farm II is a future feasibility and heritage concept, separate from the historic Welsh estate.

Recursive snowball formula: S(n+1) = S(n) + V + R + G + A + P + B - D - U - W. V = new verified artifacts/propositions; R = validated relationships; G = genuinely resolved research gaps; A = actionable follow-on leads; P = approved public/educational outputs; B = earned support or capability reinvested through approved procurement; D = duplicates removed; U = unsupported claims quarantined; W = avoidable rework. These components are reported separately. This is a management measure, not a measure of historical truth: copies, unverified leads and raw pageviews do not increase it.

The loop: new record or activity → deduplicate and preserve → canonical source/provenance record → relate people, bodies, events, parcels and titles → independent challenge → rank missing records → HubSpot task → specialist agent claim in Hive → bounded work → QA → approved public update → metric, changelog and next research question. Every loop must yield a verified record, resolved gap, approved output or explicit blocker.

Ten work packages in HubSpot:

1. Estate/title and matriarchy: parcel-by-parcel title, succession, possession, maps and interests.
2. FOI and records recovery: archive holders, Gmail, spam/archive checks, responses, attachments and follow-up.
3. Documentary bible and master script: complete, source-linked narrative with contradictory evidence and corrections retained.
4. Sequential scene production: nominal two-minute scenes, one at a time, with screenplay, evidence map, set/prop/wardrobe, choreography, camera, sound, continuity and version history; licensed OmniHuman access to be verified before use.
5. Hive / Docs / WebMCP: one top-level agent instruction, specialist routing, claims, handovers and machine-readable entry points.
6. Data architecture: one canonical writer, reconciled D1/graph/search stores, typed GraphQL and derived views.
7. Audience and business development: social, copywriting, SEO, website, e-commerce, subscribers, contributors and partnerships.
8. Procurement and funding: public, costed procurement register, spend limits and financial controls.
9. Patagonia Great House Farm II: staged land, planning, museum, governance and operating feasibility.
10. Quality and red-team: provenance, contrary evidence, privacy, legal/editorial checks, site QA and continuous improvement.

Sub-flywheels: research/title; FOI/archive and email; missing-evidence recovery; evidence grading/red-team; documentary/script/scene production; social and editorial; website/development/SEO/WebMCP; e-commerce/sales; community/contributions; procurement/funding; Patagonia feasibility. All are children of the same programme and use the same canonical records and work register.

Authority and safeguards: possible legal triggers are private by default. Agents preserve the artifact and create a confidential HubSpot review task with evidence both for and against, materiality, causation and what would confirm/refute. They do not publish allegations, update a public incident log or contact counsel automatically. Agents may research, draft, classify, challenge, QA and coordinate; legal determinations, external contact, sensitive publication, payments, transfers, debt and irreversible decisions remain with the owner/authorised professionals. No private keys, seed phrases or spend-capable wallets are exposed through MCP/WebMCP. Any disbursement requires explicit custodian approval within limits.

Control locations: HubSpot is the task/relationship/procurement register; GitHub is the versioned source; canonical data has one writer; D1, graph/search indexes and webapp views are derived; Hive is coordination; Projects is the public portfolio; Docs/Library holds the master protocol; WebMCP and the collapsed agent footer point back to the same instructions. Read the full Snowball operating protocol · Planned procurement register · Agent flywheel catalogue · Hive · WebMCP.

The operational master and ten specialist work packages are recorded in HubSpot. Detailed task ownership, deadlines, results and blockers belong in those records; this public page is the programme overview, not a second task board.

Purpose: reconstruct the Welsh family estate, Williams/Buckler matriarchy, landholding, people, history and heritage around Great House Farm / Tŷ Mawr / Llandough-juxta-Penarth; establish parcel by parcel what each person owned or occupied, by what instrument or legal interest, when it changed and what rights or heritage survive. The programme also examines documented institutional decisions and potential failures without presuming conclusions. The proposed Patagonia Great House Farm II is a future feasibility and heritage concept, separate from the historic Welsh estate.

Recursive snowball formula: S(n+1) = S(n) + V + R + G + A + P + B - D - U - W. V = new verified artifacts/propositions; R = validated relationships; G = genuinely resolved research gaps; A = actionable follow-on leads; P = approved public/educational outputs; B = earned support or capability reinvested through approved procurement; D = duplicates removed; U = unsupported claims quarantined; W = avoidable rework. Report each component separately. This is an operational learning measure, not a measure of historical truth: copies, unverified leads and raw pageviews do not increase it.

The loop: new record or activity → deduplicate and preserve → canonical source/provenance record → relate people, bodies, events, parcels and titles → independent challenge → rank missing records → HubSpot task → specialist agent claim in Hive → bounded work → QA → approved public update → metric, changelog and next research question. Every loop must yield a verified record, resolved gap, approved output or explicit blocker.

Ten work packages in HubSpot:

1. Estate/title and matriarchy: parcel-by-parcel title, succession, possession, maps and interests.
2. FOI and records recovery: archive holders, Gmail, spam/archive checks, responses, attachments and follow-up.
3. Documentary bible and master script: complete, source-linked narrative with contradictory evidence and corrections retained.
4. Sequential scene production: nominal two-minute scenes, one at a time, with screenplay, evidence map, set/prop/wardrobe, choreography, camera, sound, continuity and version history; licensed model access to be verified before use.
5. Hive / Docs / WebMCP: one top-level agent instruction, specialist routing, claims, handovers and machine-readable entry points.
6. Data architecture: one canonical writer, reconciled D1/graph/search stores, typed GraphQL and derived views.
7. Audience and business development: social, copywriting, SEO, website, e-commerce, subscribers, contributors and partnerships.
8. Procurement and funding: public, costed procurement register, spend limits and financial controls.
9. Patagonia Great House Farm II: staged land, planning, museum, governance and operating feasibility.
10. Quality and red-team: provenance, contrary evidence, privacy, legal/editorial checks, site QA and continuous improvement.

Sub-flywheels: research/title; FOI/archive and email; missing-evidence recovery; evidence grading/red-team; documentary/script/scene production; social and editorial; website/development/SEO/WebMCP; e-commerce/sales; community/contributions; procurement/funding; Patagonia feasibility. All are children of the same programme and use the same canonical records and work register.

Governance: possible legal triggers are private by default. Agents preserve an artifact and create a confidential HubSpot review task with evidence for and against, materiality, causation and what would confirm/refute. Public statements and external contact require an explicit owner/authorised professional decision. Agents may research, draft, classify, challenge, QA and coordinate; legal determinations, sensitive publication, financial transfers and irreversible decisions remain with the owner/authorised professionals.

Control locations: HubSpot is the task/relationship/procurement register; GitHub is the versioned source; canonical data has one writer; D1, graph/search indexes and webapp views are derived; Hive is coordination; Projects is the public portfolio; Docs/Library holds the master protocol; WebMCP and the collapsed agent footer point back to the same instructions. Read the full Snowball operating protocol · Agent flywheel catalogue · Hive · WebMCP.

The operational master and ten specialist work packages are recorded in HubSpot. Detailed task ownership, deadlines, results and blockers belong in those records; this public page is the programme overview, not a second task board.

The nomenclature URL cited in outbound correspondence has been corrected as a source-aware register. Track it as a cross-cutting change package, not as an extra top-level delivery project. The product description, scope/tolerances, risk and issue log, PRINCE2 mythology and release acceptance checklist are in the Nomenclature Register Repair control sheet.

Acceptance is split into source merge, assembled build/deployment and live-route checks. A merged source alone is not a completed product. The page is explicitly a working register; it does not establish that every historic name was found or prove identity, parcel boundary or title.

Each authorised project keeps its own mandate/brief, business case, plan, stage plans, work packages, product descriptions, risk/issue/quality/lessons/decision/change registers, highlight reports, end-stage reports and end-project report. The master page coordinates those plans and does not replace them. Independent Project Assurance is not currently appointed; this is a known governance gap.

Detailed recovery records remain available through the inherited work-package register, dated recovery reports, trigger register and control register index. The machine-readable programme baseline is data/programme.json.