Form D Filing Evidence Reconciler — reconcile SEC Form D / D-A notices into one accession-level filing assessment

Feed this Actor a batch of Form D / D-A filing rows from your own zinin/funding-alert and/or zinin/funding-round-tracker runs (or any compatible dataset carrying accessionNumber + form + filedAt), and it groups them by the one identity that actually matters — the exact SEC accession number — into one filing assessment per filing: which form values, filed-dates, company names and observed CIKs your sources actually agree or disagree on, so duplicate alerts get resolved before they ever reach a CRM or a deal-flow spreadsheet.

What you get

You give this Actor a dataset (or an inline list) of Form D / D-A filing rows from zinin/funding-alert, zinin/funding-round-tracker, or any compatible source emitting the same accession-number-based shape. It never queries SEC EDGAR itself, never calls a model, and never guesses at a value your rows didn't actually contain — it groups exactly the rows you supply by their exact SEC accession number and reports, per accession, a filing assessment:

• accessionNumber — the canonical dashed 10-2-6 form (e.g. 0002055305-26-000001). This is the only field that identifies a filing here; a source-specific entityId or a company name is never treated as a substitute identity. Both the dashed and exact 18-digit forms of the same real accession resolve to the same identity, so a row supplying either form still groups correctly.
• forms and formConflict — every distinct form string observed for this accession (usually one, e.g. "D" or "D/A"). "D" and "D/A" are always kept as separate literal strings — this Actor never infers that a D/A amendment "replaces" or "relates to" a prior D filing beyond disclosing, when your batch happens to carry both under the same accession number, that they disagree.
• filedAts and filedAtConflict — every distinct filedAt date string observed for this accession, and whether more than one exists.
• companyNames / companyNameConflict and observedCiks / cikSetConflict — the distinct company-name strings and the UNION of every source row's observed CIK set for this accession, each with an explicit conflict flag when different rows disagreed. ciks is treated strictly as an observed set, never a determination of which CIK is "the" issuer.
• sourceAdapters and the status/confidence this Actor assigns — whether the same accession was independently confirmed by two genuinely different upstream adapters (accession_confirmed_multi_source, confidence: high), by only one (accession_confirmed_single_source, confidence: medium), or shows an outright disagreement between sources (accession_conflict, confidence: low).
• cikObservationCoverage, sourceRowsPartialCount, sourceRowsCoverageIncompleteCount — explicit tracking of what your source rows themselves already flagged as incomplete, never silently dropped or treated as agreement.

What this Actor deliberately does not do, so a filing assessment is never mistaken for a legal or financial conclusion:

• It does not infer that a Form D notice represents a successfully closed financing round, a specific proceeds amount, or any investor/issuer role. Form D is a notice of an exempt securities offering — this Actor reports the notice's own reconciled facts, nothing more.
• It does not treat ciks as a determination of the real issuer. It reports the observed set exactly as your sources supplied it, flags disagreement when sources differ, and never picks one CIK as authoritative.
• It does not merge "D" and "D/A" into one concept, and it does not assume a D/A row is necessarily an amendment to a specific prior D row beyond what the shared accession number itself already implies.
• It does not treat a baseline/no-change/incomplete source record as a filing. A row without a syntactically valid accessionNumber, a non-empty form, and a calendar-valid filedAt is a free diagnostic, never a paid result — even when the source row itself reported found: true.
• It does not call any network, AI model, or system clock inside its transform step, and it never launches zinin/funding-alert, zinin/funding-round-tracker, or any other upstream Actor on your behalf.

Who uses it

• Sales research and deal-flow operations teams running both zinin/funding-alert (new-filing push alerts) and zinin/funding-round-tracker (query-based search hits) who need the two feeds reconciled into one row per real filing before anything reaches the CRM, instead of manually deduplicating two separate alert streams by hand.
• VC and investment-research analysts tracking exempt-offering notices for a watch list of sectors or company names, who want an honest confidence signal — multi-source-confirmed versus single-source versus outright conflicting — before treating a Form D sighting as reliable enough to act on.
• Data engineers building a funding-signal pipeline who need a dependable post-processing step that never silently drops a disagreement between two source rows reporting different company names or CIKs for the same accession.
• Compliance and diligence-support staff doing a first-pass check on a target's or counterparty's SEC exempt-offering history, where formConflict/cikSetConflict flags exactly the records that need a human before anyone relies on them.
• Search-term note: if your own workflow uses terms like "Form D deduplication", "SEC accession number reconciliation", "D vs D/A tracking", or "exempt offering CIK matching", this Actor's identity and conflict rules apply directly without extra configuration.

How to run

1. Open the Apify Console and start a new run of Form D Filing Evidence Reconciler.
2. Choose a source, in order of precedence (an explicit dataset always wins over a run reference, which always wins over the inline example):
   • Source Dataset (datasetId) — point at an existing Dataset from a prior zinin/funding-alert or zinin/funding-round-tracker run (or both, combined via your own pipeline into one dataset). Read with your run's own granted permissions.
   • Source run ID (runId) — supply a run ID instead, if you have one but not its Dataset ID directly.
   • Integration payload (payload.resource) — set automatically by Apify's Integrations "Actor/task run" template.
   • Source records (inline) — paste rows directly, or leave the prefilled real public sample: two zinin/funding-alert rows and three zinin/funding-round-tracker rows, five distinct real accession numbers, from actual public runs.
3. Optionally set Max source rows (maxInputRows, default 100, up to 1000) and Max results (maxResults, default 2, up to 1000). The platform's own Max total charge USD run option is a separate, independent stop.
4. Run it. Delivered rows land in the run's default Dataset, one per accession number, each carrying sourceRowIndexes back into your original batch.
5. Read confidence, status, and partial before treating a run's output as reconciled fact — see Decision routing and Evidence and boundaries below.

For a recurring pipeline, chain both zinin/funding-alert and zinin/funding-round-tracker into a combined dataset (or run this Actor twice, once per source, and reconcile downstream) and schedule via an Apify Task — see Integration recipes.

Pricing

This Actor bills on the Apify Pay-Per-Event model under a single primary event, result-found, described under the pricing noun "filing assessment." There is no start fee and no per-row charge — only a delivered, useful filing assessment is billed. Free diagnostics (invalid rows, source failures, baseline/no-change records without a concrete filing, budget stops, empty-batch outcomes) never request the paid event.

Tier	Price per filing assessment
Free	$0.0300
Bronze	$0.0270
Silver	$0.0240
Gold	$0.0210
Platinum	$0.0210
Diamond	$0.0210

Bronze/Silver/Gold apply Apify's standard 10%/20%/30% volume discounts off the Free-tier price; Platinum and Diamond hold at the Gold rate. This table states only the price actually configured on this Actor's result-found event, verified against the live Actor record — it is not a revenue or volume guarantee. A partial: true filing assessment (for example, one missing an observed CIK set, or one with more than five distinct company-name observations than shown) is still a useful, billable aggregate; only a genuinely empty, invalid, or baseline/no-change source outcome is free. See Evidence and boundaries for the exact delivery-and-charging mechanics.

Input contract

{
  "items": [
    {
      "recordType": "new_sec_filing_intelligence",
      "checkedAt": "2026-09-22T05:15:27.990Z",
      "company": "Kintegral Insurance Fund I Series Interests of the SALI Multi-Series Fund V, L.P.",
      "ciks": ["0002055305"],
      "filedAt": "2026-09-09",
      "form": "D/A",
      "accessionNumber": "0002055305-26-000001",
      "url": "https://www.sec.gov/Archives/edgar/data/2055305/000205530526000001/0002055305-26-000001-index.htm",
      "matchedQuery": "fund"
    },
    {
      "recordType": "sec_form_d_search_hit",
      "checkedAt": "2026-09-22T05:15:36.828Z",
      "sourceQuery": "artificial intelligence",
      "company": "Flo Artificial Intelligence, Inc.",
      "ciks": ["0001798621"],
      "filedAt": "2026-07-06",
      "form": "D",
      "accessionNumber": "0001798621-26-000003",
      "coverageComplete": true
    }
  ],
  "maxInputRows": 100,
  "maxResults": 2
}

This example is trimmed from the Actor's own real prefill, which carries five rows total: two zinin/funding-alert rows (recordType: "new_sec_filing_intelligence") and three zinin/funding-round-tracker rows (recordType: "sec_form_d_search_hit"), each with its full __source provenance block and every field disclosed in the row-shape table below. Every accession number, company name, CIK and date in the prefill is a real value observed from a real upstream run, not synthetic fixture data.

Field	Type	Notes
items	array, optional	Inline source rows. Ignored if datasetId or a resolvable runId/payload.resource is present. Bounded to 1000 rows / 4 MiB total / 64 KiB per row.
datasetId	string, optional	Reads an existing Dataset with your run's own granted permissions. Overrides inline items.
runId	string, optional	Reads a run's default Dataset when you have a run ID but not its Dataset ID. No elevated access.
payload	object, optional	A supplied Integrations/webhook envelope with resource.id, resource.defaultDatasetId, and resource.actId. The default does not fetch a source or create an envelope. Private Dataset access requires the destination run’s explicit READ grant.
maxInputRows	integer, default 100, max 1000	Hard cap on source rows read for this run.
maxResults	integer, default 2, max 1000	Hard cap on paid filing assessments delivered this run.

Recognized row shapes

Field	Which source typically carries it	Role
accessionNumber	both	Identity — dashed 10-2-6 or exact 18-digit form, normalized to the same key
form	both	Literal value ("D", "D/A", or any other exact source string), never merged
filedAt	both	Calendar-valid date required for a row to count as a concrete filing
company	both	Display and company-name-conflict detection
ciks	both	Observed-set evidence — normalized, deduped, never treated as "the" issuer
url	both	Display — retained verbatim, never fetched
sourceQuery / sourceQueries / matchedQuery	both	Union into sourceQueries, bounded to 20
checkedAt	both	Source capture timestamp, feeds observedAt/sourceObservationWindow, never a filing event date
recordType	both	Source-adapter identity (new_sec_filing_intelligence vs sec_form_d_search_hit) — required for accession_confirmed_multi_source
partial	either	Upstream's own honesty signal — a true value here always forces this result's partial: true
coverageComplete	either	false here always forces this result's partial: true

Any other field (isNew, baselineCreated, currentFilingsCount, newFilingsCount, queryMatches, retrievedCount, resultLimit, and similar) is read as part of the row but never surfaced or inferred from — it is not part of this Actor's reconciliation contract.

Output examples

Every row and diagnostic below is copied verbatim from an actual private cloud canary run of this Actor's value-add-candidate build (build 0.1.2), the round-2 build whose transform.js and .actor/dataset_schema.json hashes match this Actor's current, accepted source files exactly.

Happy path — a delivered, single-source filing assessment

Real run against the full five-row prefilled sample with maxResults: 2 (the run also produced a max_results_reached diagnostic after delivering two of the five real accessions):

{
  "entityId": "accession:0001798621-26-000003",
  "found": true,
  "status": "accession_confirmed_single_source",
  "action": "review_filing",
  "confidence": "medium",
  "accessionNumber": "0001798621-26-000003",
  "forms": [
    "D"
  ],
  "formConflict": false,
  "filedAts": [
    "2026-07-06"
  ],
  "filedAtConflict": false,
  "companyNames": [
    "Flo Artificial Intelligence, Inc."
  ],
  "companyNamesOmittedCount": 0,
  "companyNameConflict": false,
  "observedCiks": [
    "0001798621"
  ],
  "observedCiksOmittedCount": 0,
  "cikSetConflict": false,
  "cikObservationCoverage": {
    "rowsWithCikSet": 1,
    "rowsMissingCikSet": 0
  },
  "sourceUrls": [
    "https://www.sec.gov/Archives/edgar/data/1798621/000179862126000003/0001798621-26-000003-index.htm"
  ],
  "sourceUrlsOmittedCount": 0,
  "sourceQueries": [
    "artificial intelligence"
  ],
  "sourceQueriesOmittedCount": 0,
  "sourceRowsPartialCount": 0,
  "sourceRowsCoverageIncompleteCount": 0,
  "sourceAdapters": [
    "sec_form_d_search_hit"
  ],
  "sourceAdapterUnknownRowCount": 0,
  "observedAt": "2026-09-22T05:15:36.828Z",
  "sourceObservationWindow": {
    "earliest": "2026-09-22T05:15:36.828Z",
    "latest": "2026-09-22T05:15:36.828Z",
    "validCount": 1,
    "totalRowCount": 1
  },
  "evidence": [
    {
      "field": "form",
      "value": "D",
      "rule": "form_observed",
      "sourceRowIndex": 4
    },
    {
      "field": "filedAt",
      "value": "2026-07-06",
      "rule": "filedAt_observed",
      "sourceRowIndex": 4
    }
  ],
  "businessPartial": false,
  "sourceRowIndexes": [
    4
  ],
  "partial": false,
  "sourceCoverage": {
    "complete": true,
    "reason": null,
    "droppedOversized": 0
  },
  "product": "form-d-filing-evidence-reconciler",
  "schemaVersion": "1.0",
  "sourceDatasetId": null,
  "sourceRunId": null,
  "suppliedSourceRunId": null,
  "sourceRunIdVerified": null,
  "processedAt": "2026-09-23T07:54:13.092Z"
}

confidence is medium, not high, because only one identifiable source adapter (sec_form_d_search_hit, from zinin/funding-round-tracker) contributed to this accession in this batch — real, honest behavior: a single confirmed source is a real filing assessment, but it is never labeled as multi-source confirmation it did not actually receive. The run's summary reported "requested": 5, "usefulResults": 5, "delivered": 2, "paid": 2, "free": 1, "resultsCapped": true, "conflictedAccessions": 0" — five real distinct accessions were found in the batch, and maxResults: 2 genuinely capped delivery to two of them.

Partial path — a real maxInputRows cutoff, with a genuinely delivered result

Real run against the same five-row batch with maxInputRows: 1 (so only the batch's first row was read) and maxResults: 2:

{
  "entityId": "accession:0002055305-26-000001",
  "found": true,
  "status": "accession_confirmed_single_source",
  "action": "review_filing",
  "confidence": "medium",
  "accessionNumber": "0002055305-26-000001",
  "forms": [
    "D/A"
  ],
  "formConflict": false,
  "filedAts": [
    "2026-09-09"
  ],
  "filedAtConflict": false,
  "companyNames": [
    "Kintegral Insurance Fund I Series Interests of the SALI Multi-Series Fund V, L.P."
  ],
  "companyNamesOmittedCount": 0,
  "companyNameConflict": false,
  "observedCiks": [
    "0002055305"
  ],
  "observedCiksOmittedCount": 0,
  "cikSetConflict": false,
  "cikObservationCoverage": {
    "rowsWithCikSet": 1,
    "rowsMissingCikSet": 0
  },
  "sourceUrls": [
    "https://www.sec.gov/Archives/edgar/data/2055305/000205530526000001/0002055305-26-000001-index.htm"
  ],
  "sourceUrlsOmittedCount": 0,
  "sourceQueries": [
    "fund"
  ],
  "sourceQueriesOmittedCount": 0,
  "sourceRowsPartialCount": 0,
  "sourceRowsCoverageIncompleteCount": 0,
  "sourceAdapters": [
    "new_sec_filing_intelligence"
  ],
  "sourceAdapterUnknownRowCount": 0,
  "observedAt": "2026-09-22T05:15:27.990Z",
  "sourceObservationWindow": {
    "earliest": "2026-09-22T05:15:27.990Z",
    "latest": "2026-09-22T05:15:27.990Z",
    "validCount": 1,
    "totalRowCount": 1
  },
  "evidence": [
    {
      "field": "form",
      "value": "D/A",
      "rule": "form_observed",
      "sourceRowIndex": 0
    },
    {
      "field": "filedAt",
      "value": "2026-09-09",
      "rule": "filedAt_observed",
      "sourceRowIndex": 0
    }
  ],
  "businessPartial": false,
  "sourceRowIndexes": [
    0
  ],
  "partial": true,
  "sourceCoverage": {
    "complete": false,
    "reason": "max_input_rows_reached",
    "droppedOversized": 0
  },
  "product": "form-d-filing-evidence-reconciler",
  "schemaVersion": "1.0",
  "sourceDatasetId": null,
  "sourceRunId": null,
  "suppliedSourceRunId": null,
  "sourceRunIdVerified": null,
  "processedAt": "2026-09-23T07:55:30.835Z"
}

This row matches the real first-row's own data exactly (it always would have, since that same first row was read either way); only partial and sourceCoverage changed, because the run also emitted a separate free partial_source diagnostic ("reason": "max_input_rows_reached") disclosing that the batch's four other real rows were never read this run.

Failure path — the platform's own charge limit stops delivery before any row is read

Real run with the platform's Max total charge USD run option set to $0.005 — below the configured $0.03 Free-tier price:

{
  "product": "form-d-filing-evidence-reconciler",
  "schemaVersion": "1.0",
  "status": "budget_stopped",
  "reason": "Run charge limit cannot cover any result; no source was read.",
  "found": false,
  "processedAt": "2026-09-23T07:55:11.152Z"
}

Free — chargedEventCounts.result-found was 0 on the real run terminal record. The charge-limit check happens before any source row is read, so a misconfigured cap fails safely and instantly.

Empty-source path — a batch with nothing usable in it

Real run with items: []:

{
  "product": "form-d-filing-evidence-reconciler",
  "schemaVersion": "1.0",
  "status": "no_results",
  "found": false,
  "reason": "no_usable_rows_in_batch",
  "sourceCoverage": {
    "complete": true,
    "reason": null,
    "droppedOversized": 0
  },
  "processedAt": "2026-09-23T07:55:01.782Z"
}

Also free. sourceCoverage.complete: true means the Actor read the entire (empty) batch supplied — the emptiness is a fact about the input, not a read failure.

Field dictionary

Field	Meaning
entityId	accession:<canonical dashed accession number>.
found	true for a useful result eligible for the result-found event; every free diagnostic row has found: false.
status	accession_confirmed_multi_source, accession_confirmed_single_source, or accession_conflict for a delivered row; otherwise a diagnostic status.
action	review_filing (agreement or single-source) or resolve_conflict (a real disagreement) — a routing hint, never an automated legal decision.
confidence	high (2+ distinct adapters agree, no conflict, not otherwise partial), medium (single-source, or otherwise-high but partial), or low (any conflict). See Decision routing.
accessionNumber	Canonical dashed 10-2-6 identity for this assessment.
forms / formConflict	Every distinct form string observed; true when more than one.
filedAts / filedAtConflict	Every distinct filedAt observed; true when more than one.
companyNames / companyNamesOmittedCount / companyNameConflict	Distinct company names (cap 5, exact omitted count) and whether more than one was observed.
observedCiks / observedCiksOmittedCount / cikSetConflict	Union of every observed CIK set (cap 10, exact omitted count), and whether different rows reported different non-empty sets.
cikObservationCoverage	{ rowsWithCikSet, rowsMissingCikSet } — missing CIK evidence tracked separately from a CIK-set conflict; never equated with agreement.
sourceUrls / sourceUrlsOmittedCount	Distinct source URLs (cap 5), retained verbatim, never fetched.
sourceQueries / sourceQueriesOmittedCount	Union of every sourceQuery/sourceQueries/matchedQuery observed (cap 20).
sourceRowsPartialCount	Count of contributing rows that themselves carried upstream partial: true. Nonzero forces this result's partial: true.
sourceRowsCoverageIncompleteCount	Count of contributing rows with upstream coverageComplete: false. Nonzero forces partial: true.
sourceAdapters / sourceAdapterUnknownRowCount	Distinct identifiable recordType adapters contributing (only 2+ distinct known adapters count as multi-source confirmation); rows with no identifiable adapter, tallied separately.
evidence	Up to 12 { field: "form"|"filedAt", value, rule, sourceRowIndex } entries; rule is *_conflict when that field disagreed, *_observed otherwise.
observedAt / sourceObservationWindow	Real latest/earliest valid checkedAt across contributing rows — a capture time, never a filing event date.
sourceRowIndexes	The specific offsets into your original batch that produced this row.
partial	true when any display list was capped, a contributing row itself reported partial/coverageComplete: false, no row carried a usable CIK set at all, or the configured row window wasn't fully read.
sourceCoverage	{ complete, reason, droppedOversized } — whether the reader established the end of the supplied source, including a bounded probe at a row limit.
product / schemaVersion	Fixed identifiers for schema pinning.
sourceDatasetId / sourceRunId / suppliedSourceRunId / sourceRunIdVerified	Provenance for a dataset/run-sourced batch — null on an inline-items run.
processedAt	When this Actor processed the row — never a filing event date or source capture time.

Diagnostics (never billed) share a smaller shape: { product, schemaVersion, status, found: false, reason/error, sourceRowIndexes? }, with status one of invalid_row, source_row_failed, no_concrete_filing (a baseline/no-change/incomplete record — no valid accessionNumber + form + calendar-valid filedAt), no_results, budget_stopped, partial_source, or the run-level max_results_reached summary row.

Evidence and boundaries

What "found" actually means here. A delivered filing assessment requires found: true with a real accession number, at least one distinct form and filedAt observation, and populated evidence. A source row that reported found: true but lacked a syntactically valid accessionNumber, a non-empty form, or a calendar-valid filedAt is a no_concrete_filing diagnostic — a real, honest disagreement between "the source thinks it found something" and "this Actor's own stricter concrete-filing test."

Diagnostics carry no result event. The transform records rejections, but delivery is bounded to200 diagnostics and64KiB per row; the summary reports truncation/oversized omissions. After storage failures a summary itself may be unavailable. invalid_row (not an object), source_row_failed (the source itself reported found: false, failed: true, a nonempty failureType, or a failure-shaped error/errors), and no_concrete_filing produce reasons subject to the diagnostic delivery limits above.

Conflicts are never auto-resolved. When the same accession's rows disagree on form, filedAt, or the observed CIK set, this Actor reports status: "accession_conflict", confidence: "low", and the union of every observed value — it never picks a "winning" value and never discards a disagreeing one. formConflict/filedAtConflict/cikSetConflict tell you exactly which field(s) disagreed.

Multi-source confirmation requires genuinely distinct adapters. accession_confirmed_multi_source / confidence: "high" only fires when at least two distinct, identifiable recordType adapters (e.g. zinin/funding-alert's new_sec_filing_intelligence and zinin/funding-round-tracker's sec_form_d_search_hit) agree on the same accession. Duplicate rows from the same adapter, or rows with no identifiable recordType at all, never inflate this into a false multi-source claim. confidence is also capped down from high to medium whenever the result is otherwise partial: true — incompleteness never gets to claim the top confidence level, even with two agreeing adapters.

Why maxInputRows/maxResults caps and platform charge limits interact the way they do. This Actor reads at most maxInputRows source rows and delivers at most maxResults paid filing assessments, independent of each other and both independent of the platform's own Max total charge USD run option. Before reading any source row, it verifies the run's charge limit can cover at least one filing assessment at the confirmed live price; if it cannot, the run stops immediately with the free budget_stopped diagnostic shown above.

Delivery is a dataset write, then an explicit charge — never the reverse, and never guaranteed exactly-once. Every delivered filing assessment is written to your run's Dataset before the corresponding result-found charge event is requested, and the two steps are not transactional. On any ambiguity about whether a write or a charge actually completed, this Actor fails closed rather than guessing, and never automatically retries a possibly-already-charged write. A run that fails partway through may still contain already-delivered, already-charged rows; that is expected behavior for a partial run.

Re-running is new processing, not deduplication. This Actor's own-run guard only prevents an automatic resurrection of a run that already started paid work — it is not a cross-run deduplication layer. Running it again against the same input performs genuinely new processing and can bill again for the same accessions.

Source resolution precedence and permissions. An explicit datasetId/runId and an Integrations payload.resource reference must agree when both are present — a mismatch is rejected outright. A runId is read with your own run's own granted permissions; no elevated access is used, and no upstream Actor is ever started. The Source Dataset field uses Apify's resourcePicker with an explicit READ-only grant — that grant, not a bare webhook payload, is what allows this Actor to read a private Dataset. Source-resolution calls are GET requests against the fixed https://api.apify.com origin. Output storage and billing use the Apify SDK and perform writes.

Bounded everything, always. 1000 source rows / 4 MiB total input / 64 KiB per source row, per run. companyNames capped at 5, observedCiks at 10, sourceUrls at 5, sourceQueries at 20, evidence at 12 — each with an exact omitted count, and each nonzero omission forces partial: true.

What this Actor cannot verify. It cannot confirm a filing actually appears on SEC EDGAR — validation is against the syntax of a real accession number, form, and date, never a live EDGAR lookup. It cannot tell you which observed CIK is the true legal issuer when a set contains more than one, or whether a Form D notice ever resulted in a completed financing. None of these are claimed anywhere in this Actor's output.

Decision routing

confidence and status are set by one deterministic rule, applied per accession after the full batch for that accession has been aggregated:

1. accession_conflict / confidence: "low" — set whenever formConflict, filedAtConflict, or cikSetConflict is true for that accession. A conflict always overrides the other two outcomes, regardless of how many sources agree elsewhere.
2. accession_confirmed_multi_source / confidence: "high" — no conflict, and at least two distinct identifiable source adapters (recordType values) contributed to this accession. Downgraded to confidence: "medium" (status unchanged) whenever the result is otherwise partial: true — e.g. a missing CIK set, a capped display list, or an upstream partial/coverageComplete: false signal on any contributing row.
3. accession_confirmed_single_source / confidence: "medium" — no conflict, but only one identifiable adapter (or none) contributed.

Route accordingly:

• confidence: "low" (any conflict) → send to manual reconciliation before importing into a CRM or deal-flow tracker. Read formConflict/filedAtConflict/cikSetConflict and the corresponding evidence[].rule: "*_conflict" entries to find exactly which field disagreed and which source rows produced each value.
• confidence: "high" → two independent adapters agree and nothing was capped or flagged incomplete — safe to import directly, with the standing caveat that this is a reconciliation of your supplied batch, never a live EDGAR verification.
• confidence: "medium" → either a genuinely single-source sighting, or an otherwise-agreeing multi-source result with some incompleteness (check partial and its contributing flags to see which). Treat as a real filing worth tracking, but seek a second source or a longer observation window before treating it as confirmed.

partial: true is orthogonal to confidence — it tells you a displayed list was capped, upstream itself flagged incompleteness, or your configured row window wasn't fully read, never that the underlying reconciliation is wrong.

Commercial playbooks

Two-feed deal-flow reconciliation. Run both zinin/funding-alert and zinin/funding-round-tracker against your watch queries, combine their datasets, and feed the union through this Actor before anything reaches your CRM. accession_confirmed_multi_source rows go straight into the pipeline; accession_conflict rows go to a "needs review" queue; accession_confirmed_single_source rows get a lighter secondary check.

Weekly exempt-offering digest. Schedule this Actor after your alert/tracker runs on a weekly Apify Task. Route confidence: "low" accessions to a Slack channel tagged "conflicting Form D data" and everything else into your standard research log, with sourceObservationWindow telling recipients exactly how fresh each batch was.

Pre-outreach sanity check for a target company. Before reaching out to a company that just filed a Form D, run its known filing rows through this Actor to confirm the company name and CIK are consistent across your sources — a companyNameConflict or cikSetConflict is a strong signal to verify the entity manually before an outreach email goes out under the wrong company name.

Internal data-quality gate for a funding-signal warehouse. Insert this Actor immediately after any Form D-emitting scraper in your pipeline. An accession_conflict result blocks that accession from loading into your BI warehouse until a human resolves it — a cheap, deterministic gate against exactly the kind of cross-source disagreement that silently corrupts a downstream funding-tracker table.

Integration recipes

Chained via Apify Integrations (recommended for scheduled pipelines). In the Apify Console, add an "Actor/task run" integration on your zinin/funding-alert or zinin/funding-round-tracker Task, pointed at this Actor, and map {{resource.defaultDatasetId}} into this Actor's Source Dataset field and supply any webhook envelope explicitly. To reconcile both sources together, run one of them into a shared dataset your own pipeline builds, or run this Actor once per source and merge the delivered assessments downstream by accessionNumber.

Direct API call. Start a run via POST https://api.apify.com/v2/acts/zinin~form-d-filing-evidence-reconciler/runs?maxTotalChargeUsd=0.50 with your Authorization header, passing { "datasetId": "<upstream dataset id>", "maxInputRows": 200, "maxResults": 10 }. Poll GET /v2/actor-runs/<runId> for status: "SUCCEEDED", then read GET /v2/datasets/<defaultDatasetId>/items.

Webhook-notified pipeline. Attach a webhook for ACTOR.RUN.SUCCEEDED, pointed at your own endpoint. The webhook payload never grants elevated access to the run's Dataset — treat it as a "go read now" signal and fetch rows via the Dataset API with your own stored token. Define the webhook with doNotRetry: true and never embed a customer credential in it.

MCP / agent tool use. Pass the same datasetId/runId/items + maxInputRows/maxResults shape as any other caller. Surface status, confidence, and the *Conflict flags directly to the end user — those are exactly the fields that distinguish "safe to act on" from "needs a human to look at the conflicting source rows first."

The following webhook registration is a template, not a captured dispatch. Substitute the upstream ID and configure the destination’s explicit Dataset READ permission; the envelope itself grants no access. Credentials belong in headers.

{
  "eventTypes": [
    "ACTOR.RUN.SUCCEEDED"
  ],
  "condition": {
    "actorId": "<YOUR_UPSTREAM_ACTOR_ID>"
  },
  "requestUrl": "https://api.apify.com/v2/acts/zinin~form-d-filing-evidence-reconciler/runs?maxTotalChargeUsd=0.50",
  "headersTemplate": "{\"Authorization\": \"Bearer <YOUR_APIFY_TOKEN>\"}",
  "payloadTemplate": "{\"datasetId\":\"{{resource.defaultDatasetId}}\",\"payload\":{\"resource\":{{resource}}},\"maxInputRows\":100,\"maxResults\":2}",
  "doNotRetry": true
}

Finalization attempts to persist OUTPUT and SUMMARY; storage failure can prevent either. Raw Dataset rows may exceed confirmed counters after an ambiguous write or charge. Inspect actual event counters before rerunning.

Operating guide

• Start with the real prefill. Run it once against the prefilled five-row sample to confirm the delivered shape matches your expectations before pointing it at your own dataset.
• Combine both source feeds before running, if you have both. This Actor's multi-source confirmation only fires when two distinct adapters actually appear in the same batch — running zinin/funding-alert and zinin/funding-round-tracker separately, each through its own run of this Actor, can never produce a high-confidence multi-source result even for the same real accession.
• Set maxInputRows/maxResults to your real batch size, not the defaults — a genuine weekly digest across two feeds is likely larger than the 100-row/2-result defaults meant for a first test.
• Always set the platform's own Max total charge USD for any unfamiliar batch size — it fails safely via budget_stopped rather than partially processing when set too low.
• Treat accession_conflict as a to-do list. Every conflict is a real disagreement your own sources produced. Resolve at the source — check which adapter's value is stale versus current — rather than picking a value from the union arbitrarily.
• Watch cikObservationCoverage.rowsMissingCikSet. A nonzero value means some contributing rows had no observed CIK evidence at all, distinct from (and forcing partial: true alongside) an actual CIK-set conflict — don't read "no conflict shown" as "CIK confirmed" when coverage itself is incomplete.
• Do not rely on a single run for an ongoing watch. Schedule on a cadence; observedAt/sourceObservationWindow tell downstream consumers exactly how fresh each assessment was.

FAQ

Does this Actor query SEC EDGAR itself? No. It is a pure post-processing reconciliation over rows you already have from zinin/funding-alert, zinin/funding-round-tracker, or a compatible source. It never launches an upstream Actor and never fetches anything from sec.gov directly.

Why does a D/A filing never get linked to the D filing it's amending? Because this Actor's identity is the accession number alone. If your sources happen to report the amendment under the same accession number as the original (as EDGAR itself sometimes does for certain filing relationships), this Actor will group them and disclose the resulting formConflict. If your sources report the amendment under a different accession number — which is common — that relationship is outside this Actor's identity contract entirely; linking separate accessions as "the same underlying offering" would require a broader company/CIK-level correlation this Actor deliberately does not attempt.

Why did I get confidence: "medium" instead of "high" even though I only ran one source? Because "high" specifically requires two distinct, identifiable adapters agreeing on the same accession. A single-adapter batch — even a large one — can only ever produce accession_confirmed_single_source / "medium", by design: this Actor never fabricates cross-source confirmation from duplicate rows of the same source.

My row had found: true from the source, but I got a no_concrete_filing diagnostic instead of a result. Why? Because found: true from the upstream source only means the source itself believes it identified something — it does not guarantee the row carries a syntactically valid accessionNumber, a non-empty form, and a calendar-valid filedAt, which is this Actor's own independent bar for "a concrete filing." A baseline/no-change alert, or a row missing one of those three fields, is reported honestly as no_concrete_filing rather than silently promoted to a paid result.

What happens if two rows report different CIK sets for the same accession? cikSetConflict: true is set, and observedCiks shows the union of every distinct set observed (bounded to 10, with an exact omitted count) — never one set silently chosen over the other.

Will running this Actor again on the same dataset cost me twice? Yes, if the same accessions still qualify as useful filing assessments. There is no cross-run deduplication, only a same-run resurrection guard. Build your own dedupe key (accessionNumber + observedAt) if you run this on a recurring schedule against overlapping data.

Is an accession_confirmed_multi_source result a claim that the filing is legitimate or that the offering succeeded? No. It is a claim about evidence agreement across your supplied sources only — never a legal, financial, or investment-merit conclusion.

Sources and rights

This Actor processes only Form D / D-A filing rows you supply — your own zinin/funding-alert and/or zinin/funding-round-tracker runs, or any compatible source following the recognized row shapes above. It holds no independent relationship with SEC EDGAR and performs no live filing lookups of its own; you remain responsible for the terms under which your source data was originally obtained.

Related public Store Actors referenced or usable alongside this one, identified in the saved Apify Store research and public Actor metadata captured on 2026-09-23:

• zinin/funding-alert — the primary own-ecosystem push-alert source for new SEC filing intelligence rows.
• zinin/funding-round-tracker — the primary own-ecosystem query-based search source for Form D hits.
• constant_quadruped/sec-edgar-filings-scraper — SEC Edgar Filings Scraper, a related public source for broader EDGAR filing types beyond Form D.

Public examples in this Actor's prefill and in this README are curated, provenance-tagged projections of actual public source runs, never synthetic fixtures — every accession number, company name, CIK, and date traces back to a real upstream Actor, run, and Dataset recorded in the row's own __source block. The saved public examples omit dates of birth, home addresses, nationality, and personal contact details. Fields supplied in your own records remain your responsibility.

• zinin/sec-edgar-watcher — separate broader filing context. Its general filing timeline rows are not interchangeable with this Actor’s recognized Form D adapters; compare the accession and source schema before mapping any records.