Dated profile fact cards connect to separate judgment and review cards.
Keep source facts separate from derived judgments.

The X Profile public build 1.0.4 Actor accepts a `profiles` array of known public profile URLs or handles only. It contains no parameters for discovery, posts, history, language, or `maxItems`.

The public saved Task preset includes sample profiles (`OpenAI`, `NASA`, `elonmusk`). Before running a check, replace the entire `profiles` sample list with your single intended target profile rather than running `OpenAI` as a sample.

Native row fields include: `input`, `profileId`, `profileUrl`, `handle`, `displayName`, `biography`, `website`, `location`, `followersCount`, `profileMetricStatus`, `status`, `failureCategory`, `statusReason`, and `observedAt`.

In a single-profile control run for the OpenAI profile ID, the check succeeded with biography present, website present, exact follower counts available, and location missing. The run output summary reported:

  • `inputCount`: 1
  • `datasetRows`: 1
  • `usefulRows`: 1
  • `billableRows`: 1
  • `failedRows`: 0
  • `statusCounts`: `{"ok": 1}`
  • `stopReason`: `inputs_exhausted`

The native `profileMetricStatus` field is an object mapping individual metrics to `exact` or `unavailable` precision values. This control proves source data retrieval only. It does not perform memory persistence, account identity history, topic expertise verification, or large-roster throughput analysis.

Steps to manage profile memory

  1. Declare your specific research question and profile purpose before choosing one known public profile URL or handle. Do not use discovery, history, or max items since the profile builder accepts specific handles or URLs only.
  2. Run your Task with input replacing the entire saved sample list with your single intended reader target profile, using an explicit placeholder such as `{"profiles": ["https://x.com/YOUR_TARGET_PROFILE"]}` rather than running a dummy sample.
  3. Save the native row as a dated fact observation. Add a local observation id, the Actor build reference, and collection results. Keep profileId and observedAt with their original values.
  4. Create a separate judgment record with a local judgment id, your question, a rule version, and evidence references. Each reference points to an observation id and field path like biography.
  5. Write narrow interpretations that match only the exact source text. Do not let follower counts act as proof of expertise.
  6. Append a new native observation at the next session instead of overwriting old data. Check that the account identity matches before you compare facts.
  7. Check each judgment dependency. If a required field changes, mark the judgment as needs review. If a refresh fails, mark fresh support unavailable instead of copying old text.
  8. Give your next agent session a small package of current facts, supported judgments, and missing gaps. Trace every decision back to its source field.

Worked example of profile tracking

All following example records are original fiction.

Observation O1 for profileId P100 has biography "I build Python data tools," website https://cedar.example, and source status ok. Judgment J1 under rule R1 says stated bio fit is yes for Python data tooling. Its evidence reference points to O1 biography. Its unknowns state that actual posts and expertise were not checked.

At the second check, observation O2 has the same profileId, biography "I make garden videos," and the same website. J1 biography dependency changed, so we mark it needs review. A revised judgment J2 says current stated bio fit is no under rule R1, linked to O2 biography. We keep J1 as historical at O1. The unchanged website does not rescue a topic judgment that depended on different text.

At the third check, the source refresh fails and the biography is unavailable. We save O3 actual failure outcome and time, and mark fresh support unavailable. We do not copy O2 bio into O3 as if observed now. Judgment J2 stays a past supported interpretation, not a fresh finding.

The following three immutable observation records and two dependent judgment records are original fiction.

Fact Observations (Immutable Source Logs)

Worked example of profile tracking
Observation IDTarget ReferenceNative `profileId``observedAt`Native Bio / FieldsNative Outcome / Status
`O1``https://x.com/user_p100``P100``2026-10-10T10:00:00Z``biography`: "I build Python data tools."<br>`website`: "https://cedar.example"`status`: "ok"<br>`failureCategory`: null
`O2``https://x.com/user_p100``P100``2026-10-11T10:00:00Z``biography`: "I make garden videos."<br>`website`: "https://cedar.example"`status`: "ok"<br>`failureCategory`: null
`O3`Target target Ref: `P100``unknown``2026-10-12T10:00:00Z``biography`: `unknown`<br>`website`: `unknown``status`: "failed"<br>`failureCategory`: "rate_limit"

*Note: In `O3`, old `P100` native identity or bio values are never copied into the failed observation. The target handle reference is kept separately while native fields remain `unknown`.*

Dependent Judgments (Agent Memory Records)

#### Judgment `J1` (Initial Session)

  • Judgment ID: `J1`
  • Question: Does this profile claim Python data tooling focus?
  • Decision: `stated_bio_fit = yes`
  • Rule Version: `R1`
  • Evidence References: `O1.biography`
  • State: `historical_at_O1` (originally `supported`)
  • Unknowns: Actual posts and verified topic expertise were not checked.
  • Review Time: `2026-10-10T10:05:00Z`
  • Reason: Initial evaluation against `O1.biography`.

#### Judgment `J2` (Follow-up Session & Failed Refresh)

  • Judgment ID: `J2`
  • Question: Does this profile claim Python data tooling focus?
  • Decision: `current_stated_bio_fit = no`
  • Rule Version: `R1`
  • Evidence References: `O2.biography`
  • State: `fresh_support_unavailable` (Transitioned from `supported` at `O2` to `fresh_support_unavailable` after `O3` failure)
  • Unknowns: Current profile state is unknown due to `O3` refresh failure. Posts remain unchecked.
  • Review Time: `2026-10-12T10:01:00Z`
  • Reason: `O2.biography` changed text to garden videos, invalidating `J1` and creating `J2`. When `O3` failed, fresh support became unavailable; previous support was preserved as `historical_at_O2`. Unchanged `website` field does not renew the altered `biography` dependency.

Sources & further reading

By Chronometrica · Updated

Back to top ↑