Add source-rights evidence without replacing your policy engine

Start with evidence. Decide on enforcement later.

The first integration mode is Observe: AcqPath runs beside the existing request path and writes evidence to your audit stream. Nothing is blocked and no existing policy is replaced.

The commercial gate is 100 eligible events or up to 24 hours, whichever comes first. If the evidence gap is useful, move immediately to higher paid attach volume instead of waiting through a multi-week pilot.

existing request ───────────────→ existing execution
       └─→ AcqPath Evidence → audit log

100 events / max 24h → local report → scale paid usage

One provider-neutral evidence contract

Every integration consumes rights-evidence.resolution.v1. Evidence statements are declared_permitted, declared_prohibited, license_required or unknown. Transport states are resolved, unavailable, unsupported or invalid.

AcqPath never maps that evidence to your final allow/deny decision. The consumer-owned policy engine remains authoritative.

Choose the architecture you already have

AI or MCP gateway: observe tool calls and pass the normalized evidence into the existing policy engine. Crawler or search API: attach rightsEvidence beside the existing URL/content result. RAG: persist source_rights with document provenance. Policy engine: consume an attested evidence input without moving enforcement into AcqPath.

What a typical audit trail may not capture

A normal audit log can prove who acted, which tool executed, the URL and the timestamp. It may not preserve what the publisher declared about machine use at that time, the signed source-state evidence behind the decision, or later declaration drift.

If your system already captures those fields, AcqPath fits as the external evidence source behind them rather than replacing your audit or governance layer.

Build internally vs integrate

Building this internally means maintaining declaration discovery, RSL parsing, purpose mapping, conflict handling, source hashing, timestamps, signatures, freshness, caching, retry semantics, revalidation, drift detection, URL normalization and SSRF controls.

AcqPath collapses those evidence concerns behind one provider-neutral contract while your application keeps policy and enforcement.

Current production boundary

The public Ingestion Gate is intentionally bounded to 1–4 reviewed URLs per operation and current reviewed-origin coverage. Unsupported origins remain unsupported; AcqPath is not an arbitrary-URL proxy.

The future high-volume partner path is a reviewed partner-origin eligibility layer plus asynchronous batch jobs with idempotency, partial-failure semantics, quotas and signed results. That is a planned scale path, not a capability claimed by the current public endpoint.