The leak isn’t the work. It’s the chasing.

The strongest first project

Engagement to cash: the payment gate and the AR that follows

You took a deposit up front, and some clients still never sent their documents. Chasing them cost more than the deposit. A deposit is a price signal; a gate is a state machine. The gate doesn’t exist today because it takes four systems agreeing (time, delivery, invoicing and payment) and none of them share state.

What we build

• One gate state per engagement, from engagement letter sent through paid to delivered, with the upload target and the delivery step both conditioned on the gate.
• Invoice on signature, with the payment link in the same message as the letter.
• A release rule you write and we implement: full fee, deposit, or exemption by client tier. We do not ship a default, because a default is us telling you how to price.
• AR aging with structured dunning that stops permanently on any human touch, and never sends to a client flagged in dispute.
• An exceptions register: work that started before the gate opened. Every firm has exceptions; almost none can count them.

What the dashboard shows

Gate Board (engagement · state · days in state · fee · invoiced · paid · owner) · AR Aging (0–30 / 31–60 / 61–90 / 90+, reconcilable line for line to your accounting system) · Exceptions (count, dollars, who authorised) · Deposit Compliance, trended by week.

The honest caveat

This is a policy change wearing a software costume, and we say so before the invoice: if the partner won’t enforce the gate, the build produces a very good report about a decision nobody is making. We are not a collections agency, we do not touch the merchant account, and we do not recommend a processor.

The document ledger: what you asked for against what arrived

You asked for fifteen items and got back two. The organizer is functionally dead as a data-collection instrument, everyone in the firm knows it, and the workaround is an administrator manually comparing arrivals against the checklist and last year’s return. No system in the category does that diff natively: a claim you can check inside your own software in ninety seconds.

What we build

• A structured PBC list per engagement: one row per expected item, with document type, payer or EIN, tax year, and a fixed state: requested, received, illegible, superseded, not applicable, waived.
• Multi-channel ingest into one queue: portal, monitored email, front-desk scans, phone photographs, with the channel recorded.
• Matching of arriving documents to expected items; anything uncertain routes to a person, because a misfiled document is worse than a missing one.
• Reminders that name the specific missing items, in the channel the client already uses. One, then a second, then a human, never an indefinite drip, always inside the 8am–9pm send window, on one shared suppression list.
• A status view the client can read without logging in, because the login is the failure point.

What the dashboard shows

Item Ledger (client · engagement · item · payer/EIN · state · channel received · days open · reminders sent · owner) · Completeness per engagement, ordered by acceptance date rather than by percentage · Channel Split · Unmatched & Illegible, oldest first, with the source image alongside.

The honest caveat

We do not build you another portal, and we will argue against one: status and requests push to the channel the client already uses, and nothing requires a login to learn what is missing. TaxDome, Canopy and SafeSend all collect documents at scale; the seam is the reconciliation between the checklist and what arrived, and the seam is what we build. And OCR on a phone photograph of a 1098 fails often; expect a permanent manual queue, not a temporary one.

The scope ledger: what you gave away

Your realization says 100% and you have no idea what you’re giving away. The out-of-scope K-1 is discovered mid-return, by the preparer least able to stop and re-quote, and by the time anyone would look, the return is filed and the fee is fixed. There is no artifact, no register, no aggregate.

What we build

• A structured scope on the engagement letter: included forms, schedules, entities and state filings become a list rather than a paragraph.
• An out-of-scope register: every form, schedule, entity, state or K-1 that appears in preparation and is not on the list, timestamped, with the preparer and the client. It blocks nothing; a hard block mid-season is a business-stopping mechanism and we do not ship one.
• A re-quote prompt at the moment of discovery, routed to whoever owns the relationship, carrying the item and your own price for it.
• The K-1 wait clock: engagements held on an inbound K-1, with the entity and the days waiting.
• A season-end reconciliation of fee quoted against fee realised, per engagement.

What the dashboard shows

Scope Register (client · item · discovered by · date · your price for it · re-quoted? · billed?) · Quoted vs Realised by partner, sorted by difference, uncomfortable by design · The K-1 Board · Repeat Offenders, against your own threshold, two consecutive seasons.

The honest caveat

If your engagement letter says “prepare your 2026 returns”, there is nothing to be out of scope of, and the first project is a form-level engagement letter: a drafting change, and we say so before the build, not after. We do not write your engagement letter, we do not price your work, and nothing here re-quotes a client automatically.

Signature, e-file reject and delivery chasing

The return is prepared, reviewed and finished. Then it stops for weeks behind a spouse’s missing signature on Form 8879 or a reject nobody triaged. The acknowledgments live in the tax software, the signature status in the delivery tool, the client in email. No system in the firm holds a single answer to which returns are prepared and not filed.

What we build

• A filing-state ledger, one state per return, with signature tracked per signatory, because “signed” on a joint return is not a boolean.
• Reject classification by code, with your own resolution note attached to each code: the firm’s institutional knowledge, captured once, versioned. We do not bring a template of resolutions and we do not guess at them.
• An escalation clock that tightens toward the deadline. A return sitting unsigned in February gets a reminder; the same return in April gets a phone-call task assigned to a named person. The ladder ends at your partner, never at us.
• The extension decision list, surfaced with enough lead time that extending is a decision rather than a scramble.
• Reconciliation against the tax software’s own acknowledgment feed, so the two states cannot silently diverge.

What the dashboard shows

Filing Board (return · state · days in state · signatories signed/required · days to deadline · preparer · reviewer) · Partial Signatures, its own view, because it is invisible everywhere else · Reject Reasons, coded, by period and preparer · Deadline Countdown.

The honest caveat

We do not transmit returns: the e-file authorisation is the practitioner’s, the EFIN is the firm’s, and the liability follows both. We do not resolve rejects; that reconstruction is professional work. And a firm still on paper signature gets a smaller version of this build. We say which one you’re getting in week one.

The capacity queue: a slot claimable only when the file is complete

Your cutoff is March tenth, so every S-corp lands on the ninth. A date cutoff concentrates arrivals at the date; the backlog survives. The counter-pattern already exists in the profession: define capacity, and let a client claim a slot only once their file is complete. That inverts the incentive the organizer has failed to create for thirty years.

The cost of not doing it is the best-evidenced harm in the vertical: 78% of accountants exited the season with measurable damage, on an index of 438 respondents, and firms of 6–15 people scored noticeably worse than firms of 51–200.

What we build

• A capacity model you define: slots per week, by complexity tier, with your own hour budgets. We implement your numbers and supply no default, because a default capacity is us telling you how fast your people work.
• Slot claim conditioned on the document ledger’s completeness signal: the dependency that makes the whole thing work.
• A waitlist with a visible position, and a rule for released slots.
• The extension decision list, shared with the filing ledger, so the returns that will not fit are extended deliberately in February.

What the dashboard shows

The Queue (slots by week and tier: claimed, available, waitlisted) · Load by Week, as a forward projection: the only useful time to know you’re overcommitted is before you are · Tier Budget vs Actual, which is why next season’s tiers are better than a guess · Extension Decisions.

The honest caveat

This is a business-model change, and we lead with that sentence rather than burying it: if the partner won’t cull, won’t say no, and won’t raise prices, the queue becomes a waitlist everyone jumps. It depends entirely on the document ledger: a vendor selling you the queue without asking how your documents arrive has not thought about the build. And the first season’s tiers will be wrong; the dashboard corrects them over a year.

Monthly close: the uncategorized queue and the client blocker

The entire close hangs on one unresolved queue: uncategorized transactions plus missing receipts, and the client is the blocker. Every CAS firm of any size has built the same per-client spreadsheet, by hand, and maintains it monthly. A client who receives forty separate categorisation questions across a month answers none of them; a client who receives one weekly list of forty answers most of it. The batching is the intervention, and the platforms don’t do it because they are transaction-shaped rather than client-shaped.

What we build

• A per-client question queue that replaces the spreadsheet: one row per unresolved transaction, with the proposed category and the question.
• Batched asks: one message per client per week, in the channel that client actually uses, with a reply path that needs no login.
• Feed integrity checks against the statement (duplicate imports, date gaps, month-end balance mismatches) surfaced as exceptions, never corrected silently.
• Recurring-rule proposals where the same payee has been categorised the same way three times. A human approves every rule, and rules are versioned.
• A close state per client, from open through reconciled to closed, with dates.

What the dashboard shows

Close Board (client · period · state · days in state · open questions · days since last client response), distinguishing waiting-on-us from waiting-on-them · Open Questions by age · Feed Integrity, with the statement figure alongside · Rule Coverage, with its counterweight: rules that produced a correction.

The honest caveat

If you already run Uncat, Client Hub, Keeper or an equivalent, say so and we won’t sell you this; those products solve this problem, several of them well. We do not categorise transactions and we do not post to a general ledger; both are professional judgment with tax consequences. And we attach no dollar to a faster close: that would be a margin claim on a cost of delivery most CAS firms do not measure, against a benchmark that is paywalled. We would rather say that than borrow a number.

The strongest first project

Commission reconciliation: the statement against what you expected

Direct-bill commission is earned before cash arrives, then adjusted retroactively by endorsements, cancellations and chargebacks, and generic accounting software assumes revenue and cash align. The commission lives under a policy number on a carrier statement; the expectation lives in the AMS; the money lands as a sweep in the bank. Nothing joins them, so the join is done by a person, once a month, under time pressure, or not at all. A short payment is quieter than a chargeback: it generates nothing but a smaller number inside a larger total.

What we build

• Discovery first, paid, about a week: which carriers deliver a machine-readable statement, in what format, and how complete your AMS commission rates and producer splits actually are. It gates every scope estimate afterward; anyone quoting this build without it is guessing.
• Ingest and normalise statements to one shape: carrier, policy number, insured, premium basis, commission, transaction type.
• Build the expected side from the AMS: policy, premium, rate, producer split.
• Match statement line to policy; classify every line: paid as expected, paid short, paid over, chargeback, duplicate chargeback, not paid, unmatched. Unmatched is a first-class state and is never quietly dropped.
• Age everything unpaid, oldest first, by carrier; total expected against received by period, carrier, line and producer.

What the dashboard shows

Statement Ledger (carrier · policy · insured · received · expected · variance · state · producer · days open) · Expected vs Received, decomposed, displayed as an arithmetic identity you can check against a statement by hand · Aged Unpaid past 30/60/90 · Unmatched Queue, count always on the front page · AMS Data Quality, shipped on day one; if much of the book has no rate on it, you should know before you see the variance.

The honest caveat

We do not log into carrier portals with your credentials; the appointment is the business. If discovery finds no usable statement format for the carriers that matter, we say so and stop; discovery is priced separately precisely so it can end in “no”. Group benefits is materially harder than P&C, because per-member eligibility data largely does not download; scope it separately or exclude it in the contract. And we will not quote you an industry leakage percentage: the figures that circulate are claims, not benchmarks. What we sell is the audit that produces your number.

Certificates: issuance, the holder registry, and reissue on endorsement

A hundred certificates is a whole workday, and one wrong cert is an E&O claim. The requirement lives in a construction contract nobody at the agency has read, so the cert is reconstructed from the last one issued, which reproduces last year’s error indefinitely. And when a policy is endorsed mid-term, certificates already in circulation become wrong, with no system connecting the change to the paper.

What we build

• A cert holder registry: the entity the AMS does not have. Per holder: required coverages and limits, additional insured, waiver of subrogation, primary and non-contributory, the special wording verbatim, distribution method, expiry.
• Issuance from AMS policy data rather than from the last certificate, so a stale limit cannot propagate.
• Reissue on endorsement: when an endorsement changes a limit, a named insured, a location or an effective date, the registry returns the list of certificates that endorsement just made wrong, with their holders. This is the flagship, and the reason to buy the build.
• A worklist for general-contractor compliance portals: the packet assembled and staged, a person submits.
• Rejection reason capture, coded; an expiry board driven by holder requirements and policy terms.

What the dashboard shows

Holder Registry, with special wording displayed in full, never truncated · Endorsement Impact (certificates invalidated · holders affected · corrected or not · days since); this view is the product · Turnaround as a distribution, not an average, because the tail is the job site somebody couldn’t get onto · Rejection Reasons · Expiry Board.

The honest caveat

Special wording is a coverage question, not a text field. A certificate that prints “additional insured, primary and non-contributory” without a supporting endorsement on the policy is a misrepresentation of coverage, so a licensed person at your agency reviews and releases every certificate against the actual endorsement, and there is no configuration that turns that off. Applied Epic, AMS360, HawkSoft, EZLynx and NowCerts all issue certificates; the seam is the holder registry and the endorsement-to-certificate join. And a registry built from historical certificates inherits historical errors: the backfill is a real part of the first project.

The submission spine: ACORD data entered once

The same client’s name is typed into the AMS, into a rater, and then into each carrier’s own portal: three to six times before a single quote comes back. The ACORD 125 header data is re-keyed everywhere; a class-code typo cascades into the policy and then into the certificate. And the loss run, requested at 120 days and frequently late from the carrier, is the single most common reason a submission goes out incomplete.

What we build

• One canonical applicant record, with the ACORD 125 header data as its spine, mastered in one place. Everything downstream reads from it and nothing re-types it.
• ACORD form generation from that record: 125, 126, 127, 130, 140 and the supplementals your agency actually uses.
• Completeness validation before submission, against your own rules: class codes present and valid, exposure basis present, loss runs attached and current, schedules attached. A failing submission is held, not blocked.
• A portal-entry worklist: for carriers with no other path, the data staged field by field, in the order the portal asks, deliberately not credentialed automation.
• Submission tracking with coded decline reasons; loss run ordering and chase with days outstanding.

What the dashboard shows

Submission Board (insured · line · carrier · state · days in state · decline reason · producer) · Completeness at First Submission: your own rate, measured, not a vendor’s comparison · Market Response by carrier: acknowledgment and quote turnaround, decline rate, coded reasons: appetite intelligence the agency does not currently have anywhere · Loss Run Status · Re-key Count, the number you have never seen and will immediately recognise.

The honest caveat

We do not automate carrier portals with your credentials. The vendors themselves concede the forms have hundreds of fields and change regularly, and credentialed automation against a system that has not sanctioned it puts the appointment at risk. We stage the data; a person enters it. A rater reaches the markets it reaches, for everything outside it, the honest deliverable is faster keying, not no keying, and the in-scope markets are named in the contract. We do not decide appetite, and we do not write the operations narrative: that is the part of the submission an underwriter actually reads.

The renewal cadence and the shadow spreadsheet

The renewal list lives in a spreadsheet because the system doesn’t know you’re waiting on a carrier. Three reasons, all real: the AMS renewal view is buried and built for a bigger firm; the AMS holds policy records, not pipeline state; nothing in it says “submitted to four markets, two declines, one pending”; and the data is stale, because download doesn’t carry everything and endorsements aren’t posted timely, so the renewal owner keeps a shadow copy they trust.

What we build

• A renewal board that holds pipeline state: stage, markets approached, acknowledgments, quotes in hand, declines with reasons, pending items, and the named blocker. The shadow spreadsheet, made shared, current and auditable.
• The 120/90/60/30 task ladder generated per renewal, assigned to a named person, with the artifacts each stage requires.
• Loss run ordering at 120 days, tracked as its own object; an exposure-data request at 90, built from the prior-year application, so the client is asked for changes rather than for everything.
• The decision log: the documented recommendation, the client’s decision, and the date. The E&O artifact, exportable in full.
• Data-hygiene exceptions: expirations, premiums and producer assignments that disagree with the policy or the download.

What the dashboard shows

Renewal Board (insured · expiration · days out · stage · markets out · quotes in · declines · blocker · owner) · Data Hygiene as a share of the book, shipped on day one: the honest counterweight, because a board built on stale expirations is a shadow spreadsheet with better fonts · Decision Log · Loss Run Status.

The honest caveat

You are replacing a spreadsheet somebody trusts, and they trust it because the AMS data is stale. Cleaning the AMS is the real first project, and we say so before the invoice. We do not recommend coverage, compare quotes, or advise on adequacy: licensed work, and the producer’s. And we attach no retention number to this: retention cannot be attributed without a control no principal would ever run, and we won’t publish a correlation dressed as a result.

Policy checking against what was bound

Comparing the issued policy against what was quoted and bound (against a checklist that runs past nine hundred points) is the highest-return E&O control in an agency, and the first thing dropped when the team is busy. An entire outsourcing sub-industry exists only because agencies cannot get it done in-house. A control whose only output is the absence of a problem loses every scheduling contest it enters.

What we build

• Structured capture of what was quoted and bound: carrier, dates, named insureds, locations, limits, deductibles, forms and endorsements, subjectivities.
• Ingest of the issued policy: declarations plus the forms schedule. Where it arrives as a scanned PDF, extraction runs into a review queue, not through it.
• A structured diff across the header, insureds, locations, limits, deductibles, and the forms schedule, which is where reduced limits and added exclusions actually live.
• An exception queue: every difference adjudicated by a licensed person, nothing auto-cleared.
• The evidence log (which policies were checked, by whom, when, against what, and what was found) and coverage tracking against the 30-days-from-binding standard the profession already sets for itself.

What the dashboard shows

Check Queue with the 30-day line marked · Exceptions by type, quoted value beside issued value · Coverage of Checking, trended by producer and carrier · Time to Check as a distribution · Extraction Confidence, published: a checking product that hides what it could not read is worse than none.

The honest caveat

A diff is not a coverage review. We do not read policy language and form a view on adequacy (that is licensed judgment) and a nine-hundred-point checklist is not a nine-hundred-point automation: we diff the structured fields reliably and flag the forms schedule for a human. We do not assume your E&O risk, and some vendors in this category offer to; we are two people, and pretending our indemnity was worth more would be the least honest thing on this page. If your checking is already at 100% within 30 days, we will say so and not sell you this.

The strongest first project

Lockup: the days between doing the work and holding the money

There is likely six figures of your revenue sitting in work you haven’t billed and bills nobody has paid. Lockup is the one metric in this category that is publicly defined, computes entirely from your own numbers, and almost no small firm tracks. The mechanism inside the firm is a queue with one server: the pre-bill goes to a partner, the partner is billing, the pre-bill sits.

One measured lever, quoted as the vendor’s own data and nothing stronger: Clio’s 2023 numbers associate a bill-approval workflow (a non-lawyer drafts, the lawyer approves) with realization of 89% against 82%. Clio expected the finding to run the other way, and said so. A vendor publishing a result that contradicted its own hypothesis is the most credible thing in that dataset.

What we build

• WIP surfacing: unbilled time and disbursements by matter, by responsible attorney, aged. Most firms cannot see this today without exporting to a spreadsheet.
• Pre-bill assembly on a schedule, not on a partner’s initiative: unbilled entries, disbursements, prior balance and trust position in one reviewable document.
• A bill-approval workflow with the approval logged (a timestamp and a name) which is what makes the supervision demonstrable rather than assumed.
• Delivery by email direct from the billing system, with an outstanding-balance summary and a payment link.
• A reminder sequence that stops permanently on any human intervention, and never runs on a matter flagged in dispute.
• A write-down register: every reduction between recorded and invoiced, with the reason and who made it. This is where realization actually goes, and no firm of this size can currently see it.

What the dashboard shows

Lockup in dollars first: unbilled work and unpaid invoices, aged by matter and responsible attorney; days second, on one stated definition: (unbilled work ÷ annual revenue) × 365, revenue meaning billings · WIP Aging 0–30 through 90+ · Pre-bill Board, where days-with-the-attorney is the field that does the work · Delivery and Payment, your own collection curve, not a benchmark · Write-downs by attorney and matter type.

The honest caveat

For an hourly firm this moves cash forward; it does not create revenue. Billing faster does not add hours, and the ABA’s fee rule (quoted in the compliance section below) says hourly bills can only reflect actual time. The firm that gains most has already moved to flat or subscription fees, which is why pricing model is part of the engagement, not an afterthought. The responsible lawyer approves and releases every bill; we never send one. And a true solo with nobody to draft a pre-bill cannot use the measured lever; we will say so rather than sell a two-person workflow to a one-person firm.

Intake: the response clock and the conflicts gate

You paid for the lead, and then nobody picked up the phone. The failure chain is structural: the call arrives during a hearing, goes to voicemail, is returned hours later to the prospect’s voicemail, and the prospect has already retained the second firm they called. And intake is where conflicts are created: the part almost every intake vendor ignores. Information taken from a prospective client through any channel can conflict the whole firm out of a matter, which is why the conflicts check belongs at the front of intake, not after it.

What we build

• One intake record per PNC: channel, source, the situation as described, the adverse parties named, timestamped. Adverse parties are captured at first contact, because that is what the conflicts check needs.
• An immediate acknowledgment with a real next step (a scheduling link, a named person, a time window) that says in plain words it is automated.
• Routing to a named human with an escalation clock. Unclaimed past your own interval, it escalates; the ladder ends at your partner, never at us.
• A conflicts check run at intake against a consolidated party database, assembled from the practice-management system, the contact store and the historical matter list, before substantive information is taken.
• A matter-opening packet on acceptance: engagement letter from your own template, e-signature, matter number, file structure. A named human presses send.
• A response-time ledger: time to first human contact, per channel, per source.

What the dashboard shows

Intake Ledger (date · channel · source · matter type · adverse parties · conflicts state · time to first human contact · disposition · owner) · The Response Clock as a distribution, by channel and hour of day: the failure concentrates in the tail and in the hours you are in court · Conflicts Queue, nothing clears itself · Unanswered, count on the front page: the study’s 48%, computed on your own inbox · Source and Disposition: counts only; there is no revenue column.

The honest caveat

Nothing here gives legal advice, evaluates a matter, or can form an attorney-client relationship; every outbound message is logged, reviewable and editable, and a responsible lawyer is notified of any interaction that could have created a relationship. We will not build lead scoring that ranks prospective clients, we will not price this per signed case, and we will not multiply your answer rate by a value per matter: the mystery-shopper study is a real study, and it is enough. Recording an intake call is treated as an all-party-consent event, with the disclosure captured inside the recording.

Trust: three-way reconciliation and the exceptions that precede a discipline file

The trust ledger and the general ledger disagree, and someone has to find out which one is lying before Friday. Most cloud practice-management products give you a trust ledger but not a general ledger, so the firm runs accounting software alongside, and every trust deposit, earned-fee transfer and cost advance is keyed twice. Reconciliation drift is the normal state, not the exception. The detail that matters most: a negative individual client ledger is the arithmetic signature of using one client’s money for another, and it is a discipline trigger even when it is entirely unintentional.

What we build

• An exception engine, not a trust ledger, and we never move money. Nightly, over the trust ledger, the general ledger and the bank feed:
• Negative client ledger detection, run daily, with the transactions that caused it.
• An uncollected-funds watch: disbursements against deposits that have not cleared, flagged before the disbursement, using your own hold rules.
• The three-way tie-out (general ledger, the sum of the positive individual client ledger balances, and the adjusted bank balance), computed and displayed as three components and their difference, on your jurisdiction’s cadence.
• Fee-transfer support: every trust-to-operating movement matched to an invoice. Unsupported transfers are exceptions, not errors to be corrected quietly.
• The reconciliation artifact your rule requires, generated and presented for a person to review, sign and date, with your jurisdiction’s retention period.

What the dashboard shows

Tie-Out: A, B and C side by side with the difference: an arithmetic identity you can check against the statement by hand · Negative Ledger Alarm, count always visible; zero is the only acceptable value and the view says so · Uncollected Funds · Reconciliation Register: the artifact a bar auditor asks for · Unsupported Transfers · Controls: three yes/no fields, and a firm that cannot answer all three has found something out.

The honest caveat

We never move money (no transfer, no disbursement, no adjusting entry) and we do not sign the reconciliation: the rule requires a lawyer’s review, signature and date, and the signature is the point of the rule. We implement your jurisdiction’s rule, not a generic one, and we name which state’s rule we implemented in the contract; cadence, retention and supervision requirements differ materially by state. We attach no dollar to any of this: the consequence of a trust failure is a licence, not a number. And the first tie-out at a firm that has not reconciled properly will find something; that is a question for your own counsel or your bar’s ethics line before it is a question for us. We say that before go-live, in writing.

The worst first project — named, deliberately

Docketing: deadlines as a rules calculation

The firms with the most court dates have the least docketing infrastructure: 78% of small-firm practitioners are in the courtroom, small firms average 33 appearances a year (more than double firms of 100 or more) and only 27% of solos have litigation support software. A deadline is a rules calculation: trigger date, service method, the court’s own rules, the holiday calendar. There is no judgment in the arithmetic. The judgment is in identifying the trigger and confirming the rule, and both of those are lawyer work.

What we build

• A deadline engine that computes downstream dates from a trigger a person recorded: service, filing, entry of an order, a hearing set.
• Every computed date enters the calendar unconfirmed, and an attorney confirms it. There is no setting that changes this.
• The rule set is yours, versioned, and explicitly scoped: we publish which jurisdictions and rule chains are implemented and, more importantly, which are not.
• Ticklers at your own intervals before each confirmed deadline, assigned to a named person.
• A calendar write with provenance: which trigger, which rule, which version, computed when, confirmed by whom.

What the dashboard shows

Deadline Board · Unconfirmed, oldest first, count on the front page: the safety metric, and the first thing on the screen · Rule Set Coverage, with an explicit list of what is not covered · Trigger Capture: matters with recent filings and no trigger recorded, because the engine computes only from what it was told.

The honest caveat

This is the worst first project on this page, and we say so. The liability is asymmetric: a wrong date is a missed deadline, and a missed deadline is malpractice; the rule set is a research engagement before it is a build; and its value section is deliberately empty, because the outcome is a claim that did not happen and we will not invent a probability multiplied by a consequence nobody has priced. Build it third or later, in named jurisdictions, with published coverage gaps, for a firm that already trusts the work. We do not scrape court dockets, we do not integrate with court e-filing, and we do not offer an indemnity for a missed deadline.