Asset Data Release Notes

Release date: September 2026

Two changes to what JupiterOne stores on your assets and how you reach it. Your queries, your integrations, and the asset inspector all work the way they did — but free-text search now covers a deliberately narrower set of values, and raw data is retrieved on demand rather than from a stored copy. Both are worth knowing about.

What is new

Change	What it means for you
Free-text search indexes human-readable values	FIND "..." searches the values a person would type. JSON documents, true/false, and epoch-millisecond timestamps are no longer indexed — the properties are unchanged and still queryable directly
Searching object no longer matches everything	Assets carrying an object-valued property used to match a free-text search for object. They no longer do
Long assets are more findable	The search index has a size limit. Assets that used to overflow it now fit more of their content, so more of their text is reachable
Asset updates are more stable	An upstream API returning the same values in a different order no longer produces a change to your asset
Raw data is served from the ingestion pipeline	Raw data is fetched on demand from the sync job that produced it. Same inspector tab, same API field, same content
Raw data covers your recent syncs	Raw data is available for assets whose integration has synced in the last 7 days. Beyond that it reports as unavailable

---

Free-text search indexes human-readable values

A free-text search — FIND "10.0.0.1", or the equivalent _text ~= "10.0.0.1" filter — matches against an index JupiterOne builds from your asset's property values. That index now carries the values a person would actually search for and skips three kinds of value that were being carried on every asset without ever being a useful match.

Serialized JSON documents are no longer indexed

Many integrations present a property as a JSON document — policyDocument, ingressRules, eventPattern, parameters, routes, principal. Indexed verbatim, the document's structure became searchable text, so every asset holding an IAM policy matched a global search for statement, effect, or resource.

The properties themselves are untouched. They are still on the asset, still returned in query results, still shown in the inspector, and still searchable with a filter on the property itself:

FIND aws_iam_role WITH policyDocument ~= "s3:getobject"

caution

This is the one change here that narrows what a free-text search can find. Values that only ever appeared inside a JSON document — an IAM action like sts:assumerole, a CIDR like 0.0.0.0/0 buried in a security group rule — are no longer reachable with a bare FIND "...". Filter on the property that holds them, as above, or use regular expressions for more advanced matching.

If you have saved questions, alert rules, or dashboard filters that free-text search for a value found only inside a JSON property, rewrite them as a property filter.

A value is treated as a JSON document only if it actually parses as a JSON object or array. A description that merely opens with a bracket — [CRITICAL] disk full — is indexed as the string it is.

Booleans and epoch timestamps are no longer indexed

• Booleans. true recorded only that some property somewhere on the asset was set. It identified nothing, and it made every asset carrying any boolean match a search for true. Filter on the property instead: FIND Host WITH public = true.
• Epoch-millisecond timestamps. Nobody types 1789430400000. Where an integration means a date to be searchable it also emits it as a formatted string, and that string is unaffected.

Only timestamp-shaped integers are withdrawn. Ports, severities, counts, versions, and numeric IDs are numbers you might plausibly search for, and they are all still indexed. The string "true" is still indexed — it is a string value an integration chose to present as text.

Changes that do not affect what matches

Three further changes have no effect on your search results:

• Duplicate coverage is dropped. A value that appears in full inside another value on the same asset is no longer carried twice. A free-text search is a "contains" match, so any needle found in the dropped value is still found in the one that contained it.
• Unsearchable values are dropped. Empty values, and the placeholder [object object] that any object stringifies to, are gone. This is the fix for a global search for object matching every asset with an object-valued property.
• The index is sorted. The order values are stored in is now stable, so an integration that returns the same data in a different order no longer registers as a change to the asset.

Assets with a lot of text are more findable

The search index has a per-asset size limit. Assets that exceeded it — typically large policy or configuration assets — had their content cut off at the limit, and anything past the cut was unsearchable. Because the index now carries less redundant and machine-readable content, more of those assets fit inside the limit, and more of their text is reachable than before.

When you will see this

The index is rebuilt for an asset the next time that asset changes and is re-ingested. There is no bulk rewrite, so the change appears across your account as your integrations run their normal syncs.

---

Raw data is served from the ingestion pipeline

Raw data — the unmodified payload the source system returned, shown in the asset inspector and available through the API — is now fetched on demand from the sync job that produced it, rather than read from a copy held alongside the asset.

Nothing changes about how you access it. The same inspector tab, the same API field, and the same content: the payload you get back is identical to what was returned before.

Raw data covers your recent syncs

Raw data is retained for 7 days from the sync job that uploaded it. In practice this covers any integration on a normal schedule — an integration syncing daily or more often always has raw data available for the assets in its most recent run.

Where you will notice the difference:

• Dormant integrations. If an integration has not run in more than 7 days, raw data for its assets reports as unavailable rather than returning the older payload. Running the integration restores it.
• Assets not in the most recent run. Raw data comes from an integration's most recent sync. If a run did not include a particular asset — a partial dataset, for example — raw data for that asset may report as unavailable until a run covers it again.

In both cases the asset itself, and all of its properties, are unaffected. Only the raw data payload is unavailable.

info

Raw data is a record of what a source system sent, not a store of record. If you need a durable copy of a source payload, export it or retain it at the source.

Retrieval takes slightly longer

Fetching raw data now reads from the ingestion pipeline's storage rather than from the graph, which adds a small amount of latency to the first retrieval. For interactive use in the inspector this is not noticeable. If you retrieve raw data in bulk through the API, expect modestly longer per-asset retrieval times.