Courtroom.software · Court clerks’ offices & law-firm calendaring · Early access · 2026
Courtroom.software is a docket and hearing-scheduling platform for court clerks’ offices and law-firm calendaring staff. A calendar scoped to the courtroom and the judge assigned to it. Continuance requests that rebuild the calendar around a new date without ever ruling on the request itself — that stays the judge’s. A conflict check built to catch an attorney double-booked across two different courtrooms, not just one calendar’s own list. Sealed-case entries kept out of the public-docket view by design. Early access — no pricing commitment, no signup, and no live booking today.
A general appointment tool schedules one party against one resource. A docket is adversarial and multi-party by nature. A single calendar call can be blocked by a courtroom conflict, a judge double-booked by rotation, or an attorney of record already committed to a different courtroom at the same hour — three different conflict shapes a single-resource booking tool was never built to see.
Courtroom.software is built around that shape from the start. The vocabulary reflects it: the docket, calendar calls, continuances, the motions calendar, jury-selection scheduling — not appointment slots, not booking links. The database-level overlap-guarantee primitive that will underlie every conflict check here is built and production-tested on this platform today; the court-specific surfaces above it — docket entry, continuance workflow, judge-rotation, cross-courtroom attorney conflicts — are in development or planned, and are never described as live before they are.
How it works
The workflow follows a matter from its first docket entry through the day it is actually heard. Every stage below is described against its real build status — the overlap-guarantee primitive is built; the court-specific workflow on top of it is in development or planned.
Stage 1 — A matter is entered on the docket
A clerk or docket staffer enters a matter against a case number, a matter type (hearing, motion, calendar call, trial), and a requested courtroom and time window. The overlap-guarantee primitive checks the courtroom and time window against every other entry for that courtroom before the entry is accepted — the same class of database-level guarantee this platform runs for booking conflicts elsewhere.
Stage 2 — The calendar is checked across courtrooms and counsel
Beyond the single-courtroom overlap check, a cross-courtroom conflict check looks for the same judge assigned to two calendar entries at once, or an attorney of record with a matter in a different courtroom at an overlapping time. This cross-courtroom check is planned; the single-courtroom overlap guarantee it extends is built.
Stage 3 — A continuance or reassignment is ruled on and the calendar rebuilds
If a continuance is filed and granted, or a matter is reassigned to a different judge or courtroom, the docket entry is meant to update and the conflict check re-runs against the new date, courtroom, or judge. The ruling itself is always the judge’s; the platform never grants, denies, or recommends a continuance outcome.
Stage 4 — The day-of docket is published to the parties entitled to see it
The day’s docket is published to counsel of record, court staff, and, for public matters, a public-docket view consistent with the court’s own transparency rules. Once this planned publishing stage is live, a sealed matter is designed to never appear in the public view. A remote-hearing link, where one is attached to the entry, is visible to the parties entitled to see the entry itself — never exposed more broadly than the entry it belongs to.
The surfaces
Every surface is labelled honestly: Built means the underlying primitive is production-tested on this platform. In development means the court-specific surface is in active build. Planned means it is designed but not yet in active build. We do not claim otherwise.
Every scheduled matter — hearing, motion, calendar call, status conference — sits on one docket calendar scoped to the courtroom and the judge assigned to it. A clerk sees the full day’s calendar for a courtroom at a glance: case number, matter type, assigned judge, and the parties’ counsel of record. The no-double-booking primitive underneath — a database-level overlap guarantee on a courtroom and time window — is the same class of engine used elsewhere on this platform and is built and production-tested today. The docket-entry surface itself, the one a clerk would use to place a matter on the calendar, is in active development and is not live today.
Overlap-guarantee primitive built · docket entry surface in development
A continuance request is filed against a specific hearing; when the judge rules and a new date is set, the docket is meant to rebuild the affected calendar entries around it — flagging any new conflict the moved date creates for the same courtroom, the same judge, or an attorney of record already committed elsewhere that day. The platform never grants or denies a continuance itself — that ruling is the judge’s, recorded, never automated. This workflow is designed and not yet in active build; described here as planned, not live.
Planned — no automated ruling, ever
Judges rotate through courtrooms and calendar types on a schedule the clerk’s office maintains; the docket calendar is meant to reflect the current rotation so a matter assigned to a courtroom shows the judge actually sitting there that week, not a stale assignment. A conflict check across the rotation — the same judge assigned to two calendar calls at once in different courtrooms — is the kind of guarantee the underlying overlap primitive is built to catch; the judge-rotation surface that applies it to rotation scheduling specifically is in development.
Overlap primitive built · rotation surface in development
An attorney with matters in two different courtrooms at overlapping times is a routine calendaring hazard for any busy litigation practice or public defender’s office. The conflict check compares an attorney of record against every courtroom’s calendar for the day, not just one courtroom’s own list — catching a cross-courtroom double-booking a single-courtroom calendar would never surface. This cross-courtroom conflict surface is planned and builds on the same overlap-guarantee primitive used across the docket calendar; it is not yet in active build.
Planned — builds on the built overlap primitive
Motions are calendared separately from trial dates and evidentiary hearings, with their own briefing and filing-deadline clock running against each entry. A motions calendar view lets a clerk or a firm’s docket staff see only pending motions and their hearing dates, filtered from the broader docket. This is a filtered view over the same underlying calendar substrate as the docket calendar, not a separate system — and is in active development alongside it.
In development · filtered view over the docket substrate
Jury selection carries its own scheduling shape: a jury pool report date, a voir dire window, and a courtroom reservation that can run longer and less predictably than a standard hearing slot. Jury-selection scheduling is planned as its own surface on the same calendar substrate, distinct from the standard hearing and motion flows, so a courtroom reserved for jury selection is not silently double-booked against an unrelated calendar call. This surface is planned and is not in active build.
Planned
Witness scheduling coordinates an expected appearance window against the trial calendar so a witness, or the attorney coordinating them, can see roughly when testimony is expected without needing to sit through an entire trial day. This surface is planned and is not in active build; described honestly as a designed capability, not a live one.
Planned
A deadline layer over the docket — statute-of-limitations dates, filing deadlines, response windows — surfaced alongside the hearing calendar so calendaring staff see an approaching deadline in the same view as the hearings it affects. This is a scheduling and reminder layer, never a substitute for legal judgment: the platform tracks dates it is given and never calculates a jurisdiction-specific statute-of-limitations date on its own. This surface is planned and is not in active build.
Planned — a calendar layer, not a legal-advice engine
A sealed case is designed to never be listed on a public-facing docket view, once this planned safeguard ships; its calendar entries are visible only to the authorized parties and the court staff assigned to it. A public-docket entry, by contrast, is designed to be visible to the public consistent with the court’s own transparency rules — the two are never the same view, and a sealed matter is never promoted into the public view by a display default. This access-control boundary is a design commitment for the platform; the specific court-facing implementation is planned and in development, not live today.
Planned — access-controlled by design
A remote or video appearance option attaches to the calendar entry itself, so a party checking a hearing’s details sees whether it is in-person, remote, or hybrid without cross-referencing a separate video-conferencing tool. The platform does not host video itself; it is designed to hold a link to whatever conferencing system the court already uses. This surface is planned and is not in active build.
Planned — link attachment, not a video host
Many court e-filing systems generate hearing dates and deadlines that ought to land on the docket calendar automatically rather than by manual re-entry. An e-filing integration point is designed into the platform’s architecture but is not connected to any specific e-filing system today, and no e-filing feed is live. This is described honestly as a planned integration, never as a working connection to any named e-filing vendor or court system.
Planned — no live feed to any e-filing system
Who uses it
A court clerk maintains the docket for one or more courtrooms: entering matters, tracking the judge rotation, and processing continuance rulings as they come down. The clerk’s view is scoped to the courtroom or courtrooms they administer, with the cross-courtroom conflict check running underneath to catch a judge or an attorney double-booked elsewhere on the same calendar day.
A calendaring deputy handles the day-to-day mechanics: setting a new hearing date after a continuance is granted, publishing the day-of docket to the parties entitled to see it, and keeping the motions calendar current against its own briefing clock. The deputy never rules on anything — that stays with the judge — but is the one who sees the calendar rebuild happen once a ruling comes in.
A firm’s docket desk tracks every matter its attorneys have across every courtroom they appear in — not one court’s calendar, but the cross-courtroom view an individual attorney needs to avoid being double-booked. Statute-of-limitations and filing-deadline tracking sits alongside the hearing calendar so an approaching deadline is visible in the same view as the hearings it affects.
A sealed case is designed to never appear on a public-facing docket view once this planned safeguard ships; its entries are visible only to the authorized parties and the court staff assigned to it. A public-docket entry is a separate view entirely, consistent with the court’s own transparency rules — the two are never the same code path, so a sealed matter cannot be exposed by a display default that simply forgot to filter it.
A remote-hearing link, where one is attached to a calendar entry, is visible only to the parties entitled to see the entry itself — the link is never exposed more broadly than the hearing it belongs to. This access-control boundary is a design commitment for the platform; the court-facing implementation is in development, not live today.
What is built and what is coming — plainly
Built and production-tested today: the database-level overlap-guarantee primitive that underlies the no-double-booking check on a courtroom and time window — the same class of engine used elsewhere on this platform.
In development or planned: the docket-entry surface, the continuance workflow, the judge-rotation surface, the cross-courtroom attorney conflict check, the motions calendar, jury-selection scheduling, witness scheduling, statute-of-limitations and filing-deadline tracking, the sealed-case access-control implementation, remote and video hearing link attachment, and e-filing-system integration. None of these are claimed as live today. There is no live booking, no billing, and no subscription. No judicial decision of any kind is automated. Court clerks, court administrators, and firm docket staff deserve to know what is production-tested and what is still being built.
Early access · Court clerks’ offices & law-firm calendaring staff
Courtroom.software is in active development. We do conversations that show the current state honestly: how the overlap-guarantee primitive works underneath the docket calendar, which court-specific surfaces are already in build, and which are still on the roadmap. There is no pricing commitment and no signup. If it looks right for your court or your firm’s docket desk, we discuss what early access looks like.
To book: email [email protected].
FAQ
Not yet. The docket calendar, continuance workflow, judge-rotation surface, jury-selection scheduling, witness scheduling, deadline tracking, sealed-case access control, remote-hearing link attachment, and e-filing integration are all in development or planned — none are live today. The overlap-guarantee primitive that will underlie the no-double-booking check on a courtroom and time window is built and production-tested elsewhere on this platform. There is no pricing commitment and no signup. Reserve early access or book a conversation to see the current state honestly.
No. A continuance ruling, a judge assignment, and every judicial decision remain entirely the judge’s. The platform is designed to record the ruling and rebuild the affected calendar entries around it — it never recommends an outcome, never automates a ruling, and carries no AI-driven decision surface of any kind.
The planned cross-courtroom conflict check compares an attorney of record against every courtroom’s calendar for the day, not just one courtroom’s own list, so a matter in Courtroom 3 and a matter in Courtroom 7 at overlapping times for the same attorney is caught before both are confirmed. This surface is planned; it builds on the overlap-guarantee primitive, which is built and production-tested for single-courtroom conflicts today.
A sealed case is designed to never appear on a public-facing docket view once this planned control ships; its entries are visible only to the authorized parties and assigned court staff. A public-docket entry is a distinct view from a sealed entry — the two are never the same code path, so a sealed matter cannot be exposed by a display default that simply forgot to filter it. The court-facing implementation of this boundary is in development.
No. An e-filing integration point is designed into the platform’s architecture, but it is not connected to any specific e-filing vendor or court system today, and no e-filing feed is live. This is a planned integration, described honestly as such.
A general appointment tool schedules one party against one resource. A docket is adversarial and multi-party by nature: a hearing has a judge, a courtroom, and counsel for every side, each of whom can create a conflict independently — a courtroom conflict, a judge-rotation conflict, or an attorney conflict across an entirely different courtroom. The vocabulary is different too: dockets, continuances, calendar calls, and motions calendars are not appointment-booking concepts. courtroom.software is being built around that shape from the start, not adapted from a single-resource booking tool.
No. The platform does not host video. The planned remote-hearing surface attaches a link to whatever video-conferencing system a court already uses, so the calendar entry itself carries the information about whether an appearance is in-person, remote, or hybrid. No video hosting is built or claimed.
No. The planned deadline-tracking layer surfaces dates it is given — a statute-of-limitations date, a filing deadline — alongside the hearing calendar so calendaring staff see them in one view. It never calculates a jurisdiction-specific statute-of-limitations date on its own and is never a substitute for legal judgment.
No. There is no live checkout, no billing, and no subscription charge running through this surface today. Any computed fee line is reserved, never charged. Pricing, when it exists, will be a plan, not a live transaction.
Court clerks' offices, court administrators, calendaring deputies, and law-firm docket and calendaring staff — the people who maintain the docket calendar and coordinate hearing dates across judges, courtrooms, and counsel. It is not built for a personal appointment booking, a school period, or a facility rental; the workflow, vocabulary, and conflict shape are specific to a court docket.