Turning public contract awards into business intelligence

A supplier researching a new service area might ask which agencies buy the kind of work it supports, which firms appear in those procurements, and whether the records show a recurring category of projects.

Those questions suggest a product built around a buyer or supplier profile. Instead of a folder of documents, the customer gets a reviewed set of relevant contracts, the supporting sources, and enough context to decide where further research is worthwhile.

AICD API can provide documented discovery and civic-record interfaces for supported sources. The contract model, vendor matching, and business-intelligence calculations are the application you build on top.

Start with a profile a customer would use

For a first version, choose a category such as water-utility construction, facilities maintenance, or municipal software procurement. Limit the research to a defined set of agencies and dates.

A buyer profile could show the procurements found in that scope, their documented stages, the firms named, and links to the original material. A supplier profile could collect the verified records associated with one legal entity.

The useful questions are descriptive: What work appears in the records? Which agencies are associated with it? What amounts and terms are actually documented? Where is the next source to inspect?

Do not turn an incomplete collection into a claim about a vendor's market share or an agency's total spending. A scoped, source-linked research product can be valuable without claiming to be a complete market census.

Build around the procurement, not every mention

A contract may appear in a proposal, an authorization, an amendment, and a later report. Your product should connect related evidence to one procurement rather than count every appearance as a separate win.

Dallas's historical April 23, 2025 file 25-625A illustrates the issue. It names SYB Construction Company, Inc. and describes a $1,929,810.72 increase, moving a contract amount from $21,679,451.50 to $23,609,262.22. The official page marks the item Approved.

For an intelligence product, those numbers have different meanings. The increment is not a new contract worth the revised total, and neither amount establishes a payment. Your model should preserve the relationship instead of choosing the largest number on the page.

A proposed application record for that source could look like this:

{
  "source_file": "25-625A",
  "agenda_date": "2025-04-23",
  "vendor_name_as_published": "SYB Construction Company, Inc.",
  "event_kind": "amendment",
  "source_status": "Approved",
  "currency": "USD",
  "increment": "1929810.72",
  "previous_contract_ceiling": "21679451.50",
  "revised_contract_ceiling": "23609262.22",
  "payment_amount_observed": null
}

This is an application schema derived from the linked official example, not an AICD API response. Decimal strings preserve the stated monetary precision until your application parses them with decimal arithmetic. Attach the source URL and evidence locations to the stored record as well.

Discover candidate records with the documented search

Begin by checking supported source status. Use the separate research coverage catalog to investigate other source families and gaps, without treating a discovered source as an ingested feed.

An enabled MCP client can use search_agenda for a buyer, phrase, or named company. Here is a tool-name and arguments pair for a historical vendor search:

{
  "name": "search_agenda",
  "arguments": {
    "query": "\"SYB Construction\"",
    "jurisdictionSlug": "dallas",
    "fromDate": "2025-01-01",
    "toDate": "2025-06-30",
    "limit": 20
  }
}

This pair belongs inside an MCP tools/call, not directly in a REST request body. The transport documentation provides the complete envelope and headers for POST /api/v1/mcp. The key requires mcp:read and enabled access. The route is marked Limited availability, and the tool section Limited availability.

Search results are candidates. Read the successful tool result under structuredContent.data, inspect its pagination and truncation signals, and fetch selected itemId values with get_agenda_item. Follow the original source for evidence not included in the shortened tool text.

Do not assume the query returns the historical example above. That example was inspected on the official publisher's site. Its role here is to show the information model your application needs.

Add the procurement evidence that search alone cannot supply

The documented tool searches agenda records. It does not expose a vendor-awards endpoint, supplier revenue field, or complete procurement database. Those should not appear as invented features in an integration.

Other official sources can supply additional evidence. Dallas County's 2024 bid-tabulation page links individual procurements to court orders and bid or scoring material. Mesquite's bid-tabulation page distinguishes pre-award and awarded records. Your application could investigate those sources alongside supported civic records, with separate connectors or reviewed manual imports where needed.

For each candidate, retain the agency, procurement identifier, source-system identifier, named legal entity, document date, event type, and evidence for any amount or outcome. Some of these values may be absent. A source-linked unknown is preferable to a generated contract number that breaks every later join.

The extraction model can propose associations. A reviewer or an explicit, tested matching rule should determine when records refer to the same procurement or vendor.

Keep a supported civic-data collection up to date

For an application maintaining supported civic records locally, the snapshot interface provides a consistent starting state:

: "${AICD_API_KEY:?Set an enabled customer API key}"

curl --fail-with-body --silent --show-error --request POST \
  'https://aicdapi.com/api/v1/data/snapshots' \
  -H "Authorization: Bearer $AICD_API_KEY"

Snapshot creation requires civic:export and consumes an export allowance. Preserve data.snapshotId and data.boundaryCursor, import every resource and page including aliases, then consume the change feed from that boundary with civic:read. The full resource enums and schemas belong in the OpenAPI document; the article does not assume a resource named contracts exists.

For records already identified by your integration, the batch endpoint retrieves current state. Replace this illustrative UUID with an actual record ID of the requested resource type:

curl --fail-with-body --silent --show-error --request POST \
  'https://aicdapi.com/api/v1/data/batch' \
  -H "Authorization: Bearer $AICD_API_KEY" \
  -H 'Content-Type: application/json' \
  --data '{
    "requests": [{
      "resource": "agenda_items",
      "ids": ["11111111-1111-4111-8111-111111111111"]
    }]
  }'

This call requires civic:read. The response contains data.items; missing and removed IDs are omitted, so compare the response with the requested set. The limit is 100 IDs across the entire batch, not 100 IDs per resource group. These customer endpoints are marked Limited availability.

Batch reads are for current state, not an amendment-history query. Preserve source-backed contract events in your own model and reconcile them when the underlying civic evidence changes.

Calculate a summary that can be inspected

Maintain separate measures for the count of verified initial awards, initial award ceilings, amendment increments, latest verified ceilings, and payments observed in a payment source. Label the scope and the measurement explicitly.

For a vendor profile, group only records whose entity match has been established. Similar company names, abbreviations, and trade names should remain review candidates until the evidence supports a connection.

Let the customer open the records behind an aggregate. A profile saying “three verified award records in the sources and period checked” gives them a defined claim to evaluate. “Leading supplier in the region” would require a different and much more complete evidentiary basis.

Make the first deliverable a research brief

Start with a small collection of reviewed procurements in one category. Produce a buyer brief or supplier profile that includes the relevant records, the relationships between them, the documented amounts, and the remaining research questions.

Ask a business-development user whether the brief helps them choose an agency, company, or project to investigate further. Track incorrect entity matches, duplicate procurements, unsupported amounts, and useful follow-up actions before adding predictive scores or expansive market claims.

The first product is a navigable account of what the checked records establish. Its advantage is that the customer can move from a business question to the underlying evidence without rebuilding the collection themselves.