Assessment sample

Make the integration accountable.

An example of technical findings, options, and acceptance criteria for a leadership decision.

Download the assessment (PDF)Read the assessment

Prepared from our published, anonymized implementation runbook. Historical findings are identified as documented. The options, delivery sequence, and acceptance gates are a new demonstration of assessment method, not a claim that the original client commissioned or approved this assessment.

01 / Executive decision

Approve delivery against verified business transactions, with explicit ownership of exceptions and recovery.

A request can reach its destination and still fail to represent the right business activity. The decision must account for correctness, repeat processing, uncertain outcomes, and the operating team’s ability to recover.

Option 01

Replicate the legacy mapping

Minimizes the immediate design change.

Trade-off. Can carry forward assumptions that no longer match the actual procedure or business rule.

Insufficient where the documented contract and rule mismatches remain unresolved.

Option 02

Verify and separate the transaction paths

Makes each operation, validation rule, and operating responsibility explicit.

Trade-off. Requires representative business cases and evidence for each process.

Recommended assessment approach. It directly addresses the documented failure modes.

Option 03

Replace the surrounding platforms

May address broader constraints if they are independently established.

Trade-off. Expands scope, dependencies, and the change burden on operations.

Not justified by this excerpt alone. Requires a separate business case.

02 / Evidence to decision

Findings and proposed acceptance criteria

The following findings and corrections are documented in the published runbook. The implications and acceptance criteria are our assessment of that evidence.

E01

Daily posting required an additional pricing parameter in the database procedure signature.

Documented correction: Parameter mapping was corrected to include the pricing override.
Assessment implication: The interface contract must be verified against the operating implementation, not inferred from a familiar field list.
Proposed acceptance evidence: A representative posting produces the expected business result with the complete parameter set.

E02

A class of activity was restricted by the enterprise system’s posting rules.

Documented correction: The posting category was aligned with the permitted business process.
Assessment implication: A valid value and a valid business action are different acceptance questions.
Proposed acceptance evidence: Allowed and disallowed business cases produce their agreed outcomes without unintended postings.

E03

Identifiers arrived in both string and numeric representations.

Documented correction: Type handling was corrected in input validation and parameter preparation.
Assessment implication: Normalize and validate at the boundary before transaction processing.
Proposed acceptance evidence: Equivalent valid representations resolve consistently; invalid input is rejected before processing.

03 / Operating architecture

System responsibilities and interfaces

System of record

Enterprise system

Work orders, allocations, resources, rates, employee records, and operational postings.

Orchestration & control

Integration layer

A central router dispatches requests to purpose-built handlers for validation, transformation, and business processing.

Operational execution

Field-service platform

Work information moves to the field. Status, user, and daily-activity updates return to the enterprise system.

The source architecture places the enterprise database and integration runtime internally, with external access through an authenticated application proxy. The view here omits network topology and deployment configuration.

04 / Proposed delivery sequence

Proposed phases and completion criteria

This sequence demonstrates how we would structure acceptance for a comparable assessment. It is not a reconstruction of the original project schedule.

01
Establish the operating contract
Inventory operations, dependencies, transaction inputs, permitted actions, and the expected business result.
Owner: Technical lead + business process owner
Exit evidence: A reviewed contract and representative case set for every in-scope operation.
02
Prove the critical paths
Exercise mappings and rules against representative cases. Verify the resulting business records independently of the transport response.
Owner: Integration lead + enterprise system owner
Exit evidence: Correctness evidence, visible exceptions, and no unresolved ambiguity in the critical cases.
03
Prove controlled recovery
Test repeated requests, interrupted processing, and uncertain outcomes. Define when to reconcile and when reprocessing is safe.
Owner: Technical lead + operations owner
Exit evidence: A rehearsed recovery procedure with decision authority and an agreed stop condition.
04
Release and transfer ownership
Review the evidence, accept residual risks, release the agreed scope, and transfer the runbook and escalation responsibilities.
Owner: Business owner + delivery lead
Exit evidence: Recorded acceptance, assigned operational ownership, and a dated residual-issue review.

05 / Acceptance & ownership

Acceptance responsibilities

On smaller screens, scroll the table sideways to see all columns. With the table focused, use the arrow keys.

Case	Proposed proof	Accountable reviewer
Valid business transaction	Expected downstream record and values; agreement with the source intent.	Business process owner
Invalid or disallowed input	Clear rejection with no unintended business change.	System owner
Repeated request	Agreed repeat behavior; no unintended duplicate business effect.	Integration lead
Uncertain or interrupted result	Outcome can be established before an operator chooses to reprocess.	Operations owner
Cross-system reconciliation	Source and destination agree on the required business state; exceptions have owners.	Business + operations

Record the evidence reference, reviewer, date, decision, and any accepted residual issue. A passing transport response alone does not close a business acceptance gate.

What this sample establishes

The published source records nine production processes completed and operational at closeout. It does not establish their current availability.
No cost savings, revenue impact, incident reduction, performance targets, or delivery dates are inferred.
Recovery, repetition, and reconciliation gates here are proposed assessment criteria. Their execution is not evidenced by the public excerpt.
Client names, platform names, endpoints, record identifiers, schemas, code, and credentials are excluded.

Read the underlying implementation excerpt or explore the three engineering decisions.

Bring a decision that matters

Discuss an assessment for your initiative

The paid Technology Decision Assessment turns one consequential question into findings, options, a first-phase plan, and acceptance criteria.

Explore the paid assessment Book a consultation Send the context first