Specere · L. to look at · the platform’s own operational visibility
The school platform, reporting on itself — including the parts where it has to say “we cannot tell you”.
Specere is the visibility layer of a K-12 platform: the endpoints that answer “is it up, which build is up, can a real person actually sign in and save an edit, and was there an incident” — and answer them to anyone, without a login. It is deliberately built so that the absence of a signal reads as absence. An unwired board returns an empty board, not a green one. A probe with no result rolls up as unknown, not as operational. There is no uptime percentage on this page, because we have not published a measured one, and an invented one would be the exact thing this surface exists to argue against.
What this does not watch
A Latin name meaning “to look at”, attached to a school product, invites one assumption, so it is answered before anything else: nothing on this surface watches a person. There is no camera here, no video feed, no hallway monitoring, no visitor screening, no attendance-by-observation, and no face claim of any kind. The subject of every sentence on this page is a piece of software — an API process, a database connection, a cache, a queue, a build identifier.
That distinction matters for a procurement file, so it is written plainly rather than implied by omission: if you are evaluating campus physical security, this is not that product and this page will not pretend otherwise to stay in the conversation. What this is, is the part of a vendor relationship that usually stays invisible until an outage — the instrumentation, and the willingness to publish what it says.
What runs today
Every card below is a code path that exists in the platform now, not a roadmap item written in the present tense. Each one is named by what it does and by the failure it was built to make visible — because a capability list that does not name the failure it prevents is decoration.
A health check that names its own build
GET /healthz answers with the service and time, and folds in the commit the running bytes were cut from. That single field is what turns “something answered” into “this exact build answered” — so a deploy that did not actually replace the running process is visible from outside instead of being argued about. It is pinned by its own test file. Shipped
A readiness check that asks the dependencies
GET /readyz is a deep check, not a liveness ping: it asks whether the database and the cache are actually reachable and degrades honestly when they are not. A process that is running but cannot reach its own store answers this endpoint differently from one that can, which is the distinction a load balancer needs and a liveness ping cannot make. Shipped
Request metrics that cannot leak an identifier
GET /metrics exposes Prometheus text: a request-latency histogram and an error-rate counter. Both are keyed on the matched route TEMPLATE rather than the raw URL, deliberately. A metric label built from a real path would carry whatever identifier was in that path into your monitoring system forever; a low-cardinality template cannot. Shipped
One correlation identifier through the whole request
Every request carries a request identifier — an inbound one is honoured rather than overwritten — and it is bound, with the user and school scope, into the per-request context so every log line and downstream call correlate. When you send us a support message from inside the product, that identifier travels with it, so a report is a thread to pull rather than a description to reconstruct. Shipped
A log that redacts before it writes
The structured logger is a redacting one: personal data, secrets and tokens do not reach a log line. This is a property of the logger every surface shares, not a setting each route remembers to switch on — which is the only version of that promise worth making, because the other version fails on the one route somebody forgot. Shipped
A probe that walks a real session
The synthetic probe does three things a real signed-in session does: mints a short-lived token and verifies it round-trips through the same signing and verification path a real login uses; reads a known fixture through the repository under system scope, exercising the database read and the row-level-security plumbing; and writes then re-reads a throwaway marker through the durable key-value store. Each step is timed against a soft budget: over budget classifies as degraded, a throw or a timeout classifies as failed, and the roll-up is the worst step — so the report names WHICH step is sad, not merely that something is. Shipped
An aggregator whose pill is the worst of three
GET /status folds the latest probe record, the readiness dependencies, and the service-level breach COUNTS into one unauthenticated, no-personal-data response, and returns 503 when it is degraded or down rather than a cheerful 200 with a sad body. Breach counts are counts: how many are breached, how many at risk, how many total. No ticket identity, no subject, no text. Shipped
A public board anyone can read
GET /v1/status/board needs no key, no cookie and no account: it returns the curated components in their published order, every ongoing incident, and a capped recent-resolved history. An incident is ongoing until it carries a resolution timestamp, so “resolved” is a stamped fact rather than a quietly dropped row. Shipped
The public board, and why its empty state is empty
The board is two things: a list of service components with a current health state each, and a timeline of incidents. Reads are anonymous by policy — the row-level-security rule on those tables permits the public read outright, which is what makes it safe to hand a district a link and let them check without asking us for anything. Writes are the opposite: posting or updating a component or an incident is gated to a platform owner (a support administrator, or the flagged platform-owner studio’s partner administrator) and executes through the elevated system seam the write policy requires. A sales representative is denied unconditionally — not because the role check upstream is expected to fail, but because a board that a salesperson can edit is not a status board.
The part worth reading twice is the failure mode. The store behind the board is an optional seam, and the honest fallbacks are the design, not a stopgap: an unwired read returns an empty board — components: none, incidents: none — and an unwired write returns 503 with the reason code status_store_unavailable. Neither path can produce a green component that nobody wrote. The same discipline governs the probe: a roll-up over an empty result is unknown, rendered as “checking”, never as operational. If this system does not know, it says it does not know.
The reason to build it that way is unglamorous. A status surface that defaults to healthy is worse than no status surface, because it converts a silent outage into a confident denial — and the person it misleads first is the school administrator deciding whether to call you.
Who this is for, and what the first week actually looks like
The reader here is a district technology director, a systems administrator, or the operations person who gets called when a teacher cannot open a page at 8:05 in the morning. Not a buyer looking for a slogan — a person who will be asked, in front of a board, why the vendor said everything was fine.
Day one: point a monitor at the health endpoint on the deployment your schools use and read the build identifier it returns. You now have an outside-verifiable answer to “which version is actually running” that does not depend on us telling you. Day two: add the readiness endpoint to the same monitor as a separate check, so a dependency failure is distinguishable from a process failure in your own dashboard rather than in ours. Later in the week: scrape the metrics endpoint with the collector you already run — it is Prometheus text, no adapter — and put the request-latency histogram and error-rate counter beside the rest of your infrastructure. Then call the board endpoint and read it: if it returns components and incidents, that is the curated board; if it returns an empty board, that is an unwired store in that deployment, and you have learned something true either way.
What you should be able to say at the end of that week is narrow and checkable: you can tell whether the platform is up, which build is up, whether its dependencies are reachable, and whether we have posted an incident — all four without a support ticket, and none of it taking our word for it.
Fair objections, answered
These are the five things a technology director actually says in the second meeting. They are written here rather than left for the call, including the one where the honest answer is a limit.
“We already pay a hosted status-page vendor. Why would we care about yours?”
A hosted status page is a place where a human types a colour. That is genuinely useful for communication and it is not a measurement. The distinction here is that the pill is backed by a probe walking the same token, database and key-value paths the product walks, and by readiness checks against the real dependencies — so the signal originates in the system rather than in someone’s judgement about the system. Use both if you like; they answer different questions.
“Every vendor claims high availability. What is your number?”
We do not state one here, and that is deliberate. We have not published a measured availability figure, and a number typed onto a marketing page to match what everyone else types is not a measurement. If a figure like that becomes contractual for your district, it belongs in a signed agreement with a defined measurement window and a named instrument — not in a hero paragraph.
“A public board just means you will hide the embarrassing incidents.”
A fair suspicion, and the structural answer is what the schema permits rather than what we promise. An incident row is ongoing until a resolution timestamp is stamped on it; there is no state where an incident is quietly marked done without that stamp. The board also returns a capped recent-resolved history alongside the ongoing ones, so a resolved incident stays visible for a while rather than vanishing the moment it is closed. What we cannot offer you structurally is proof that an incident was posted at all — that is a human commitment, and this page will not dress it up as a technical guarantee.
“Does giving us a public endpoint expose anything about our students?”
The public board is built on tables that carry no tenancy column and no student datum — the health of a component reads identically for every school, which is precisely why an anonymous read is safe. The health, readiness and status responses are enum statuses, step names, latencies, safe reason codes, dependency names and integer counts. The probe’s read touches a known fixture and its write touches a throwaway marker, so it does not read or write real school data to prove the platform works.
“Your monitoring is your problem. Why is it on a marketing page?”
Because in K-12 the vendor’s instrumentation becomes the district’s problem on exactly the days that matter — a deadline week, a picture day, the morning of a board meeting. A district that can independently observe a vendor is in a materially different position from one that has to file a ticket and wait to be told. That is a procurement fact, so it belongs where procurement reads.
What is not built, stated in the present tense
This host serves this page. It does not serve a hosted, human-readable status web page with component tiles and a live incident feed — what exists is the API surface described above plus the status pill inside the product. If you want a browser view today, you read the board endpoint directly or you read the pill while signed in.
There is no published per-school uptime history and no availability percentage anywhere in this platform’s public surfaces. There is no email or text subscription to incident notifications: the board is a thing you poll, not a thing that reaches out to you. There is no archive of written post-incident analyses. Distributed traces are not exported at all unless an operator sets the exporter configuration; with none set, the tracer is a no-op and nothing is sent anywhere.
Each of those is a real absence today. None of them is described here as arriving, because a page that describes an absence as an arrival is just a promise with a timestamp attached, and the timestamp is the part that rots. If one of them is the thing your district would need, say so in a conversation — that is a scoping discussion, not a queue position.
Students, logs, and what an observability layer must never accumulate
Observability is the discipline most likely to quietly become the largest store of personal data in a company, because a log line is cheap to write and nobody reads them until they matter. The countermeasures here are properties of the plumbing rather than rules each route follows: the structured logger redacts before it writes, so personal data, secrets and tokens are not persisted to a log line; and request metrics are keyed on the matched route TEMPLATE, so an identifier that appeared in a URL never becomes a permanent label in a metrics store.
The public surfaces carry no student data by construction, not by filtering. The health, readiness and status responses are limited to enum statuses, step names, latencies, safe reason codes, dependency names and integer counts — there is no field in those shapes for a name. The status board’s tables carry no tenancy column and no student datum at all, which is exactly what makes an anonymous public read of them defensible: the health of the editor is the same fact for every school. And the probe deliberately avoids real data on both sides — it reads a known fixture and it writes a throwaway marker, so proving the save path works never means touching a student’s work.
Minors’ data across this platform is consent-gated and never public. Nothing described on this page is an exception to that, and nothing described on this page needs to be.
What this costs, in the present tense
Nothing on this page takes a payment. There is no pricing table, no checkout, no plan comparison, and no live charge on this host. The health check, the readiness check, the metrics endpoint, the correlated redacting log, the synthetic probe and the public board are part of the platform a school already runs — they are not sold as a separate product today.
No probe step creates or settles a payment either. That is worth stating because a synthetic check that exercised a real payment path would be a monitoring system that spends money to prove it can spend money, and a green light of that kind is not one anybody should want.
Where this sits among the rest
Specere belongs to a small set of Latin-named infrastructure hosts in this estate, and it takes the plainest reading of its own name: specere, to look at. Its typography follows the family — the same headline and body faces every property here uses, institutional navy for an institutional reader — with one thing of its own: an open, horizontal treatment with an implied horizon line under the headline, an aperture rather than a shield. That is the brief for this name specifically, and it is why this page looks related to its siblings without looking like a copy of one.
It is not the same surface as the security-and-trust one-pager, and the difference is not cosmetic. A trust page describes a policy: which controls exist, how data is handled, who can see what. A status surface reports a measurement: what is true right now. Both matter in a procurement file and neither substitutes for the other — a perfect policy document tells you nothing about this morning, and a green board tells you nothing about who can read a student record.
Questions we are actually asked
Does Specere watch students, hallways, or cameras?
No. Nothing on this surface touches a camera, a video feed, or a person. The Latin root means “to look at”, and the thing being looked at is the software itself — whether the API is answering, which build is answering, whether the database and cache are reachable, and whether a signed-in adviser could actually sign in and save an edit.
Why is a health check that returns 200 not enough?
Because a 200 proves a process is up; it does not prove a person can work. The synthetic probe walks the three steps a real session walks — mint and verify a token, read a fixture through the repository under system scope, write and re-read a throwaway marker — and reports which of those three is slow or broken. A health endpoint answering while sign-in is broken is precisely the case a 200 cannot see.
What uptime do you guarantee?
This page states no uptime percentage and no availability guarantee, because we have not published a measured one. A number invented for a marketing page is the exact failure this surface exists to argue against. What the platform gives you instead is the raw signal: the health check, the readiness check, the metrics endpoint, and a component-and-incident board you can read without asking anyone.
If the status store is not wired in our deployment, do we get a green board?
No. An unwired board read returns an EMPTY board, and an unwired board write returns 503 with the reason code status_store_unavailable. An empty probe result rolls up as unknown, not as operational. The failure mode of this design is “we cannot tell you”, never “everything is fine”.
Who can post or resolve an incident on the public board?
Only a platform owner. The component and incident writes are gated to a support administrator or the flagged platform-owner studio’s partner administrator, and they execute through the elevated system seam the migration’s own write policy requires. A sales representative is denied unconditionally as defence in depth. An incident is ongoing until it carries a resolution timestamp; there is no way to mark it resolved by leaving the timestamp blank.
Do your logs or metrics contain student data?
The structured logger redacts: personal data, secrets and tokens are not written to a log line. Metrics are keyed on a low-cardinality route template rather than the raw URL, so an identifier that appears in a path does not become a metric label. The health, readiness and status responses carry enum statuses, step names, latencies, safe reason codes, dependency names and integer counts only. The board’s tables carry no tenancy column and no student datum — the health of the editor reads the same for every school.
Does telemetry leave our deployment?
Traces are exported only when an operator sets the OTLP exporter configuration. With none set, the tracer is the zero-overhead no-op and no trace is exported anywhere. The metrics endpoint is a Prometheus text surface your own collector scrapes; nothing in this stack ships telemetry to a third party on its own initiative.
Does this cost anything?
Money is honest-off on this page: there is no pricing table, no checkout, and nothing here takes a live charge. The health, readiness, metrics, probe and board surfaces are part of the platform a school already runs; they are not sold as a separate line today. A conversation works out what, if anything, applies.
The next concrete step
If you are evaluating this platform, the useful next step is not a demo of this page — it is a short conversation in which we tell you the deployment your schools would be on and you point your own monitoring at its health and readiness endpoints for a fortnight before signing anything. That is a request we can answer in a day, and it is the only evaluation of an operations claim that is worth the meeting.
If you are already a school on this platform and something is wrong right now, do not start here: use the support path inside the product, because that intake captures the request identifier automatically and that identifier is what makes your report traceable through the logs described above.
What this page is, and is not, claiming
Specere is the operational-visibility surface of a K-12 platform. The health check carrying a build identifier, the deep readiness check, the Prometheus metrics on low-cardinality route labels, the correlated redacting log, the three-step synthetic probe, and the public component-and-incident board are all shipped code paths today. No uptime percentage, availability guarantee, recovery-time figure or incident count is claimed anywhere on this page, because none has been published as a measurement. Nothing here watches a person — no camera, no video, no face, no hallway. A hosted status web page, per-school uptime history, incident subscriptions and a post-incident write-up archive are not built, and are named above as absent rather than as forthcoming. Traces are exported only where an operator configures an exporter; with none configured, none leave. Minors’ data is consent-gated and never public, and no surface described here logs it. This is a for-profit vendor, not a charity. Money is honest-off: no pricing table, no checkout, no live charge, and no probe step creates or settles a payment. No AI claim is made on this page. There are no invented statistics, adoption counts or testimonials here, and no competitor is named. The word “adviser” is spelled that way throughout.