Prototype

Reframing Student Administration as a Lifecycle Problem

Using discovery and prototyping to move from disconnected local views to a cross-organizational workflow model

Solution Discovery and Architecture · 2026 ·July 2026–present ·Workflow discovery and operational data · 4 min read

Discovery interviews overturned the original registrar-centered framing and exposed a broader lifecycle problem spanning arrivals, eligibility, holds, ownership, handoffs, and exceptions. The result is a revised prototype built around actionable work populations rather than disconnected dashboards.

Overview

This is a discovery and prototyping case, not a deployed-product claim. The work began as an attempt to improve visibility across student administration. Interviews with registrar and holding-organization stakeholders showed that no single organization or tracker represents the full lifecycle: all new arrivals enter through one in-processing function, but later hold states and blockers may remain distributed elsewhere. I used that evidence to revise the system boundary and prototype a workflow that connects attention states, work populations, ownership, and lifecycle transitions.

Initial Ask

Improve visibility and coordination across a fragmented student-administration process.

Problem

Users were trying to understand a lifecycle from separate local processes and records. The initial framing overemphasized registrar problems, while later interviews showed that arrivals, eligibility, holds, blockers, ownership, and handoffs cross organizational boundaries. A single dashboard owned by one office would reproduce that misunderstanding rather than solve it.

Desired Outcome

Give each user group a view of the work it actually owns while preserving enough lifecycle context to understand where a person is, what is blocking progress, and who owns the next action.

Constraints

  • The authoritative personnel and training systems remain systems of record; the prototype is a workflow and visibility layer, not a replacement.
  • Real student identities, records, medical/profile details, security-eligibility details, internal identifiers, and organizational weaknesses cannot be published.
  • The complete routing for every hold category and the authoritative owner of every lifecycle update are still being discovered.
  • The prototype is evidence of discovery and design work, not a deployed operational system.

Approach

I interviewed users, reconstructed the lifecycle from their local perspectives, compared those perspectives for contradictions, and used the contradictions to refine the problem model. I then iterated prototype views around attention states, arrivals, holds, ownership, and work populations so users could move from seeing an exception to working it directly. The discovery process deliberately treats exceptions and unclear ownership as first-class design inputs rather than edge cases.

Key Decisions

Treat the problem as a lifecycle rather than a registrar-owned workflow

Reasoning:

Interviews showed that registrar decisions are important but do not explain or own every blocker. All arrivals initially pass through a holding/in-processing function, while later hold populations can exist elsewhere. The system therefore needs to represent transitions and ownership across organizations.

Design around actionable work populations instead of disconnected dashboards

Reasoning:

An attention indicator is useful only if it leads users to the population they can actually work. The prototype therefore connects exceptions to the relevant roster/work view rather than creating separate summary screens with no resolution path.

Keep the authoritative-system boundary explicit

Reasoning:

The prototype can improve visibility, ownership, and coordination without pretending to replace the underlying systems of record or writing back before the workflow model is validated.

Solution

A discovery-stage lifecycle workbench prototype that connects arrivals, eligibility states, hold/blocker states, ownership, work populations, and transitions while leaving authoritative source systems in place.

Personal Contribution

I conducted stakeholder interviews, reconstructed lifecycle and exception flows, challenged the initial problem framing, identified ownership and system boundaries, developed workflow and ontology concepts, and iterated prototype views as new evidence changed the model.

Technical Implementation

The current work is primarily discovery, workflow modeling, data/ontology design, and prototype iteration. Foundry/Vantage is a candidate implementation environment, but this case intentionally does not claim a deployed Foundry solution. Public visuals should use entirely synthetic identities, statuses, organizations, and data.

Tech Stack

  • Workflow modeling
  • Ontology / data modeling
  • Interactive prototyping
  • Palantir Foundry / Vantage (candidate implementation platform)

Result & Impact

The strongest result so far is a corrected problem model. Interviews with holding-organization leadership showed that the holding function is a major part of the lifecycle but not the destination for every later hold, while registrar stakeholders clarified that important eligibility decisions do not make the registrar the owner of every exception. Those findings changed the prototype from a registrar-centered view into a cross-organizational lifecycle and exception-management concept.

Learnings

  • A coherent dashboard can still encode the wrong problem if discovery stops at the first stakeholder group.
  • Exceptions, handoffs, and unclear ownership often reveal the real system boundary more clearly than the happy path.
  • The useful unit of design is often the work population a user can act on, not the organizational chart or the database that happens to contain a status.
  • A prototype is most valuable when it is allowed to change the hypothesis rather than merely demonstrate the original idea.

Next Steps

  • Continue stakeholder interviews to complete the hold-category and ownership model.
  • Validate the revised attention and work-population views with users.
  • Confirm authoritative data sources and update ownership for each lifecycle state before implementation.
  • Create a synthetic public lifecycle diagram that demonstrates the design without exposing real personnel or internal process details.
All projects