Context before template
The artifact changes with the uncertainty. A workflow problem does not need the same document as a discovery problem.
Artifact library
The deliverable is not the document. It is the clarity the document creates.
Browse product requirements, functional specifications, wireframes and operating models. Artifact type comes first; the project provides the context.
Decisions over decoration
The useful part is the business rule, state boundary, open question or trade-off—not how polished the page looks.
Executable enough to test
Good product artifacts reduce interpretation while leaving room for engineering, design and operational judgement.
Library map Browse by artifact type
Start with the kind of product decision you need to inspect.
Evidence status remains visible on every item, but it is metadata—not the navigation system.
Requirements & specifications
Documents that turn product intent into buildable behaviour.
Original working requirements are presented through readable web views with confidential details removed.
Partner & Donor Cycle Management
High-Level Product Requirements Document
Partner registration, donor-cycle rules, overlapping programmes, extensions, student association, reporting and access.
Placement Operating System
Job Management Module — Functional Specification
Field definitions, configurable hiring stages, learning-based shortlisting, publishing states and implementation use cases.
Wireframes & interface evidence
Original product surfaces grouped by the work they supported.
Counts are supporting metadata. The titles describe the product area and the kind of decisions visible in the archive.
Placement Operating System
Placement Product Wireframe Library
Job management, student job discovery, applicant tracking, preferences, resumes, skills and placement operations.
Price & Market Intelligence
Price Intelligence Operations Evidence
Internal platform architecture, automated-matching visibility, anomaly investigation and quality-control operations.
03 Product logic & operating models
Use the workbench to inspect how rules, states, workflows, rollout and quality become explicit.
These are portfolio reconstructions and system explainers. They communicate decision logic; they are not substitutes for the original PRD, FSD or interface evidence above.
ProjectProject 05 · Partner & Donor Cycle Management
ArtifactRequirements decision model
Evidence statusPortfolio Reconstruction
Reconstructed from documented product requirements and product logic for portfolio presentation. This is not the confidential source document.
Requirements logic
Turn ambiguous operations into explicit product behaviour
Problem
A donor relationship can span multiple overlapping cycles while students progress on different timelines.
Core entities
Partner · Donor cycle · Student-cycle association · Extension · Outcome
Critical rule
The contractual end date and actual outcome completion date are separate concepts.
Product implication
Support overlapping active cycles and continue outcome tracking beyond the original funding period.
Open policy
Do not automate unresolved students into a next-cycle transfer until the organisational policy is settled.
ProjectProject 07 · Fall Detection System with GPS
ArtifactIncident lifecycle model
Evidence statusSystem Explainer
A simplified explanatory model created for this portfolio to communicate the underlying incident lifecycle. This is not product UI.
Workflow model
Design the end-to-end outcome, not only the interface step
Detect Verify Notify Acknowledge Locate Respond Escalate Resolve
Product implicationAn alert being sent does not prove that help is on the way. Responsibility and closure must be explicit states.
ProjectProject 04 · Multi-Campus Asset Management System
ArtifactState and responsibility model
Evidence statusPortfolio Reconstruction
Reconstructed from the product state model and operational rules for portfolio presentation. It is not a production application screen.
State & rule model
Separate dimensions that look similar in a spreadsheet
StatusActiveNeeds repairIn repairStorageOut of service
LocationCampusRemoteRepair centreIn transit
ResponsibilityStudentEmployeeIT / campusUnassigned
Product implicationA laptop can be Active, assigned to an employee and physically remote at the same time. Collapsing these dimensions destroys the operating model.
ProjectProject 05 · Partner & Donor Cycle Management
ArtifactRelease and rollout model
Evidence statusPortfolio Reconstruction
Reconstructed from the rollout sequence and operating approach for portfolio presentation. It is a summary model, not an original launch document.
Release system
Sequence organisational change as carefully as product scope
Jashpur pilot Information collection Bulk upload Slack operating rhythm Phase 1 campuses Phase 2 campuses Production monitoring
Product implicationData readiness, training and operating communication were treated as part of the launch—not as post-launch administration.
ProjectProject 02 · Price & Market Intelligence Platform
ArtifactQuality and evaluation model
Evidence statusPortfolio Reconstruction
Reconstructed from the product quality model and human-review workflow for portfolio presentation. This visual is not the client application UI.
Human-in-the-loop quality
Test the system where uncertainty is concentrated
Automate
High-confidence matches where multiple signals agree.
Review
Ambiguous, high-risk or low-confidence matches.
Re-check
Accepted matches when price, metadata, URLs or source conditions change.
Measure
Matching method, anomaly type, reviewer patterns, domain, country and time.
Learn
Quality-control outcomes feed product rules and future automation thresholds.
04 Artifact system
How the pieces fit together
An artifact set should move from intent to behaviour, interaction and operating proof.
Requirements
Problem, users, scope, policy, business rules and success boundaries.
PRD · requirement modelSpecification
Inputs, validations, states, outputs, actor logic and exception paths.
FSD · use case · state modelProduct surface
Information architecture, flows, wireframes and operational control surfaces.
Wireframe · interface evidenceDelivery & quality
Rollout sequencing, evaluation, review, monitoring and feedback loops.
Release model · QA modelHow evidence is labelled
You should never have to guess whether you are looking at real product evidence or a portfolio explanation.
A genuine working document, screenshot or output that can be shown publicly.
A recreated view grounded in the original product logic, used when source material cannot be shared.
A simplified diagram made specifically to explain how the product worked. It is not product UI.