SOW compliance plan
Original requirement mapping and the access assumptions in force at the time it was written.
discovery/sow-compliance-and-access-plan.mdView source on GitHub Superseded for current status. Live-access status is maintained on this site, not in this document.
Status date: 2026-08-07
SOW reviewed: /Users/np/Downloads/Tenexity - OptiCat - Statement of Work (DHW Red Line version) (1).docx
This is an operational reading used to control the assessment workflow, not legal advice.
Bottom line
The repository is sufficient for a thorough preliminary architecture assessment, including source-backed tool, API-path, deployment, instruction, schema, security, and fixture-level serialization findings. It is not sufficient for the SOW's live accuracy baseline or a complete Phase 1 acceptance package. Under SOW §4.1, the Access Date is the business day on which the last §6.1 item is delivered. The running Prototype, usable development credentials, written brand entitlement, complete handover materials, and named API/catalog contact have not been provided here. The Access Date therefore has not occurred on the evidence available to this review.
No application source, deployment configuration, environment, or infrastructure will be modified. That boundary follows SOW §§3.4 and 7(a)–(c).
Evidence labels used in the offline review
| Label | Meaning | What it can support |
|---|---|---|
STATIC-PROVEN |
Directly established from tracked source, configuration, documentation, or git history | Architecture, declared contracts, request construction, serializer logic, deployment wiring |
FIXTURE-VALIDATED |
Executed through the real tool functions with deterministic mocked upstream responses | Branch behavior, fixed parameters, caps, dropped fields, exact formatted output |
DOCUMENTATION-INFERRED |
Supported by the bundled manual/Postman collection but not exercised against the live service | Upstream capability hypotheses and expected response fields |
HISTORICAL-QA |
Recorded in OptiCat's April evaluation dataset | Prior observed behavior only; not a current rerun |
ACCESS-REQUIRED |
Requires the deployed host, rotated credentials, entitlement scope, or a catalog/API owner | Current accuracy, live data reachability, latency, rate limits, key scope, host/model behavior |
Fixture success never upgrades an upstream capability to live-reachable, and historical QA never becomes a current measured baseline.
SOW obligation matrix
| SOW requirement | Source | Offline status | What can be completed now | What remains for SOW completion |
|---|---|---|---|---|
| Codebase and architecture review | §2.1; report Part 1 | Preliminary complete | End-to-end repository map, tool surface, instruction layer, API patterns, runtimes, hosting, dependencies, retain/repair/replace classification | Confirm deployed branch/config matches this checkout |
| Repeatable OptiCat-derived test set | §2.2; report Part 2 | Complete as an artifact | 50-case versioned dataset is present; fixture harness is repeatable | Confirm the supplied cases are the agreed canonical QA set |
| Run test set against live Prototype | §2.2 | Blocked — access required | N/A — an offline mock is not the live Prototype | Running Prototype, host-agent export, safe credentials, permission for test traffic |
| Measured current accuracy baseline | §2.2; report Part 2 | Blocked — access required | Historical April distribution can be reported separately | Execute direct-tool and agent-loop replays; retain transcripts and judge review |
| API/data-path assessment | §2.3 | Partial | Endpoint/operation inventory, request shapes, auth code, fields dropped by serializers, documented assets/fitment paths | Live endpoint reachability, rate limits, brand entitlement, key-scope comparison, data drift |
| Target architecture and sequenced plan | §2.4; report Parts 3–4 | Can be completed preliminarily | Concrete contracts, validation gate, clarification/abstention, ranking, response assembly, diagrams, workstreams | Validate assumptions against live response shapes and OptiCat decisions |
| Review session up to 90 minutes | §2.5 | Pending | Agenda and decision list can be prepared | Schedule after Assessment Report delivery |
| Detailed fixed-price Phase 2 proposal | report Part 5 | Cannot be final without business inputs | WBS, milestones, staffing assumptions, dependencies, exclusions, risks, effort ranges, architecture, acceptance criteria | Tenexity price approval, staffing commitment, delivery-date commitment, scope choice |
| Success metrics and production targets | report Part 6 | Can be proposed | KPI definitions and recommended targets | Baseline calibration and OptiCat risk tolerance approval |
| PDF and editable report | §3.2 | Pending finalization | Markdown working report is editable and can be converted after review | Final content approval, then render and visually verify PDF/editable package |
| Required appendices | §3.2 | Can be drafted | Architecture, sequence, data-flow, API interaction, risk matrix, decision log, roadmap | Validate live/runtime-dependent portions |
| Security/auth/authz/observability/logging/AI governance gaps | §7(f) | Preliminary complete | Static assessment documents the gaps | Validate deployed controls and cloud account policies |
| No source/config/environment/deployment deliverable | §§3.4, 7 | Enforced | Work is confined to discovery/ artifacts and test harnesses |
N/A — source remediation belongs in a separate Phase 2 authorization |
Section 6.1 access checklist
| Required item | Evidence available | Status |
|---|---|---|
| Partner account | No partner identity supplied in this workspace | ACCESS-REQUIRED |
| Repository with history/config | Checkout and git history available; deployed-state parity unknown | Partial |
| Running Prototype and dependencies | No endpoint/host session supplied | ACCESS-REQUIRED |
| Development API credential and endpoint docs | Bundled manual/Postman exist; no approved usable credential; one tracked gateway credential requires incident handling | ACCESS-REQUIRED |
| Written brand entitlement | Not present | ACCESS-REQUIRED |
| Handover recording/material | Candidate prompt, planning files, proposal, and April case reconstruction exist; no recording identified | Partial |
| Prior QA results | 50 reconstructed April cases present | Available, provenance confirmation requested |
| Named one-business-day contact | Not established in the workspace | ACCESS-REQUIRED |
Minimum safe access package
- Confirm the deployed repository SHA/branch and export the actual host-agent definition: model, instructions, sampling settings, attached tools/grounding, and tool bindings.
- Rotate/revoke the credential-like gateway key already identified in tracked history before any automated probe. Provide a new development credential through an approved secret channel; do not commit or paste it into chat.
- Provide written brand/dataset/VIN entitlement for that key and, if materially different, one customer-representative key for scope comparison.
- Provide the running Prototype URL/connection method, test window, rate-limit guidance, and approval for approximately 300–500 read-only catalog calls.
- Provide current API documentation for VIN, competitive interchange, lifecycle/supersession, assets, qualifier-bearing applications, pagination, totals, and error/rate-limit conventions.
- Confirm a named catalog/API reviewer who can adjudicate data-versus-code disputes and any ground-truth drift within one business day.
Completion rule
The offline report must be titled and watermarked Preliminary — repository and fixture evidence only. It can be upgraded to the SOW Assessment Report only after:
- all 50 direct-tool cases have an upstream-reachability result;
- all 50 agent-loop cases have a stored transcript and adjudicated grade;
- API/key-scope buckets are complete;
- the deployed instruction/model/tool configuration is captured;
- the fixed price, staffing commitment, and date have been authorized by Tenexity; and
- the PDF/editable package and required appendices pass a visual and traceability review.