Umay Ana / Agricultural Data Dictionary / Institutional API Specification v1
ENTERPRISE INTEGRATION · OPENAPI 3.1 · REFERENCE CONTRACT

Turn agricultural field intelligence into a versioned institutional API contract.

This is Umay Ana's proposed Institutional API Specification v1: a technical reference for how banks, insurers, reinsurers, MRV providers and green-finance partners could consume permissioned agricultural context without unrestricted access to the underlying farmer database.

Version 1.0.0-draft · OpenAPI 3.1 · Proposed reference specification · Not a live production API
Product boundary
The endpoints and hostname shown here define the proposed enterprise contract. They are not a live production API. The purpose is to let a technical partner review the data model, permissions, response boundaries and integration shape before a pilot is implemented.

Architecture principle

Farmer-facing workflows
Governance & consent
Normalized data dictionary
Partner-specific API contract
Institutional decision system

The institution receives only fields required for an agreed purpose. Raw identifiers are replaced with partner-specific pseudonymous references wherever practical. Precise farm location can be reduced to region or district when exact coordinates are unnecessary. AI-derived values carry source/version metadata and remain distinguishable from farmer-entered observations or independently verified evidence.

Proposed endpoints

POST/v1/partner-subject-mappings

Pseudonymous partner subject mapping with purpose + consent reference.

subject-map:write
GET/v1/farmer-context/{subjectRef}

Normalized crop, geography, season and field context.

farmer-context:read
GET/v1/field-signals

Crop, weather, plant-health, weekly-plan and sustainability signals.

field-signals:read
GET/v1/portfolios/{portfolioRef}/risk-context

Aggregated portfolio crop, region, coverage and field-risk context.

portfolio-risk:read
GET/v1/insurance/claims/{claimRef}/triage-context

Non-decisional claim-prioritization context.

insurance-triage:read
GET/v1/sustainability/{subjectRef}/evidence

Regenerative / Carbon Diary evidence.

sustainability:read
GET/v1/mrv/{subjectRef}/readiness

Methodology completeness and missing-field status; not certification.

mrv:read
GET/v1/metadata/data-dictionary

Dictionary version and download metadata.

metadata:read
GET/v1/metadata/taxonomies/{taxonomy}

Versioned crop, practice, evidence and signal taxonomies.

metadata:read

Authentication & authorization

The draft uses OAuth 2.0 Client Credentials as the proposed B2B authentication model. Each institutional client receives only the scopes required for its integration.

subject-map:writefarmer-context:readfield-signals:readportfolio-risk:readinsurance-triage:readsustainability:readmrv:readmetadata:read

Identity model: partner references, not raw PII

The primary external identifier is partnerSubjectRef. It should be pseudonymous. The reference specification instructs partners not to transmit email, phone, national ID or other raw PII through the mapping request.

{
  "partnerSubjectRef": "bank_farmer_123",
  "purpose": "credit_monitoring",
  "consentRef": "consent_contract_ref_001",
  "expiresAt": "2027-08-29T00:00:00Z"
}

Every response carries decision-boundary metadata

{
  "requestId": "req_01J...",
  "generatedAt": "2026-08-29T16:30:00Z",
  "apiVersion": "1.0.0-draft",
  "dataAsOf": "2026-08-29T16:00:00Z",
  "dataCoverage": 0.72,
  "qualityStatus": "medium",
  "decisionBoundary": "Contextual decision support only. This response must not be used as the sole basis for automatic credit approval/rejection, claim approval/rejection, underwriting, carbon certification or another high-impact institutional decision."
}

Banking example — farmer context

GET/v1/farmer-context/{subjectRef} returns purpose-specific agricultural context. It does not return a credit score.

{
  "subjectRef": "bank_farmer_123",
  "context": {
    "location": {
      "countryCode": "TR",
      "region": "Konya",
      "district": "Cihanbeyli",
      "locationPrecision": "district",
      "parcelRef": null
    },
    "crop": {
      "crop": "wheat",
      "cropType": "annual_field_crop",
      "seasonStage": "planting",
      "plantingWindow": "2026-10-15/2026-11-15",
      "harvestEstimate": "2027-07"
    },
    "weatherExposure": "normal",
    "fieldRiskTrend": "stable",
    "sustainabilityEvidenceCompleteness": 0.75
  },
  "meta": {
    "requestId": "req_01J...",
    "generatedAt": "2026-08-29T16:30:00Z",
    "apiVersion": "1.0.0-draft",
    "dataAsOf": "2026-08-29T16:00:00Z",
    "dataCoverage": 0.72,
    "qualityStatus": "medium",
    "decisionBoundary": "Context only \u2014 not an automated credit decision."
  }
}

Portfolio risk context

The portfolio endpoint is aggregated. It answers where crop concentration is high, what proportion has field-data coverage and where field-risk signals are changing rather than exposing raw app conversations.

{
  "portfolioRef": "bank_agri_portfolio_01",
  "summary": {
    "subjects": 50000,
    "dataCoverage": 0.64,
    "cropConcentration": [
      {
        "crop": "wheat",
        "share": 0.31
      },
      {
        "crop": "cotton",
        "share": 0.18
      }
    ],
    "regionalSignals": [
      {
        "region": "region_A",
        "signal": "heat_watch",
        "trend": "rising",
        "coverage": 0.71
      }
    ]
  },
  "decisionBoundary": "Descriptive portfolio context; not a regulated credit rating."
}

Insurance example — claim triage context

Claim triage is deliberately non-decisional. The reference schema fixes automaticDecision to false.

{
  "claimRef": "claim_abc123",
  "triageContext": {
    "recommendedAction": "additional_evidence_needed",
    "weatherContext": "heat event in claim window",
    "fieldObservationCount": 3,
    "evidenceCoverage": 0.68,
    "automaticDecision": false
  },
  "meta": {
    "requestId": "req_01J...",
    "generatedAt": "2026-08-29T16:30:00Z",
    "apiVersion": "1.0.0-draft",
    "dataCoverage": 0.68,
    "qualityStatus": "medium",
    "decisionBoundary": "Triage support only; policy wording and formal claims process remain authoritative."
  }
}

MRV example — readiness, not certification

The MRV endpoint measures data readiness against a selected methodology. It can identify missing evidence; it cannot declare a carbon outcome certified.

{
  "subjectRef": "green_farm_456",
  "readiness": {
    "status": "partial",
    "completeness": 0.78,
    "methodologyId": "partner_methodology_example",
    "methodologyVersion": "v1",
    "missingFields": [
      "baseline_reference",
      "soil_measurement_reference"
    ],
    "externalValidationRequired": true
  },
  "meta": {
    "requestId": "req_01J...",
    "generatedAt": "2026-08-29T16:30:00Z",
    "apiVersion": "1.0.0-draft",
    "dataCoverage": 0.81,
    "qualityStatus": "medium",
    "decisionBoundary": "MRV readiness only; not carbon quantification or certification."
  }
}

Field signals: the common event layer

/v1/field-signals can filter by subject, crop, region, signal type and time. Each signal carries evidence metadata distinguishing farmer-entered, AI-derived, external and verified sources.

Pagination, traceability and rate control

ElementV1 approachPurpose
PaginationOpaque cursor; max 500 records/page.Stable large-portfolio iteration.
Trace IDX-Request-Id + returned requestId.Audit/support/reproducibility.
As-of timeOptional asOf.Historical snapshots where retention permits.
Source versionModel/taxonomy version retained.Historical interpretability.
429Explicit rate-limit response.Protect shared B2B infrastructure.
Purpose enforcementOAuth scope + partner purpose + consent reference.Purpose limitation.

Error model

{
  "code": "purpose_not_permitted",
  "message": "Requested data is not permitted for this partner purpose.",
  "requestId": "req_01J...",
  "details": {
    "requiredScope": "mrv:read"
  }
}

Proposed webhook events

field_signal.createdfield_signal.updatedrisk_cluster.changedsustainability_evidence.updatedmrv_readiness.changed

The draft proposes HMAC-SHA256 signing, idempotent event IDs and controlled retries. These are architecture targets, not active webhooks.

Versioning policy

The proposed contract is path-versioned at /v1. Additive fields may remain in v1; breaking semantic changes should require a new API version or documented compatibility period.

Relationship to the Agricultural Data Dictionary

The Agricultural Data Dictionary defines field meaning, source, status, sensitivity and use boundaries. The API defines who may receive which subset, under which purpose, through which endpoint.

Data dictionary = what a field means.

Institutional API = who may receive which fields, through which endpoint, under which purpose, with which quality and decision boundaries.

DOWNLOADABLE TECHNICAL ASSETS

Give the contract directly to an integration team.

RELATED INSTITUTIONAL ASSETS

API contract, semantics and business use cases now connect.

From “we have agricultural data” to “here is the contract your systems can integrate.”

The specification turns Umay Ana's institutional vision into a reviewable interface for pilot discussions.