{ "version": 3, "updatedAt": "2026-09-04T15:13:25.000Z", "updatedBy": "Add Fantastic All Library ingestion and SEO backlog items", "title": "bndy workboard", "description": "Single view of active bndy product, platform, ingestion, intelligence and growth work.", "principles": [ "Canonical BNDY APIs remain the write authority.", "Capture is transport and durable intake, not the intelligence engine.", "Enrichment is the strategic resolution and intelligence runtime.", "BNDY Backline is the capability/product name; bndy-enrichment remains the single strategic Backline runtime rather than creating a parallel repository.", "All new ingestion paths should converge on Capture + Enrichment rather than inventing another write path.", "The target state is evidence -> claims -> projection -> canonical BNDY, not source -> direct database write.", "BNDY Backline is the durable intelligence substrate: immutable evidence plus observations and atomised claims feed policy and projection; the graph is a derived view, not the authority.", "Healthy source delivery requires both ingestion health and evidence-backed enrichment health; blank or explicitly unknown is safer than an invented classification or a wrong identity link.", "Every new mutation route must have an explicit trust-zone classification and fail closed until it is classified." ], "activityRepos": [ "flowency-live/bndy-app", "flowency-live/bndy-serverless-api", "flowency-live/bndy-backstage", "flowency-live/bndy-website", "flowency-live/bndy-chatzone", "flowency-live/bndy-capture", "flowency-live/bndy-enrichment", "flowency-live/bndy-MCP", "flowency-live/bndy-ops" ], "repositories": [ { "id": "app", "repo": "flowency-live/bndy-app", "serves": "https://bndy.live", "role": "Core public gig discovery PWA: map, gigs, artists, venues, festivals, favourites and public add flows.", "status": "production" }, { "id": "api", "repo": "flowency-live/bndy-serverless-api", "serves": "Canonical BNDY backend", "role": "Authoritative artists, venues, events, festivals, auth, curator policy, source inspection and edition-aware APIs.", "status": "production" }, { "id": "backstage", "repo": "flowency-live/bndy-backstage", "serves": "BNDY Backstage / Godmode", "role": "Admin operations, curator policy management and traffic visibility.", "status": "production" }, { "id": "website", "repo": "flowency-live/bndy-website", "serves": "https://www.bndy.co.uk", "role": "Public brand, proposition, policy and architecture pages. The workboard lives here.", "status": "production" }, { "id": "chatzone", "repo": "flowency-live/bndy-chatzone", "serves": "https://chat.bndy.live", "role": "Public Dropzone UI for gig poster and text submission. Routes into Capture.", "status": "production" }, { "id": "capture", "repo": "flowency-live/bndy-capture", "serves": "https://capture.bndy.co.uk + Android APK", "role": "Durable intake transport for Android Send to bndy and public web submissions. Stores evidence and queue state.", "status": "production" }, { "id": "enrichment", "repo": "flowency-live/bndy-enrichment", "serves": "AWS BNDY Backline runtime", "role": "Strategic Backline runtime for source acquisition, immutable evidence, observations, atomised claims, identity resolution, authority, projection, Capture processing and enrichment.", "status": "active" }, { "id": "ops", "repo": "flowency-live/bndy-ops", "serves": "Cowork operational evidence", "role": "Live Cowork task definitions, source snapshots, cursors, state, machine run ledgers and human run reports. It is an operational evidence source for Backline, not a second strategic runtime or canonical authority.", "status": "support" }, { "id": "mcp", "repo": "flowency-live/bndy-MCP", "serves": "Agent/MCP adapter", "role": "Thin agent-facing adapter around BNDY capabilities. Needs a current-role audit as Enrichment becomes the orchestration layer.", "status": "support" }, { "id": "signals", "repo": "flowency-live/bndy-signals", "serves": "Legacy signals runtime", "role": "Older Signal -> interpretation -> claims implementation. Useful concepts should be absorbed then the runtime retired.", "status": "legacy" }, { "id": "frontstage", "repo": "flowency-live/bndy-frontstage", "serves": "Decommissioned", "role": "Previous public application. Do not use for new work.", "status": "decommissioned" }, { "id": "types", "repo": "flowency-live/bndy-types", "serves": "Shared package", "role": "Shared type definitions used by older/newer surfaces where applicable.", "status": "support" }, { "id": "ui", "repo": "flowency-live/bndy-ui", "serves": "Shared package", "role": "Shared UI package from the earlier application generation. Audit before expanding usage.", "status": "support" }, { "id": "legacy-other", "repo": "flowency-live/bndy.live, bndylivebeta, bndy-centrestage, bndy-portal, bndy-api, bndy-infrastructure", "serves": "Legacy / audit required", "role": "Older BNDY generations. Confirm no live dependency, then archive or label clearly to reduce agent confusion.", "status": "audit" } ], "backlog": [ { "id": "recurring-grassroots-sessions", "rank": 1, "laneId": "core-discovery", "title": "Recurring grassroots sessions", "detail": "Make venue-hosted open mics, jam nights and folk sessions first-class recurring discovery objects rather than copying dozens of dated gigs. Store one canonical series with Venue, recurrence, optional host Artist, session type, admission, participation details and source provenance; expand only a bounded future window for public discovery. Support excluded dates and occurrence-specific cancellation, time or host overrides. Give sessions clear filters and presentation so they do not masquerade as ordinary gigs. Complete recurrence support through canonical public reads and creation, then ingest and re-verify suitable sources through Backline. Every series must carry lastVerifiedAt and a freshness/expiry policy so an abandoned weekly listing never repeats indefinitely." }, { "id": "curator-activity-audit", "rank": 2, "laneId": "curators", "title": "Curator activity audit and accountable editing", "detail": "Keep trusted Curators productive in bndy-app while making every meaningful mutation reviewable. Curators may directly edit safe whitelisted Artist, Venue, Festival and Event fields within their assigned access; identity and linkage fields remain protected, and hide or cancel actions require a reason. Complete the existing bndy-activity-log foundation into a reliable immutable mutation trail covering create, edit, hide, restore, cancel, role, access and ownership actions with actor, role, entity, timestamp, changed fields, reason and request correlation, excluding secrets and unnecessary private data. Add one bounded Godmode review screen with pagination, drill-through and filters for Curator, action/activity type, entity type, entity and date. Prove coverage across mutation routes and alert on audit-write failure; do not turn this into indiscriminate read or HTTP request logging." }, { "id": "artist-booking-requests", "rank": 3, "laneId": "core-discovery", "title": "Complete in-bndy Artist booking requests", "detail": "Build on the live Artist availability and date-aware contact foundation, which already lets a person select an available or unlisted date and open a prepared WhatsApp, SMS or telephone enquiry. Complete the journey by storing a private booking request inside BNDY, delivering it to the claimed Artist account, providing in-app and explicitly opted-in notifications, and supporting reply, accept, decline and request status. Define claimant authority, consent, spam and rate controls, privacy, retention and any external-channel fallback before delivery. Keep open social messaging out of scope and do not duplicate the existing availability calendar or direct contact actions." }, { "id": "replace-static-aws-root-credentials", "rank": 4, "laneId": "api-security", "title": "Replace static AWS root credentials with scoped OIDC roles", "detail": "Audit every remaining GitHub Actions reference to static AWS access-key secrets and establish which paths still resolve to the root credentials identified during recovery. Move legitimate deployment and diagnostic paths to least-privilege GitHub OIDC roles, then revoke the root access keys and verify closure through IAM and CloudTrail last-used evidence. Map dependencies before revocation to avoid an accidental outage. This is a separate platform-security task and does not block normal Backline, Claims or product backlog development.", "evidence": [ "https://github.com/flowency-live/bndy-serverless-api/pull/71", "https://github.com/flowency-live/bndy-ops/blob/main/cto/BACKLINE-POST-RECOVERY-LIVE-AUDIT-2026-08-30.md" ] }, { "id": "discovery-image-capture-claim-confirmation", "rank": 5, "laneId": "join-bndy", "title": "Discovery image capture and Claim confirmation", "detail": "Keep useful discovery-sourced Artist and Venue images visible before Claim while removing the live runtime dependency on Meta. Prefer Facebook where available; when no Facebook image exists but an Instagram URL does, make one bounded attempt to resolve normally accessible public profile metadata without login bypass, aggressive scraping or repeated retries. Download permitted results into BNDY-controlled S3 storage and retain platform, original URL, capture time, image hash and evidence lineage with status discovery_unconfirmed. During Claim, show the current image and require the claimant to confirm continued use, upload a replacement or remove it. Owner-supplied images have highest authority. Support immediate takedown and never discard the original provenance URL." }, { "id": "social-identity-instagram", "rank": 6, "laneId": "intelligence", "title": "Instagram as first-class Artist identity evidence", "detail": "Normalise and retain Instagram handles as strong Artist identity evidence without making them unconditional canonical uniqueness keys. Store source, observed date and handle history. An exact handle may resolve automatically only when the Artist name is compatible with no location conflict, the account is verified through the Claim journey, or independent official evidence corroborates the identity; otherwise route to review. Backfill existing Instagram URLs through a dry-run and controlled evidence path first. Recycled, personal or shared handles must never bypass ADR-014 location safeguards or the zero-wrong-artist-link rule." }, { "id": "artist-performance-variants", "rank": 7, "laneId": "intelligence", "title": "Artist performance variants and duplicate consolidation", "detail": "Represent recurring billing formats such as Full Band, Acoustic Duo and Party Band beneath one canonical Artist without collapsing genuinely separate acts. Add owned performance variants with stable IDs, and store both performanceVariantId and an immutable billed-name snapshot on each Event so public listings retain what was actually advertised while the canonical Artist profile aggregates all appearances. Search and Backline resolution may use supported name variants, location and identity evidence, but ambiguous side-projects or unrelated similarly named acts must route to review. Audit duplicate Artist records that are really performance variants, merge only with evidence, reassign Events safely and preserve aliases, provenance and redirects. This completes the partial ADR-023/name-variant foundation rather than introducing a competing Artist identity model." }, { "id": "canonical-artist-lifecycle", "rank": 8, "laneId": "intelligence", "title": "Canonical Artist lifecycle and discovery visibility", "detail": "Keep evidence-backed Artist identities canonical even when they have no upcoming gigs, while separating canonical existence from default public discovery. Classify Artists as active, historical, dormant or retired/duplicate/invalid. Active Artists have an upcoming public gig or a claimed published profile and appear normally; historical Artists retain their profile and past-event history but are excluded from default active browsing; dormant unclaimed Artists remain stable Claim, matching, deduplication and Backline-monitoring targets but are suppressed from normal discovery. A legitimate future Event or approved Claim reactivates a dormant Artist automatically. Merge or hide only evidence-backed duplicates, invalid identities and retired records, preserving provenance, redirects and audit history. Apply the existing gigging-only API capability consistently across bndy-app discovery surfaces instead of deleting useful canonical records." }, { "id": "favourite-feed", "rank": 9, "laneId": "core-discovery", "title": "Favourite feed", "detail": "Give signed-in people a personal activity feed covering the Artists and Venues they have favourited, including useful changes such as a newly added gig. Build this from canonical entity and event activity rather than introducing user posts, comments or a general social feed. Define the supported activity types, ordering, deduplication, read state and notification boundaries before delivery." }, { "id": "festival-pre-event-monitoring", "rank": 10, "laneId": "festivals", "title": "Adaptive Festival programme monitoring", "detail": "Add Festival-aware monitoring to Backline BAU so canonical programmes stay current as organisers change line-ups, stages, venues, dates, times and cancellations in the weeks before and during a Festival. Register each authoritative Festival and Venue programme source, capture immutable snapshots, increase checking cadence as the start date approaches, and emit only evidence-backed deltas into normal Claims and projection policy. Treat late additions and explicit cancellations as urgent; never infer cancellation solely because an item disappears from an incomplete or rolling listing. Record source freshness, last meaningful change and unresolved conflicts in Godmode, then taper and close monitoring after the Festival ends." }, { "id": "fizgig-backline-onboarding", "rank": 11, "laneId": "source-automation", "title": "Fizgig Backline source onboarding", "detail": "Fizgig's Lincolnshire and East Midlands gig data has already been ingested into canonical BNDY. First recover and record the import lineage, hydrate the corresponding canonical Artists, Venues and Events into Backline without recreating them, then capture a current source snapshot and resolve its source identities against that baseline. After fixture and snapshot-semantics checks, introduce one shadow BAU acquisition path for additions, changes and explicit removals, with ambiguity parked and canonical projection disabled until separately approved.", "evidence": [ "http://www.fizgig.epizy.com/fizgig-gigs.htm" ] }, { "id": "livebandphotos-backline-onboarding", "rank": 12, "laneId": "source-automation", "title": "Live Band Photos Backline source onboarding", "detail": "Live Band Photos data has already been ingested into canonical BNDY. Recover the canonical import lineage and hydrate those records into Backline first, then reconcile them against immutable evidence from the current gig listing, county Venue indexes and band directory. Delivery remains fixture-gated until query-string detail pages and complete-versus-rolling snapshot behaviour are proven. The provisional shadow BAU shape is a daily gig listing, weekly county and band indexes and monthly reconciliation, with no duplicate canonical creation, no inferred cancellation from an incomplete window and no canonical projection without separate approval.", "evidence": [ "https://www.livebandphotos.co.uk/" ] }, { "id": "venue-website-monitoring-workers", "rank": 13, "laneId": "venue-workers", "title": "Venue website monitoring workers", "detail": "Establish a Backline source family for known canonical Venues whose own websites publish reliable gig listings. Maintain a reviewed registry containing canonical Venue ID, authoritative listing URL, acquisition strategy, cadence, freshness and last successful scan. Capture immutable snapshots, resolve listings to the registered Venue, and emit only evidence-backed new or changed Event Claims through the normal Backline policy and projection path. Never infer cancellation solely because an item disappears unless the source semantics prove a complete programme or explicit cancellation. Track failures, meaningful deltas and useful discoveries in Godmode. Begin after the core Backline control plane and current named-source relaunch gates are healthy." }, { "id": "facebook-page-event-sharing", "rank": 14, "laneId": "meta-facebook", "title": "BNDY Facebook Page and event sharing", "detail": "Build the public BNDY Facebook Page into a credible front door for the product: complete branding, username, About copy, verified bndy.live and chat.bndy.live links, appropriate Page roles and security, action button, Messenger greeting, pinned Send to bndy explainer, initial content plan, moderation rules and basic Page-to-BNDY analytics. Make canonical BNDY Event pages share cleanly out to Facebook using strong Open Graph metadata, the normal web/native share journey and an optional Facebook Share Dialog; sharing publishes the BNDY link and never grants BNDY permission to post on a person’s behalf. For inbound contribution, let people send a Facebook Event URL, BNDY link, poster, screenshot or text to the BNDY Page through Messenger, verify the webhook, route it into Capture with idempotency and provenance, and return bounded acknowledgement and final outcomes. Do not describe the Meta developer app as a user-facing destination, and do not ingest visitor posts, comments or mentions until permissions, moderation, privacy and review requirements justify a later controlled extension.", "evidence": [ "https://developers.facebook.com/documentation/sharing/overview.md/", "https://developers.facebook.com/documentation/sharing/reference/share-dialog.md/", "https://developers.facebook.com/documentation/business-messaging/messenger-platform/get-started.md/", "https://developers.facebook.com/documentation/business-messaging/messenger-platform/webhooks.md/", "https://developers.facebook.com/documentation/business-messaging/messenger-platform/app-review.md/" ] }, { "id": "festival-add-claim-management", "rank": 15, "laneId": "festivals", "title": "Festival Add, Claim and management parity", "detail": "Extend the normal BNDY account and relationship model to Festivals. People should be able to find and claim an existing Festival page, safely add a genuinely new Festival, manage more than one Artist, Venue or Festival from the same account, invite legitimate collaborators and relinquish or transfer control without deleting the public record. Reuse the evidence-led Claim, conflict protection and review model rather than creating Festival-specific authentication or ownership shortcuts." }, { "id": "builder-curator-applications", "laneId": "rhythm", "title": "BNDY Builder applications and Curator approval", "detail": "Later, when the contributor community is large enough to need it, let people apply or be nominated as BNDY Builders and give platform administrators a simple approve, reject and access-scope journey. BNDY Builder is the user-facing contributor identity; Curator remains the trusted permission role. Rhythm history and verified contributions may inform a decision but must never grant write authority automatically. Reuse the existing Curator role, own-only, postcode and trusted/global access controls rather than creating another permission model.", "rank": 16 }, { "id": "builder-contribution-analytics", "laneId": "rhythm", "title": "BNDY Builder contribution analytics", "detail": "Later, provide useful contribution metrics for BNDY Builders and Curators, such as accepted gigs added, meaningful corrections, source freshness work, duplicate prevention and sustained local coverage. Metrics must reward verified quality rather than raw volume, expose enough evidence for accountability, resist gaming and feed Rhythm only after the scoring policy is agreed. Edition visits, embed views and click analytics remain part of Editions/traffic analytics and are not duplicated here.", "rank": 17 }, { "id": "multi-artist-event-indexing", "rank": 18, "laneId": "core-discovery", "title": "Multi-Artist event indexing and complete Artist gig history", "detail": "Low priority. Make every canonical Event discoverable from every participating Artist, not only its primary artist_id. Define and retain each Artist's billing role, maintain a reverse Artist-to-Event edge or equivalent queryable index across Event create, edit and delete, and backfill existing multi-Artist Events safely. Artist profiles, event counts, deletion guards and historical views must include headline, support and collaborating appearances without full-table scans. Select the smallest reliable DynamoDB implementation after measuring current access patterns; a separate join table is an option, not a pre-decided product requirement." }, { "id": "estate-wide-product-analytics", "rank": 19, "laneId": "analytics", "title": "Estate-wide product analytics coverage", "detail": "Extend privacy-friendly product analytics across every public browser surface, including www.bndy.co.uk and chat.bndy.live, and maintain one explicit coverage matrix for visits, submissions, successful additions, searches, shares, map interactions and PWA installs. Use aggregate, purpose-limited measurement without user profiling or fingerprinting. Audit cookies, local storage, pixels, SDKs and third-party embeds across the estate: Cloudflare Web Analytics may remain banner-free where it is confirmed cookieless, while any future non-essential storage or tracking must be blocked until valid consent under PECR and UK GDPR. Document essential authentication and security storage, retention and provider behaviour in the public privacy/cookie notice." }, { "id": "server-side-artist-browse", "rank": 20, "laneId": "core-discovery", "title": "Server-side Artist browse API", "detail": "The discover-lambda provides a server-side /api/artists/browse endpoint with faceted search, pagination, and an S3-backed search index rebuilt every 15 minutes. The current bndy-app uses client-side filtering over the full artist list, which works well at current scale. When the dataset grows significantly or SSR becomes important, switch the app to use the server-side browse endpoint. The endpoint returns card-format responses; switching requires mapping the response shape and adjusting facet counting to use server-provided facets instead of client-computed counts. Keep client-side filtering as the default until the dataset justifies the latency trade-off of server round-trips per filter change.", "evidence": [ "https://github.com/flowency-live/bndy-serverless-api/tree/main/discover-lambda" ] }, { "id": "repository-ownership-legacy-cleanup", "rank": 21, "laneId": "repo-consolidation", "title": "Repository ownership and legacy cleanup", "detail": "Low priority. Confirm the live dependency and deployment status of every plausible-looking BNDY repository, then assign each capability exactly one primary repository and one canonical backend path. Publish a concise ownership map. Archive obsolete repositories where safe, or add unmistakable legacy and do-not-use README banners where archival must wait. Preserve any useful history and do not disturb current bndy-app, API, Capture, Backline, Claims or deployment work." }, { "id": "deterministic-gig-artwork-creator", "rank": 22, "laneId": "core-discovery", "title": "Optional BNDY gig artwork creator", "detail": "Low priority. Let a claimed Artist, Venue or authorised Curator create tasteful shareable promotional artwork from a canonical BNDY Event without making posters mandatory for discovery. Populate date, time, billing, Venue and BNDY link directly from canonical data, then combine approved BNDY layouts with owner-supplied Artist, Venue or event imagery. Provide accessible aspect-ratio variants for social sharing and download. Do not generate fake bands, crowds or generic AI gig imagery, and do not turn generated artwork into a requirement for Map, List or Event visibility." }, { "id": "fantastic-all-library-automated-ingestion", "rank": 23, "laneId": "source-automation", "title": "Automate Fantastic All Library Facebook ingestion", "detail": "Find a way to automate ingestion of https://www.facebook.com/fantasticallibrary events. Currently requires manual copy-paste of the Facebook events page into a Cowork session, which is labour-intensive and error-prone. Investigate Facebook Graph API access, public event scraping within platform terms, RSS or iCal feeds, or a lightweight capture integration that can ingest new events without manual intervention. This is a high-value source covering library-hosted grassroots gigs and should be reliable rather than ad-hoc.", "evidence": [ "https://www.facebook.com/fantasticallibrary" ] }, { "id": "seo-grassroots-gig-discovery", "rank": 24, "laneId": "core-discovery", "title": "SEO activation for grassroots gig search visibility", "detail": "Improve search engine optimisation so that Google searches for grassroots live music discovery surface bndy.live in results. Target queries include: grass roots gigs, live music near me, live music near me tonight, music gigs around me, live bands pubs, local gig guide, whats on tonight live music, pub gigs near me, and variants. Audit current indexing, meta tags, structured data, sitemap coverage, page speed and mobile experience. Add Event, MusicEvent and Place schema markup where missing. Ensure artist, venue and gig pages have crawlable unique URLs with relevant titles and descriptions. Track search console performance and iterate. The goal is organic discovery growth without paid advertising." } ], "lanes": [ { "id": "core-discovery", "title": "Core live discovery", "objective": "Make bndy.live the best way to discover grassroots live music.", "health": "blue", "deliveryState": "building", "targetState": true, "repos": [ "app", "api", "mcp" ], "done": [ { "title": "bndy.live is the current public product", "detail": "Map, gig list, artist and venue profiles are on the bndy-app + canonical API stack." }, { "title": "Mobile gig-list UX heavily refined", "detail": "Search-first layout, compact filters, favourites and venue/mobile presentation have been iterated." }, { "title": "Ticketing surfaced at event and venue level", "detail": "Recent work makes ticketed status explicit without treating unknown admission as a reason to hide a gig." }, { "title": "Artist profile map includes recorded gig history", "detail": "The Artist Map view now combines upcoming public gigs with all recorded non-cancelled public history. Upcoming gigs remain solid orange, past gigs use muted markers, and repeat appearances at the same Venue aggregate into one counted marker. Initial framing favours upcoming gigs, while By Date and By Distance remain future-only. The result has been reviewed and approved in production.", "evidence": [ "https://github.com/flowency-live/bndy-app/pull/33" ] }, { "title": "Saved gigs and Going", "detail": "Signed-in people can privately save a gig and separately mark themselves as Going. Both account-backed intent states are live and remain private. They do not expose attendee lists or attendance counts, add curator recommendations, affect Scene or Ask bndy ranking, or introduce posts, comments or follower mechanics." }, { "title": "Map refactor complete", "detail": "The historical map-refactor plan is closed. The current production map experience is working and accepted, so no migration work remains scheduled from that document. Any future map work must be driven by a specific product outcome or defect." }, { "title": "Public gig wizard and Add entry", "detail": "The current bndy-app provides the public /add gig wizard and standalone /list-a-gig form, with a visible Add navigation entry, Artist and Venue profile prefills, calendar and busy-date context, session persistence, multi-act billing support and canonical community-event creation. The older FS-07 proposal is therefore complete rather than backlog work.", "evidence": [ "https://github.com/flowency-live/bndy-app/commit/9ea563db1eb8f68db443755f522eba4e6ef1f2a0", "https://github.com/flowency-live/bndy-app/commit/108b3290d865c889178cd4407ecf88db34978c6a" ] }, { "title": "Accounts, favourites and saved gig filters", "detail": "Signed-in accounts, Artist and Venue favourites, favourite filtering across gigs and the map, and reusable saved gig-filter presets are implemented in the current bndy-app. The older FS-08 proposal is therefore complete rather than backlog work. This does not complete the separately ranked Favourite feed, which remains a future canonical activity experience.", "evidence": [ "https://github.com/flowency-live/bndy-app/commit/200a4505cc2c824f025dfc932bc3f16d3b7f2c88", "https://github.com/flowency-live/bndy-app/commit/0b735b5ea0501155421ed6158034ec929ac3a453", "https://github.com/flowency-live/bndy-app/commit/81e9fcf7bcfb101b1b6b5d28fe26f4dc72a03760" ] }, { "title": "Canonical public CRUD uses canonical APIs", "detail": "New public add flows currently resolve data then write through the existing canonical backend." }, { "title": "Product UX is separated from evidence architecture", "detail": "The UI can stay simple while the backend moves from direct creation to claims/projection." }, { "title": "Ask bndy canonical MCP discovery foundation", "detail": "The first bounded foundation is merged in bndy-MCP: discover_events provides read-only canonical BNDY gig discovery across date, text, city, recorded ticketed/free state, open-mic and radius filters. It returns canonical IDs and BNDY URLs with explicit grounding metadata, excludes cancellations and has no mutation path. TypeScript build and all 43 tests passed. This completes only the MCP discovery tool, not the Ask bndy voice or conversational product.", "evidence": [ "https://github.com/flowency-live/bndy-MCP/pull/9" ] } ], "now": [ { "title": "Ask bndy voice-first grounded discovery", "detail": "The canonical read-only MCP discovery foundation is complete and recorded in DONE. The wider voice-first conversational product remains unfinished. No realtime voice, conversational orchestration or bndy-app UI slice is authorised or under implementation at this checkpoint.", "evidence": [ "https://github.com/flowency-live/bndy-MCP/pull/9" ] } ], "next": [ { "title": "Route assisted creation through shared evidence", "detail": "Artist, venue and gig creation should emit evidence/claims before projection rather than each surface inventing its own logic." }, { "title": "PWA install journey", "detail": "Finish the explicit Add to Home Screen/install experience requested by users." } ] }, { "id": "join-bndy", "title": "Add, Claim & Ownership", "objective": "Let one person find, add, claim and manage multiple Artists and Venues through clear relationship and ownership roles without creating duplicates or displacing an established owner.", "health": "amber", "deliveryState": "building", "targetState": false, "repos": [ "app", "api", "backstage", "enrichment", "website" ], "done": [ { "title": "JOIN-01 — Join shell", "detail": "/join, /join/artist and /join/venue are live product routes with a dedicated mobile-first onboarding feature rather than the Add utility UI." }, { "title": "JOIN-02 — identity before creation", "detail": "Artist canonical/variant/location resolution and Venue Google Place identity run before creation. Existing identities branch safely to Claim rather than duplicate creation." }, { "title": "JOIN-03 — auth + resume", "detail": "Existing bndy auth is reused, Join state survives auth redirects, and Venue Google Place details are rehydrated on return." }, { "title": "JOIN-04/05 — owned Artist and Venue creation", "detail": "Authenticated Join endpoints recheck identity at commit and create the entity plus initial owner relationship as one logical operation. Artist uses legacy artist memberships; Venue uses generic entity memberships." }, { "title": "JOIN-06 — Artist profile step", "detail": "Artist type, canonical act types, acoustic capability and canonical genres are captured in the lightweight Join step using the shared taxonomy." }, { "title": "JOIN-07 — Claim persistence and review", "detail": "CLAIM V2 LIVE. Existing-entity Claims capture relationship, requested role, explanation, official email and public supporting URL. They persist, appear to the claimant, and are reviewable in Godmode without overwriting the entity before verification. Godmode can approve, reject or request more evidence; the reviewer note and evidence follow-up loop are live in Manage.", "evidence": [ "https://github.com/flowency-live/bndy-app/pull/25", "https://github.com/flowency-live/bndy-app/pull/27", "https://github.com/flowency-live/bndy-serverless-api/pull/60", "https://github.com/flowency-live/bndy-serverless-api/pull/63", "https://github.com/flowency-live/bndy-backstage/pull/13", "https://github.com/flowency-live/bndy-backstage/pull/14" ] }, { "title": "JOIN-08 — management and delegation foundation", "detail": "/manage lists Artists, Venues and Claims. Venue delegates use expiring email-bound invite links and their own accounts; owners can revoke delegates and safely transfer Venue ownership." }, { "title": "JOIN-09 — owner authority protection", "detail": "Backline authority policy now blocks lower-authority automated mutations/destructive changes on owner-managed projections while retaining external evidence for conflict/review." }, { "title": "JOIN-10 - multi-entity and ownership foundation", "detail": "One account can already hold multiple active Artist and Venue relationships. Artist roles are owner/admin/member; Venue roles are owner/admin. New safe creation establishes the initial owner, existing entities enter Claim, and established ownership cannot be replaced silently. Venue delegation, ownership transfer and explicit Artist/Venue relinquish preserve the public entity.", "evidence": [ "https://github.com/flowency-live/bndy-app/commit/3c2deeb", "https://github.com/flowency-live/bndy-serverless-api/commit/7128e3d", "https://github.com/flowency-live/bndy-serverless-api/commit/904372b" ] }, { "title": "JOIN-11 - contextual Add, Find and multi-entity UX", "detail": "The signed-in account menu and Manage experience now use Add artist or venue, /join is framed as Find an artist or venue with signed-in context, and Manage always exposes an Add action while clearly covering entities the person owns, manages or participates in.", "evidence": [ "https://github.com/flowency-live/bndy-app/pull/34" ] }, { "title": "JOIN-12 - safe same-name, different-location continuation", "detail": "A person can now review same-name matches and explicitly choose Different artist in [location]. The decision uses the existing confirmNew dry-run and is carried through authenticated creation while API uniqueness and final race checks continue to block same-region duplicates.", "evidence": [ "https://github.com/flowency-live/bndy-app/pull/34" ] }, { "title": "JOIN-13 - truthful Facebook verification exposure", "detail": "The unavailable Facebook Page-control panel and internal Meta-access status have been removed from the public Claim journey. Manual evidence remains available. Facebook Page verification stays a separate future capability and will not be exposed until it works end to end.", "evidence": [ "https://github.com/flowency-live/bndy-app/pull/34" ] }, { "title": "JOIN-14 - Join navigation, location surface and accessibility", "detail": "/join now has safe back navigation, child-flow labels return to Find artist or venue, the Artist location suggestions use an opaque theme surface, and the Artist name and location labels are correctly associated with their inputs. PR CI passed typecheck, 257 tests and the production build; the no-rendered-em-dash check also passed.", "evidence": [ "https://github.com/flowency-live/bndy-app/pull/34", "https://github.com/flowency-live/bndy-app/actions/runs/33275435575", "https://github.com/flowency-live/bndy-app/actions/runs/33275435567" ] }, { "title": "Artist profile media and lightweight availability", "detail": "Staff, owners and admins can edit YouTube, Spotify, SoundCloud and Bandcamp links and manage bookable dates directly from the lightweight public Artist profile. Public media uses mobile-first, tap-to-load embeds with no autoplay. The approved public availability tab covers twelve months in compact three-month windows, supports an Artist booking message, and clearly distinguishes Available, Public gig and Private booking dates while leaving unlisted dates open to enquiry. Public gigs and private Backstage bookings protect those dates without exposing member-unavailability noise. The work reuses the canonical availability model and does not alter Claim creation, evidence or review.", "evidence": [ "https://github.com/flowency-live/bndy-app/pull/26", "https://github.com/flowency-live/bndy-serverless-api/pull/61", "https://github.com/flowency-live/bndy-app/pull/32", "https://github.com/flowency-live/bndy-serverless-api/pull/67" ] } ], "now": [ { "title": "JOIN-15 - production smoke and authenticated acceptance", "detail": "The Add, Find and same-name correction is merged to bndy-app main in PR #34, remains in current main and passed PR CI plus rendered-copy checks. Production deployment has not yet been independently confirmed. Confirm the live build, then complete signed-in multi-entity acceptance across new Artist, new Venue, existing-entity Claim, request-more-evidence, approval, conflict, delegate acceptance, ownership transfer and relinquish." }, { "title": "JOIN-16 - Facebook Page Claim verification rollout", "detail": "The capability-gated claimant UI is merged in bndy-app PR #35 and remains hidden while the API reports the capability unavailable. The rebuilt API exchanges the Meta code server-side, never stores or returns the user token, and accepts only a short-lived signed Page receipt bound to the same user and entity. Remaining gates are API publication and CI, secure Meta secret configuration, exact callback registration, bounded deployment and a truthful production screencast for pages_show_list App Review.", "evidence": [ "https://github.com/flowency-live/bndy-app/pull/35" ] } ], "next": [ { "title": "Claim authority projection acceptance", "detail": "The privacy-safe Claim stream and Backline consumer are deployed and CI-proven, but production synthetic acceptance did not prove the final authority record. Run a fresh bounded proof without making Backline transport a dependency of Claim success or enabling canonical writes." }, { "title": "Venue profile polish", "detail": "Add optional post-identity Venue music-specific profile fields after the core Add, Claim and ownership journey is coherent and accepted." } ] }, { "id": "festivals", "title": "Festivals", "objective": "Treat festivals as first-class discovery objects with child gigs/events.", "health": "green", "deliveryState": "live", "targetState": false, "repos": [ "app", "api" ], "done": [ { "title": "Core Festival support", "detail": "Festivals are implemented as first-class parent programmes over ordinary canonical gigs. The current app supports single-venue and town-wide multi-venue Festivals, multi-day schedules, dedicated discovery and detail pages, Schedule/Map/Info views, and curator creation and management. The older FS-11 core proposal is complete; public Add, Claim and collaborator parity remains separately ranked.", "evidence": [ "https://github.com/flowency-live/bndy-app/blob/main/FESTIVALS-V1-SPEC.md", "https://github.com/flowency-live/bndy-app/tree/main/src/features/festivals", "https://github.com/flowency-live/bndy-serverless-api/tree/main/festivals-lambda" ] }, { "title": "Publication-scope filtering added", "detail": "Festival visibility participates in edition/publication filtering alongside artists, venues and events." } ], "now": [], "next": [ { "title": "Festival ingestion through Enrichment", "detail": "Source-discovered Festival data should become evidence and claims, project into canonical Festivals and gigs under normal policy, then enter adaptive pre-event monitoring so programmes remain current through the event date." } ] }, { "id": "curators", "title": "Curators & Godmode", "objective": "Delegate local data stewardship safely without giving every curator global write access.", "health": "green", "deliveryState": "building", "targetState": false, "repos": [ "app", "api", "backstage" ], "done": [ { "title": "Postcode-area restrictions", "detail": "Curator access policies can be limited by configured postcode areas." }, { "title": "Ownership restrictions", "detail": "Curators can be restricted to records they created, while trusted curators can be broader." }, { "title": "Godmode policy editor", "detail": "Backstage has curator permission management and creator provenance is recorded by public wizards." } ], "now": [ { "title": "Production verification", "detail": "Exercise postcode, own-only and trusted/global combinations against Artists, Venues, Events and Festivals in production. Festival acceptance must cover both single-Venue and multi-Venue programmes, including rejection when any linked Venue falls outside the Curator’s permitted postcode scope." } ], "next": [ { "title": "Curator dashboard", "detail": "Give curators a clear view of their area, records, outstanding quality issues and recent submissions." } ] }, { "id": "rhythm", "title": "BNDY Rhythm / Curator rewards", "objective": "Turn high-quality community contribution into durable provenance, trusted human verification and meaningful progression without making Beats a gameable currency.", "health": "amber", "deliveryState": "building", "targetState": true, "repos": [ "app", "api", "enrichment", "backstage", "website" ], "done": [ { "title": "Detailed product and solution PRD committed", "detail": "BNDY Rhythm is specified as Beats + Trust + local authority + Backline Bounties, with an append-oriented contribution/reward ledger and explicit future gates for Credits, ownership and tokenisation.", "evidence": [ "https://github.com/flowency-live/bndy-website/blob/main/docs/BNDY-RHYTHM-CURATOR-REWARDS-PRD.md" ] }, { "title": "Core product boundary decided", "detail": "Beats recognise accepted contribution; Trust controls Backline influence. Beats launch non-transferable, non-purchasable, non-cash and off-chain." } ], "now": [ { "title": "RHY-00 - architecture and policy contract", "detail": "Define contribution taxonomy, musical reward subunits, reward lifecycle, Trust dimensions, Scene Trust geography, owner/self rules, Backline Claim mapping, abuse policy and plain-English Beats terms before visible points UI." } ], "next": [ { "title": "RHY-01 - contribution ledger foundation", "detail": "Instrument eligible curator actions into durable Contribution and append-oriented Reward Ledger records with idempotency and auditable reward decisions." }, { "title": "RHY-02/03 - Backline human claims and reward settlement", "detail": "Make curator assertions first-class Backline evidence/Claims, apply contextual authority and settle rewards only when contribution value is accepted/corroborated." }, { "title": "RHY-04/05 - Trust, ranks and UX", "detail": "Build global/local Trust projections, capability gates, Listener-to-Scene-Keeper progression, musical totals and local recognition." }, { "title": "RHY-06 - Backline Bounties", "detail": "Turn unresolved/conflicted Backline knowledge into targeted local human verification tasks with auditable Beat/Bar rewards." }, { "title": "Future economic gates", "detail": "Keep commercial Credits, community ownership and any tokenisation as separate future decisions. Do not create a Beat-to-money or Beat-to-equity promise." } ] }, { "id": "facebook-artist-assist", "title": "Facebook artist assist", "objective": "Paste a Facebook artist URL and let BNDY resolve enough trustworthy data to make creation effortless.", "health": "green", "deliveryState": "live", "targetState": false, "repos": [ "app", "api" ], "done": [ { "title": "Facebook source inspector", "detail": "Backend handles About data, mbasic/title fallbacks, profile wrappers and rejects Facebook login/error/system identities." }, { "title": "Artist form prefill", "detail": "Standalone Add Artist and Add Gig can prefill source-backed name/location/bio/website hints and persist them." }, { "title": "Inspector route hardened", "detail": "Recent deploy work keeps the companion source-inspector route present after normal API deployments." } ], "now": [], "next": [ { "title": "Converge Facebook-assisted creation with evidence projection", "detail": "The resolver helps the UI, but accepted data is still written directly through canonical creation rather than becoming durable claims first. Preserve the working human Add journey until the Backline Observation, Claim and projection path is production-ready, then migrate without adding visible friction or risking lost submissions." }, { "title": "Converge with Enrichment evidence model", "detail": "Reuse the same Observation/Extraction/Interpretation/Claim pipeline used by automated ingestion." }, { "title": "Show evidence confidence in the form", "detail": "Differentiate observed Facebook facts, inferred values and mere handle/name hints." } ] }, { "id": "chatzone", "title": "chat.bndy.live public ingestion", "objective": "Let anyone submit a gig poster or event text and get a useful, low-friction result.", "health": "amber", "deliveryState": "live", "targetState": false, "repos": [ "chatzone", "capture", "enrichment" ], "done": [ { "title": "Disconnected from bndy-signals", "detail": "The public Dropzone no longer uses the old Signals/Textract/Haiku claims UI." }, { "title": "Multimodal poster interpretation", "detail": "Poster processing uses the actual image in the Capture/Enrichment path, avoiding OCR-only mistakes." }, { "title": "Useful result response", "detail": "Added/already-existing results show artist, venue, date/time and a direct bndy.live gig link." } ], "now": [ { "title": "Send to bndy production qualification", "detail": "The mobile-first poster, screenshot, link and event-text intake is merged and under live production testing. Confirm truthful processing and recovery across real poster and text submissions, including partial matches, human-review outcomes, canonical additions, duplicates and final Artist, Venue, date and time findings. Close only when the UI consistently returns the outcome Capture actually produced.", "evidence": [ "https://github.com/flowency-live/bndy-chatzone/pull/3", "https://github.com/flowency-live/bndy-chatzone/pull/4", "https://github.com/flowency-live/bndy-chatzone/pull/6", "https://github.com/flowency-live/bndy-chatzone/pull/7", "https://github.com/flowency-live/bndy-chatzone/pull/8" ] }, { "title": "Immediate Capture dispatch and retry-safe processing", "detail": "PR #134 reconciles the immediate Capture dispatch already observed in production with source-controlled retry safety, preserved review context and canonical start-time defaults. Keep this active until the controlled Capture Processor and Capture Scanner deployment is complete and live text and poster submissions prove prompt dispatch without duplicate processing.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/pull/134" ] } ], "next": [ { "title": "Representative reliability qualification", "detail": "Build a repeatable poster, screenshot, link and event-text cohort that measures extraction, identity resolution, deduplication and uncertain-result handling before the feature is treated as production-solid." }, { "title": "Enqueue immediately on submission", "detail": "Send the Capture message to the processing queue at create time and keep the scanner only as a recovery safety net." }, { "title": "Richer live progress", "detail": "Show resolving artist, matching venue, deduping event and final result rather than a generic spinner." } ] }, { "id": "capture", "title": "Send to bndy / Capture transport", "objective": "One durable intake layer for Android, web, WhatsApp, Messenger and future channels.", "health": "green", "deliveryState": "live", "targetState": false, "repos": [ "capture", "enrichment" ], "done": [ { "title": "Android share target", "detail": "Send to bndy accepts shared URLs/text/images, writes locally first and syncs to capture.bndy.co.uk." }, { "title": "Durable AWS backlog", "detail": "Capture API, DynamoDB and S3 provide transport-independent evidence storage and processing state." }, { "title": "Facebook event sharing proven", "detail": "Opaque Facebook /share URLs are resolved to exact canonical event URLs, deduped and projected safely." }, { "title": "Public Dropzone transport added", "detail": "chat.bndy.live uses the same Capture intake instead of a parallel backend." }, { "title": "Capture transport and resolution boundary established", "detail": "It is the transport/backlog. bndy-enrichment performs interpretation, matching and canonical projection." }, { "title": "Shared Send to bndy intake contract implemented", "detail": "Capture now has stable transport idempotency, structured sanitised public outcomes including needs_review, compatible web and Android contracts, and a verified disabled-by-default WhatsApp transport boundary. WhatsApp production activation remains separately controlled.", "evidence": [ "https://github.com/flowency-live/bndy-capture/pull/4" ] } ], "now": [ { "title": "Capture review and follow-up contract", "detail": "Complete the controlled review-loop delivery in PR #5: persist retry-safe immediate dispatch in source, retain human-review context, store optional per-submission follow-up contact separately with expiry, and expose bounded internal review and notification contracts. Keep WhatsApp disabled. Close only after a reviewed Capture change set deploys without resource deletion or replacement and the Chatzone follow-up journey passes end to end.", "evidence": [ "https://github.com/flowency-live/bndy-capture/pull/5" ] } ], "next": [ { "title": "Immediate queue dispatch", "detail": "Remove the normal-path dependency on the five-minute scanner." }, { "title": "Transport idempotency", "detail": "Add stronger submission idempotency and lease recovery for unattended/high-volume use." } ] }, { "id": "intelligence", "title": "BNDY Backline", "objective": "Make sources produce evidence and atomised claims; let policy derive BNDY truth.", "health": "amber", "deliveryState": "building", "targetState": true, "repos": [ "enrichment", "api", "backstage", "app", "capture", "mcp", "ops", "signals" ], "done": [ { "title": "Target architecture defined", "detail": "bndy-enrichment documents Observation, Extraction, Interpretation, Claim, EvidencePack, authority policy, tombstones and projection workers." }, { "title": "Durable knowledge substrate exists", "detail": "Immutable source evidence is stored in the existing S3 EvidenceBucket. Observation, Claim, Source Registry/State and Tombstone records live in the existing DynamoDB StateTable; WP-02 deliberately added no new DynamoDB table." }, { "title": "Claims are atomised database records", "detail": "A Claim is one subject-predicate-value assertion linked back to an Observation/evidence source. Claims are single-copy durable records with indexes by observation and subject, rather than duplicated whole Artist/Venue/Event documents." }, { "title": "Graph is a derived view, not the authority", "detail": "The KLMA vertical slice materialises graph.json and graph.html from claims and can add resolved canonical BNDY nodes. Future Neptune is explicitly allowed only as a projection/index; S3 evidence plus DynamoDB observations/claims remain authoritative." }, { "title": "Strategic projection worker exists", "detail": "The projection engine consumes durable Claims, applies predicate-specific authority, owner protection and tombstones, then writes through canonical BNDY APIs with read-back verification." }, { "title": "KLMA dual-path vertical slice proven", "detail": "A live KLMA source fetch has been proven through Observation + Claims + graph-shaped knowledge and additive canonical BNDY projection with production read-back verification.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/commit/6fd66f4314fc35900dcb2bfbba263a8fb897eb4b" ] }, { "title": "Capture interpretation runs in Enrichment", "detail": "Facebook events and posters already use the newer enrichment runtime for resolution." }, { "title": "Canonical APIs remain the write boundary", "detail": "Artist, venue and event uniqueness/dedupe is enforced centrally." }, { "title": "Canonical BNDY baseline complete", "detail": "The existing BNDY corpus is now represented in Backline in shadow mode: 15,288 logical entities and Observations, 518,131 Claims, 15,288 Resolutions and 15,288 immutable evidence objects, with zero recorded baseline errors.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/blob/main/docs/backline-live-audit.json" ] }, { "title": "National Lemonrock bootstrap completed in AWS", "detail": "COMPLETE LIVE SHADOW. The single owned national reconciliation run-907eba4a-b7eb-4d41-95f5-06bbc91beef4 passed its terminal manifest at 22:44 UTC on 27 Aug. All 28,504 logical tasks completed with zero failures; active queue and DLQ are zero; directory and future-gig inventory controls pass. The corpus contains 7,787 discoverable future Gig identities, 2,220 Venue identities and 2,254 Artist identities. The 74-item gap against Lemonrock's earlier advertised count is covered by explicit terminal 410 evidence, not fabricated identities or inferred cancellations. Immutable evidence, Observations and Claims remain in shadow mode and canonical writes remain disabled.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/blob/main/ops/lemonrock-reconciliation-manifest.json", "https://github.com/flowency-live/bndy-enrichment/blob/main/ops/lemonrock-historical-failure-quarantine.json", "https://github.com/flowency-live/bndy-enrichment/actions/runs/33120136044", "https://github.com/flowency-live/bndy-enrichment/actions/runs/33123589794" ] }, { "title": "Multi-source Backline Explorer deployed", "detail": "The deployed Backstage Godmode is a read-only operational inspector for Lemonrock, On The Case, KLMA, GigsNews and the Trust Loop. Its latest qualification record is the explicit-contract Gemini 3.6 Flash cohort: 20 completed responses across 10 Artists and 10 Venues, 15 high-confidence identities, 5 safe abstentions, zero admitted facts, 67 uncited facts quarantined, $0.66234 measured cost and zero canonical writes. The read-only publication succeeded and the provider remains unqualified and unscheduled.", "evidence": [ "https://github.com/flowency-live/bndy-backstage/blob/main/client/src/pages/godmode/enrichment/BacklineExplorer.tsx", "https://github.com/flowency-live/bndy-backstage/pull/4", "https://github.com/flowency-live/bndy-backstage/pull/9", "https://github.com/flowency-live/bndy-serverless-api/pull/58", "https://github.com/flowency-live/bndy-enrichment/actions/runs/33205085332", "https://backstage.bndy.co.uk/godmode/enrichment", "https://github.com/flowency-live/bndy-backstage/pull/10", "https://github.com/flowency-live/bndy-backstage/pull/11", "https://github.com/flowency-live/bndy-enrichment/actions/runs/33206574422", "https://github.com/flowency-live/bndy-enrichment/actions/runs/33214350278", "https://github.com/flowency-live/bndy-backstage/pull/12", "https://github.com/flowency-live/bndy-enrichment/pull/92", "https://github.com/flowency-live/bndy-enrichment/pull/93", "https://github.com/flowency-live/bndy-enrichment/actions/runs/33245560046", "https://github.com/flowency-live/bndy-backstage/commit/b6ae0efeb03c59cf0db7b66e1e5ea230b039dd55", "https://github.com/flowency-live/bndy-enrichment/pull/96", "https://github.com/flowency-live/bndy-enrichment/pull/97", "https://github.com/flowency-live/bndy-enrichment/actions/runs/33246356714", "https://github.com/flowency-live/bndy-enrichment/actions/runs/33250186946", "https://github.com/flowency-live/bndy-enrichment/blob/main/ops/enrichment/google-pse-gemini-structured-unreviewed.json", "https://github.com/flowency-live/bndy-enrichment/actions/runs/33264108261", "https://github.com/flowency-live/bndy-enrichment/blob/main/ops/enrichment/gemini-grounded-explicit-contract-20-case-unreviewed.json", "https://github.com/flowency-live/bndy-enrichment/blob/main/ops/enrichment/gemini-grounded-explicit-contract-20-case-review.md", "https://github.com/flowency-live/bndy-enrichment/pull/108", "https://github.com/flowency-live/bndy-enrichment/pull/110", "https://github.com/flowency-live/bndy-enrichment/pull/111", "https://github.com/flowency-live/bndy-enrichment/actions/runs/33264551514" ] }, { "title": "Bounded evidence graph reader v1 shipped", "detail": "Backline already has an indexed, read-only one-hop graph reader, admin API and static operator view spanning Sources, Observations, Claims, candidate identities, Resolutions and canonical entities. The remaining product work is to populate source-resolution/conflict state consistently and embed this capability in Godmode, not to invent another graph store.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/blob/main/src/knowledge/graph-read.ts", "https://github.com/flowency-live/bndy-enrichment/blob/main/src/handlers/backline-admin-api.ts", "https://github.com/flowency-live/bndy-enrichment/blob/main/ops/explorer/backline-explorer.html" ] }, { "title": "Cowork operational repository connected", "detail": "flowency-live/bndy-ops is now the versioned operational evidence source for still-running Cowork writers. Its task definitions, captures, cursors and current state are useful supporting evidence, but mutable snapshots alone do not prove canonical activity. The shared run contract now requires append-only JSON per run, a human report, CTO inbox entry and canonical API read-back.", "evidence": [ "https://github.com/flowency-live/bndy-ops", "https://github.com/flowency-live/bndy-ops/blob/main/RUN-CONTRACT.md", "https://github.com/flowency-live/bndy-ops/blob/main/RUN-LEDGER-SCHEMA.json" ] }, { "title": "Reusable source-ingestion blueprint committed", "detail": "The Lemonrock implementation, durable evidence/Claim model, AWS runtime, recovery controls, source definition of done and a concrete On The Case Music design are documented as the handover pattern for future sources.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/blob/main/docs/BACKLINE-SOURCE-INGESTION-BLUEPRINT.md" ] }, { "title": "Lemonrock low-cost steady state deployed", "detail": "VERIFIED BAU SHADOW. Hourly new-gig and explicit-cancellation sweeps, a daily bounded future-health check and monthly future reconciliation remain deployed. Artist and Venue directories are unscheduled; profiles hydrate only when referenced by gigs. Source worker concurrency remains capped at two, shadow mode remains on and canonical writes remain off.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/blob/main/ops/lemonrock-low-cost-operating-status.json", "https://github.com/flowency-live/bndy-enrichment/blob/main/ops/lemonrock-reconciliation-manifest.json" ] }, { "title": "On The Case gig-led adapter merged", "detail": "On The Case now has source-native IDs, structural safety gates, bounded gig -> venue -> band fanout, unresolved open-mic/buskers handling, hourly gig scheduling, owned reconciliation lineage and completion controls. Canonical writes remain off.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/pull/25" ] }, { "title": "GigsNews stale-edition protection", "detail": "A stale rendered edition is downgraded from complete so it cannot generate destructive withdrawals." }, { "title": "Scenic Eye adapter merged shadow/manual", "detail": "Scenic Eye weekly-edition ingestion is implemented with derived identities and stale-edition protection. It remains unscheduled pending a source-specific cadence decision.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/pull/27" ] }, { "title": "Insangel and Norfolk reconnaissance retained", "detail": "Both sources are explicitly fixture/AWS-reachability gated. No blind adapters or acquisition-evasion work will proceed.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/pull/26" ] }, { "title": "On The Case feed status", "detail": "HEALTHY LIVE SHADOW. Owned gig-led reconciliation on 27 Aug completed 145/145 scoped tasks with zero failures: 1 gig index, 29 gig-linked venue hydrations and 115 gig-linked band hydrations. Shared duplicate-Claim persistence and failed-task replay defects are fixed; explicit reconciliations now carry complete gig -> venue -> band lineage while BAU retains daily venue / weekly band dedupe. Directory roots remain manual audit/bootstrap paths. Canonical writes remain disabled.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/blob/main/ops/onthecase-reconciliation-manifest.json", "https://github.com/flowency-live/bndy-enrichment/blob/main/ops/onthecase-live-probe.json" ] }, { "title": "GigsNews weekly shadow activated", "detail": "GigsNews is deployed as the fourth live Backline shadow source on a weekly standard-runtime cadence. Production evidence is immutable, the source is incremental and append-only, Cowork retains writer authority, disappearance is not cancellation evidence, and canonical writes remain disabled. The live quality-proof cohort contains current GigsNews Artists, Venues and Events with no booking/contact footer artefacts.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/blob/main/ops/trust-loop-v1-manifest.json", "https://github.com/flowency-live/bndy-enrichment/actions/runs/33180195595", "https://github.com/flowency-live/bndy-enrichment/pull/73" ] }, { "title": "Complete repaired grounded enrichment recapture failed closed", "detail": "The approved one-shot citation-mapped recapture completed all 20 public Artist and Venue cases in shadow with zero provider errors. Seventeen identities were high-confidence and three ambiguous cases safely abstained. The strict evidence gate accepted zero facts and quarantined 99 proposals because their citations were not present as exact captured provider evidence. Measured complete-path cost was $1.8712. Canonical writes remained zero, and the provider remains unqualified and unscheduled.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/actions/runs/33202407979", "https://github.com/flowency-live/bndy-enrichment/blob/main/ops/enrichment/gemini-grounded-unreviewed.json", "https://github.com/flowency-live/bndy-enrichment/blob/main/ops/enrichment/gemini-grounded-review.md", "https://github.com/flowency-live/bndy-enrichment/pull/77", "https://github.com/flowency-live/bndy-enrichment/pull/80", "https://github.com/flowency-live/bndy-enrichment/pull/81", "https://github.com/flowency-live/bndy-serverless-api/pull/59", "https://github.com/flowency-live/bndy-backstage/pull/6", "https://github.com/flowency-live/bndy-enrichment/actions/runs/33206067020", "https://github.com/flowency-live/bndy-enrichment/pull/84", "https://github.com/flowency-live/bndy-enrichment/pull/87" ] }, { "title": "Human review operating model defined", "detail": "Human adjudication is a bounded commissioning and exception-control mechanism, not a daily Product Owner dependency and not model fine-tuning. Qualification reviews known answers to prove the provider and thresholds. BAU automatically accepts only facts that pass hard identity and exact citation rules, automatically parks uncertainty, and sends only genuine conflicts plus a small periodic quality sample to designated reviewers. The Product Owner approves provider activation and canonical projection policy.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/blob/main/docs/ENRICHMENT-PROVIDER-QUALIFICATION.md", "https://github.com/flowency-live/bndy-enrichment/pull/86" ] }, { "title": "Gemini inline grounding citation repair merged", "detail": "The 20-case proof showed that Gemini Search completed reliably but structured-output mode omitted the inline url_citation annotations required by Backline. The repaired adapter now keeps one model call, requests ordinary grounded output shaped as JSON, preserves official inline citation URLs and cited text, ignores empty search queries in usage accounting, validates the response with the strict schema, and continues to quarantine arbitrary or uncaptured URLs. All 303 tests and the TypeScript build pass. No provider call or canonical write was made by the repair.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/pull/88", "https://github.com/flowency-live/bndy-enrichment/actions/runs/33207719876", "https://ai.google.dev/gemini-api/docs/google-search" ] }, { "title": "Inline-citation live proof failed closed", "detail": "The separately approved one-shot proof attempted the same 10 Artist and 10 Venue cases with one grounded Gemini call per case and at most two requested searches. All 20 provider responses returned, but none conformed to Backline's strict fact schema: identityReason was absent in every response, with additional facts-array and evidenceUrls shape defects. Backline accepted zero facts, activated no schedule and made zero canonical writes. The committed legacy artefact reports a zero measured subtotal because its parse-error path discarded usage; provider calls did occur, so total cost is explicitly unavailable rather than zero. PR 90 repairs that evidence ledger for future failures. The provider remains unqualified and unscheduled.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/pull/89", "https://github.com/flowency-live/bndy-enrichment/actions/runs/33214350278", "https://github.com/flowency-live/bndy-enrichment/blob/main/ops/enrichment/gemini-grounded-unreviewed.json", "https://github.com/flowency-live/bndy-enrichment/blob/main/ops/enrichment/gemini-grounded-review.md", "https://github.com/flowency-live/bndy-enrichment/pull/90", "https://github.com/flowency-live/bndy-backstage/pull/12", "https://github.com/flowency-live/bndy-enrichment/pull/92", "https://github.com/flowency-live/bndy-enrichment/pull/93", "https://github.com/flowency-live/bndy-enrichment/actions/runs/33245560046" ] }, { "title": "Split search and structured reasoning path merged inactive", "detail": "Backline now has a tested v2 qualification adapter that captures at most two explicit Google Programmable Search result sets, then gives Gemini only that fixed public evidence allow-list for one stateless schema-constrained reasoning call with no browsing tool. Exact citation, requested-predicate, token, deadline and cost controls fail closed, including preservation of public evidence and measured usage on schema errors. The command is inactive: no credentials, Lambda wiring or schedule were added, no provider call was made and canonical writes remain zero. Repository CI passed all 48 test files and 311 tests.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/pull/98", "https://github.com/flowency-live/bndy-enrichment/blob/main/docs/ENRICHMENT-PROVIDER-QUALIFICATION.md", "https://github.com/flowency-live/bndy-enrichment/blob/main/src/enrichment/providers/google-programmable-search.ts", "https://github.com/flowency-live/bndy-enrichment/blob/main/src/enrichment/providers/gemini-structured-reasoner.ts" ] }, { "title": "Google Programmable Search qualification failed closed", "detail": "The separately approved one-shot split-provider qualification attempted the existing 10 Artist and 10 Venue cohort in production shadow. Every case stopped on its first Google request with 403 PERMISSION_DENIED because the project does not have access to the Custom Search JSON API. Google now documents the API as closed to new customers. No Gemini reasoning call ran, no facts were accepted, no schedule or provider activation occurred, estimated spend was unavailable with no measured usage, and canonical writes remained zero. The public failure artefact and review were committed and the capture-failed result was published read-only to Godmode. The provider remains unqualified and unscheduled; another run requires a supported evidence-search provider and separate approval.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/pull/99", "https://github.com/flowency-live/bndy-enrichment/actions/runs/33250186946", "https://github.com/flowency-live/bndy-enrichment/blob/main/ops/enrichment/google-pse-gemini-structured-unreviewed.json", "https://github.com/flowency-live/bndy-enrichment/blob/main/ops/enrichment/google-pse-gemini-structured-review.md", "https://developers.google.com/custom-search/v1/overview" ] }, { "title": "Explicit-contract Gemini qualification failed closed", "detail": "The approved one-shot cohort ran exactly 20 Gemini 3.6 Flash calls over the existing 10 Artist and 10 Venue cases. All responses completed and passed the JSON contract. Google grounding executed 43 searches, with Neovenator using 3 and The Humbuckers 4 despite the two-search request. Measured cost was $0.66234 against the $0.60 reservation. Gemini proposed 67 facts but supplied zero provider url_citation annotations, so Backline quarantined every fact and admitted none. Five ambiguous identities safely abstained. The public artefact and review are committed, the exact status is live read-only in Godmode, canonical writes remain zero and the provider remains unqualified and unscheduled.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/actions/runs/33264108261", "https://github.com/flowency-live/bndy-enrichment/blob/main/ops/enrichment/gemini-grounded-explicit-contract-20-case-unreviewed.json", "https://github.com/flowency-live/bndy-enrichment/blob/main/ops/enrichment/gemini-grounded-explicit-contract-20-case-review.md", "https://github.com/flowency-live/bndy-enrichment/pull/108", "https://github.com/flowency-live/bndy-enrichment/pull/110", "https://github.com/flowency-live/bndy-enrichment/pull/111", "https://github.com/flowency-live/bndy-enrichment/actions/runs/33264551514", "https://backstage.bndy.co.uk/godmode/enrichment" ] }, { "title": "Interactions evidence-first citation proof passed on Whittles Oldham", "detail": "The new inactive Gemini Interactions evidence-first adapter uses one deterministic tab-delimited IDENTITY line plus zero or more FACT lines and admits a fact only from provider url_citation metadata bound to that fact segment. The approved Whittles Oldham shadow proof made one Gemini 3.6 Flash call and two Google searches, returned six provider citations and admitted five venue facts at a measured $0.02963275 within the $0.05 reservation. The full provider response is public. Canonical writes were zero, no schedule was created and the provider remains inactive. The response also exposed cumulative citation ranges starting at offset zero; PR 116 tightens binding to the FACT line containing each citation end offset and is green but awaiting explicit merge approval. This is a one-venue transport/evidence-contract proof, not provider qualification.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/pull/114", "https://github.com/flowency-live/bndy-enrichment/commit/937db16e1da5231ab76755cd824eca18a6b209ab", "https://github.com/flowency-live/bndy-enrichment/blob/main/ops/enrichment/gemini-interactions-evidence-first-whittles-oldham-unreviewed.json", "https://github.com/flowency-live/bndy-enrichment/pull/116" ] }, { "title": "Lemonrock national bootstrap complete and gate-passed", "detail": "run-907eba4a: 28,504/28,504 tasks terminal, 0 failed, queues and DLQ empty. Artists 10,587 vs 10,533 advertised; venues 8,341 vs 8,287; future gigs covered with the residual 74 closed as terminal-gone evidence. Low-cost BAU deployed: hourly new-gig/cancellation sweeps, daily health, monthly reconciliation, gig-led hydration.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/blob/main/ops/lemonrock-reconciliation-manifest.json", "https://github.com/flowency-live/bndy-enrichment/blob/main/ops/lemonrock-low-cost-operating-status.json" ] }, { "title": "Evidence-first citation transport proven and hardened", "detail": "Whittles Oldham one-case proof: 5 admitted facts from 6 provider citations at $0.0296, zero writes. PR 116 merged 2026-08-29: citations bind to the FACT line containing their end offset, preventing backwards evidence leakage. Safe redirect-destination resolution (SSRF-guarded, fail-closed) added for grounding URLs.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/pull/116", "https://github.com/flowency-live/bndy-enrichment/blob/main/src/enrichment/citation-destination.ts" ] }, { "title": "CTO audit passed: technical excellence and low running cost", "detail": "29 Aug CTO audit: architecture matches the documented model, 340 tests green, fail-closed discipline throughout. AWS steady state ~$8-20/month; enrichment hard-capped $0.60/day. Open operational risks: no CloudWatch alarms, legacy discovery worker write grants, no integration tests.", "evidence": [ "https://github.com/flowency-live/bndy-ops/blob/main/cto/BACKLINE-CTO-AUDIT-2026-08-29.md" ] }, { "title": "Production safety and canonical convergence proven", "detail": "The 31 Aug production audit found BndyEnrichmentStack IN_SYNC, all 39 source records shadow=true, global canonical projection default-off, canonical streams disabled and legacy Signals schedules disabled. The approved 1 Sep delta hydration then converged Backline with current canonical BNDY: 17,716 scanned, 2,494 inserted, 2,105 modified, 66 removals represented, 169,053 Claims written and 13,117 checkpoints backfilled, with zero errors and zero canonical writes.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/commit/fd322b1", "https://github.com/flowency-live/bndy-enrichment/pull/135" ] }, { "title": "Canonical convergence and graph visibility shipped", "detail": "Godmode now exposes canonical hydration state, projection control state and a bounded intelligence graph. The read path was deployed without an enrichment CDK deployment. Canonical projection remains disabled-default.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/pull/135", "https://github.com/flowency-live/bndy-serverless-api/pull/76", "https://github.com/flowency-live/bndy-backstage/pull/19", "https://backstage.bndy.co.uk/godmode/enrichment" ] }, { "title": "Lemonrock occurs-at defect repaired in Backline", "detail": "The shared ProjectionDLQ exposed a Lemonrock event projection defect: occursAt Claims lacked venueLocation. The source was contained, parser and projection handling were repaired, and 8,306 evidence-backed repair Claims were written to Backline under run lemonrock-occurs-at-repair-write-2026-09-02-v1. Seventeen candidates remain explicitly unresolved. A 100-message pilot and 252 further bounded messages replayed successfully in shadow with no canonical writes." }, { "title": "OnTheCase repair path merged", "detail": "PR 140 merged as 32f957c. New OnTheCase observations derive venue locality from structured address evidence and the repository now contains a gated, read-only-first historical repair CLI. CI passed 64 test files and 405 tests. No deployment or OnTheCase repair write has occurred.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/pull/140" ] }, { "title": "OnTheCase historical repair plan passed", "detail": "Read-only run onthecase-occurs-at-repair-plan-2026-09-03 inspected 210 Observations and 278 event candidates. All 278 are repairable from their retained event-address Claims; none require a venue-Claim fallback, none are unresolved and no errors occurred. ProjectionQueue remained empty and ProjectionDLQ remained stable at 10,909. No Claims were written." }, { "title": "OnTheCase historical Claims repaired", "detail": "Approved write run onthecase-occurs-at-repair-write-2026-09-03-v1 completed in 37 seconds. It inspected 278 candidates and wrote exactly 278 provenance-linked venueLocation repair Claims from retained event-address evidence, with zero unresolved cases, zero errors and an independent count of 278. ProjectionQueue stayed empty, ProjectionDLQ stayed at 10,909, both affected sources remained disabled and shadowed, the OnTheCase rule remained disabled and canonical projection remained disabled." }, { "title": "Corrected SourceWorker code deployed", "detail": "The existing SourceWorker BndyEnrichmentStack-SourceWorker336FEA29-ghZk2mBRjOks was updated code-only from exact bndy-enrichment merge commit 32f957c using aws lambda update-function-code. CodeSha256 changed from FjlxSVGSQr5/v0PicpicZYag/eM8PqPgBgL8coBirXg= to L/TK4YpWp6lHpCvJJzXYdOn7ruYYsaBsXdUMKBzsszs=. The function is Active with LastUpdateStatus Successful and reported runtime, handler, memory, timeout, role and environment unchanged. No CDK, SAM or CloudFormation deployment ran.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/commit/32f957c1b29fc85d6fb02e8aec48882ff10bcdad" ] }, { "title": "Corrected SourceWorker deployment verified", "detail": "The corrected SourceWorker was deployed code-only from the reviewed OnTheCase repair merge. The built artefact matches the deployed code, Lambda configuration remained unchanged, no infrastructure deployment occurred, operational queues remained stable, both affected sources remained contained and canonical projection remained off.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/commit/32f957c1b29fc85d6fb02e8aec48882ff10bcdad" ] }, { "title": "Initial OnTheCase replay attempt stopped safely", "detail": "The initial bounded replay stopped safely because historical recovery work from multiple sources shares the same queue. No messages were transferred or deleted and the contained system state was preserved." } ], "now": [ { "title": "ProjectionDLQ recovery is contained and source-specific", "detail": "ProjectionDLQ is stable at 10,909 historical event-create messages. A 550-message composition sample found only lemonrock-gig-hydration (58.7%) and onthecase-gig-index (41.3%). Both producers are now disabled and shadow=true. OnTheCase's hourly EventBridge rule is disabled, SourceScanQueue is empty, and no new OnTheCase run, Observation, Claim or DLQ message appeared through the 19:00 UTC boundary on 3 Sep. Canonical writes remain disabled." }, { "title": "Lemonrock and OnTheCase historical Claims are repaired", "detail": "Lemonrock has 8,306 evidence-backed venueLocation repair Claims with 17 explicitly unresolved candidates. OnTheCase has exactly 278 evidence-backed repair Claims with zero unresolved candidates. Corrected SourceWorker code from 32f957c is now deployed code-only. Both writes completed with canonical projection disabled. The shared historical DLQ remains quarantined at 10,909 pending completion of post-deployment evidence and a fresh bounded replay.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/pull/140" ] }, { "title": "Backline corpus is converged with canonical BNDY", "detail": "The Backline canonical corpus reflects the approved 1 Sep canonical state, including the recent manual canonical clear-out. Continuous DynamoDB stream ingestion is still disabled, so later canonical changes require another bounded delta until infrastructure ownership permits gap-free ingestion." }, { "title": "Godmode is operational but not yet the complete control surface", "detail": "Godmode exposes the intelligence graph, source families, projection control and canonical convergence. The next UX refactor must make source freshness, run history, queue incidents, evidence, Claims, resolutions, conflicts, would-write outcomes and bounded graph exploration immediately understandable.", "evidence": [ "https://backstage.bndy.co.uk/godmode/enrichment" ] }, { "title": "New source onboarding remains queued behind incident recovery", "detail": "Fizgig and Live Band Photos already contributed data to canonical BNDY and are represented by the converged canonical hydration. Their source-native evidence scans, lineage reconciliation and shadow BAU runners remain outstanding. They must not create duplicate canonical entities." }, { "title": "Canonical writes remain the destination, not the current mode", "detail": "After DLQ recovery and two clean shadow runs per selected source, Backline will generate a human-reviewed would-write cohort for a bounded additive-only canonical pilot. The global gate stays off until that separate approval." }, { "title": "GigsNews parity fixtures require maintenance", "detail": "The deployment verification test run passed 396 tests, with two unrelated failures isolated to date-sensitive GigsNews parity fixtures and seven skips. OnTheCase adapter and projection coverage passed. Make the GigsNews fixture deterministic before declaring the whole repository green; it does not block the bounded OnTheCase replay." } ], "next": [ { "title": "Run a bounded OnTheCase replay pilot", "detail": "After explicit approval, transfer exactly 100 validated historical OnTheCase messages from the dead-letter queue back to processing at no more than one per second. Require repaired or already-complete location evidence for every candidate, retain shadow mode and stop on any validation failure, worker error or dead-letter rebound.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/commit/32f957c1b29fc85d6fb02e8aec48882ff10bcdad" ] }, { "title": "Deploy the corrected SourceWorker code only", "detail": "After the repair plan is accepted, build from main commit 32f957c or its current descendant and deploy only the SourceWorker asset. No CDK deploy-all and no resource, schedule, queue, IAM or stream changes. Verify CodeSha256 and parser behaviour before any source re-enable." }, { "title": "Drain the shared DLQ by classified source", "detail": "Redrive Lemonrock and OnTheCase separately in bounded, validated shadow batches. Delete a DLQ message only after ProjectionQueue accepts its replacement. Stop on an unknown source, worker error or DLQ rebound. Reconcile the final queue balance." }, { "title": "Restore shadow BAU one source at a time", "detail": "Re-enable OnTheCase and Lemonrock independently only after repaired historical messages succeed. Require two clean scheduled runs, fresh heartbeats, stable queues, no DLQ growth and visible Godmode intelligence before restoring the next source." }, { "title": "Onboard Live Band Photos and Fizgig in shadow", "detail": "Recover import lineage, capture immutable current evidence, match source identities to the already-hydrated canonical corpus and measure new, changed and conflicting intelligence. Add one authoritative BAU schedule per source only after fixture and snapshot-semantics qualification." }, { "title": "Run the first controlled canonical projection pilot", "detail": "Select five to ten additive future Events whose Artists and Venues already resolve unambiguously. Review the full would-write set, enable the global gate only for the bounded execution, write through canonical APIs, read back every result and stop on the first mismatch. No updates, deletes, cancellations or entity creation in the first pilot." } ] }, { "id": "source-automation", "title": "Automated source acquisition", "objective": "Continuously discover grassroots artists, venues and gigs without manual database entry.", "health": "amber", "deliveryState": "building", "targetState": true, "repos": [ "enrichment", "mcp", "api", "ops" ], "done": [ { "title": "National Lemonrock implementation plan committed", "detail": "The full national bootstrap, rich artist/venue hydration, source-native identity, legacy Cowork repair, change-detection, cancellation, reconciliation and Backline Explorer plan is now committed in bndy-enrichment as docs/LEMONROCK-NATIONAL-INGESTION.md.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/commit/f51d3ba6f10860da6b47d2fcc06853761188bca6" ] }, { "title": "Source Registry, dispatcher and queues exist", "detail": "An hourly EventBridge SourceDispatcher, due-source registry query, standard/browser queues and DLQs, generic Source Runner and ProjectionQueue/worker are implemented in bndy-enrichment. Source-specific schedules can run less often where freshness permits." }, { "title": "KLMA live vertical slice proven", "detail": "KLMA can fetch the live enduring Google Sheet, create immutable observations and claims, project a safe additive sample through canonical Artist/Venue/Event APIs, and verify the event by read-back. Most rows already exist in BNDY; the important recurring behaviour is detecting newly added gigs as the same sheet evolves.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/commit/6fd66f4314fc35900dcb2bfbba263a8fb897eb4b" ] }, { "title": "GigsNews parser/adapter and parity harness ported", "detail": "The recurring GigsNews HTML structure has been ported and parity/cutover tooling exists. This is not yet live scheduled ingestion into BNDY.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/commit/e8a7c9ad78130320bce2d74e5938ae452328372b", "https://github.com/flowency-live/bndy-enrichment/commit/ab8e0d4cef921ac9f525bbf8b360c5be19b9e919" ] }, { "title": "Canonical duplicate gates proven", "detail": "Artist, venue and event APIs safely reject duplicates while returning reusable canonical identity." }, { "title": "Lemonrock national source family deployed in shadow mode", "detail": "Artist, Venue and Gig discovery/hydration plus fast-change and cancellation sources run on the Backline serverless source runtime. National bootstrap completeness is now proven by the terminal 22:44 UTC manifest; the source remains deliberately shadowed with canonical writes disabled.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/blob/main/docs/backline-live-audit.json", "https://github.com/flowency-live/bndy-enrichment/blob/main/docs/LEMONROCK-NATIONAL-INGESTION.md#31-owned-completion-execution-control", "https://github.com/flowency-live/bndy-enrichment/blob/main/ops/lemonrock-reconciliation-manifest.json" ] }, { "title": "Lemonrock rate-safe recovery deployed", "detail": "Production caps source-worker concurrency at two and uses bounded retry/backoff. One same-run repair replayed the pre-fix Venue fanout gap, then a final bounded pass converted 756 retryable failures into terminal evidence with zero send failures. All 6,047 superseded DLQ delivery copies are retained outside the active queue with no automatic replay or destructive purge.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/actions/runs/33119366369", "https://github.com/flowency-live/bndy-enrichment/blob/main/ops/lemonrock-targeted-recovery-status.json", "https://github.com/flowency-live/bndy-enrichment/blob/main/ops/lemonrock-historical-failure-quarantine.json" ] }, { "title": "Lemonrock low-cost gig-led operating model deployed", "detail": "Production now checks the new-gig and explicit-cancellation feeds hourly, performs one bounded future-gig health check daily and one future-gig reconciliation monthly. Artist and Venue profiles are hydrated only when linked from a discovered gig; scheduled Artist, Venue and full-directory crawling is off. The verified scheduled root footprint is 1,471 runs per 30 days. Backline remains shadowed and canonical writes remain disabled.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/pull/23", "https://github.com/flowency-live/bndy-enrichment/actions/runs/32972919883", "https://github.com/flowency-live/bndy-enrichment/blob/main/ops/lemonrock-low-cost-operating-status.json", "https://github.com/flowency-live/bndy-enrichment/blob/main/docs/BACKLINE-SOURCE-INGESTION-BLUEPRINT.md" ] }, { "title": "Rejected source candidates — 26 August 2026", "detail": "yorkshiregigguide.co.uk — editorial magazine + Facebook group, no structured listing. yorkshiregigs.co.uk — DNS dead. yorkshirecoastgigs.co.uk — content stale since 2016-2017. thebristolgigguide.com — reviews blog, stale since March 2025. the-south-yorkshire-entertainer.co.uk — active and grassroots, but client-side data behind a WAF; revisit later. gig-guide.uk (Wales) — 403, unreachable. gig-guide.co.uk — multi-city platform, client-side, mixed ticketed content; weak fallback. Skiddle, allevents, Bandsintown, GigXchange — excluded aggregator class (GigXchange excluded by Jason)." }, { "title": "On The Case gig-led source family deployed to shadow", "detail": "Production shadow path is proven end-to-end for evidence hydration. Hourly gig-led discovery fans only to referenced venues then referenced bands. A clean owned reconciliation completed 145/145 tasks with zero scoped failures. Manual directory/audit coverage has been restored in CI. Canonical projection remains off.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/pull/30", "https://github.com/flowency-live/bndy-enrichment/pull/31", "https://github.com/flowency-live/bndy-enrichment/blob/main/ops/onthecase-reconciliation-manifest.json" ] }, { "title": "Lemonrock national bootstrap proven complete", "detail": "The single owned reconciliation run-907eba4a-b7eb-4d41-95f5-06bbc91beef4 passed at 22:44 UTC: 28,504 completed tasks, zero failures, all tasks terminal, active queue and DLQ zero, both directory inventories covered, future coverage proven by 7,787 identities plus bounded terminal 410 evidence, and gig-led Venue hydration proven at 2,220 identities. Canonical writes remained disabled throughout.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/blob/main/ops/lemonrock-reconciliation-manifest.json", "https://github.com/flowency-live/bndy-enrichment/blob/main/ops/lemonrock-historical-failure-quarantine.json", "https://github.com/flowency-live/bndy-enrichment/actions/runs/33120136044", "https://github.com/flowency-live/bndy-enrichment/actions/runs/33123589794" ] }, { "title": "Cowork source operations audited", "detail": "bndy-ops confirms current source captures for GigsNews, KLMA, On The Case and Scenic Eye plus active direct canonical discovery-crawler history. It also exposes an evidence gap: the latest 28 Aug state/snapshot commit has no corresponding per-run report or CTO inbox entry, and run-reports currently stop in July. A shared v2 output contract now requires append-only machine ledgers, per-record identity and enrichment evidence, exact canonical actions and API read-back.", "evidence": [ "https://github.com/flowency-live/bndy-ops", "https://github.com/flowency-live/bndy-ops/blob/main/RUN-CONTRACT.md", "https://github.com/flowency-live/bndy-ops/blob/main/RUN-LEDGER-SCHEMA.json" ] }, { "title": "Corrected OnTheCase parser deployed to SourceWorker", "detail": "SourceWorker was updated code-only from exact commit 32f957c. Deployed CodeSha256 is L/TK4YpWp6lHpCvJJzXYdOn7ruYYsaBsXdUMKBzsszs= and Lambda reports a successful update. No infrastructure deployment ran.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/pull/140" ] } ], "now": [ { "title": "Lemonrock and OnTheCase contained for shared DLQ recovery", "detail": "lemonrock-gig-hydration and onthecase-gig-index are disabled and remain shadow=true. The OnTheCase hourly EventBridge rule is disabled. ProjectionDLQ is stable at 10,909 historical messages and SourceScanQueue is empty. No source is to be re-enabled until its repairs and classified redrive pass." }, { "title": "Lemonrock historical Claims repaired", "detail": "8,306 evidence-backed venueLocation repair Claims were written to Backline; 17 cases remain unresolved rather than guessed. The corrected path has processed 352 historical Lemonrock messages successfully in shadow." }, { "title": "OnTheCase historical Claims repaired", "detail": "Write run onthecase-occurs-at-repair-write-2026-09-03-v1 wrote exactly 278 event-address-backed venueLocation Claims with zero unresolved. Corrected SourceWorker code is now deployed from 32f957c. Replay remains blocked until the missing post-deployment evidence is closed.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/pull/140" ] }, { "title": "Other source families remain shadow-only", "detail": "The global projection gate remains disabled. Before broader BAU claims are made, reconcile current schedules and freshness for KLMA, GigsNews and ScenicEye against Godmode and live AWS evidence." }, { "title": "Fizgig and Live Band Photos remain canonical-first backlog", "detail": "Their existing canonical records were included in the 1 Sep convergence. Next acquire source-native evidence and reconcile lineage and identities before enabling any shadow BAU runner." } ], "next": [ { "title": "Run a bounded OnTheCase replay pilot", "detail": "After explicit approval, replay exactly 100 individually validated OnTheCase dead-letter messages at no more than one per second in shadow. Stop on any unexpected source, missing repair coverage, validation failure, worker error or rebound." }, { "title": "Complete classified DLQ recovery", "detail": "After approved repairs and SourceWorker code-only deployment, redrive only validated Lemonrock and OnTheCase messages in separate bounded operations." }, { "title": "Prove restored shadow BAU", "detail": "Re-enable and observe OnTheCase and Lemonrock separately. Require two clean runs each before declaring the incident closed." }, { "title": "Bring Live Band Photos into shadow BAU", "detail": "Capture and fixture-qualify the current gig root and directory surfaces, match them to canonical entities, then introduce daily gig and slower discovery/reconcile schedules with projection off." }, { "title": "Complete Fizgig acquisition reconnaissance", "detail": "Prove a permitted, stable acquisition route and snapshot semantics, capture fixtures, reconcile existing imported canonical records, then define its bounded shadow cadence." } ] }, { "id": "venue-workers", "title": "Venue listing workers", "objective": "Keep high-value venue calendars fresh by revisiting known reliable venue websites on a predictable cadence.", "health": "blue", "deliveryState": "planned", "targetState": true, "repos": [ "enrichment", "api" ], "done": [ { "title": "Capability fits the Source Registry model", "detail": "Known venue websites are sources. Their pages can be scheduled, observed, interpreted into event claims and deduped through the normal projection path." } ], "now": [], "next": [ { "title": "Weekly venue worker schedule", "detail": "Run one source job per watched venue weekly, with retry/backoff and a faster cadence only where evidence justifies it." }, { "title": "Delta new listings into Claims", "detail": "Only new/changed gigs become claims. Existing gigs dedupe normally; removed listings are not treated as cancellations unless source semantics are explicit." }, { "title": "Venue freshness dashboard", "detail": "Show last checked, last changed, failures and new gigs found in Godmode so reliable sources can be expanded safely." } ] }, { "id": "meta-facebook", "title": "Meta / Facebook presence", "objective": "Give BNDY an official Meta identity and make Facebook a supported public intake channel without personal-account automation.", "health": "amber", "deliveryState": "live", "targetState": false, "repos": [ "website", "api", "capture" ], "done": [ { "title": "BNDY Facebook Page created", "detail": "The public Page exists and Meta developer setup has been started." }, { "title": "Facebook URLs work without Graph dependency", "detail": "Public source inspection and Capture can resolve useful Facebook evidence without making privileged Graph access a core dependency." }, { "title": "Meta app approved and in Live mode", "detail": "The Meta app has completed approval and is now in Live mode. This is the platform checkpoint, not proof that managed Facebook Page retrieval or Page-control Claim verification works end to end." }, { "title": "Minimal Page permission boundary confirmed", "detail": "Facebook Login public_profile and email access are active. The Page Claim design now requests only pages_show_list; pages_read_engagement is not required. Graph Explorer proved the test token carried the requested Page scopes, while /me/accounts still returned an empty list despite the correct personal user, app Administrator role and full Page control. That inconsistency remains a Meta test/review issue rather than proof of a working production journey." } ], "now": [], "next": [ { "title": "Messenger Send to bndy", "detail": "Let people send a Facebook Event URL, BNDY link, poster, screenshot or event message to the public BNDY Page in Messenger. Receive verified Page message webhooks into Capture, preserve transport idempotency and evidence, return bounded acknowledgement and final outcomes, and keep Page/App permissions and review truthful. The Meta developer app is infrastructure, not a user-facing sharing destination." } ] }, { "id": "whatsapp", "title": "WhatsApp Send to bndy", "objective": "Let anybody send a poster, link or event message to BNDY like messaging a friend.", "health": "blue", "deliveryState": "building", "targetState": true, "repos": [ "capture", "enrichment" ], "done": [ { "title": "Architecture/spec decided", "detail": "WhatsApp is a transport into Capture, not another ingestion brain. Message IDs provide dedupe; media is downloaded then stored as Capture evidence." } ], "now": [ { "title": "Cloud API transport in active delivery", "detail": "Build verified webhooks, media retrieval, message-ID deduplication and bounded acknowledgement and result replies through Capture. Production activation still requires a dedicated BNDY number and Meta credentials." } ], "next": [ { "title": "Production Meta activation", "detail": "Connect a dedicated public BNDY number, WhatsApp Business Account, phone ID, app secret, access token and webhook subscription after the transport passes local qualification." }, { "title": "Bounded WhatsApp acceptance", "detail": "Qualify text, links, posters, screenshots, duplicate delivery, transient failure and final-result replies before publishing the number." } ] }, { "id": "analytics", "title": "Analytics & traffic", "objective": "Understand usage across every BNDY surface without adding unnecessary cost or complexity.", "health": "green", "deliveryState": "live", "targetState": false, "repos": [ "app", "backstage", "website", "chatzone" ], "done": [ { "title": "Cloudflare Web Analytics added to bndy.live", "detail": "The public app emits privacy-friendly web analytics." }, { "title": "Godmode traffic panel", "detail": "Backstage has a Cloudflare traffic dashboard/client." } ], "now": [], "next": [] }, { "id": "editions-brass", "title": "Editions & partner views", "objective": "Support scoped, branded BNDY experiences on subdomains and embeds without forking the platform, duplicating canonical data or leaking edition-only records into another public view.", "health": "amber", "deliveryState": "building", "targetState": true, "repos": [ "api", "website", "app", "enrichment", "backstage" ], "done": [ { "title": "Publication-scope contract implemented", "detail": "Artists, venues, events and festivals have edition-aware public filtering while legacy unscoped records stay live." }, { "title": "Brass architecture explainer added", "detail": "www.bndy.co.uk documents the brass-bands architecture and public-source approach." }, { "title": "Atomic edition-scoped creation added", "detail": "Canonical creation has explicit edition-scoping support." } ], "now": [ { "title": "Brass edition v2 UI", "detail": "A current bndy-app branch/PR is rebuilding the brass edition on current main with Concerts, Bands, Festivals and dual-mode map.", "evidence": [ "https://github.com/flowency-live/bndy-app/pull/16" ] }, { "title": "Evidence-first brass discovery", "detail": "Edition-aware enrichment policy, 2026 band bootstrap, identity inference and no-write projection commands are under active build.", "evidence": [ "https://github.com/flowency-live/bndy-enrichment/pull/17" ] }, { "title": "Reconcile Editions and the existing Builder foundation", "detail": "The generic Builder foundation is genuinely half-built: bndy-serverless-api contains a Builder Lambda for subdomain lookup, themes, postcode/radius coverage and explicit Venue collections, while bndy-backstage contains Builder branding, theme, coverage and Venue-management screens. The current SAM template does not wire the Builder function or routes, and bndy-app resolves only the compile-time Brass edition. Consolidate these foundations into one current Edition model rather than reviving or deploying the older Builder architecture unchanged." } ], "next": [ { "title": "Deploy isolated brass read path", "detail": "Prove the brass read API/UI against edition-scoped data without any fallback to live records." }, { "title": "Promote brass intelligence from no-write to controlled projection", "detail": "Only after publication-scope guardrails, identity confidence and parity gates are production-proven." }, { "title": "Generic Edition definition and runtime", "detail": "Define one Edition configuration containing slug, branding, terminology/navigation, inclusion policy and enabled rendering surfaces. Inclusion must support publication scope for domain editions such as Brass, postcode/radius for regional partners such as OnTheCase, and explicit canonical Venue collections for organisations such as brewery estates. Resolve the incoming subdomain at runtime while keeping one application and one canonical data authority." }, { "title": "OnTheCase and Robinsons partner proofs", "detail": "Use OnTheCase as the regional Edition proof with its existing skin and bounded postcode/radius coverage. Use robinsons.bndy.live as the organisation proof, limited to an explicit Robinsons Venue collection with Robinsons branding. Both consume canonical public BNDY records and must not fork or copy the database." }, { "title": "Powered by bndy embeds", "detail": "Render the same Edition configuration as a lightweight embeddable gig list for partner websites. Use canonical public gigs, Edition inclusion rules, suitable BNDY and partner branding, links back to BNDY entity pages, caching, rate limits and basic view/click analytics. Do not create a separate editing system or data store." } ] }, { "id": "api-security", "title": "API security & platform hardening", "objective": "Keep the canonical backend auditable, least-privilege and safe for humans, public apps and agent integrations.", "health": "amber", "deliveryState": "live", "targetState": false, "repos": [ "api" ], "done": [ { "title": "Machine-readable route security baseline", "detail": "SEC-00 added trust-zone policy, route inventory generation and mutation/authorizer checks.", "evidence": [ "https://github.com/flowency-live/bndy-serverless-api/pull/3" ] }, { "title": "Secrets and CI baseline remediated", "detail": "Cognito credentials moved out of tracked config, SAM validation was hardened and backend test/audit baseline improved.", "evidence": [ "https://github.com/flowency-live/bndy-serverless-api/pull/5" ] }, { "title": "Source inspector deployment drift hardened", "detail": "Recent workflow changes reconcile the Facebook source-inspector route after normal API deployment." }, { "title": "Production serverless incident recovered and deployment gated", "detail": "The 29 August incomplete-template deployment removed five Claim and ownership Lambdas and detached four retained DynamoDB tables. The tables were imported back into CloudFormation, the missing functions and 22 routes were restored through reviewed surgical change sets, and five frontend authentication aliases were separately deployed. The stack is UPDATE_COMPLETE with 270 routes, all four tables IN_SYNC, unchanged outputs and successful 401 Lambda smoke responses. API deployment is now manual-only behind two explicit guards; Enrichment and combined Capture deployment workflows are also manual, use a dedicated deploy-role boundary and no longer run CDK bootstrap routinely. The superseded combined deployment PR #122 was closed unmerged.", "evidence": [ "https://github.com/flowency-live/bndy-website/blob/main/docs/SERVERLESS-API-INCIDENT-RECOVERY-2026-08-30.md", "https://github.com/flowency-live/bndy-serverless-api/pull/68", "https://github.com/flowency-live/bndy-serverless-api/commit/ca641b99ea0c2941daacccc9172c6a0cfc14df3b", "https://github.com/flowency-live/bndy-enrichment/pull/123", "https://github.com/flowency-live/bndy-enrichment/pull/122" ] }, { "title": "Claim and Join route security baseline reconciled", "detail": "SEC-01 now classifies all restored Claim, Join, membership, invite, ownership and same-origin authentication alias mutations. Join analytics is explicitly classified as bounded anonymous telemetry rather than authenticated user data. CI passed and PR #69 is merged.", "evidence": [ "https://github.com/flowency-live/bndy-serverless-api/pull/69" ] }, { "title": "Bounded SourceRuns summary and Godmode visibility deployed", "detail": "The bounded SourceRuns Lambda summary and corresponding Godmode visibility are deployed in production. Recent-run metrics remain exact and bounded, while the task ledger is separately paginated. Deployment was verified through the SourceRuns Lambda release and successful Backstage Amplify build.", "evidence": [ "https://github.com/flowency-live/bndy-serverless-api/pull/70", "https://github.com/flowency-live/bndy-backstage/pull/16" ] } ], "now": [], "next": [ { "title": "Explicit public route allowlist", "detail": "Continue the SEC programme so unknown/new routes fail closed against the declared public surface." }, { "title": "Finish SDK/dependency hardening", "detail": "Plan remaining AWS SDK v2/transitive dependency migration without destabilising the production API." } ] }, { "id": "adversarial-security", "title": "Adversarial security & abuse resistance", "objective": "Prove that BNDY can withstand deliberate attack, automation abuse and hostile content without exposing canonical data, private information, infrastructure control or unbounded cost.", "health": "amber", "deliveryState": "building", "targetState": true, "repos": [ "app", "api", "website", "chatzone", "capture", "enrichment", "backstage" ], "done": [], "now": [ { "title": "Whole-estate attack-surface and threat-model audit", "detail": "Inventory every public host, API route, webhook, authentication and Claim journey, upload/parser path, queue, data store, third-party integration, administrative surface and infrastructure control. Model unauthenticated attackers, malicious accounts, compromised Curators, bots and denial-of-wallet attacks. Include OWASP web and API risks, IDOR/BOLA, privilege escalation, injection, SSRF, secret exposure and unsafe defaults." } ], "next": [ { "title": "Adversarial abuse and content-integrity testing", "detail": "Test automated fake-gig and duplicate submission floods, identity poisoning, malicious links and files, parser bombs, oversized payloads, replayed webhooks, enumeration, scraping and attempts to bypass review or write directly to canonical records. Prove rate limits, idempotency, quarantine, evidence lineage, moderation controls and account or source suspension." }, { "title": "DDoS, cost-exhaustion and containment controls", "detail": "Review Cloudflare, API Gateway, Cognito, Lambda, SQS, DynamoDB and third-party provider protections. Establish appropriate WAF and bot rules, per-route throttles, concurrency and payload limits, budgets and anomaly alarms, queue back-pressure, emergency kill switches and a tested incident runbook." }, { "title": "Controlled penetration test and closure evidence", "detail": "Run destructive techniques only in an isolated environment unless a separately authorised production-safe test window exists. Record findings by severity, owner and remediation deadline, retest every critical and high issue, and require evidence-backed closure before declaring the public estate launch-ready." } ] }, { "id": "website-brand", "title": "Public website & proposition", "objective": "Explain what BNDY is, why it exists and how the ecosystem fits together.", "health": "green", "deliveryState": "live", "targetState": false, "repos": [ "website" ], "done": [ { "title": "New public website", "detail": "bndy-website is the current www.bndy.co.uk brand/proposition site." }, { "title": "Audience-specific copy and policy", "detail": "Gig-goer, artist, venue, promise, why and policy material has been built out." }, { "title": "Workboard v1 live", "detail": "The JSON-backed operating board is deployed on www.bndy.co.uk/workboard." }, { "title": "Workboard focus controls", "detail": "The live workboard supports collapsible swimlanes, expand/collapse all, SOLO lane view, independent NOW/NEXT/DONE column collapse, a NOW-across-all focus mode and explicit target-state stamps. View preferences persist locally." } ], "now": [], "next": [ { "title": "Use workboard as the agent coordination surface", "detail": "Agents update structured JSON in the repo and use the same stable stream IDs rather than inventing new parallel plans." } ] }, { "id": "repo-consolidation", "title": "Repository consolidation", "objective": "Make it obvious which repositories are live, supporting, legacy or safe to ignore.", "health": "blue", "deliveryState": "planned", "targetState": false, "repos": [ "signals", "frontstage", "mcp", "types", "ui", "legacy-other" ], "done": [ { "title": "Frontstage explicitly decommissioned", "detail": "Do not use bndy-frontstage for current product work." }, { "title": "Chatzone removed from Signals", "detail": "One major accidental duplicate runtime has been eliminated from the live public ingestion path." } ], "now": [], "next": [] } ] }