Guardian SIS — Implementation Guide

What to enter

Two things this path also creates, which the other does not do consistently

The role templates. Onboarding seeds the tenant's roles with their permission matrix, so day-one access control is already correct. Verify it in step 15.

The tenant administrator. An account is created for the person who will configure the institution. If you provision instead, note that the tenant's domain is left empty — see step 17 for why that matters.

Run it in Bruno

Paste into a Bruno collection, or generate the whole one with scripts/_build_bruno_collection.py. Every request carries a status assertion, so a run can genuinely fail — without one, Bruno reports PASS on a 403.

meta {
  name: List Institutions (verify the code)
  type: http
  seq: 4
  tags: [
    1-create-the-tenant
  ]
}

get {
  url: {{baseUrl}}/api/v1/super-admin/institutions
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

assert {
  res.status: eq 200
}

docs {
  STEP 1 verification. Confirm the tenant exists with the code you chose.

  ⚠️ THIS ENDPOINT REQUIRES A PLATFORM SUPER-ADMIN. A tenant administrator gets 403, correctly — it is a platform operation, not a tenant one. Use a super-admin token for step 1 and a tenant-admin token from step 2 onward. Measured.
}

meta {
  name: Onboard Institution
  type: http
  seq: 3
  tags: [
    1-create-the-tenant
  ]
}

post {
  url: {{baseUrl}}/api/v1/super-admin/institutions/onboard
  body: json
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

body:json {
  {
    "name": "Guardian Demo University",
    "code": "GUARDIANDE3D70",
    "domain": "dev.guardiansis.com",
    "institution_type": "us_university",
    "admin_email": "admin@your-institution.edu"
  }
}

assert {
  res.status: eq 200
}

docs {
  STEP 1. The `code` you set here is what every SQL block in the guide filters on. The /provision path CANNOT set a code — it generates one — and a generated code makes every verification query match zero rows, silently.
}

Request bodies

{
  "name": "Guardian Demo University",
  "code": "GUARDIANDE3D70",
  "domain": "dev.guardiansis.com",
  "institution_type": "us_university",
  "admin_email": "admin@your-institution.edu"
}

Verify in the database

Each query states what a correct result looks like. Run them as a superuser, or with the tenant scope set — see the note before step 1 about why an unscoped query returns zero rows.

select institution_id, institution_code, institution_name, domain, is_trial
  from institutions
 where institution_code = 'GUARDIANDE3D70';

select count(*) as roles
  from roles
 where institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70');

Verify this step

• The console lists the institution with the code you chose.
• GET /api/v1/super-admin/institutions returns it.
• The tenant administrator can sign in.

If you skip it

What to enter

Set the main campus deliberately

The product asks which campus is the main one, and it is worth answering rather than accepting a default: documents and defaults resolve against it. Exactly one campus should carry the flag.

The demonstration tenant has a single campus, MAIN, and it is the main one. Institutions with several locations create each and flag one — overlapping or missing main-campus flags are a common misconfiguration.

Run it in Bruno

Paste into a Bruno collection, or generate the whole one with scripts/_build_bruno_collection.py. Every request carries a status assertion, so a run can genuinely fail — without one, Bruno reports PASS on a 403.

meta {
  name: Create Campus
  type: http
  seq: 5
  tags: [
    2-campuses
  ]
}

post {
  url: {{baseUrl}}/api/v1/admin/campuses
  body: json
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

body:json {
  {
    "campus_code": "MAIN",
    "campus_name": "Main Campus",
    "city": "Springfield",
    "is_main": true
  }
}

assert {
  res.status: eq 200
}

docs {
  STEP 2. Exactly one campus should carry is_main. Sections and terms reference a campus.
}

meta {
  name: List Campuses
  type: http
  seq: 6
  tags: [
    2-campuses
  ]
}

get {
  url: {{baseUrl}}/api/v1/admin/campuses
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

assert {
  res.status: eq 200
}

docs {
  STEP 2 verification. Check the main-campus flag on the returned rows.
}

Request bodies

{
  "campus_code": "MAIN",
  "campus_name": "Main Campus",
  "city": "Springfield",
  "is_main": true
}

Verify in the database

Each query states what a correct result looks like. Run them as a superuser, or with the tenant scope set — see the note before step 1 about why an unscoped query returns zero rows.

select campus_code, campus_name, is_main, city
  from campuses
 where institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70')
 order by campus_id;

Verify this step

• The campus appears in the Campuses table with an active badge.
• The institution card reflects the campus count.

If you skip it

What to enter

Two settings that are easy to skip and expensive to change later

The timezone. Term start, census and deadline dates are stored as dates but shown in the institution's timezone. Getting this wrong shifts every deadline by hours — enough to matter at a census date.

The date format. It governs every date the institution prints. An institution that expects day-first dates should set it before generating any transcript, because those documents are issued, not regenerated.

The institution code is read-only here by design: changing it would break the audit chain and every external reference, so the field exists to be seen, not edited.

Run it in Bruno

Paste into a Bruno collection, or generate the whole one with scripts/_build_bruno_collection.py. Every request carries a status assertion, so a run can genuinely fail — without one, Bruno reports PASS on a 403.

meta {
  name: Read Institution Settings
  type: http
  seq: 7
  tags: [
    3-institutional-settings
  ]
}

get {
  url: {{baseUrl}}/api/v1/admin/institution
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

assert {
  res.status: eq 200
}

docs {
  STEP 3. Shows what the product stores: timezone, date format, theme, identity.
}

meta {
  name: Update Institution Settings
  type: http
  seq: 8
  tags: [
    3-institutional-settings
  ]
}

patch {
  url: {{baseUrl}}/api/v1/admin/institution
  body: json
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

body:json {
  {
    "timezone": "America/New_York",
    "date_format": "YYYY-MM-DD",
    "theme_key": "slate"
  }
}

assert {
  res.status: eq 200
}

docs {
  STEP 3. Timezone governs how term deadlines render; date format governs every document the institution issues.
}

Request bodies

{
  "timezone": "America/New_York",
  "date_format": "YYYY-MM-DD",
  "theme_key": "slate"
}

GET /api/v1/admin/institution

Verify in the database

Each query states what a correct result looks like. Run them as a superuser, or with the tenant scope set — see the note before step 1 about why an unscoped query returns zero rows.

select institution_name, institution_code, timezone, date_format, theme_key
  from institutions
 where institution_code = 'GUARDIANDE3D70';

Verify this step

• Save the form and confirm the values persist after a reload.
• Confirm the institution name renders on a document preview.

If you skip it

What to enter

The rule the product enforces: a college is top-level

A college sits at the top of the hierarchy and cannot have a parent. A department belongs inside a college. Divisions sit inside departments.

This is enforced rather than advisory: the product refuses a college with a parent, and refuses a department without one. That is deliberate — the shape governs grade-approval routing and workload reporting, and a malformed tree produces approvals that go nowhere.

In the demonstration tenant the hierarchy resolves to 4 colleges and 9 departments, and every department resolves to a college. A useful check before you continue to step 9: every department should have a parent, and no college should.

Run it in Bruno

Paste into a Bruno collection, or generate the whole one with scripts/_build_bruno_collection.py. Every request carries a status assertion, so a run can genuinely fail — without one, Bruno reports PASS on a 403.

meta {
  name: Create Department (inside a college)
  type: http
  seq: 10
  tags: [
    4-departments
  ]
}

post {
  url: {{baseUrl}}/api/v1/admin/departments
  body: json
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

body:json {
  {
    "department_code": "FIN",
    "department_name": "Finance",
    "unit_type": "department",
    "parent_department_code": "COB"
  }
}

assert {
  res.status: eq 200
}

docs {
  STEP 4. The product REFUSES a college with a parent and a department without one — that rule is what keeps grade-approval routing coherent.
}

meta {
  name: Create Department (top-level college)
  type: http
  seq: 9
  tags: [
    4-departments
  ]
}

post {
  url: {{baseUrl}}/api/v1/admin/departments
  body: json
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

body:json {
  {
    "department_code": "COB",
    "department_name": "College of Business",
    "unit_type": "college"
  }
}

assert {
  res.status: eq 200
}

docs {
  STEP 4. A college sits at the top of the hierarchy and takes no parent.
}

Request bodies

{
  "department_code": "COB",
  "department_name": "College of Business",
  "unit_type": "college"
}

{
  "department_code": "FIN",
  "department_name": "Finance",
  "unit_type": "department",
  "parent_department_code": "COB"
}

Verify in the database

Each query states what a correct result looks like. Run them as a superuser, or with the tenant scope set — see the note before step 1 about why an unscoped query returns zero rows.

select d.department_code || ' (' || d.unit_type || ')' ||
       case when p.department_code is not null
            then ' under ' || p.department_code
            else ' [top level]' end as placement
  from departments d
  left join departments p on p.department_id = d.parent_department_id
 where d.institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70')
 order by d.department_id;

select count(*) as colleges_with_a_parent
  from departments d
 where d.institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70')
   and d.unit_type = 'college'
   and d.parent_department_id is not null;

Verify this step

• The department list shows the parent/child relationship.
• Attempt to create a college with a parent — the product should refuse it.

If you skip it

What to enter

Degrees versus programmes — the distinction that trips people up

A degree is the award: “Bachelor of Science”. A programme is the course of study that leads to it: “BSc Nursing”. Several programmes can lead to the same degree, and a programme can be revised over time without the degree changing.

Define the degrees first, because the programme form in step 9 selects from this list — and so does the transcript that is eventually issued in the student's name.

The demonstration tenant defines 6 degrees: AA, AAS, BA, BS, BBA and BSN, spanning associate and bachelor levels with their credit totals.

Run it in Bruno

Paste into a Bruno collection, or generate the whole one with scripts/_build_bruno_collection.py. Every request carries a status assertion, so a run can genuinely fail — without one, Bruno reports PASS on a 403.

meta {
  name: Create Degree
  type: http
  seq: 12
  tags: [
    5-degrees
  ]
}

post {
  url: {{baseUrl}}/api/v1/config/academics/degrees
  body: json
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

body:json {
  {
    "degree_code": "BSN",
    "degree_name": "Bachelor of Science in Nursing",
    "degree_level": "bachelor",
    "duration_years": 4,
    "total_credits_required": 120
  }
}

assert {
  res.status: eq 200
}

docs {
  STEP 5. A degree is what the institution may CONFER; a programme (step 9) is what a student is ENROLLED on. Define degrees first.
}

meta {
  name: List Degrees
  type: http
  seq: 13
  tags: [
    5-degrees
  ]
}

get {
  url: {{baseUrl}}/api/v1/config/academics/degrees
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

assert {
  res.status: eq 200
}

docs {
  STEP 5 verification. The demonstration tenant defines 6: AA, AAS, BA, BS, BBA, BSN.
}

Request bodies

{
  "degree_code": "BSN",
  "degree_name": "Bachelor of Science in Nursing",
  "degree_level": "bachelor",
  "duration_years": 4,
  "total_credits_required": 120
}

Verify in the database

Each query states what a correct result looks like. Run them as a superuser, or with the tenant scope set — see the note before step 1 about why an unscoped query returns zero rows.

select degree_code, degree_name, degree_level, total_credits_required
  from degrees
 where institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70')
 order by degree_id;

Verify this step

• The degree list shows each award with its level and credit total.

If you skip it

What to enter

The product ships eight scales, and one of them must be the default

A new tenant is provisioned with a working vocabulary of scales rather than an empty list — which matters, because a section cannot accept a grade until a scale resolves for it:

Run it in Bruno

Paste into a Bruno collection, or generate the whole one with scripts/_build_bruno_collection.py. Every request carries a status assertion, so a run can genuinely fail — without one, Bruno reports PASS on a 403.

meta {
  name: List Grade Scales
  type: http
  seq: 14
  tags: [
    6-grade-scales
  ]
}

get {
  url: {{baseUrl}}/api/v1/config/academics/grade-scales
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

assert {
  res.status: eq 200
}

docs {
  STEP 6. Eight scales are seeded with the tenant; exactly one must be the default. The default is what a section falls back to, so a wrong default makes GPA quietly incorrect.
}

Request bodies

{
  "scale_code": "STD_LETTER",
  "scale_name": "Standard Letter 4.0 (+/-)",
  "scale_type": "letter",
  "is_default": true
}

{
  "grade_label": "A-",
  "numeric_min": 90,
  "numeric_max": 92,
  "grade_points": 3.7,
  "is_passing": true,
  "sort_order": 3
}

Verify in the database

Each query states what a correct result looks like. Run them as a superuser, or with the tenant scope set — see the note before step 1 about why an unscoped query returns zero rows.

select scale_code, scale_name, scale_type, is_default
  from grade_scales
 where institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70')
 order by is_default desc, scale_id;

select e.grade_label, e.grade_points, e.is_passing
  from grade_scale_entries e
  join grade_scales s on s.scale_id = e.scale_id
 where s.institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70')
   and s.is_default
 order by e.sort_order;

Verify this step

• The scale list marks exactly one default.
• The default scale's entries cover the full letter range, including F.

If you skip it

What to enter

Define the terms ahead of the one you need

An institution that cannot see next year's terms before this year ends cannot plan registration. Create the current term active and at least the next one planned — the product supports terms existing before they begin, and step 17 opens registration against one of them.

The four dates that bind

These are not decoration; each one changes what the product permits:

The demonstration tenant carries four terms — 2026FA active, with 2026SU, 2027SP and 2027FA planned — and the deadlines above.

Run it in Bruno

Paste into a Bruno collection, or generate the whole one with scripts/_build_bruno_collection.py. Every request carries a status assertion, so a run can genuinely fail — without one, Bruno reports PASS on a 403.

meta {
  name: Create Term (current)
  type: http
  seq: 15
  tags: [
    7-terms
  ]
}

post {
  url: {{baseUrl}}/api/v1/config/academics/terms
  body: json
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

body:json {
  {
    "term_code": "2026FA",
    "term_name": "Fall 2026",
    "start_date": "2026-08-24",
    "end_date": "2026-12-12",
    "census_date": "2026-09-08",
    "drop_deadline": "2026-10-30",
    "withdrawal_deadline": "2026-11-14",
    "grade_deadline": "2026-12-19",
    "status": "active"
  }
}

assert {
  res.status: eq 200
}

docs {
  STEP 7. TWO term endpoints exist in this product (/config/academics/terms and /terms). Use ONE of them consistently — using both produces duplicate terms, and any report grouped by term then double-counts.
}

meta {
  name: List Terms (check for duplicates)
  type: http
  seq: 16
  tags: [
    7-terms
  ]
}

get {
  url: {{baseUrl}}/api/v1/terms
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

assert {
  res.status: eq 200
}

docs {
  STEP 7 verification. Exactly one term should be active. A duplicated term_code here is the failure the warning above describes.
}

Request bodies

{
  "term_code": "2026FA",
  "term_name": "Fall 2026",
  "start_date": "2026-08-24",
  "end_date": "2026-12-12",
  "census_date": "2026-09-08",
  "drop_deadline": "2026-10-30",
  "withdrawal_deadline": "2026-11-14",
  "grade_deadline": "2026-12-19",
  "status": "active"
}

{
  "term_code": "2027SP",
  "term_name": "Spring 2027",
  "start_date": "2027-01-11",
  "end_date": "2027-05-07",
  "status": "planned"
}

Verify in the database

Each query states what a correct result looks like. Run them as a superuser, or with the tenant scope set — see the note before step 1 about why an unscoped query returns zero rows.

select term_code, term_name, status, start_date, census_date,
       drop_deadline, withdrawal_deadline, grade_deadline
  from terms
 where institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70')
 order by start_date;

select term_code, count(*) as occurrences
  from terms
 where institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70')
 group by term_code
 having count(*) > 1;

select count(*) as terms_missing_a_binding_date
  from terms
 where institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70')
   and (census_date is null or drop_deadline is null
        or withdrawal_deadline is null or grade_deadline is null);

Verify this step

• The term list shows the current term as active and later terms as planned.
• Open a term and confirm all four binding dates are set, not blank.

If you skip it

What to enter

The rank is not decoration — it carries a workload default

Each rank stores a default standard load and a default contract length. The product uses them when a staff member is appointed (step 16), which is what lets workload reporting work on day one rather than after a term of data entry.

The demonstration tenant defines all 10 ranks. Shifts and honours are optional at this stage and can be added when a section needs one.

Run it in Bruno

Paste into a Bruno collection, or generate the whole one with scripts/_build_bruno_collection.py. Every request carries a status assertion, so a run can genuinely fail — without one, Bruno reports PASS on a 403.

meta {
  name: Create Rank
  type: http
  seq: 17
  tags: [
    8-ranks-and-shifts
  ]
}

post {
  url: {{baseUrl}}/api/v1/config/academics/ranks
  body: json
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

body:json {
  {
    "rank_code": "ASSOCIATE_PROFESSOR",
    "rank_name": "Associate Professor",
    "rank_abbr": "Assoc Prof",
    "default_standard_load": 12,
    "default_contract_length": 9
  }
}

assert {
  res.status: eq 200
}

docs {
  STEP 8. A rank carries a default teaching load, which is what makes workload reporting meaningful before anyone has entered a load by hand.
}

meta {
  name: List Ranks
  type: http
  seq: 18
  tags: [
    8-ranks-and-shifts
  ]
}

get {
  url: {{baseUrl}}/api/v1/config/academics/ranks
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

assert {
  res.status: eq 200
}

docs {
  STEP 8 verification. 10 ranks are seeded — a full academic ladder.
}

Request bodies

{
  "rank_code": "ASSOCIATE_PROFESSOR",
  "rank_name": "Associate Professor",
  "rank_abbr": "Assoc Prof",
  "default_standard_load": 12,
  "default_contract_length": 9
}

Verify in the database

Each query states what a correct result looks like. Run them as a superuser, or with the tenant scope set — see the note before step 1 about why an unscoped query returns zero rows.

select rank_code, rank_name, default_standard_load, default_contract_length
  from ranks
 where institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70')
 order by sort_order;

Verify this step

• The rank list shows the full academic ladder with each rank's default load.
• A new staff appointment can name a rank (step 16).

If you skip it

What to enter

Three programmes, because the shape matters more than the count

The demonstration tenant carries a business, a nursing and a liberal-arts programme — deliberately different in structure, so anything built against one is tested against the others.

Run it in Bruno

Paste into a Bruno collection, or generate the whole one with scripts/_build_bruno_collection.py. Every request carries a status assertion, so a run can genuinely fail — without one, Bruno reports PASS on a 403.

meta {
  name: Create Programme
  type: http
  seq: 19
  tags: [
    9-programmes
  ]
}

post {
  url: {{baseUrl}}/api/v1/programs
  body: json
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

body:json {
  {
    "program_code": "BBA-20",
    "program_name": "Bachelor of Business Administration",
    "degree_code": "BBA",
    "department_code": "COB",
    "total_credits_required": 120
  }
}

assert {
  res.status: eq 200
}

docs {
  STEP 9. The programme is the course of study. It has VERSIONS (step 11), and a student is pinned to the version current at admission — which is how requirements change without rewriting the rules under students already studying.
}

meta {
  name: List Programmes
  type: http
  seq: 20
  tags: [
    9-programmes
  ]
}

get {
  url: {{baseUrl}}/api/v1/programs
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

assert {
  res.status: eq 200
}

docs {
  STEP 9 verification. Capture a program_id from the response — step 11 needs it.
}

Request bodies

{
  "program_code": "BBA-20",
  "program_name": "Bachelor of Business Administration",
  "degree_code": "BBA",
  "department_code": "COB",
  "total_credits_required": 120
}

Verify in the database

Each query states what a correct result looks like. Run them as a superuser, or with the tenant scope set — see the note before step 1 about why an unscoped query returns zero rows.

select program_code, program_name, total_credits_required
  from programs
 where institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70')
 order by program_id;

Verify this step

• The programme list shows each programme with its degree and credit total.
• Opening a programme offers a Versions tab (populated in step 11).

If you skip it

What to enter

24 courses across the three programmes

The demonstration tenant defines a realistic catalogue: business core (ACC, BUS, FIN, MKT, MGT), nursing (NUR), computing (CSC), and general education (ENG, GEN, HIS, PSY).

Run it in Bruno

Paste into a Bruno collection, or generate the whole one with scripts/_build_bruno_collection.py. Every request carries a status assertion, so a run can genuinely fail — without one, Bruno reports PASS on a 403.

meta {
  name: Create Course
  type: http
  seq: 21
  tags: [
    10-courses
  ]
}

post {
  url: {{baseUrl}}/api/v1/courses
  body: json
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

body:json {
  {
    "course_code": "ACC201",
    "course_name": "Financial Accounting",
    "credits": 3,
    "department_code": "FIN",
    "is_active": true
  }
}

assert {
  res.status: eq 200
}

docs {
  STEP 10. A course is the DEFINITION; a section (step 12) is one offering of it in one term. Keeping those apart is what lets a catalogue be reused across terms.
}

meta {
  name: List Courses
  type: http
  seq: 22
  tags: [
    10-courses
  ]
}

get {
  url: {{baseUrl}}/api/v1/courses
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

assert {
  res.status: eq 200
}

docs {
  STEP 10 verification. 24 courses are seeded across roughly ten subject prefixes.
}

Request bodies

{
  "course_code": "ACC201",
  "course_name": "Financial Accounting",
  "credits": 3,
  "department_code": "FIN",
  "is_active": true
}

Verify in the database

Each query states what a correct result looks like. Run them as a superuser, or with the tenant scope set — see the note before step 1 about why an unscoped query returns zero rows.

select split_part(course_code, '1', 1) as subject_prefix, count(*) as courses
  from courses
 where institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70')
 group by 1
 order by 1;

select count(*) as courses_without_a_department
  from courses
 where institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70')
   and department_id is null;

Verify this step

• The course list shows the catalogue with credits and owning departments.
• An export produces a file that matches the import format.

If you skip it

What to enter

The lifecycle that protects students already studying

A programme version moves draft → published → archived. Publishing is the moment a version can be pinned by students, and the typing is deliberate: a published version with students enrolled on it resists being returned to draft, because that would change their requirements mid-degree.

Publish, then verify

A draft catalogue year is invisible to students and to the public catalogue. If registration refuses everyone in step 17, check here first — an unpublished catalogue year is the most common cause.

Run it in Bruno

Paste into a Bruno collection, or generate the whole one with scripts/_build_bruno_collection.py. Every request carries a status assertion, so a run can genuinely fail — without one, Bruno reports PASS on a 403.

meta {
  name: Create Catalogue Year
  type: http
  seq: 23
  tags: [
    11-curriculum
  ]
}

post {
  url: {{baseUrl}}/api/v1/catalog-years
  body: json
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

body:json {
  {
    "year_code": "TR20-2026",
    "year_name": "2026-2027 Catalog",
    "start_date": "2026-07-01",
    "end_date": "2027-06-30",
    "status": "draft"
  }
}

assert {
  res.status: eq 200
}

docs {
  STEP 11. Create as DRAFT, add requirements, then publish. A draft catalogue year is invisible to students and to the public catalogue.
}

meta {
  name: List Catalogue Years
  type: http
  seq: 25
  tags: [
    11-curriculum
  ]
}

get {
  url: {{baseUrl}}/api/v1/catalog-years
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

assert {
  res.status: eq 200
}

docs {
  STEP 11 verification. Status must read 'published', not 'draft'.
}

Request bodies

{
  "year_code": "TR20-2026",
  "year_name": "2026-2027 Catalog",
  "start_date": "2026-07-01",
  "end_date": "2027-06-30",
  "status": "draft"
}

returns the year with status = published

Verify in the database

Each query states what a correct result looks like. Run them as a superuser, or with the tenant scope set — see the note before step 1 about why an unscoped query returns zero rows.

select year_code, status
  from catalog_years
 where institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70');

select p.program_code, count(v.program_version_id) as versions
  from programs p
  left join program_versions v on v.program_id = p.program_id
 where p.institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70')
 group by p.program_code
 order by p.program_code;

Verify this step

• The catalogue year reads published, not draft.
• Every programme reports at least one version.
• Opening a programme version lists its requirement categories.

If you skip it

What to enter

Capacity is enforced, so set it deliberately

current_enrollment is derived from the enrolments, and registration refuses a student beyond max_enrollment. A section left at 0 capacity silently blocks everyone; a capacity far above any real room overstates the timetable. The demonstration tenant shows both ends: one section at 6 of 6 — full, and therefore waitlisted in step 17 — and others at 0 of 35.

Run it in Bruno

Paste into a Bruno collection, or generate the whole one with scripts/_build_bruno_collection.py. Every request carries a status assertion, so a run can genuinely fail — without one, Bruno reports PASS on a 403.

meta {
  name: Create Section
  type: http
  seq: 26
  tags: [
    12-sections
  ]
}

post {
  url: {{baseUrl}}/api/v1/sections
  body: json
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

body:json {
  {
    "course_code": "ACC201",
    "term_code": "2026FA",
    "campus_code": "MAIN",
    "section_number": "01",
    "instructor_email": "alice.grant@your-institution.edu",
    "max_enrollment": 35,
    "room": "B-204"
  }
}

assert {
  res.status: eq 200
}

docs {
  STEP 12. Do NOT leave the instructor blank. A section with no instructor does not error — it fails later, at grade time, because the roster has no owner and the approval chain has nowhere to start.
}

meta {
  name: List Sections
  type: http
  seq: 27
  tags: [
    12-sections
  ]
}

get {
  url: {{baseUrl}}/api/v1/sections
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

assert {
  res.status: eq 200
}

docs {
  STEP 12 verification. Check each section has an instructor and a sane capacity.

  ⚠️ NOTE THE PATH: the UI reaches sections at /admin/sections, but the API path is /api/v1/sections. UI route and API path are NOT the same thing in this product, and /admin/sections returns 404 to an API client. Measured.
}

Request bodies

{
  "course_code": "ACC201",
  "term_code": "2026FA",
  "campus_code": "MAIN",
  "section_number": "01",
  "instructor_email": "alice.grant@your-institution.edu",
  "max_enrollment": 35,
  "room": "B-204"
}

Verify in the database

Each query states what a correct result looks like. Run them as a superuser, or with the tenant scope set — see the note before step 1 about why an unscoped query returns zero rows.

select s.section_id, c.course_code, s.section_number
  from sections s
  join courses c on c.course_id = s.course_id
 where s.institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70')
   and s.instructor_id is null
 order by s.section_id;

select c.course_code, s.section_number, s.current_enrollment, s.max_enrollment
  from sections s
  join courses c on c.course_id = s.course_id
 where s.institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70')
 order by c.course_code;

select s.section_id, s.current_enrollment,
       (select count(*) from course_enrollments e
         where e.section_id = s.section_id and e.enrollment_status = 'ENROLLED') as actual
  from sections s
 where s.institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70')
   and s.current_enrollment <> (select count(*) from course_enrollments e
         where e.section_id = s.section_id and e.enrollment_status = 'ENROLLED');

Verify this step

• Every section has an instructor assigned (the query above returns 0 rows).
• current_enrollment agrees with the enrolments for every section.
• Opening a section shows its roster.

If you skip it

What to enter

The flag that decides whether a student's tax statement is correct

Each fee structure carries 1098-T eligibility. Tuition is eligible; a technology fee is not. That single flag is what the 1098-T export sums into Box 1 — and it is set here, on the fee, not at filing time.

Verified on the demonstration tenant: tuition is flagged eligible and the technology fee is not, and the generated export reflects exactly that, per student.

Run it in Bruno

Paste into a Bruno collection, or generate the whole one with scripts/_build_bruno_collection.py. Every request carries a status assertion, so a run can genuinely fail — without one, Bruno reports PASS on a 403.

meta {
  name: Create Fee Structure
  type: http
  seq: 28
  tags: [
    13-fees-and-plans
  ]
}

post {
  url: {{baseUrl}}/api/v1/billing/fee-structures
  body: json
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

body:json {
  {
    "name": "Tuition per credit",
    "fee_type": "tuition",
    "amount": 450.00,
    "billing_frequency": "term",
    "is_1098_t_eligible": true,
    "is_active": true
  }
}

assert {
  res.status: eq 200
}

docs {
  STEP 13. The is_1098_t_eligible flag is set HERE, on the fee — not at filing time. It is what the 1098-T export sums into Box 1.
}

meta {
  name: Create Payment Plan
  type: http
  seq: 29
  tags: [
    13-fees-and-plans
  ]
}

post {
  url: {{baseUrl}}/api/v1/billing/payment-plans
  body: json
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

body:json {
  {
    "student_id": 210,
    "invoice_id": 34,
    "installment_count": 3,
    "frequency": "monthly",
    "start_date": "2026-10-01"
  }
}

assert {
  res.status: eq 200
}

docs {
  STEP 13. A plan splits an existing invoice balance. The invoice must exist first, with its balance derived from the payment ledger — the balance is denormalised and must be recomputed, never incremented.
}

Request bodies

{
  "name": "Tuition per credit",
  "fee_type": "tuition",
  "amount": 450.00,
  "billing_frequency": "term",
  "is_1098_t_eligible": true,
  "is_active": true
}

{
  "student_id": 210,
  "invoice_id": 34,
  "installment_count": 3,
  "frequency": "monthly",
  "start_date": "2026-10-01"
}

Verify in the database

Each query states what a correct result looks like. Run them as a superuser, or with the tenant scope set — see the note before step 1 about why an unscoped query returns zero rows.

select name, fee_type, amount, is_1098_t_eligible
  from fee_structures
 where institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70')
 order by fee_id;

select p.plan_id, p.total_amount,
       (select coalesce(sum(i.amount), 0) from payment_plan_installments i where i.plan_id = p.plan_id) as instalments_sum
  from payment_plans p
 where p.invoice_id in (select invoice_id from invoices
                       where institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70'));

Verify this step

• Fee structures exist with 1098-T eligibility set deliberately on each.
• A payment plan's instalments sum exactly to its plan total.
• Generating an invoice from a fee structure produces correct line items.

If you skip it

What to enter

Why these belong in the foundation, not a later tidy-up

Neither is glamorous, and both are easy to skip when the first invoice happens to work without them. The cost appears later:

• An invoice line with no tax code cannot be reported by tax treatment, and retro-fitting one across a term of invoices is a data change, not a setting.
• A payment with no bank account cannot be reconciled to a statement, which turns an accounting task into a manual exercise.

Financial configuration is jurisdiction-specific and deliberately left to the implementer. The structure is the same everywhere; the values are not.

Run it in Bruno

Paste into a Bruno collection, or generate the whole one with scripts/_build_bruno_collection.py. Every request carries a status assertion, so a run can genuinely fail — without one, Bruno reports PASS on a 403.

meta {
  name: Create Bank Account
  type: http
  seq: 31
  tags: [
    14-tax-and-bank
  ]
}

post {
  url: {{baseUrl}}/api/v1/config/finance/bank-accounts
  body: json
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

body:json {
  {
    "account_name": "Operating Account",
    "account_number_last4": "4471",
    "is_active": true
  }
}

assert {
  res.status: eq 200
}

docs {
  STEP 14. A payment with no bank account cannot be reconciled to a statement.
}

meta {
  name: Create Tax Code
  type: http
  seq: 30
  tags: [
    14-tax-and-bank
  ]
}

post {
  url: {{baseUrl}}/api/v1/config/finance/tax-codes
  body: json
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

body:json {
  {
    "code": "EXEMPT",
    "name": "Tuition — tax exempt",
    "rate": 0.0,
    "is_active": true
  }
}

assert {
  res.status: eq 200
}

docs {
  STEP 14. An invoice line with no tax code cannot be reported by tax treatment, and retro-fitting one across a term of invoices is a data change rather than a setting.
}

Request bodies

{
  "code": "EXEMPT",
  "name": "Tuition — tax exempt",
  "rate": 0.0,
  "is_active": true
}

{
  "account_name": "Operating Account",
  "account_number_last4": "4471",
  "is_active": true
}

Verify in the database

Each query states what a correct result looks like. Run them as a superuser, or with the tenant scope set — see the note before step 1 about why an unscoped query returns zero rows.

select 'tax_codes' as reference, count(*) as rows
  from tax_codes
 where institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70')
 union all
select 'bank_accounts', count(*)
  from bank_accounts
 where institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70');

Verify this step

• Both reference tables return a non-zero count.
• Creating an invoice line accepts a tax code, and recording a payment accepts a bank account.

If you skip it

What to enter

The seeded set is a starting point, not a blank sheet

Onboarding creates the tenant's roles with their permission matrix already resolved, so day-one access control is correct rather than deliberately empty. Your job here is to verify the grants match your institution's intent and add custom roles where they do not.

Two structural facts worth knowing before you edit anything

The matrix is per-entity. A grant is a row of (entity, permission, can_view/can_add/can_edit/can_delete, scope) — it says "this role may edit this entity", not "this role has this capability everywhere". Role Designer changes take effect immediately, so test with a real login after each change.

Some screens gate on a role string, not on a permission. Where that is true, a permission grant alone will not open the screen. The most visible case is financial aid: the aid screens check for an aid-staff role or financial:view_all, and a platform administrator is refused by design.

Run it in Bruno

Paste into a Bruno collection, or generate the whole one with scripts/_build_bruno_collection.py. Every request carries a status assertion, so a run can genuinely fail — without one, Bruno reports PASS on a 403.

meta {
  name: List Roles
  type: http
  seq: 32
  tags: [
    15-roles
  ]
}

get {
  url: {{baseUrl}}/api/v1/admin/roles
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

assert {
  res.status: eq 200
}

docs {
  STEP 15. Read the grants carefully. They run from 17 down to ZERO, and IR Officer holds none — a role that can log in and reach nothing, which presents as a broken account rather than a permissions decision.
}

Request bodies

{
  "name": "Enrollment Coordinator",
  "description": "Registration and enrollment operations"
}

{
  "grants": [
    { "entity_name": "students", "permission": "student:view_all",
      "can_view": true, "scope": "INSTITUTION" }
  ]
}

Verify in the database

Each query states what a correct result looks like. Run them as a superuser, or with the tenant scope set — see the note before step 1 about why an unscoped query returns zero rows.

select r.name as role, count(rp.permission_id) as grants,
       coalesce(string_agg(distinct rp.permission, ', ' order by rp.permission), '(none)') as permissions
  from roles r
  left join role_permissions rp on rp.role_id = r.role_id
 where r.institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70')
 group by r.name
 order by count(rp.permission_id) desc, r.name;

select r.name, rp.permission, rp.scope
  from role_permissions rp
  join roles r on r.role_id = rp.role_id
 where r.institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70')
   and r.name in ('Faculty', 'Dept Chair', 'Advisor')
 order by r.name, rp.permission;

Verify this step

• The role list shows all 14 roles with their grants.
• A user assigned to a role can sign in and reach that role's surfaces.
• A role with 0 grants is identified before anyone is appointed to it.

If you skip it

What to enter

The head appointment is separate from the role

A department head is an appointment recorded as a flag on the user, not a role in itself. Any non-student role may hold it — a registrar or a bursar can be a head. Students are refused explicitly, because the flag grants approval authority.

The demonstration tenant holds 16 staff accounts spanning all 14 roles, which is what makes it possible to demonstrate every role's own view of the product — including the student's.

Run it in Bruno

Paste into a Bruno collection, or generate the whole one with scripts/_build_bruno_collection.py. Every request carries a status assertion, so a run can genuinely fail — without one, Bruno reports PASS on a 403.

meta {
  name: Create Staff User
  type: http
  seq: 33
  tags: [
    16-staff
  ]
}

post {
  url: {{baseUrl}}/api/v1/admin/users
  body: json
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

body:json {
  {
    "email": "alice.grant@your-institution.edu",
    "password": "<meets your policy>",
    "first_name": "Alice",
    "last_name": "Grant",
    "role": "faculty",
    "department_code": "FIN",
    "rank_code": "ASSOCIATE_PROFESSOR",
    "can_be_department_head": false
  }
}

assert {
  res.status: eq 200
}

docs {
  STEP 16. The email domain must be VALID: letters, digits and hyphens in each label. The browser's own <input type=email> validation rejects an underscore in a domain label, and an earlier platform version generated exactly that — which made a new customer unable to add ANY staff member.
}

meta {
  name: List Users
  type: http
  seq: 34
  tags: [
    16-staff
  ]
}

get {
  url: {{baseUrl}}/api/v1/admin/users
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

assert {
  res.status: eq 200
}

docs {
  STEP 16 verification. Every role that must operate the institution needs a holder.
}

Request bodies

{
  "email": "alice.grant@your-institution.edu",
  "password": "<a password meeting your policy>",
  "first_name": "Alice",
  "last_name": "Grant",
  "role": "faculty",
  "department_code": "FIN",
  "rank_code": "ASSOCIATE_PROFESSOR",
  "can_be_department_head": false
}

Verify in the database

Each query states what a correct result looks like. Run them as a superuser, or with the tenant scope set — see the note before step 1 about why an unscoped query returns zero rows.

select r.name as role, count(u.user_id) as users
  from roles r
  left join users u on u.role = case r.name
      when 'System Admin' then 'system_admin' when 'Registrar' then 'registrar'
      when 'Faculty' then 'faculty' when 'Student' then 'student'
      when 'Bursar' then 'bursar' when 'Financial Aid' then 'financial_aid'
      when 'Advisor' then 'advisor' when 'Dept Chair' then 'dept_chair'
      when 'Auditor' then 'auditor' when 'IR Officer' then 'ir'
      when 'Admissions Officer' then 'admissions'
      when 'Title IX Coordinator' then 'title_ix'
      when 'Veterans SCO' then 'veterans_sco'
      when 'Disability Services' then 'disability' end
   and u.institution_id = r.institution_id and u.deleted_at is null
 where r.institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70')
 group by r.name order by count(u.user_id), r.name;

select email
  from users
 where institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70')
   and deleted_at is null
   and email !~ '^[A-Za-z0-9._%+-]+@[A-Za-z0-9-]+(\.[A-Za-z0-9-]+)+$';

Verify this step

• Every role that must operate the institution has at least one holder.
• Staff addresses all pass the validity check (the query returns zero rows).
• A staff member can sign in and sees only their own role's surfaces.

If you skip it

What to enter

Holds block registration, and they are working when they block

A registration hold is placed against a student — a financial hold, an advising hold — and while active it prevents enrolment. It is an auditable object with a reason, a placer and a date, not a free-text note.

In the demonstration tenant one active financial hold exists, deliberately: it makes it possible to show what a blocked student sees, which is more informative than a clean run. A hold that is not cleared will silently keep blocking after the reason is resolved, so clear holds rather than removing them.

Capacity and waitlists follow from step 12

A section at capacity produces a waitlist rather than an overflow. The waitlist is ordered and the product supports promotion and auto-enrolment — POST /api/v1/registration/waitlist/promote/{section_id}. The demonstration tenant has one full section with students waiting, so the waitlist alerts on the registration screen are populated rather than empty.

Run it in Bruno

Paste into a Bruno collection, or generate the whole one with scripts/_build_bruno_collection.py. Every request carries a status assertion, so a run can genuinely fail — without one, Bruno reports PASS on a 403.

meta {
  name: Create Registration Window
  type: http
  seq: 35
  tags: [
    17-registration-windows
  ]
}

post {
  url: {{baseUrl}}/api/v1/registration/periods
  body: json
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

body:json {
  {
    "term_id": 65,
    "name": "Fall 2026 Open Registration",
    "start_date": "2026-09-10T00:00:00Z",
    "end_date": "2026-10-24T23:59:59Z",
    "is_active": true
  }
}

assert {
  res.status: eq 200
}

docs {
  STEP 17 — the step most likely to go wrong. A closed window refuses EVERYONE and does not look like a bug. Three failure modes present identically: no window, dates that do not cover today, or inactive. Check them in that order.
}

meta {
  name: List Holds
  type: http
  seq: 37
  tags: [
    17-registration-windows
  ]
}

get {
  url: {{baseUrl}}/api/v1/registration/holds
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

assert {
  res.status: eq 200
}

docs {
  STEP 17 verification. Know every active hold before demonstrating registration, or a blocked student looks like a bug.
}

Request bodies

{
  "term_id": 65,
  "name": "Fall 2026 Open Registration",
  "start_date": "2026-09-10T00:00:00Z",
  "end_date": "2026-10-24T23:59:59Z",
  "is_active": true
}

{
  "student_id": 210,
  "hold_type": "financial",
  "reason": "Unpaid balance on Fall 2026 invoice"
}

Verify in the database

Each query states what a correct result looks like. Run them as a superuser, or with the tenant scope set — see the note before step 1 about why an unscoped query returns zero rows.

select name, start_date, end_date, is_active,
       (now() between start_date and end_date) as covers_today
  from registration_periods
 where institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70');

select count(*) as sections_without_an_instructor
  from sections
 where institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70')
   and instructor_id is null;

select s.student_id, s.first_name, s.last_name, h.hold_type, h.reason, h.placed_date
  from registration_holds h
  join students s on s.student_id = h.student_id
 where h.institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70')
   and h.is_active
 order by s.student_id;

Verify this step

• A registration window exists, is active, and covers today.
• A student can be registered into a section inside the window.
• Active holds are known and explainable before demonstrating registration.

If you skip it

What to enter

What is actually enforced, and what is configuration

Two different things live under FERPA in this product, and it is worth separating them:

The first column is the part worth demonstrating. A platform administrator attempting to open a student's grades is refused by the API, not by a convention — which is exactly what a compliance reviewer asks for. It is also why the aid screens refuse a super-admin: the denial is the feature.

Run it in Bruno

Paste into a Bruno collection, or generate the whole one with scripts/_build_bruno_collection.py. Every request carries a status assertion, so a run can genuinely fail — without one, Bruno reports PASS on a 403.

meta {
  name: Read FERPA Config
  type: http
  seq: 38
  tags: [
    18-ferpa
  ]
}

get {
  url: {{baseUrl}}/api/v1/config/ferpa-config
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

assert {
  res.status: eq 200
}

docs {
  STEP 18. Zero rows is a valid answer — it means no policy is recorded yet, which is the state to fix, not an error to investigate.
}

meta {
  name: Update FERPA Config
  type: http
  seq: 39
  tags: [
    18-ferpa
  ]
}

put {
  url: {{baseUrl}}/api/v1/config/ferpa-config
  body: json
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

body:json {
  {
    "ferpa_contact_email": "registrar@your-institution.edu",
    "directory_info_items": ["name", "enrollment_status", "dates_of_attendance", "degrees_awarded"],
    "opt_out_default": false,
    "consent_lifetime_days": 365
  }
}

assert {
  res.status: eq 200
}

docs {
  STEP 18. What counts as directory information is an INSTITUTION decision, often constrained by state law. The product enforces whatever you configure — including a choice you did not mean to make.
}

Request bodies

{
  "ferpa_contact_email": "registrar@your-institution.edu",
  "directory_info_items": ["name", "enrollment_status", "dates_of_attendance", "degrees_awarded"],
  "opt_out_default": false,
  "consent_lifetime_days": 365
}

Verify in the database

Each query states what a correct result looks like. Run them as a superuser, or with the tenant scope set — see the note before step 1 about why an unscoped query returns zero rows.

select ferpa_contact_email, opt_out_default, consent_lifetime_days,
       array_length(directory_info_items, 1) as directory_items
  from ferpa_config
 where institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70');

select u.email, u.role
  from users u
 where u.institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70')
   and u.role in ('system_admin', 'admin')
   and u.deleted_at is null;

Verify this step

• A FERPA configuration row exists with a contact and directory-information items.
• A system administrator is refused a student's education record — the enforced half, testable in one attempt.

If you skip it

What to enter

The product's own funnel is the worked example

The applicant pipeline ships as a nine-state funnel, and it is a good template for the shape:

inquiry → applied → in_review → decision_pending → admitted / waitlisted / rejected → enrolled, with withdrawn as an exit.

Why a defined list matters: the product refuses a transition that is not in the workflow. That is what prevents an applicant jumping from inquiry to enrolled without a decision — and it is why a missing state, rather than a wrong one, is the usual defect. If a record cannot reach a state your institution uses, the state is missing from the lifecycle, not broken.

Status workflows and processes are not seeded by default in the demonstration tenant — the applicant funnel is built into the admissions module rather than configured as a workflow. Configure lifecycles here for any record type your institution moves through custom states.

Run it in Bruno

Paste into a Bruno collection, or generate the whole one with scripts/_build_bruno_collection.py. Every request carries a status assertion, so a run can genuinely fail — without one, Bruno reports PASS on a 403.

meta {
  name: Create Status Workflow
  type: http
  seq: 40
  tags: [
    19-lifecycles
  ]
}

post {
  url: {{baseUrl}}/api/v1/config/status-workflows
  body: json
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

body:json {
  {
    "name": "Applicant pipeline",
    "nodes": [
      { "state": "inquiry", "is_initial": true },
      { "state": "applied" },
      { "state": "in_review" },
      { "state": "admitted" },
      { "state": "enrolled", "is_terminal": true }
    ],
    "edges": [
      { "from": "inquiry", "to": "applied" },
      { "from": "applied", "to": "in_review" },
      { "from": "in_review", "to": "admitted" },
      { "from": "admitted", "to": "enrolled" }
    ]
  }
}

assert {
  res.status: eq 200
}

docs {
  STEP 19. The product REFUSES a transition not on the list — so a MISSING state, not a wrong one, is the usual defect. If a record cannot reach a state your institution uses, the state is missing from the lifecycle.
}

Request bodies

{
  "name": "Applicant pipeline",
  "nodes": [
    { "state": "inquiry", "is_initial": true },
    { "state": "applied" },
    { "state": "in_review" },
    { "state": "admitted" },
    { "state": "enrolled", "is_terminal": true }
  ],
  "edges": [
    { "from": "inquiry", "to": "applied" },
    { "from": "applied", "to": "in_review" },
    { "from": "in_review", "to": "admitted" },
    { "from": "admitted", "to": "enrolled" }
  ]
}

Verify in the database

Each query states what a correct result looks like. Run them as a superuser, or with the tenant scope set — see the note before step 1 about why an unscoped query returns zero rows.

select count(*) as workflows
  from status_workflows
 where institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70');

Verify this step

• Any workflow your institution uses is configured, and a refused transition names the missing state rather than failing opaquely.

If you skip it

What to enter

Two tables, two purposes — do not confuse them

Write the student-facing message before the term, not during it

The temptation is to defer templates until something needs sending — which is always a moment when nobody has time to write carefully. A decision letter that reaches an applicant with an unrendered merge field or the wrong institution name is a reputational cost with no upside.

Run it in Bruno

Paste into a Bruno collection, or generate the whole one with scripts/_build_bruno_collection.py. Every request carries a status assertion, so a run can genuinely fail — without one, Bruno reports PASS on a 403.

meta {
  name: Create Notification Template
  type: http
  seq: 41
  tags: [
    20-templates
  ]
}

post {
  url: {{baseUrl}}/api/v1/communication/templates
  body: json
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

body:json {
  {
    "name": "Application received",
    "channel": "email",
    "subject": "We received your application to {{institution_name}}",
    "body": "Dear {{first_name}},\n\nThank you for applying to {{institution_name}}. Your reference is {{application_uid}}.\n\nRegards,\n{{institution_name}} Admissions"
  }
}

assert {
  res.status: eq 200
}

docs {
  STEP 20. Send every template to a REAL address before relying on it — merge fields either resolve or they do not, and the difference is invisible until the message is in someone's inbox.
}

meta {
  name: List Transcript Templates
  type: http
  seq: 42
  tags: [
    20-templates
  ]
}

get {
  url: {{baseUrl}}/api/v1/config/transcript-templates
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

assert {
  res.status: eq 200
}

docs {
  STEP 20. These are the DOCUMENTS (transcripts, letters), seeded 2 per tenant — distinct from notification_templates, which are the MESSAGES.
}

Request bodies

{
  "name": "Application received",
  "channel": "email",
  "subject": "We received your application to {{institution_name}}",
  "body": "Dear {{first_name}},\n\nThank you for applying to {{institution_name}}. Your application reference is {{application_uid}}.\n\nRegards,\n{{institution_name}} Admissions"
}

Verify in the database

Each query states what a correct result looks like. Run them as a superuser, or with the tenant scope set — see the note before step 1 about why an unscoped query returns zero rows.

select name, is_default
  from transcript_templates
 where institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70')
 order by is_default desc;

select count(*) as notification_templates
  from notification_templates
 where institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70');

Verify this step

• At least one transcript template exists and exactly one is the default.
• A template sent to a real address renders its merge fields correctly.

If you skip it

What to enter

Ask the product, not the implementer

The final pass is deliberately not a checklist of what you did — it is a set of questions put to the running product. That is the difference between "I configured it" and "it works".

The six checks, in the order that fails fastest

Run it in Bruno

Paste into a Bruno collection, or generate the whole one with scripts/_build_bruno_collection.py. Every request carries a status assertion, so a run can genuinely fail — without one, Bruno reports PASS on a 403.

meta {
  name: Curriculum Health
  type: http
  seq: 45
  tags: [
    21-verify
  ]
}

get {
  url: {{baseUrl}}/api/v1/analytics/curriculum-health
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

assert {
  res.status: eq 200
}

docs {
  STEP 21, check 3. Orphaned requirements and programmes without versions.
}

meta {
  name: Data Integrity
  type: http
  seq: 44
  tags: [
    21-verify
  ]
}

get {
  url: {{baseUrl}}/api/v1/analytics/data-integrity
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

assert {
  res.status: eq 200
}

docs {
  STEP 21, check 2. Structural drift detected by the product rather than by a checklist.
}

Request bodies

"status": "healthy", "version": "...", "db": "ok", "seed_status": { "...": {"status": "ok"} }

returns a list of detected inconsistencies

returns orphaned requirements and programmes without versions

returns plans whose instalments do not reconcile

Verify in the database

Each query states what a correct result looks like. Run them as a superuser, or with the tenant scope set — see the note before step 1 about why an unscoped query returns zero rows.

with inst as (select institution_id from institutions where institution_code = 'GUARDIANDE3D70')
select 'roles' as entity, count(*) from roles where institution_id = (select institution_id from inst)
union all select 'staff users', count(*) from users where institution_id = (select institution_id from inst) and deleted_at is null
union all select 'campuses', count(*) from campuses where institution_id = (select institution_id from inst)
union all select 'departments', count(*) from departments where institution_id = (select institution_id from inst)
union all select 'degrees', count(*) from degrees where institution_id = (select institution_id from inst)
union all select 'programmes', count(*) from programs where institution_id = (select institution_id from inst)
union all select 'courses', count(*) from courses where institution_id = (select institution_id from inst)
union all select 'catalogue years', count(*) from catalog_years where institution_id = (select institution_id from inst)
union all select 'terms', count(*) from terms where institution_id = (select institution_id from inst)
union all select 'sections', count(*) from sections where institution_id = (select institution_id from inst)
union all select 'fee structures', count(*) from fee_structures where institution_id = (select institution_id from inst)
union all select 'open registration windows', count(*) from registration_periods where institution_id = (select institution_id from inst) and is_active
order by 1;

select count(*) as sections_without_an_instructor
  from sections
 where institution_id = (select institution_id from institutions where institution_code = 'GUARDIANDE3D70')
   and instructor_id is null;

Verify this step

• GET /api/v1/health reports healthy with every seeder ok.
• The configuration census returns no unexpected zero.
• No section is left without an instructor.
• A person who did not configure the tenant can use it.

If you skip it