highereducation.network · A new segment, described at its real size

A peer community for advisers and registrars in post-secondary — being built now, and named honestly at every step

Discussion boards, an opt-in adviser directory, and a shared practice library for post-secondary advising. None of the three exists today, and this page says which piece of missing backend is the reason. What does exist is the machinery underneath: six named K–12 modules — a requirement engine that returns three verdicts rather than two, a counseling request-and-track ladder, a transcript issuer, a public credential verifier, a records inference seam, and an adult-education domain object. They run for schools. None of them is pointed at a post-secondary institution today, which is a sentence you should be able to hold us to. No checkout, no membership fee, no adoption claims, no vendor names. When there is something real to join, the way in will be a conversation.

Email a person What exists underneath What is missing

Discussion boardspeer practice-sharing between institutions — blocked on moderation, being built

Adviser directoryopt-in, never default-public — planned, no record to list

Practice libraryshared templates and checklists — planned, no upload path

Six named modulesthe K–12 machinery this segment would extend — running today

What we are building

The community surface — and the specific thing blocking each piece

Each card below is labelled with where it actually is: being built, planned, or a platform primitive being reused. Each one also names what is in the way, because “planned” on its own tells you nothing you can check. Nothing here is a running community with members. If a card interests you, that is exactly the moment to get in touch — while its shape is still soft enough to change.

Peer discussion boards

A place for an adviser or registrar to ask how another institution actually handles a tricky case — a transfer-credit decision where the sending course maps to no local requirement, a requirement-rule exception nobody wrote down, a caseload that grew faster than the team did. Practice-sharing between peers, not a support forum for our own product. There is no board to post to and no thread to read: the moderation half of the peer identity and moderation API described in “Where things stand” is unwritten, and a board without moderation is not something we will put in front of people who work with student records.

Being built

Adviser directory

An opt-in directory so an adviser or registrar can be found by a peer at another institution who works the same problem. Opt-in means exactly that: nobody is listed by default, and visibility is a choice each person makes for themselves, not a default we set for them. The nearest built precedent is the public credential verifier, which answers a single verification question over POST /v1/public/credential-verify and deliberately discloses nothing else about the person — that narrow surface is the posture a directory would inherit. The directory itself does not exist: there is no record to be listed in.

Planned

Practice library

A shared shelf of the artifacts a peer community actually trades — a requirement-mapping template, a sample outreach cadence, a checklist for a records migration. Contributed by members, not authored top-down. There is nothing on the shelf because there is no shelf: no upload path, no contribution licence decided, no moderation queue. We would rather write that sentence than show an empty grid with a search box over it.

Planned

One shared identity and privacy posture

The community would be built on the identity and privacy substrate that already runs a K–12 platform: scoped, auditable access rather than a forum login bolted on beside it. That substrate is real and running for schools. It is the one part of this page you can hold us to today, which is why the next section names the specific modules instead of saying “platform” and stopping there.

Platform primitive being reused

Who it is for

Three roles, and the named module each one would actually ride

An earlier version of this section described three people entirely in terms of what they wanted, which told you nothing about whether we could help any of them. Each role below instead names the existing module its work would extend, the item number it carries on our own internal gap-list, and the part we do not have. Every module named here is a K–12 module running for schools today.

The college adviser

Advising caseload and appointment workflow is item 9 on a 34-item list of what a post-secondary institution needs and we do not have. The closest built thing is the counseling REQUEST and TRACK ladder in domain/college-career.ts: two request kinds (a recommendation and a transcript send), a tracked status carried on each, and a readiness compute over eight named milestones running from FAFSA filed through to decision finalized. It is a K–12 ladder. Generalising it to advising requests is a real, bounded piece of work rather than a rewrite. The caveat you should hear first: appointment booking itself is unowned even in K–12 — a platform-wide gap, not a post-secondary one — so nobody here is going to tell you scheduling is nearly done.

Rides: domain/college-career.ts — a K–12 module today.

The registrar

Degree audit is the one item on that list with no K–12 analog at all. What exists is the shape, not the data: the academic-eligibility engine evaluates a requirement ladder and returns three verdicts rather than two — eligible, ineligible, or indeterminate — with four named reasons a verdict can be indeterminate, including a governing rule that has not been confirmed by a subject-matter expert, which defaults to deny rather than to a guess. Every verdict pins its provenance: the rule id and version, the grading period, the fact counts it was computed from, and an as-of instant, so an auditor recomputing from the same facts and the same rule version gets a byte-identical stamp. If you own requirement rules and the exceptions nobody wrote down, that refusal to guess is the part worth arguing with us about while the degree-audit data model is still soft enough to change.

Rides: domain/academic-eligibility-engine.ts — a K–12 module today.

The small advising team

A team of two or three advisers doing the work of a much larger office has no professional-development budget to spend. Two built things are relevant and both are deliberately small: the public credential verifier answers a verification as a machine-readable verdict over POST /v1/public/credential-verify and serves a minimal page over GET on the same path, with no account required at either end; and an adult-education domain object already exists, which makes continuing and adult enrolment a partial-reuse path rather than a net-new build. The practice library aimed at your team is planned and empty. What we can offer a small team today is a conversation with the people building it, which is worth saying plainly rather than dressing up.

Rides: routes/credential-verifier-public.ts — a K–12 module today.

What already exists underneath

Six named modules, and the post-secondary need each one maps to

“Built on a platform” is the kind of sentence that survives because nobody can check it. So here is the check: six modules by name, each opened before it was written down here, each mapped to the post-secondary capability it would be extended into. Read the important caveat first. These are K–12 modules. They serve schools. Not one of them serves a post-secondary institution today. Naming them is a claim about what we would build from, and it is deliberately not a claim about what a college can use this afternoon.

Degree audit and requirement rules

`domain/academic-eligibility-engine.ts`

A requirement-ladder evaluator with a three-valued verdict, four named indeterminate reasons, a default pass mark held as a named percentage constant rather than a number buried in a branch, and a provenance stamp that makes any verdict re-derivable. Pattern reuse, not data reuse: the post-secondary requirement set is its own model and has to be built.

Advising requests and caseload tracking

`domain/college-career.ts`

The counseling REQUEST and TRACK ladder, plus a readiness compute over eight milestones. The transcript-send request already rides the issuer rather than duplicating it, and that seam is exactly what an advising-request workflow would extend.

Transcript and record exchange

`domain/diploma-issuer.ts with routes/transcripts-report-cards.ts`

A diploma and transcript issuer with its own route surface for transcripts and report cards. It is key-gated, which is a constraint we state here rather than route around quietly.

Public credential verification

`routes/credential-verifier-public.ts`

One verification question, answered as a machine-readable verdict over POST and as a minimal server-rendered page over GET, both on /v1/public/credential-verify, with no account at either end. The narrow disclosure surface is the whole point of it.

Student records core and records interoperability

`domain/sis-inference-seam.ts`

The inference seam a records core syncs through. A post-secondary records core would extend this seam rather than get a parallel one, because two record seams is how a platform starts disagreeing with itself.

Continuing and adult enrolment

`domain/adult.ts`

An adult-education domain object already exists, which makes continuing-education enrolment partial reuse rather than a net-new build — one of the few post-secondary items where that is true.

What is missing

The part of the list with nothing underneath it

A dated internal gap-list enumerates thirty-four post-secondary items against what we own. Roughly nineteen extend something that exists. Four share a shape but need their own data model, which makes them new builds wearing a familiar outline. That leaves the two groups below, plus the community backend itself. We publish this because a segment page that lists only the reusable nineteen is technically accurate and functionally a lie.

Nothing to extend — these start at zero

Housing and residence life, research administration, work-study and campus-employment tracking, proctoring, e-textbook and courseware, simulation and lab courseware, and faculty HR at post-secondary scale and tenure model. That is roughly nine of the thirty-four enumerated items with no K–12 analog to extend at all. Several are a decision to build, license, or partner before they are a piece of engineering, and none of them is a sprint.

Missing here, and missing in K–12 as well

Appointment booking and a public application portal are absent on both sides of the house. They are platform-wide gaps, and counting them as post-secondary debt would inflate the same backlog twice. We name them so that when somebody tallies what is missing, these two items are not counted in both columns.

The community backend itself

Account creation for advisers and registrars, opt-in directory visibility, and discussion moderation. None of it is written. It is the single dependency between this page and a community that exists, which is why it appears in the posture section, in the FAQ, and here, rather than being mentioned once and left to be found.

How a decision is audited

Why the requirement engine refuses to guess — and why that is the part worth extending

A registrar’s real question about any audit tool is not what it computes, it is whether the answer can be defended afterwards. The engine we would extend was built for K–12 academic eligibility and answers that question in four specific ways. Each of them is a property of code that exists today. None of them is a claim that a degree audit exists.

Three verdicts, not two

A requirement evaluation returns eligible, ineligible, or indeterminate. The third value is the one that matters: a rule engine that only knows pass and fail has to invent an answer whenever a fact is missing, and inventing an answer about a student record is how a system quietly becomes wrong. Individual criteria carry the same three outcomes, so a partial answer stays partial instead of being rounded into a verdict.

The reason is named, not implied

There are four named reasons a verdict can be indeterminate: no live grade feed resolved, a feed that resolved with zero graded courses in the period, an attendance criterion with no attendance feed behind it, and a governing rule that has not been confirmed by a subject-matter expert. That last one defaults to deny. A reader is told which of the four applies rather than being handed a shrug.

The verdict is re-derivable

Each decision pins its provenance: the rule id and version, whether that rule was confirmed, the grading period, the counts of the facts it was computed from, and the as-of instant. Recomputing from the same facts and the same rule version produces a byte-identical stamp. That is the difference between a number on a dashboard and a decision somebody can defend in a meeting.

What this does not do

It evaluates K–12 academic eligibility. It has never been pointed at a degree requirement, a transfer-credit mapping, or a catalog year. The audit properties above are the reason we would extend this engine rather than start a new one — they are not a claim that a degree audit exists.

The segment

Four domains cover higher education — this is the honest map

There is no fabricated member count or institution count behind these links. This is the shape of the segment: a peer community, a portal, a catalog of coverage, and professional services — each labelled with where it stands and what it actually holds today.

highereducation.network

The peer community

A peer community for advisers and registrars in post-secondary — a place to compare practice and shape what gets built. It has its own render module rather than a shared template, and you are reading the whole of it: there is no logged-in half waiting behind this page.

You are here

highereducation.center

The portal

The front door for the segment: what is being built, who it is for, and how to reach a person. It is the page that describes this domain as the peer community, which is the sentence this page is accountable to.

Building

highereducation.courses

The catalog of coverage

An honest catalog of what the segment covers as it is built — advising, degree audit, and continuing-education workflows. Continuing education is the one of those three with an existing domain object underneath it today.

Building

highereducation.services

Professional services

Hands-on help for an institution adopting the segment — mapping requirement rules, migrating a record, training advisers. Planned, and the only one of the four with no page-level build underway.

Planned

The incumbent

There is already a professional community for advisers, and we are not claiming to beat it

Academic advising has an established professional association: a membership, a national conference programme, regional divisions, published standards, and decades of institutional standing. Advisers and registrars already belong to it, and it is a real thing that works. We do not name it here, because naming a competitor in order to stand next to it is a marketing move rather than an argument.

What we have against that is a render module and a plan. A community product — member profiles, moderated boards, a real directory — would be built from close to zero, against an incumbent with conference infrastructure we could not match for years. Our own internal per-domain plan says exactly that, and says the credible options include a narrower wedge or coexistence rather than head-on competition. That is a founder decision that has not been made, and we are not going to pre-announce it as a strategy on a marketing page.

The one thing we can offer that an association structurally cannot is the machinery: an identity and privacy substrate, a requirement engine that names why it is uncertain, and a records seam — all of which live in the same platform rather than beside it. That is the wedge worth arguing about, and it is the reason the sections above name modules instead of adjectives.

Where things stand

New, early, and honest about both

The peer community is a new segment for us. We are not going to dress it up as an established forum. The discussion boards, the adviser directory, and the practice library are being built or planned; today there is no board to post to and no directory to be listed in. What already exists is the identity and privacy substrate underneath, the same one that runs a K–12 platform, and the six modules named above. We reuse the built parts and write the new ones in the open.

There is one specific piece of backend infrastructure standing between this page and a community: a peer identity and moderation API — account creation for advisers and registrars, opt-in directory visibility, and discussion moderation. That API does not exist. We say so here rather than showing a sign-up form that would quietly do nothing, and we say it again in the FAQ so that nobody has to take our word for it from a single sentence.

One more thing worth stating in the same place: this page has no student account, no student-data form, and no field that would accept a minor’s information. It is a marketing surface. When there is a real community with real accounts, the identity substrate underneath it is the one that already carries scoped, auditable access for schools — not a forum login bolted on beside it.

Email a person Read the honest FAQ

Get in touch

What happens when you email us

If you advise students, own a registrar’s requirement rules, or would simply help pressure-test what is described above, email is the only door and it is a real one. Tell us your role and what you would want to trade with a peer at another institution. A person reads it and a person answers it.

What you are agreeing to is a conversation. There is no place being held for you, no queue position, no list, and nothing to pay — and if we said otherwise we would be describing a membership system that does not exist. The most useful thing you can send is the case that went badly: the transfer-credit decision with no clean mapping, the requirement exception that took four emails, the audit you had to defend by hand. Those are what the requirement model gets built against.

[email protected]

No newsletter sign-up, no lead form, no price, no checkout, and no student-data field on this page. Just a conversation when you want one.

Common questions

What people ask

Is there a community to join today?

No. There is no discussion board to post to, no directory to be listed in, and no membership. This page describes what is being built and what is planned, labelled that way card by card.

You say “built on a platform” — which parts actually exist?

Six named modules, listed in “What already exists underneath” with the post-secondary need each one maps to: the academic-eligibility engine, the counseling request ladder, the diploma and transcript issuer with its transcript routes, the public credential verifier, the records inference seam, and the adult-education domain object. They run for K–12 schools. Not one of them is pointed at a post-secondary institution today.

What would a degree audit actually inherit from you?

The evaluation shape, not the requirement data. The existing engine returns eligible, ineligible, or indeterminate, and it names which of four reasons made a verdict indeterminate rather than guessing — an unconfirmed governing rule defaults to deny. It pins the rule version, the grading period, the fact counts, and an as-of instant, so the verdict recomputes to a byte-identical stamp. A degree audit built on that shape would refuse to guess for the same reasons. The requirement model itself is new work.

How much of post-secondary could you cover by extending what you have?

On a dated internal gap-list of thirty-four post-secondary items, roughly nineteen extend something that exists, four share a shape but need a new data model, two are gaps in K–12 as well and are therefore not post-secondary debt, and roughly nine have no analog at all. That is a planning estimate from one document rather than a roadmap commitment, and the nine are the honest part of it.

Is the adviser directory public by default?

No, and it will not be when it exists. The directory is planned as opt-in: nobody is listed unless they choose to be. The nearest built precedent is the public credential verifier, which answers one question and discloses nothing else. We are not building a default-public directory of people’s names and institutions.

What backend does this need before a community can exist?

A peer identity and moderation API: adviser and registrar account creation, opt-in directory visibility, and discussion moderation. None of it exists. Until it does, the way in is a person reading your email, not a sign-up form that would quietly do nothing.

Are you claiming to replace the professional association advisers already belong to?

No. There is an established professional association for academic advising, with a membership, a conference programme, and decades of standing behind it. We have a render module and a plan. Claiming a win over that would be the easiest sentence to write on this page and the least true one, so it is not here.

What are the other highereducation domains?

Four domains cover the segment: highereducation.center (the portal), highereducation.courses (a catalog of coverage, building), highereducation.services (professional services for adopting institutions, planned), and this page, highereducation.network. Links are in the footer.

How do I get in touch, and what happens then?

Email [email protected] and tell us your role and what you would want to trade with a peer at another institution. A person reads it and answers. There is no form, no drip campaign, no queue position, and nothing to pay.