When one app reads answer sheets and another needs the capability, sharing code is only one option. First establish whether the domain behavior is shared.

Architecture notes

A versioned processing boundary

Two consumer applications use a shared processing contract. The core produces versioned results while each app retains its own workflow.
Two consumer applications use a shared processing contract. The core produces versioned results while each app retains its own workflow. View full-size diagram

Identify the boundary

Compare layouts, input quality, algorithm versions, result schema, confidence, and manual review. App navigation and assessment rules should not become hidden dependencies of a common reader.

Library or service?

A library simplifies local calls but couples deployments and runtimes. A service provides an independently deployed contract, while adding availability, latency, and ownership concerns. Both need compatibility tests.

A proposed contract

request: document_id, layout_version, input_reference
result: document_id, algorithm_version, status,
        extracted_answers, confidence, review_reasons

This is a public design example, not an existing internal contract. Add authorization, idempotency, retention, timeouts, and compatibility rules.

Questions before committing

Who owns incidents and releases? Can consumers pin an algorithm version? Which fixtures test compatibility? Can results be reproduced? How do partial reads reach review? These answers determine whether the boundary is sustainable.

References and further reading

Primary sources for the technical concepts in this article. The examples and decisions above are my synthesis, not quotations from these sources.

  1. AWS Prescriptive GuidanceStrangler fig pattern

    Incremental boundary migration; useful when extracting a shared capability.

  2. AWS Prescriptive GuidanceRetry with backoff pattern

    Idempotency and transient-failure handling across service boundaries.