A model of your institution, and everything built on it
黑料不打烊 builds an ontology of your institution, then deploys applications, agents, and workflows on top of it.
- 1Connect your systemsSIS, CRM, aid, ERP, HR, LMS, advancement, and the documents around them
- 2Model your core business objects and relationshipsStudents, courses, aid awards, invoices, and gifts, related the way the institution works
- 3Encode the business logicRich expressions and ML models on the objects that matter
- 4Define allowable transactions as governed actionsEvery change runs through an action, inside each person鈥檚 permissions
- 5Keep the informal knowledge as memoryPolicies, advisor notes, emails, and past decisions, tied to the objects they explain
- 6Deploy on topApplications, agents, and workflows for every domain
Connect your systems
Every system, document, and outside source, in one place
Model your core business objects and relationships
One model of the institution, across every domain
Each object belongs to a domain and links to the others. Logic and actions sit on the objects.
A slice of the full model: the labeled objects are the ones this work runs on most.
Applicant
A person applying for admission, from first inquiry to census.
- stage
- enum
- entry_term
- term
- likely_to_enroll
- Chance this applicant enrolls by census. From program.
- applies toProgramone
- becomesStudentone
Program
A degree program, its requirements, and its seats.
- degree
- enum
- seats
- integer
- receivesApplicantmany
- is pursued byStudentmany
Degree plan
The student's term-by-term path to the degree.
- target_term
- term
- catalog_year
- integer
- 茠on_track
terms_to_finish 鈮� terms_until(target_term)
- is followed byStudentone
- calls forCoursemany
Course
A catalog course, its prerequisites, and the sections it runs as.
- credits
- decimal
- level
- integer
- next_term_demand
- Seats needed next term, from degree plans, admits, and waitlists. From degree plan, applicant, and section.
- is planned inDegree planmany
- offered asSectionmany
- is owned byDepartmentone
Department
An academic or administrative unit with a budget and an owner.
- cost_center
- string
- budget
- money
- budget_variance
- Where the department will land against its budget at year-end. From instructor and revenue stream.
- ownsCoursemany
- employsInstructormany
- is funded byRevenue streammany
Office
A student-facing office, its staff, and the work it handles.
- division
- enum
- staffed_fte
- decimal
- 茠capacity_gap
forecast workload 鈭� staffed hours
- handlesService casemany
Student
One student, shared by every domain: enrolled, billed, advised, supported, and served.
- class_level
- enum
- credits_earned
- decimal
- persistence_risk
- Chance the student does not return next term. From section, account, hold, service case, and degree plan.
- 茠unmet_need
cost_of_attendance 鈭� student_aid_index 鈭� accepted aid
- wasApplicantone
- pursuesProgramone
- followsDegree planone
- takesSectionmany
- opensService casemany
- carriesHoldmany
- is billed throughAccountone
Section
One offering of a course in a term, with its capacity and its roster.
- capacity
- integer
- enrolled
- integer
- 茠fill_rate
enrolled 梅 capacity
- offersCourseone
- enrollsStudentmany
- is taught byInstructorone
Instructor
A faculty member with a teaching load.
- rank
- enum
- load_target
- decimal
- 茠assigned_load
sum(sections.credits)
- teachesSectionmany
- works inDepartmentone
Revenue stream
Tuition, fees, grants, gifts, and endowment payout, forecast by month.
- forecast
- money
- budget
- money
- revenue_forecast
- Revenue through year-end, with net tuition built from applicants, students, and aid. From applicant, student, aid award, and account.
- fundsDepartmentmany
- collected intoCash positionone
- is discounted byAid awardmany
Service case
A request a student makes of any office.
- topic
- enum
- status
- enum
- root_cause
- Names the form, policy, or office behind the request. From office.
- is opened byStudentone
- handled byOfficeone
Hold
A block on registration placed because of an unpaid balance.
- kind
- enum
- blocks_registration
- boolean
- placed onStudentone
- is triggered byAccountone
Account
The student's account with the bursar.
- balance
- money
- due_on
- date
- 茠balance_due
charges 鈭� payments 鈭� disbursed aid
- triggersHoldmany
- billsStudentone
- is paid byAid awardmany
Aid award
Aid offered to a student for a term from one fund.
- amount
- money
- status
- enum
- retention_lift
- Change in the chance the student returns if this award grows by $1,000. From account.
- discountsRevenue streamone
- pays intoAccountone
- is paid fromFundone
Cash position
Cash across every bank and investment account, with what is coming in and going out.
- balance
- money
- as_of
- date
- 茠days_cash_on_hand
unrestricted cash 梅 daily operating expense
- collectsRevenue streammany
Donor
An alum, parent, friend, or foundation that gives.
- affiliation
- enum
- capacity_band
- enum
- likely_to_give
- Chance of a gift in the next 12 months. From fund.
- gives toFundmany
Fund
An endowed or current-use fund and the restrictions on it.
- market_value
- money
- payout_rate
- percent
- 茠eligible_now
count(students its restrictions match and unmet_need > 0)
- paysAid awardmany
- is given byDonormany
Encode the business logic
Expressions and models that read across domains
Defined once on the objects, so every application and agent uses the same definitions and the same forecasts.
It reads from three domains at once. Advisors and agents see the same score and the reasons behind it.
It walks from a fund to its restrictions to the students they match, and uses unmet need, itself an expression from Student Finance.
Define allowable transactions as governed actions
Allowable transactions, defined once and enforced everywhere
Actions define who can change what, when approval is needed and where the change is written back. Permissions apply to every object and property.
- On
- Student 路 Hold
- Who can run it
- Bursar, student services agent
- Approval
- Second approver over $500
- Writes back to
- Student accounts
- Logged
- Who, when, why, and the evidence
| Advisor | Bursar | Registrar | Agent | |
|---|---|---|---|---|
| term_gpa | Yes | No | Yes | inherits |
| balance | No | Yes | No | inherits |
| advising_notes | Yes | No | No | inherits |
| holds | Yes | Yes | Yes | inherits |
An agent inherits the permissions of the person it works for, and never sees more.
Keep the informal knowledge as memory
The informal knowledge stays with your model
Policies, notes, emails, and past decisions are tied to the objects they explain. Agents cite them when they answer. Memory adds context. It does not override the model.
Registration hold policy
Which balances block registration, and the exceptions the bursar allows.
Counselor thread
What the family asked about, and what the counselor promised to follow up on.
Appeal precedent
A past appeal and the reason it was approved, so similar cases are handled the same way.
Deploy on top
Frontier agents, an apps platform, and workflows, all on the model
Everything that runs reads the same objects and changes them only through governed actions.
Agents that do the work, inside the rules
Agents built on frontier models read the model, reason with your policies, and act only through governed actions, with the permissions of the person they work for.
- Read any object in the model
- Act through governed actions
- Cite the policy behind every answer
- Read the student, the hold, the account, and next term鈥檚 aid
- Checked
茠 balance_dueand鈼� hold_risk - Followed the hold policy and the payment plan terms
Standard terms are allowed for this agent. The bursar approves anything else.
An application for every team, built from the model
Each domain ships with an application. New ones are assembled from the same objects, logic, and actions, with permissions built in.
- Queues and object views
- Forecasts with their reasons
- Actions with approvals
Workflows that combine agents, rules, and people
Triggers fire on changes in the model. Agents take the routine steps, rules route the rest, and people approve what matters.
- Triggers on the model
- Agent and human steps
- Every step writes back through a governed action
Continuous improvement
Results feed back into the model
- 1SeeEvery system and document in one model of the institution
- 2ActRoutine work runs automatically, and decisions stay with your staff
- 3MeasureResults tracked against goals, holdouts, and prior years
- 4ImproveForecasts and plans updated as results come in
Talk to us
Start with one domain, then expand on the same model
We scope the first domain with your team and agree on the outcomes to measure.
