📊 Leadership Dashboard

The Leadership Dashboard is a client-side HTML/JavaScript application. It runs entirely in the browser, connecting directly to Airtable via its REST API and to Gmail via a deployed Google Apps Script web app. There is no back-end server.

On load, the dashboard fetches 9 Airtable tables in parallel: Accounts, Fixed Costs, Tenancies, Transactions, Rental Units, Tenants, Categories, Sub-Categories, and Businesses. It also fires non-blocking fetches for invoices, Gmail sync, and Fintable status.

Those nine are not the whole list. The same load also reads Strategic Projects (tblHrpTMd5LNYn8v1, js/dashboard.js:185), Tasks and Prospects for the KPI compute (:487, :458), Team Members and AI Agents for the agent cards, and AI Recon Audit for the accuracy score. Opening the page also writes to Airtable, in two places: the Strategic KPI automation below, and the recon audit log in section 6.

Some Strategic Projects carry their own KPI compute code. It is written by hand and stored in the KPI Compute Code field on the project record in Airtable. Opening the dashboard runs that code in your browser and saves the answer back to Airtable. The page is not read-only.

1. loadDashboard() calls loadStrategicKpis() as its first action (js/dashboard.js:929), which reads the Strategic Projects table (:110, :185).
2. Every open project that has compute code goes to runAutomatedKpis() (:514). Projects with a close date are skipped, so a closed quarter cannot drift away from its snapshot (:519).
3. The code runs in the browser through new Function() (:429). A safety check blocks obvious dangerous wording first (:410), and the note beside it in the code is honest that this is a speed bump rather than a wall. Only put compute code in that field if you wrote it yourself.
4. The answer is saved straight back onto the project record (:611-617): KPI Current, KPI Last Updated, KPI Last Updated By, and a KPI Detail JSON blob holding the workings, capped at about 95KB.

1. Open app.operationsdirector.co.uk in any browser.
2. On first load, the login screen appears requesting your Airtable Personal Access Token (PAT).
3. Enter your PAT and press Enter or click Connect. The dashboard loads all data from Airtable.
4. Your PAT is saved to localStorage (key _dlr_pat) and persists across browser sessions until you log out or clear storage.

The dashboard uses a stale-while-revalidate caching strategy to provide instant page loads. On every successful data load, the full dataset is saved to localStorage under the key _dlr_dashcache_v1.

The Operations Hub uses a fixed left sidebar for navigation. Each page also has a standalone URL for deep-linking and sharing.

The financial overview section shows five KPI cards. All figures are calculated from live Airtable data.

Eight cards, worked out on every load. Nobody types a number. The rules are in js/re-kpis.js (tests: tests/re-kpis.test.js); the named units, tenants and targets are RE_Q4 in js/config.js.

When a card stops updating. A card shows a red Not updating badge and the reason when its data did not load, the bank feed is more than 4 days old, no rent is in the window, or a named unit or tenant is missing. An amber Check badge means the figure will move (payments not yet filed) or needs a look; the reason is written beside the badge. The bar on a card always measures progress to the committed target, and the card says so. The health bar check Q4 real estate KPIs updating turns red with it. The three project KPIs are also saved to their projects; the daily data check q4-real-estate-kpis-are-current fails if any of them has not been saved for 2 days.

Above the financial KPI cards, the reconBar section displays two cards side by side:

1. Unreconciled Transactions — expandable card showing the count and list of all transactions where txReconciled is false and txAccountAlias matches one of the monitored accounts (Santander or TNT Mgt Zempler). Each row shows date, label, and amount.
2. Run Reconciliation button — inside the expanded card, a blue Run Reconciliation button calls triggerReconciliation(this), which runs the AI matching engine from js/reconciliation.js. A status span (id="reconStatus") shows progress.
3. AI Reconciliation Accuracy — shown as a separate KPI card (only rendered if the accuracy log has at least one entry). Displays the percentage of reconciliation matches confirmed as accurate, colour-coded: ≥90% green, 75–89% amber, <75% red.

After the tenancy cards, the dashboard checks for potential CFVs not yet flagged in Airtable. The logic:

1. For each tenancy with tenPayStatus = “In Payment” and active tenant status and rent > 0:
2. Calculate daysOver = days since the current month’s due day (0 if not yet due).
3. If daysOver ≥ CFV_TOLERANCE_DAYS (= 2 days) AND tenPaidThisMonth is falsy AND no cfv_dismissed_[tenancyId] key in localStorage…
4. …the tenancy counts as a potential CFV.

If any potential CFVs are detected, an amber banner is inserted below the tenancy cards: “N potential CFVs detected — click to review”. Clicking the banner calls switchTab('cfv') to navigate directly to the CFV tab.

This section compares actual spending over the last 31 days against monthly budget targets. Transactions are filtered to the 31-day window using txDate and matched to sub-categories by sub-category record IDs in the REC constants.

Built by buildCashFlow() in js/cashflow.js. Projects daily inflows and outflows for 31 days from today’s opening balance.

The table has seven columns. There is no Net column (js/cashflow.js:719-726).

All the money columns are read from the same worked-through series (waProjected, js/cashflow.js:712-714), not from the raw Airtable rows, so each row reconciles exactly: Opening + In − Out − Withdraw = Closing. The table prints that same line under its totals row (:770).

The forecast is not a plain projection of Airtable data. Two things are applied on top of it before the table is drawn.

1. Weekly commitments. Wages of £150 (Roy, the £650 a month wages budget) are added to the Out column every Friday by default (waDefaultCommitments()). It is not held in Airtable. It lives in this browser only, under the localStorage key _wa_settings (:1192). Edit the amounts and days in the controls above the table. A different browser, or a cleared cache, falls back to those defaults.
2. Recommended withdrawals. The advisor walks the 31 days and, at least three days apart, marks an amount that is safe to take out, in £50 steps (:517-552). It only takes what still leaves the safety floor intact on that day and on every day after it, after holding back the rest of the variable budget: £3,650 a month for maintenance, compliance, utilities and the non-payment allowance, spread evenly over the 31 days (wages are already in the weekly commitments). That money stays in the Closing column; only the withdrawals are smaller (Kevin, 14 Oct 2026: it read £23,950 when £20,300 left the budget covered). Once marked, the withdrawal is subtracted from every later Opening and Closing (:546-549), so the Closing balance you are reading already assumes you took that cash. The green Safe to withdraw (31-day cycle) figure above the table is the total of them (:629).

Where the safety floor comes from: the largest single expected payment in, times 30%, scaled by how late payments have actually been running (analysePaymentLag(), :502-508), rounded up to the nearest £50 and never below £500. You can type over it in the floor box, which is also stored in _wa_settings.

The AI commentary section (id="aiCommentary") is generated in renderDashboard() using live KPI data. It covers six titled sections:

• Financial Health: Confirmed monthly income (In Payment), best-case total (+ CFV Actioned), fixed costs, gross margin range, and whether the upper range is healthy (≥40%).
• Income Floor: The cushion from In Payment tenancies vs the £14,300 the £10,000 income floor needs, how far above or below it is, the figure if the CFV Actioned tenancies pay too, and the Q4 target.
• Operational Performance (31-Day): Actual rental income, maintenance status (vs the £1,700 budget), wages status (vs the £650 budget).
• Occupancy & Voids: Occupancy rate, void count, estimated cost per void per month (monthly income ÷ occupied units), and ROI of filling voids.
• CFV Risk: CFV exposure vs the £750 non-payment allowance, count of unactioned CFVs and value at risk.
• Quick Wins: Prioritised action list: fill voids (1), action CFVs (2), reduce maintenance if over budget (3), plus a note about mortgage clusters on days 1–6.

Below the AI commentary the dashboard works out how to split one payment across the cards. It is a single-payment allocator, not a weekly schedule. There is no Friday timetable and no £750 buffer any more. The card list is built inline in renderDashboard() (js/dashboard.js:1950-1990) and the split is redrawn by recalcCCStrategy() (:2046).

Any card with nothing owed drops out of the list entirely (:1966).

How the split is worked out

1. The Payment box starts at what can go to the cards each month: personal net cash flow (Wealth page rules, 3-month average) times your Debt pot share (Income Buckets, 70% in October 2026), rounded down. You can type any amount over it and the split redraws as you type.
2. Cards are sorted by estimated APR, dearest first (:2049). This is the avalanche method: pay the minimum on everything, then put all the rest against the dearest card.
3. Every card gets its minimum first (:2054). If your figure is below the total of the minimums, the total of the minimums is used instead (:2052).
4. Whatever is left goes to the dearest card until it is cleared, then to the next (:2055-2059).
5. The summary line estimates next month’s interest on whatever is still owed after the payment (:2077-2085).

The standalone Balance Calculator has gone, along with its own opening balance box and its Select All, Deselect All, Inflows Only and Outflows Only buttons. The what-if tool now sits inside the cash flow forecast itself: open any day in the table and every expected item has a tick box beside it (js/cashflow.js:670-673 for money in, :681-684 for money out).

1. Ticked means the item is still expected and counts towards the forecast. Untick it to take it out.
2. Unticking redraws the table, the totals and the chart straight away (toggleCFExclusion(), :1148).
3. Items already reconciled in Airtable are shown struck through with a Reconciled badge and have no tick box. They are already in the bank, so there is nothing to model.
4. The amber dashed What-If line on the chart shows the balance with your unticked items removed, and also takes off the wages budget spread evenly across the 31 days (buildWhatIfLine(), :1159-1179). It only appears once something is unticked.

1. Open Google Apps Script at script.google.com and open the existing project (or create new).
2. The script reads Gmail threads labelled 3. to pay, extracts invoice fields (payee, amount, due date, reference), and handles markPaid actions.
3. Deploy as a Web app: Execute as Me, Who has access: Anyone.
4. Copy the Web app URL and paste into GMAIL_SCRIPT_URL in js/config.js.
5. Verify by loading the Invoices tab — invoices should appear with a live badge.

Since 9 Oct 2026 every AI card sits in its own AI Team section, below the 31-Day Operational Metrics. Since 15 Oct 2026 it opens with one panel that replaced the Agent Work, Defects, Bottleneck and Fix of a Fix cards. The same day it was made simpler, so you can see at a glance whether the AI team works and whether it improves week on week. The Mac works all of it out (scripts/ai_team_health.py, the Estate Status row ai-team-verdict, every 10 minutes); the page only draws it.

The checks behind each light (tap a check to see its rule, the tasks or jobs behind it, and where the number came from):

What counts as a thing needing a fix: tasks stuck with nothing blocking them, every blocked task (a stuck task that gets blocked still counts, so the number never falls with nothing fixed), approved work not done in 24 hours, idle agents, failing or blocked jobs, wrong data checks, things missed, emails over 2 days old, email tasks waiting for a draft, approval cards over 2 days old, and 1 for any Claude allowance pause this week. The open code-problem backlog and the two rates (work done against new, drafts right first time) never add to it; they turn their light amber or red instead. A task, job or email that two checks both count is counted once.

The answer, in order: red "Getting worse" when a light is red that was not red at the end of last week (or whose colour last week is not on record), or there are more things to fix than last week; grey "Can't tell" when more than two checks cannot be read or the number is "at least"; green "Working well" when no light is red, no light got worse since last week, every check was read and there are 5 things or fewer; grey "Can't tell" when there is no number from last week yet; amber "Getting better" when there are fewer things than last week and no light got worse; amber "Not getting better" otherwise. A red light always shows red and is named under the answer, even when the number falls.

Trust guards: a check whose source cannot be read, is missing or is out of date is grey, "Can't tell"; it is never shown green, and the number becomes "at least". A check that read red and cannot be read now keeps its light red. "Everything's moving" leaves out blocked tasks, which "No bottlenecks" counts, so one task is never counted twice. An answer the Mac worked out more than two hours ago turns the answer, the lights and the bars grey, "Not updated since …", and a row the Mac could not build shows its reason instead of its last answer. The health bar's "AI team verdict read from the Mac" check says the same. The old cards' numbers (the agent work split, the defect split, blocks by kind and the fix-of-a-fix rate) sit inside the checks they explain.

Below the panel, under the heading North star: how much work AI does, two cards measure progress to getting up to 90% of repeatable operational work done by AI agents. The two agent cards follow under The agents and your approvals.

What counts as AI work (both cards use the same rules): a task completed with an AI agent on the Team Member field, or work an agent prepared that was approved first time. Work that was sent back for changes never counts as AI work, whatever the links say, because a human had to redo it.

How the money figure is worked out: every completed task carries a time estimate (how long a person would need). AI hours are those estimates summed for AI work, then valued at £17.50 per hour: the UK office admin wage plus employer National Insurance and pension. The rate and the go-live date live in js/config.js (AI_LABOUR_RATE_GBP_PER_HOUR, AI_WORK_EPOCH), so changing them is one edit. Figures are whole pounds; pence on an estimate would be false precision.

Trust guards: both cards publish the share of completed tasks carrying a time estimate and warn below 80% (a task without an estimate is invisible to the sums). An empty query shows "no data", never a fake 0% or £0. The health bar's "AI Time & Money Saved card computed" check confirms the card loaded on every sync.