Start here

To find an evidenced office or business site in a city, use search version 0.2.0. For example, combine Azure/Entra penetration testing with a Herlev business location:

{"search_version":"0.2.0","response_detail":"compact","limit":5,"confirmed_only":false,"include_partial":true,"requirements":[{"criterion_id":"capability.specialization.azure_entra_penetration_testing","dimension":"capability","value":"azure_entra_penetration_testing","importance":"hard"},{"criterion_id":"business_location.city.Herlev","dimension":"business_location","country_code":"DK","city":"Herlev","importance":"hard"}]}

POST this body to /v0.2.0/search or use it as the arguments to MCP search_candidates. A match supports the business location stated by the source. It does not establish where a service is delivered, which staff work there, price or availability.

Use service_geography for service coverage instead. Replacing the location criterion with {"criterion_id":"service_geography.DK","dimension":"service_geography","country_code":"DK","importance":"hard"} asks a different question. An office never confirms that coverage.

City matching ignores letter case and normalizes Unicode, but does not translate names: use København for Copenhagen. City and country must match together. Region, municipality, island, map and radius filters are not supported. Where available, administrative context is returned separately as an inference from the business locality and an official hierarchy; it does not establish service coverage. Unsupported areas are reported explicitly; an unconfirmed city does not prove a provider is absent.

Location results include a location_claim with location type (which may be unknown for a supported contact locality), claim class, source references, observation time and extraction metadata. Optional administrative_claims give municipality and region fields, each labelled inferred with its own source references and time. These fields do not make a location or service-area filter match. Set response_detail: full to read the embedded location and mapping source summaries and qualifications. Optional business_locations profile records can include source-qualified postcode, municipality, official contact page and a precise business address when supported. An address never establishes customer visits; these require a separate claim. Missing precision is not a failed match. Retained cyber profiles expose location evidence through search without changing their profile projections. VVS profiles also preserve the original site claims and roles in the optional vvs_research extension. Do not look for these location references in the legacy profile sources.

Search versions 0.1.0 and 0.2.0 accept 1–8 requirements and at least one hard requirement. All hard criteria are AND. For an OR task, search each branch separately and combine canonical IDs while retaining each branch's evidence; do not turn OR into AND.

• Exact specializations: azure_entra_penetration_testing and iso_27001_consulting, with criterion IDs capability.specialization.VALUE; omit taxonomy fields.
• Broad capabilities: strategy_risk_compliance, assessment_testing, managed_detection_response, incident_response_forensics, security_engineering, awareness_training, resilience_recovery, threat_intelligence. Use capability.taxonomy.VALUE, dimension: capability, taxonomy_id: frontierbeacon.taxonomy.cybersecurity_services and taxonomy_version: 0.1.0. Broad assessment is not proof of pentest methodology; security engineering is not Azure/Entra proof.
• Experience: experience.regulation.nis2 with experience_kind: regulation, value: nis2; or experience.sector.financial_services with experience_kind: sector, value: financial_services. Both use dimension: experience.
• Service geography: dimension: service_geography, country_code: DK, optional subdivision_code: DK-84 (Capital Region) or DK-85 (Region Zealand, not the whole island). Criterion ID is service_geography.DK or the subdivision. Registered presence and offices do not prove coverage.
• Price and availability are not supported filters or promises. Any dated advertised offer remains qualified in its profile.

Set confirmed_only: false and include_partial: true together to receive qualified alternatives. Use the same as_of clock across comparisons. A future read past next_review_at moves stale profiles into review; it does not renew source support.

Use search version 0.2.0, taxonomy frontierbeacon.taxonomy.transport_services version 0.1.0. For pallets use criterion_id: capability.taxonomy.transport.pallet_groupage, dimension: capability, value: transport.pallet_groupage and importance: hard. Add transport.tail_lift as a second capability requirement for unloading equipment.

Capabilities: transport.road_freight, transport.freight_forwarding, transport.pallet_groupage, transport.ftl, transport.part_load, transport.temperature_controlled, transport.refrigerated, transport.frozen, transport.dangerous_goods, transport.special_oversized, transport.machinery, transport.tank_silo, transport.tail_lift, transport.warehousing, transport.bulk.

An explicit current service exclusion is returned as not_offered with its evidence; missing evidence remains unknown. For ADR not required, omit the dangerous-goods requirement; providers offering ADR remain eligible. For ADR required, dangerous-goods service evidence does not establish classes, permits or shipment suitability. Generic temperature control proves neither frozen carriage nor a numerical temperature range.

Use exact delivery_model or service_territory values from transport_research, with criterion IDs DIMENSION.VALUE. Roles such as carrier, carrier_and_network and forwarder_and_network are distinct. Territories are company statements, not confirmed route pairs; cargo-specific territory remains qualified and cannot satisfy a general route request. No country expansion from Europe or office locations.

Set confirmed_only: false and include_partial: true for partial alternatives. Frigoscandia and Lauritzen have partial cold-service evidence; reasons and related sources remain visible. Temperature ranges, cargo suitability, current permits, price, departures and capacity are not supported filters and require provider confirmation. The 996 transport profiles contain company statements and attributed public reporting; legal identity does not verify website ownership or delivery.

Use search version 0.2.0 with taxonomy_id: vvs and taxonomy_version: 0.5.0 (the semver representation of Research taxonomy 0.5). For heat pumps, use criterion_id: capability.taxonomy.vvs.heat_pumps, dimension: capability, value: vvs.heat_pumps and importance: hard.

Combine that with an evidenced city, or exact customer_type, specialism, problem_type, delivery_model and service_territory values. For these five dimensions, criterion IDs are DIMENSION.VALUE. Values are Unicode-normalized and case-insensitive; they are not expanded into synonyms or larger regions. Read the profile’s vvs_research fields for the available source-specific values, site IDs, roles and qualifications.

For example, customer_type.housing_organizations requires its own customer evidence. service_territory.Møn requires a stated service territory and never implies a Møn business location. Unknown city does not prevent a capability match. Optional claim_class: registry_verified requires exactly that class; it will not accept company statements. Inferred municipality/island, authorization, guarantees and numeric prices are not supported filters.

The 189 VVS profiles have company-stated services. Legal identity is registry-supported where evidence is present; website associations remain inferred where indicated. Official VVS service authorization remains unknown. A displayed company name does not establish a legal name. The original attributed fields and source qualifications are retained in vvs_research. VVS profiles cannot be represented by the cyber-only 0.1.0 contract; a mixed bulk export requested as 0.1.0 returns version_not_representable. Individual retained cyber projections remain available.

record_origin distinguishes real records and fixtures. source_class identifies the actual source class. The required legacy simulates_source_class field is meaningful for local_synthetic fixtures only; real records may repeat their actual class there for compatibility. That repeated value does not make a real source synthetic.

registry_verified establishes identity, not delivery. source_observed records a source observation; business_claimed attributes a provider statement without independent verification. inferred remains an inference; unknown is unanswered. Retrieval, claim observation and review times have different meanings. Source text retains direct/partner qualifications.

Profile contract 0.2.0 preserves a 0.1.0 projection where representable. Invalid requests return 400, missing profiles 404, unsupported versions 409. Search failures retain machine error codes. Correct the request using OpenAPI rather than guessing routes.