HIS-027: decision record and delivery evidence

All estimates, findings, and results below belong to the fictional narrative. They are not vendor quotes, actual test results, or evidence that the reviewed Arcore tools have these integrations.

ADR-001 revision 2: choose the application boundary

Decision: build a narrow Service Commitment Workspace, integrating with existing CRM, ERP, and field-service records. Keep dispatch in Field Service and reservations in ERP. Approve the build only after the dependency spike in story step 07 succeeds. Reconsider extending Field Service if the reservation/reconciliation interface cannot be supported or if the custom operating owner is unavailable.

Why: the missing capability is a durable, auditable commitment decision across systems, including partial success and recovery. A new inventory or scheduling engine would duplicate mature authority. A simple dashboard would show information without safely coordinating decisions. The local Field Service extension is a credible alternative but, under this fictional tenant's constraints, still requires an external worker for the difficult transaction semantics.

Hard constraints

Constraint	Required proof	Effect on selection
H1 Authorization and accountability	Employee sign-in, role separation, auditable restricted overrides	A candidate that cannot enforce this is ineligible
H2 Authoritative reservations	ERP-issued reservation ID, concurrency handling, reconciliation after timeout	Cached availability cannot satisfy the requirement
H3 Durable recovery	Demonstrate crash/replay/partial-success behavior without duplicate allocation	Workflow convenience does not compensate for a failure
H4 Supported operation	Named owner, supported interfaces, entitlement confirmation, incident and recovery path	No owner or unavailable interface means Hold
H5 Bounded pilot	One branch, controlled users, minimal retained customer data, reversible rollout	Excludes a company-wide ERP replacement

At step 06, H2–H4 are assumptions for several candidates. Scores are provisional, not permission to proceed. Step 07 resolves them for the selected candidate. Other candidates would require their own validation if selected.

Weighted preference matrix

Scores are fictional workshop judgments: 1 poor, 3 adequate, 5 strong. Weighted total = sum(weight × score) / 100, on a 1–5 scale. Cost scores cover three-year ownership cost, not initial development alone.

Criterion	Weight	Process only	Extend CRM	Extend Field Service	Low-code composition	Buy specialist tool	Narrow custom workspace
Cross-system workflow fit	25	2	3	4	4	4	5
Correctness and recovery	25	1	3	4	2	3	5
Delivery speed	15	5	3	4	5	3	2
Three-year cost	15	4	3	3	3	2	2
Support and ownership fit	10	3	3	4	3	3	3
Exit and interoperability	10	5	3	3	3	2	4
Weighted total	100	2.90	3.00	3.75	3.30	3.00	3.80

Interpretation: custom wins narrowly, by 0.05. This is not a decisive numerical result. If Field Service's cost score rises from 3 to 4 after an entitlement review, its score becomes 3.90 and it leads. If custom recovery falls from 5 to 4, custom falls to 3.55. The spike must establish whether the custom recovery advantage is real. The architect records the final rationale in prose and keeps the incumbent extension as the fallback.

Process-only outcome: standard checklists and a daily coordination call are retained as immediate containment, but they cannot reliably prevent simultaneous coordinators from acting on the same apparent availability. A process change is useful even though it is insufficient as the final control.

Buy outcome: a fictional vendor demonstration covers scheduling but does not demonstrate Harborline's ERP timeout reconciliation. The procurement team does not classify an unproven integration as impossible; it records insufficient evidence within the evaluation timebox. A verified lower-cost offer would reopen this decision.

Cost model and financial boundaries

All amounts are hypothetical USD planning estimates using an approved internal loaded labor rate of $100/hour. They are not market prices or vendor quotations. Already-incurred discovery work is not used to bias the remaining-investment decision.

Custom pilot component	Assumption	Estimate
Cross-functional delivery	2,400 hours × $100, including discovery, engineering, QA, product, architecture, platform/security effort, and training	$240,000
Pilot cloud, test environments, and incremental integration charges	Budget allowance, to be validated	$12,000
Delivery contingency	20% of $252,000 baseline	$50,400
Initial funding ceiling	Baseline plus contingency; release of contingency requires sponsor approval	$302,400
Annual recurring ownership	$60,000 labor + $18,000 hosting/integration + $12,000 security/recovery/upgrade allowance	$90,000
Three-year planning total	Conservative: initial ceiling + three full years recurring costs	$572,400

Three-year option ranges used for the workshop: process-only $180k–$420k in coordination effort and training; CRM extension $380k–$600k; Field Service extension $360k–$520k; low-code composition $300k–$560k; specialist purchase $420k–$720k; custom $460k–$650k. These scenario ranges include incremental delivery, access/integration allowances, and ongoing support; real quotations and staffing estimates would replace them. Existing enterprise platform costs are excluded consistently unless the option increases them. Common business losses are evaluated in benefits, not added selectively to an option's cost score.

The fictional six-week baseline contains 960 eligible complex requests and 115 failed commitments: 11.98%, reported as 12.0%. The target is no more than 6.0%. At 160 eligible requests per week and 50 operating weeks, avoiding six percentage points of failures means 480 fewer failures annually. At an illustrative $300 avoidable direct cost each, the annual benefit is $144,000.

A ten-minute reduction in average coordination time across 8,000 annual requests releases approximately 1,333 hours. At $60/hour coordinator loaded cost, the capacity value is approximately $80,000. It is not automatic cash savings and is excluded from the conservative cash-like payback calculation. Customer retention upside is also excluded because the evidence is insufficient.

At the target, direct avoided cost of $144,000 minus $90,000 recurring ownership yields $54,000 annually before recovering initial investment. The funding ceiling divided by $54,000 implies approximately 5.6 years simple payback. Three years of that net benefit is $162,000, below the initial ceiling. The case is therefore not approved on a claim of rapid financial payback. The sponsor funds a pilot for customer reliability and operating resilience, with an explicit option to stop. If failure reduction is only three percentage points, annual direct avoided cost is $72,000, below recurring ownership. No discounted cash-flow claim is made.

Fiscal contributes expense/billing context, Chronos effort actuals, and Ledger the commitment/funding view. Finance reconciles these to ERP records and approved internal rates. Invoice value is never treated as internal labor cost. Commitments that become actuals are counted once.

Requirements baseline: SPEC-027 revision 3

ID	Requirement and reason	Testable acceptance criterion	Owner / evidence case
R01	Show one coordinated view without duplicating record ownership	Display CRM account, ERP readiness, and work-order references with source timestamps; unavailable source is visibly unknown	Product / T01
R02	Confirm commitments against authoritative prerequisites	A commitment reaches CONFIRMED only with valid ERP reservation and field-service slot confirmation; competing updates produce one valid version	ERP + dispatch / T02
R03	Survive partial success and retry	After ERP commits but response is lost, replay/lookup produces one reservation and one local association; no blind duplicate request	Engineering / T03
R04	Preserve human exceptions with accountable authority	A coordinator cannot approve a restricted override; an authorized independent supervisor supplies reason and expiry; event history identifies both users	Operations + security / T04
R05	Make stale data explicit	Prerequisite observations older than five minutes cannot authorize a new confirmation; show source and last successful refresh	Product / T05
R06	Notify only after durable state change	Outbox entry is committed with the decision; notification failure leaves commitment state correct and retryable; no false confirmation from a queued message	Engineering / T06
R07	Meet the pilot performance budget	Under 50 concurrent active sessions for a 30-minute representative test, workspace read p95 <2 seconds and local decision submission p95 <3 seconds; external confirmation is asynchronous and visible	Service owner / T07
R08	Recover service and reconcile business state	Restore a backup in the isolated exercise within a two-hour RTO and demonstrated ≤15-minute RPO; reconcile potentially newer upstream reservations before enabling confirmations	SRE / T08
R09	Enforce branch and role access	Cross-branch record requests fail for branch-scoped users; revoked access cannot create a new session; active sessions follow the agreed 15-minute revalidation policy	Security / T09
R10	Preserve an auditable decision history	Each transition includes actor/service identity, time, prior/new version, reason, and correlation ID; ordinary users cannot update audit events	Security / T10
R11	Support the actual operator workflow	Keyboard-only users complete the critical flow; status is not conveyed by color alone; errors preserve entered reason text	Product / T11
R12	Detect stalled coordination	Alert if the oldest unresolved reservation is >10 minutes or reconcile worker heartbeat is absent >2 minutes; report source freshness separately from HTTP health	SRE / T12; added after incident

The five-minute freshness threshold is a pilot policy assumption. It is not a guarantee that inventory remains available for five minutes: the authoritative reservation transaction remains necessary. RTO/RPO are pilot recovery targets, not evidence that remote transactions can be rolled back with the local database.

Out of scope: route optimization, customer self-service, invoicing, forecasting with AI, HR scheduling, ERP replacement, enterprise-wide rollout, and automatic promises based on cached stock.

Data model and integration contract

Schema models Commitment, CommitmentVersion, PrerequisiteObservation, ReservationAttempt, ExceptionDecision, AuditEvent, and OutboxEvent. A commitment stores external IDs, branch, owner, state, and optimistic-lock version. Observations carry source, observed time, received time, and result. Reservation attempts carry stable idempotency/correlation keys, upstream ID when known, attempt status, and next reconciliation time.

The state machine is DRAFT → CHECKING → READY → CONFIRMING → CONFIRMED, with BLOCKED, UNKNOWN, EXPIRED, and CANCELLED as explicit alternatives. READY means prerequisites appear usable; it does not reserve stock. UNKNOWN means the remote outcome is uncertain. The UI cannot convert UNKNOWN to CONFIRMED through an ordinary retry. Cancellation of confirmed work requires a separately recorded cancellation process and upstream acknowledgement.

Interface	Record owner / operation	Reliability and authorization contract
CRM adapter	Read account/entitlement references	Scoped read identity, data minimization, timestamp; no account edits
ERP adapter	Request reservation, look up outcome, request release	Stable key; deduplicated lookup; version/concurrency response; release requires explicit upstream acknowledgement
Dispatch adapter	Read work order; submit proposed slot; retrieve confirmed status	Proposal is not confirmation; preserve dispatcher authority and external revision
Notification worker	Send Teams/email update from committed outbox	Retriable and deduplicated; failure does not undo valid business state
Reporting export	Publish approved outcome facts to warehouse	Revision/correction handling, stable denominator, no operational control path

The workflow is a recoverable sequence of local and remote transactions. There is no claim of a distributed atomic commit or global exactly-once execution. Idempotency and reconciliation make retries safe within the verified interface contract. If the ERP cannot supply an adequate lookup/deduplication mechanism, the architecture decision reopens.

Traceability and release acceptance

Illustrative labels such as BUILD-027-04 identify narrative evidence, not actual builds or commits. A real implementation must replace them with actual immutable identifiers and controlled evidence locations.

Business need	Requirement	Design decision	Delivery work	Test / acceptance	Release evidence
Fewer premature promises	R02	ERP/dispatch retain authority	HIS-027-21 reservation slice	T02 + coordinator scenario UAT-01	BUILD-027-04 candidate record
No duplicate reservations	R03	Stable key and UNKNOWN reconciliation	HIS-027-22 retry worker	T03 response-loss/crash replay	Same candidate; error injection evidence
Emergency handling	R04	Independent, scoped delegation	HIS-027-23 supervisor flow	T04 + UAT-02 after-hours coverage	SPEC-027 r2, then r3 compatibility review
Recover safely	R08	Restore then upstream reconciliation	HIS-027-24 recovery runbook	T08 timed restore and discrepancy review	Operations acceptance attached to candidate
Detect silent stalls	R12	Queue and freshness telemetry	HIS-027-31 incident follow-up	T12 stalled-worker regression	BUILD-027-05, new approval required

Release checklist for a real pilot:

• Approved specification revision and recorded requirements coverage; no unexplained missing test evidence.
• Reviewed source commit and artifact digest; build reports, security results, and UAT attach to that identity.
• No unresolved defect that permits unauthorized confirmation, duplicate allocation, misleading confirmation, or unrecoverable state.
• R07 performance, R08 recovery, and R09 authorization checks meet their acceptance criteria.
• Named on-call owner, functioning alerts, support procedures, and trained pilot operators.
• Feature flag defaults off outside the selected branch; no irreversible schema changes in the initial rollout.
• Rollback prevents new confirmations and reconciles in-flight work; already-confirmed external reservations are not silently discarded.
• Affected evidence and approvals are renewed after any change to the candidate, requirements, or material configuration.

Case outcome ledger

Observation	Fictional result	Interpretation
Six-week baseline	115 failures / 960 eligible requests = 11.98%	Baseline across all eight branches
Pilot branch, pre-period	15 / 120 = 12.5%	Four-week local baseline for the pilot branch
Pilot branch, four-week pilot	7 / 120 = 5.83%	Meets point target; small sample does not establish a durable effect
Comparison branch, pre-period	14 / 120 = 11.67%	Similar volume/mix chosen before pilot
Comparison branch, concurrent period	13 / 120 = 10.83%	Some improvement without application; seasonality/process effects remain possible
Average coordination time	26 → 17 minutes on pilot requests	Nine-minute reduction; the ten-minute target is not yet met
Pilot unknown-state incident	Three requests delayed; zero duplicate reservations; one counted among seven failed commitments	Safe failure still creates operational cost and customer impact
Initial spend	$246,000 labor + $11,000 environments/integration = $257,000	$5,000 above $252,000 baseline, within $302,400 ceiling; $45,400 ceiling headroom is not benefit

Pilot failure-rate improvement is 6.67 percentage points; comparison improvement is 0.83 points, giving a descriptive difference in changes of approximately 5.83 points. This is not a randomized trial or a statistically established causal estimate. Management authorizes planning for a second bounded cohort, with more observation and cost review, rather than declaring an enterprise-wide success.