From a business problem to a working application

This case study follows Harborline Industrial Services, a fictional company maintaining industrial equipment for commercial customers. A late delivery exposes a gap between sales promises, inventory, field scheduling, and customer communication. The company must decide whether to change its process, configure an existing system, buy an extension, or build software.

Everything about Harborline—people, contracts, software editions, integration permissions, prices, workloads, approvals, test results, and business outcomes—is an illustrative assumption. Named commercial platforms are a plausible fictional installed estate, not a verified assessment of their current features, licensing, or prices. Arcore adoption is also hypothetical; the portfolio guide's implementation limitations still apply. No application was built, tested, deployed, or integrated as part of writing this story.

Read the documents in this order:

1. Company and technology inventory: operating context, systems of record, integration assumptions, and extension candidates.
2. Decision and execution framework: a reusable process with owners, evidence, gates, return paths, and the case's checklist status.
3. The story, step by step: sixteen stages, each showing decisions, analysis, deliverables, and gate outcomes.
4. Decision record and delivery evidence: option scoring, cost assumptions, requirements, traceability, interfaces, and release criteria.
5. UAT evidence to user training: Scriptor capture, BrowserForge verification, ArcoreUAT acceptance, and Showcase documentation, demos, and training gates (framework revision 1.5).

The completed checkboxes in the framework mean the stage is developed in this fictional narrative, not that real engineering work or enterprise approval occurred. Unchecked items identify work beyond the initial pilot. The framework's revision log records lessons discovered while developing the story, so the final checklist incorporates those lessons without pretending they were all known at intake.

The result is a proposed Service Commitment Workspace: a small custom application for coordinating cross-system service commitments while CRM, ERP, and field-service systems retain authority over their own records. The choice is reached through the documented decision process rather than assumed at the start.

The initial story is complete through a bounded production pilot and a post-release learning cycle. Enterprise rollout remains a separate decision. Real implementation would begin by replacing the fictional evidence with verified company evidence.