DecisioQ Auto Repair Developer Integration Manual

How software developers should incorporate DecisioQ into shop management, estimating, diagnostics, scheduling, parts, and customer approval systems

Version 1.0 - Auto Repair industry edition

Contents

1. Purpose and integration model

2. Auto Repair decision domains

3. Reference architecture

4. Data mapping and template design

5. API integration patterns

6. End-to-end workflow examples

7. User interface guidance

8. Security, auditability, and governance

9. Testing, deployment, and operations

10. Implementation checklist

1. Purpose and integration model

This manual explains how developers in the Auto Repair industry should embed DecisioQ into operational software. The goal is not to replace an existing shop management system, estimating product, diagnostic platform, or parts ordering tool. DecisioQ should act as a decision service that receives structured alternatives, criteria, weights, constraints, and context, then returns ranked recommendations with transparent scoring and explanation data.

In an Auto Repair environment, many decisions are multi-factor and time-sensitive. A shop may need to decide which vehicle to repair first, which technician should receive a job, which parts supplier should be used, whether a warranty claim should be approved, or how inventory should be replenished. DecisioQ converts these choices into reusable templates so the same business logic can be applied consistently across web, mobile, back-office, and API-driven workflows.

2. Auto Repair decision domains

The DecisioQ Auto Repair templates provide a starting point for high-value workflows. Developers can use these templates directly, clone them per tenant, or create shop-specific variants with adjusted weights and constraints.

3. Reference architecture

A production integration should isolate DecisioQ calls behind an internal domain service. This keeps UI teams from depending directly on scoring details and makes it easier to add caching, retries, observability, and tenant-level configuration.

Recommended request lifecycle:

1. The user opens a workflow such as dispatch, scheduling, warranty review, or supplier selection.
2. The application service gathers candidate options and normalized criteria values from operational systems.
3. The service selects the relevant DecisioQ template and applies tenant-specific weight overrides if configured.
4. The application posts the decision request to DecisioQ.
5. DecisioQ validates criteria, applies constraints, computes scores, ranks options, and returns explanations.
6. The application displays the recommendation and persists the decision trace with the business transaction.

4. Data mapping and template design

Each Auto Repair template should have a deterministic mapping from operational data fields to DecisioQ criteria. Developers should keep these mappings in configuration or a domain-specific mapper class so they can be tested independently.

5. API integration patterns

Use a small internal client library so all Auto Repair applications call DecisioQ consistently. The client should standardize authentication, base URL handling, timeouts, retry policy, request validation, and telemetry.

5.1 Sample JSON request: technician assignment

{
  "templateName": "Technician Assignment",
  "industry": "Auto Repair",
  "algorithm": "TOPSIS",
  "options": [
    {
      "name": "Technician A",
      "attributes": {
        "SkillMatch": 94,
        "Productivity": 88,
        "CurrentWorkload": 3,
        "CustomerRating": 96,
        "CertificationLevel": 3
      }
    },
    {
      "name": "Technician B",
      "attributes": {
        "SkillMatch": 89,
        "Productivity": 92,
        "CurrentWorkload": 6,
        "CustomerRating": 91,
        "CertificationLevel": 2
      }
    }
  ],
  "context": {
    "correlationId": "optional",
    "attributes": {}
  }
}

5.2 C# client pattern

public sealed class AutoRepairDecisionClient
{
    private readonly HttpClient _http;

    public AutoRepairDecisionClient(HttpClient http) => _http = http;

    public async Task<DecisionResponse> RankTechniciansAsync(
        TechnicianAssignmentRequest request,
        CancellationToken cancellationToken)
    {
        using var response = await _http.PostAsJsonAsync(
            "/api/decisions/evaluate",
            request,
            cancellationToken);

        response.EnsureSuccessStatusCode();
        return await response.Content.ReadFromJsonAsync<DecisionResponse>(
            cancellationToken: cancellationToken)
            ?? throw new InvalidOperationException("DecisioQ returned an empty response.");
    }
}

5.3 TypeScript adapter pattern

export async function evaluateRepairJobPriority(input: RepairJobPriorityInput) {
  const request = mapRepairOrdersToDecisionRequest(input);

  const response = await fetch(`${DECISIOQ_BASE_URL}/api/decisions/evaluate`, {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${await getAccessToken()}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify(request)
  });

  if (!response.ok) {
    throw new Error(`DecisioQ evaluation failed: ${response.status}`);
  }

  return await response.json();
}

6. End-to-end workflow examples

6.1 Repair job prioritization

Use this workflow when multiple vehicles are waiting and the shop needs to decide which jobs should be advanced first. The dispatch screen should call DecisioQ when the queue changes, when parts availability changes, or when a manager requests a re-rank.

6.2 Parts supplier selection

Use this workflow in estimate approval, backorder handling, substitute part selection, and rush repair scenarios. Each supplier quote becomes an option. The result can be displayed beside price, ETA, warranty, and quality indicators.

6.3 Warranty claim approval

Use this workflow when a customer returns with a complaint, warranty repair, comeback, or disputed workmanship issue. DecisioQ should not automatically deny a customer-facing claim; instead, it should triage the claim into approve, manager review, or investigate.

7. User interface guidance

The integration succeeds when users trust the recommendation. Avoid hiding the score behind a black box. Show enough detail to make the recommendation actionable, but do not overload service advisors or technicians during time-sensitive work.

• Use a recommendation card at the top of the workflow: recommended technician, supplier, job, or appointment slot.
• Show the rank, score, and two or three strongest contributing factors.
• Show hard constraint failures separately from low scores so users know why an option was removed.
• Allow manager override with mandatory reason code for safety, warranty, financial, or customer-impacting workflows.
• Record whether the user accepted the recommendation, changed it, or dismissed it.

8. Security, auditability, and governance

Auto Repair systems often include customer contact data, vehicle identification information, payment information, and insurer or fleet account data. Send only the fields required for decision scoring. Avoid sending raw notes, payment card data, or unnecessary personally identifiable information.

9. Testing, deployment, and operations

Before production rollout, test both the technical integration and the operational behavior. The best test data comes from historical repair orders, completed estimates, technician assignments, supplier selections, and warranty outcomes.

10. Implementation checklist

Suggested first rollout: start with Repair Job Prioritization or Technician Assignment because both deliver visible operational value, use readily available data, and can be implemented as recommendations without forcing immediate automation.

Appendix A. Template-to-system mapping quick reference

End of manual.