Customer-Supplied Binary Components: Document Who Can Diagnose and Replace Them
When a customer supplies a binary that the integrator cannot inspect or rebuild, define who can observe, diagnose, escalate and replace it before calling the handover maintainable. Pinning its checksum is necessary for identity, but it does not create access to internal diagnostics or a commitment from its supplier to provide a fix.
This article proposes a responsibility and evidence map. It does not interpret licenses, promise supplier support or diagnose any real binary. No customer component, confidential input or credential is included, and no integration test was run.
1. Describe the opacity boundary
Identify what is available: binary release, documented interface, supported environment, symbols, diagnostic controls, test vectors, source access and replacement route. Mark unavailable items explicitly.
Different limitations lead to different support paths. A binary with stable diagnostics and a responsive authorized owner may be diagnosable without source. A component with no version identity or documented input contract may block useful escalation before internal inspection even becomes relevant.
NASA’s interface-management guidance, section 6.3, calls for defined responsibilities. The original map here applies that principle to an opaque dependency rather than treating “supplied by customer” as a complete support policy.
2. Allocate responsibilities by layer
| Layer or decision | Responsibility to identify | Evidence needed |
|---|---|---|
| Integrator wrapper | Who owns invocation, inputs and error handling? | Reproducible boundary trace and wrapper identity |
| Runtime environment | Who confirms the supported platform and settings? | Relevant environment/configuration record |
| Binary internals | Who can analyze internal behavior? | Agreed escalation package and access route |
| Replacement supply | Who can obtain an authorized candidate? | Version, provenance and availability record |
| Replacement acceptance | Who decides whether the integrated product can use it? | Scoped integration and regression evidence |
Use actual agreed roles when applying the map. Do not assign obligations to a supplier merely because its name appears on the binary. Missing responsibility is a handover issue to resolve, not a reason to invent a service promise.
3. Define a minimum diagnostic boundary
Capture the component identity, relevant input properties, call sequence, returned status and observable output. Include surrounding resource or timing conditions when they matter, but avoid collecting full private payloads by default.
Separate observed facts from attribution. An application crash after calling a component does not alone establish that the binary caused it. Incorrect inputs, lifetime errors, unsupported concurrency or environment mismatch may exist outside the opaque boundary.
The integrator should identify what can be checked locally and what requires the binary owner. If the API contract does not define an important condition, record the ambiguity instead of treating the wrapper’s assumption as authoritative.
4. Agree a usable escalation package
Propose a minimal reproducer with artificial or authorized sanitized input, exact versions, expected behavior, actual observation and reproduction limits. Include a control case that succeeds where useful, so the owner can distinguish general setup failure from the reported condition.
Sanitization can change behavior. If the failure disappears after removing private content, say that the sanitized fixture does not reproduce it. Seek an approved alternative evidence method rather than sending sensitive data through an unapproved channel.
Record the permitted recipient, access route and information scope. A package stored locally is not the same as an authorized external escalation, and this article does not send one.
5. Separate investigation access from replacement authority
The party able to analyze a binary may not be the party authorized to distribute a replacement. Likewise, the customer supplying a candidate may not own approval of the integrated product’s release.
NASA’s technical-data guidance, section 6.6, distinguishes data responsibilities and authorized access. Record these boundaries explicitly, including any unresolved rights or access questions for the appropriate owner to address.
Do not place production secrets in the engineering package to make a dependency appear self-contained. Document the approved external provisioning or access prerequisite instead.
6. Work through a fictional binary conversion component
A fictional customer supplies a conversion library used by an embedded reporting application. The integrator has an interface specification and release binary but no source or internal symbols. One artificial input produces an unexpected status.
The integrator checks the documented input contract, call order and supported environment, then retains the boundary observation. The component owner receives only an authorized diagnostic package if the project’s process permits escalation. The record does not label an internal root cause that nobody has established.
If a replacement arrives, its identity and provenance are recorded separately. A successful check of the original input is useful but insufficient for the whole product: other supported inputs, error behavior and integration assumptions still require their planned review.
7. Qualify the replacement path before relying on it
| Question | Handover outcome |
|---|---|
| Can an authorized party obtain a replacement? | Confirmed route or explicit availability risk |
| Can the receiver identify the installed version? | Usable identity check or a diagnostic gap |
| Can the original issue be evaluated on the candidate? | Reproducer/control plan with evidence limits |
| Who approves integrated use? | Named authority and required regression scope |
Retain the approved previous artifact and recovery information where policy requires it. Do not assume reverting the binary also reverses persistent state or surrounding configuration changes.
The final responsibility map should distinguish work the receiving team can perform independently, work requiring the component owner and questions still unresolved. That makes the support boundary reviewable without claiming access, response times, licensing rights or replacement guarantees that the project does not actually have.
