The product question.

Placement coordination involves people, host organisations, supervisors, milestones and hours. A useful board needs to answer simple operational questions quickly: who is blocked, what is due and which record needs attention.

The original academic concept was rebuilt as a deliberately bounded static application. Public data is fictional, changes stay in the browser and every demo state can be reset.

What the public edition promises.

The reconstruction keeps its boundary small and inspectable:

  1. Every person and organisation in the shipped dataset is fictional.
  2. Search and status filters operate on one explicit placement model.
  3. Milestone updates persist only in browser local storage and can be reset.
  4. No account, database, analytics endpoint or remote write API exists.

Model the operation before the dashboard.

A dashboard becomes brittle when totals, labels and row state each derive status differently. The first task was to make placement state and hour calculations one tested model.

The interface then became a projection of that model: cohort metrics, filters and individual progress use the same functions, while local persistence stores only the fictional working state.

A complete static product boundary.

A checked-in fictional dataset feeds the placement model. Search, filters, cohort summaries and milestone transitions read the same derived state. The browser persists changes locally; reset restores the original fixture.

A complete static product boundary. One browser-local model drives the summary and the individual placement view.SYSTEM VIEW / VECTORFICTIONAL DATAPLACEMENT MODELSEARCH +FILTERSMILESTONESLOCAL STORAGEVERSIONED DELIVERY PATH
One browser-local model drives the summary and the individual placement view.

Decisions that keep the demo trustworthy.

The public app does less, but every visible interaction is real.

D01

Ship fictional records

The complete cohort is designed for demonstration, so the application does not need redacted production exports.

The demo cannot claim to represent a real institution’s process or data volume.

D02

Derive metrics from the model

Status and hour calculations are shared by cards, filters and individual records and covered by Node.js tests.

New workflow states must update the model contract before they appear in the interface.

D03

Keep persistence local

Milestone changes survive a refresh through local storage and a reset returns the original fixture.

There is no collaboration, authentication or cross-device sync in this edition.

Static-site verification.

The local server reproduces the exact GitHub Pages base path so absolute-link regressions fail before deployment. Node.js tests cover the data model and Playwright exercises the browser experience.

Stable releases package deterministic ZIP and TAR archives with an inventory, CycloneDX SBOM, source-commit evidence and SHA-256 checksums.

What the board supports.

An operator can search by student, host or supervisor, filter the cohort by status, inspect progress, advance a milestone and return to the same local state after a refresh.

VECTOR is a focused demonstrator, not a hosted placement service. Its value is a coherent, working interaction model with an unusually clear data boundary.

Evidence ledger.

The public edition ships a deliberately small, testable fixture:

Fixture
Six fictional placements across four status states; two active and two in review.
Derived view
The checked fixture reports 67% aggregate completion from 160/180-hour targets.
Verification
30 Node.js and five browser E2E declarations, including 390 px mobile and exact 320 px overflow checks.
Boundary
All persistence belongs to one browser. The project is not a live multi-user placement system.
Open the working project