Proceedings.

briefedbot

If you administer a trustee, monitor or receiver website and you found briefedbot — or any request carrying From: ops@briefed.ca — in your logs, this page tells you exactly what it is doing and how to control it. If anything here is unwelcome, email ops@briefed.ca and we will stop — you do not need to block us to get our attention.

What Proceedings. is

Proceedings. is a free, public index of Canadian corporate insolvency and restructuring cases — CCAA filings, receiverships, notices of intention, proposals and bankruptcies. The publication was previously named briefed.; the crawler’s user-agent and contact address predate that rename and are unchanged, so the name in your logs is still the one below. Creditors, counsel and journalists otherwise have to know which firm is appointed on which matter and then find that firm’s own document page. We put those proceedings in one searchable place and link back to the documents where they are published.

What briefedbot fetches, and why

The court filings you publish on your engagement pages — appointment orders, officer reports, claims procedure materials, sale approvals. We fetch them because they are published in order that creditors and the public read them: distribution is the function of those pages, and a named agent taking them at human pace is the use they exist for.

We do not fetch anything behind a login, anything marked confidential or sealed, or anything your own robots.txt asks us to leave alone — with one narrow exception, set out under “How we behave”, which concerns a third-party document host’s factory-default file and nothing you have written. We do not scrape contact details, and we do not crawl the rest of your site — only the engagement or document pages a matter points at, and the filings those pages link.

That list is the whole of it. briefedbot is a narrow-purpose retrieval agent for documents published for readers, not a general-purpose crawler: it follows a known matter to the page you published for it, takes the filings on that page once each, and stops. The only links it follows are the ones that lead further into the same material — your insolvency index to the engagement pages under it, an engagement page to its own section pages and its own documents. It does not wander the rest of your site, and it does not come back for a document it already holds.

How we behave

  • An address on every request. Every request we make — page or PDF, on every host, without exception — carries From: ops@briefed.ca, RFC 9110’s header for the human responsible for an agent. It names a person, which no user-agent does. If you see it in a log, that is us, and that mailbox answers.
  • One user-agent, never rotated. Sent verbatim, byte for byte:
    briefedbot/0.2 (+https://briefed.ca/bot; ops@briefed.ca) - indexes published Canadian insolvency court filings
  • The one exception, stated in full. Some hosts run a filter that refuses any client that names itself — in the case we have measured, the substring botanywhere in the user-agent was enough — while serving the same bytes to clients that say nothing at all. On a host measured to behave that way, we read its pages and the filings they link with a real, unmodified browser under that browser’s own user-agent. Where that browser runs headless the HeadlessChrome token is included and never edited out, because editing it is the disguise; where a host serves only an on-screen browser, we run a real Google Chrome on screen and it reports plain Chrome, because that is genuinely what ran. We leave navigator.webdriver set to true either way — we do not hide that we are automated. From: ops@briefed.ca still goes on every one of those requests, so they are still attributable to us. We do not invent a user-agent, try strings against a filter to see what passes, or present as a person. This is a recorded decision per host, with its evidence, and it currently applies to two hosts. If you would rather we arrived as briefedbot everywhere, allowlist it and we will — that is the outcome we are asking for.
  • robots.txt is obeyed per RFC 9309, per origin. A Disallow on a path stops us on that path, and we escalate it to a human rather than routing around it.Crawl-delay is honoured and only ever slows us down. Any rule naming briefedbot, and any rule on a site you administer, is followed without exception.
  • One narrow exception, and it is about boilerplate. Some firms publish their filings from a third-party document host — a SharePoint or OneDrive tenant — and link them from their own website. Those tenants ship Microsoft’s default User-agent: * / Disallow: /, identical on every tenant ever created, written by nobody at the firm, on infrastructure the firm does not administer. Where a firm has published a filing and linked it publicly from its own site, we treat that link as what the firm intends and retrieve the document — same user-agent, same From: address, same pacing as everywhere else. We do not do this on any site a publisher runs itself, and a rule naming briefedbot stops us here as everywhere. If you would rather we did not, email ops@briefed.ca and we stop — nothing to configure at your end.
  • One request at a time per host, at least two seconds apart, jittered. We are not a load event. Two seconds is a floor rather than a setting: no flag, job or configuration can ask for less, and one that tries is raised back to it.
  • Conditional requests (If-None-Match, If-Modified-Since) wherever your server supports them, so a re-check costs you a 304.
  • A block on the identified agent is a block. A 401, 403, 429 or bot challenge is recorded as a refusal and we stop — we do not route around it, we do not re-ask it nightly, and we do not attempt to pass a challenge. That includes the exception above: a refusal that answers a real browser, or that answers every client alike, ends it, and the only route left is an email to a person. If we are blocked, we would rather ask you than work around you.
  • We serve our own copy. Once fetched, a document is served from our archive so your bandwidth is not paying for our readers, and links on our pages do not rot.

How to block us

Add this to your robots.txt and we will stop within a day:

User-agent: briefedbot
Disallow: /

That rule stops us everywhere, including on the one host where we fetch with a browser’s user-agent: we evaluate your robots.txt as briefedbot whatever we send on the wire, so a rule aimed at us is obeyed even where the wire does not say our name. User-agent: * works too.

To allow the index but keep us off a particular area, disallow that path instead — we read path rules the same way. Either way, an email to ops@briefed.ca gets a reply from a person and takes effect immediately.

Why you might prefer to allow it

Every document we index links back to the page you published it on, attributed to your firm, and every case page names the appointed officer and links to that firm’s other mandates. Creditors searching a debtor’s name find your engagement page through us. We are not republishing your work as ours — the record says where it came from, on every fact.

Corrections

Facts on Proceedings. are extracted from filings automatically and can be wrong. If we have misread something about a matter you are appointed on, tell us at proceedings.ca/report and we will review it against the filing.

Contact

ops@briefed.ca — a person, not a queue. Include the host and a date range and we can tell you exactly what we requested.

Facts and summaries are extracted automatically from the court filings linked on each page; the filings remain the authoritative record. Suggested corrections are reviewed against the source filings.