How GhostPost observes.

GhostPost sits between public job-board sources (an employer's verified Greenhouse, Lever, or Ashby account, or the employer's own careers page) and the downstream system that consumes the evidence. It is read-only middleware: it normalizes, timestamps, and sources public evidence so a consuming platform can trust it without re-deriving it.

It is deliberately not a workflow, remediation, or compliance-certification system. It does not pull data down, run a cure clock, assign owners, or track resolution status. Those belong to the system on top.

• Each observation is filed under a verified employer identity — a provider (Greenhouse, Lever, Ashby, or the employer's own domain) plus that account. A board timeline is never silently merged with a careers-page timeline.
• Every line in the record carries an observation timestamp and the source URL it came from.
• Observations happen two ways: a user-initiated scan (an investigative entry point) and a scheduled re-observation that re-reads sources already in the record. Scheduled looks consume no scan allowance and write no charge row — the record deepens on its own clock.
• Each employer is isolated. One source being unreachable never fails the batch and never becomes evidence of anything.

A source that could not be read is reported as unread — never as an absence of postings and never as a disappearance. Disappearance is recorded only when a source was genuinely read on a later look and no longer lists the posting. This distinction is the whole point of keeping the attempt log.

The Monitor layer (/coverage) exposes every recorded attempt, including blocked or unreachable sources, so a reader can see what GhostPost tried, not just what it found.

GhostPost is non-judgmental by construction. It never automatically labels a posting as a ghost job, fraudulent, deceptive, illegal, non-compliant, or a violation. Every evidence line resolves to exactly three states:

• Observed — a source GhostPost successfully read showed this, at a recorded time.
• Stated absent — the source was read and stated nothing on this point.
• Can’t determine — the available evidence does not settle the question.

Source readability is a separate axis, not a fourth state: a source that could not be read is recorded as unread, and a requirement record is surfaced as a record with its citation and jurisdiction.

Whether a requirement applies to a given employer is not something GhostPost decides.

• Determine whether an organization is compliant
• Determine whether a law or requirement applies
• Declare a violation, or that anyone is liable
• Provide legal advice or legal opinions
• Assign severity or risk
• Produce a score of any kind — no composite score, no 0–100, no letter grade, no ranking
• Assign, track, or execute remediation
• Track resolution or assign owners
• Remove postings or send takedown demands
• Run notice-to-cure clocks or enforce requirements

GhostPost observes and documents. Qualified professionals and the systems an organization already runs decide what the evidence means and what happens next.

The read-only Record API (/api/public/v1) exposes four layers:

• Monitor — every recorded attempt to read a source, and its outcome.
• Watch — what changed between observations, filterable with ?since=ISO8601 for a dated delta.
• Requirements — records that exist for named jurisdictions.
• Evidence — the timestamped, sourced observation history.

Every endpoint is a read, key-authenticated and scoped to the caller's own workspace. No endpoint writes, charges, or mutates the record.