Skip to main content

Factor Freshness

Factor freshness is market-calendar-aware. A response is not current just because it was served quickly; it is current when the relevant source session, materialized rows, and response metadata agree.
SEC API factor workflows use different freshness clocks for daily, intraday, and portfolio-derived data. Always inspect freshness, materialization, and degradedState before making customer-visible recency claims.

Freshness Clocks

SurfaceFreshness clockLaunch expectation
Factor catalogCatalog version and release metadataStable unless factor definitions change.
Daily factor returnsLast complete U.S. market session for the requested factor setCurrent after the daily factor materialization completes for the last complete market day.
Factor history and sparklinesRow-level daily return coverage for the requested factor and rangerange=max should only be claimed to the proven row-level floor for that factor.
Intraday factor returnsSnapshot timestamp and current market-data inputsCurrent only when underlying market-data inputs are current during market hours.
Factor exposuresLatest exposure model session and source factor-return sessionCurrent when exposure rows and their source return windows are current.
Valuations and valuation stocksFactor-return z-score session plus latest exposure session for stock drilldownsCurrent when both factor-side and exposure-side inputs are current.
Portfolio attributionSubmitted holdings, factor exposures, factor returns, and holding market barsPartial if any material input is missing or stale.
Portfolio hedgeSubmitted holdings, factor exposures, hedge constraints, and candidate mappingsPartial if exposures or candidate mappings are unavailable.

Market-Calendar Policy

Daily factor data is measured against the last complete market session, not wall-clock midnight. Weekends and market holidays do not create missing daily factor rows. Early closes and delayed data-plane jobs should produce explicit stale or degraded metadata rather than false freshness. For launch-readiness and customer-facing claims:
  • make 2010+ history claims only for factors with row-level proof
  • check historyStartDate, historyEndDate, observationCount, and lastCompleteMarketDate when present
  • treat stale materialization as a launch blocker for marketed freshness promises
  • treat intraday data as current only when the snapshot and market-data plane are current

Compact Requests With Trust Metadata

Use compact mode for agent and chart workflows, then request trust metadata when recency matters:
curl -H "x-api-key: $SECAPI_API_KEY" \
  -H "secapi-version: 2026-03-19" \
  "https://api.secapi.ai/v1/factors/history/VALUE?range=1y&response_mode=compact&include=trust"
MCP tools accept the same intent:
{
  "name": "factors.history",
  "arguments": {
    "factorKey": "VALUE",
    "range": "1y",
    "response_mode": "compact",
    "include": ["trust"]
  }
}

Reading Freshness Fields

FieldMeaning
freshness.statusCurrent state such as fresh, stale, degraded, or unknown.
freshness.asOfThe timestamp or session the response is current as of.
freshness.sourcePublishedAtThe source-side publish or session timestamp when available.
freshness.lagMsMeasured lag between source time and available response time when applicable.
materialization.materializationVersionRead-model or computation version used to produce the response.
degradedStateStructured explanation for partial, stale, or fallback behavior.
Field availability varies by response type and response mode. Use include=trust if an agent must preserve the full trust envelope.

Operational Interpretation

Response stateWhat to do
Fresh with matching materializationSafe for normal product and agent workflows.
Fresh but missing requested history floorDo not claim MAX or 2010+ coverage for that factor.
Stale daily factor returnsShow stale status, avoid launch freshness claims, and wait for or repair the data-plane materialization.
Stale intraday snapshotsAvoid live-market language; use the last complete daily surface instead.
Degraded portfolio attributionShow partial attribution and preserve missing capabilities.
Explicit materialization errorTreat as retryable only if the error details say the missing read model can be repaired or rerun.

Next Pages