Licensed LatAm Job Export Normalizer

Turn a structured job export you are allowed to use into clean, provenance-linked records for review, routing, and reconciliation. This Actor accepts buyer-owned, employer-authorized, ATS-authorized, or otherwise licensed job data. It does not visit Computrabajo, scrape job boards, log in to a recruiting system, or verify that a vacancy is still open.

The historical Store slug is computrabajo-jobs. The current product is a zero-network normalizer, not a Computrabajo crawler and not an affiliated Computrabajo service. Legacy country:query inputs remain API-compatible: they produce a free migration diagnostic instead of contacting the old source.

What you get

For each valid, unique licensed job record, the Actor delivers one Dataset row containing:

• the familiar job fields: title, company, rating when supplied, location, posting time, URL, and processing time;
• a stable job identity derived from the supplied source name and source job ID;
• a deterministic input digest and a row digest for change-safe downstream processing;
• explicit source name, source URL, licence statement, retrieval timestamp, and changes made;
• freshness calculated from the buyer-supplied source retrieval timestamp;
• an evidence confidence score with concrete gaps rather than an unsupported accuracy claim;
• a human-review summary, priority, recommended action, and safeToAutomate: false boundary;
• settlement-neutral billing metadata in the Dataset row;
• authoritative current-run delivery and charge reconciliation in KVS OUTPUT.

The Actor deliberately separates three questions that are often blurred together:

1. Was the supplied record structurally valid? The closed input contract answers this.
2. Was a normalized row written to the current Dataset? The current-run receipt answers this.
3. Was one result-found event confirmed for that row? The named-event counter delta in OUTPUT answers this.

It does not claim that the job is genuine, open, approved by the employer, suitable for a candidate, or lawful for every downstream purpose. Those are review decisions outside this normalization step.

Who uses it

Recruiting operations teams

Normalize exports from employer ATS systems, internal recruiting databases, approved partners, or licensed feeds before moving records into a shared review queue. Stable IDs and provenance fields make it easier to trace where each row came from.

Job-data vendors

Convert an authorized regional feed into one consistent Dataset contract while preserving the source licence statement and changes made. The Actor does not expand the rights granted by the original source.

Automation engineers

Use deterministic identities, digests, explicit failure rows, and a current-run KVS receipt instead of inferring success from process exit alone.

Data governance and compliance reviewers

Inspect the source context, source URL, licence text, retrieval time, transformations, gaps, human-review action, and billing intent in one row.

Analysts and operations managers

Route fresh and stale exports differently, quantify invalid and duplicate inputs, and distinguish delivered paid records from free diagnostics or withheld work.

What it does not do

• It does not call Computrabajo or any other job board.
• It does not fetch the recorded job URL or source URL.
• It does not log in to an ATS, CRM, employer portal, or job board.
• It does not bypass robots rules, access controls, paywalls, or rate limits.
• It does not verify employer identity, vacancy status, salary, location, or employment terms.
• It does not enrich people, candidates, recruiters, or companies.
• It does not infer protected characteristics, suitability, employability, or hiring outcomes.
• It does not send applications, messages, emails, or webhooks.
• It does not make a hiring decision or rank candidates.
• It does not make the Dataset billing metadata authoritative for settlement; KVS OUTPUT is authoritative.

How the workflow works

1. Rights confirmation — you select the source-rights context and confirm that you may process and commercially use the supplied records.
2. Closed-schema validation — unknown fields, invalid types, malformed URLs, impossible timestamps, control characters, and out-of-range values are rejected from paid work.
3. Identity deduplication — valid records are deduplicated by case-insensitive sourceName + sourceJobId before billing.
4. Evidence construction — the Actor builds stable IDs, digests, freshness, confidence gaps, provenance, and a human-review decision boundary.
5. Atomic delivery intent — each eligible row is sent through one linked pushData(row, 'result-found') operation.
6. Settlement verification — the Actor proves the named result-found counter moved by exactly +1 and checks the aggregate receipt.
7. Terminal reconciliation — KVS OUTPUT records requested, unique, duplicate, invalid, attempted, successful, failed, delivered, paid, free, withheld, unknown, partial, budget, fatal, and replay facts.

No source network request occurs anywhere in that sequence.

How to run

Open the Actor, keep the default contract version, confirm the rights statement, choose the source context, and paste one to 100 structured job records into jobs.

Minimal modern input:

{
  "schemaVersion": "2.0",
  "authorization": "I confirm I may process and commercially use these job records.",
  "sourceContext": "employer_authorized_export",
  "batchName": "latam-sales-review",
  "freshnessHours": 168,
  "jobs": [
    {
      "sourceCountry": "mx",
      "sourceQuery": "ventas",
      "sourceJobId": "demo-sales-001",
      "title": "Account Executive",
      "company": "Example Employer SA de CV",
      "companyRating": null,
      "location": "Ciudad de México",
      "postedAt": "2026-08-12T09:00:00.000Z",
      "url": "https://careers.example.com/jobs/demo-sales-001",
      "employmentType": "Full-time",
      "descriptionSnippet": "Buyer-supplied summary of the role.",
      "sourceName": "Example employer ATS export",
      "sourceUrl": "https://careers.example.com/exports/jobs",
      "sourceLicense": "Employer-authorized export for recruiting operations.",
      "sourceRetrievedAt": "2026-08-12T10:00:00.000Z",
      "changesMade": "Selected fields and normalized whitespace."
    }
  ]
}

The sample domains and employer are placeholders. Replace them with data and provenance you are authorized to submit.

Input contract

The root object is closed. Unknown properties fail before Dataset delivery. Use exactly one input mode.

Modern licensed-export mode

Required root fields:

Field	Type	Meaning
schemaVersion	string	Must be 2.0.
authorization	closed string	Exact confirmation that you may process and commercially use the records.
sourceContext	enum	Rights context for the supplied export.
jobs	array	One to 100 structured job records.

Optional root fields:

Field	Bounds	Default	Meaning
batchName	1–80 nonblank characters	licensed-job-evidence-review	Human-readable review batch label.
freshnessHours	1–8,760 integer	168	Threshold applied to the supplied sourceRetrievedAt.

Allowed sourceContext values:

• buyer_owned_job_export
• employer_authorized_export
• ats_authorized_export
• other_licensed_job_export

The selection is a buyer assertion, not an independent legal determination by the Actor.

Job record fields

Field	Required	Contract
sourceCountry	yes	mx, co, cl, ar, pe, or other.
sourceQuery	no	Nullable nonblank text, maximum 200 characters.
sourceJobId	yes	Nonblank source identity, maximum 200 characters, no control characters.
title	yes	Nonblank supplied title, maximum 300 characters.
company	no	Nullable supplied company name, maximum 200 characters.
companyRating	no	Nullable finite number from 0 through 5.
location	no	Nullable supplied location, maximum 300 characters.
postedAt	no	Nullable calendar-valid UTC timestamp ending in Z.
url	no	Nullable HTTPS URL without credentials, explicit port, or fragment. It is recorded, never fetched.
employmentType	no	Nullable supplied label, maximum 100 characters.
descriptionSnippet	no	Nullable buyer-supplied snippet, maximum 1,000 characters.
sourceName	yes	Nonblank name of the export or licensed feed, maximum 200 characters.
sourceUrl	yes	HTTPS provenance URL without credentials, explicit port, or fragment. It is recorded, never fetched.
sourceLicense	yes	Nonblank licence or authorization statement, maximum 700 characters.
sourceRetrievedAt	yes	Calendar-valid UTC timestamp for when the buyer or authorized provider obtained the source record.
changesMade	yes	Nonblank description of selection, normalization, truncation, or other transformation, maximum 500 characters.

Whitespace is normalized. URL hostnames are lowercased by the URL parser. The Actor does not resolve DNS, open a socket, or assert that an HTTPS URL is safe, reachable, official, or controlled by the stated entity.

Legacy migration mode

The historical input remains accepted:

{
  "items": ["mx:ventas", "co:desarrollador"],
  "maxConcurrency": 1
}

In this mode:

• no Computrabajo or other source request is made;
• raw query strings are not copied into KVS OUTPUT;
• no result-found event is intentionally emitted;
• one free migration diagnostic explains how to use jobs;
• the terminal receipt marks the run partial because it delivered a diagnostic, not a normalized job result.

maxConcurrency is retained for input compatibility but is not used by the zero-network workflow.

Happy, partial, and failure output

The release gate uses these concise acceptance wrappers. They bind the current run and immutable build; they are verification evidence, not extra Dataset or OUTPUT fields.

{
  "runId": "example-current-run",
  "buildId": "candidate-build-id",
  "status": "SUCCEEDED",
  "evidenceAccepted": true,
  "artifact": "Dataset row"
}

{
  "runId": "example-current-run",
  "buildId": "candidate-build-id",
  "status": "SUCCEEDED",
  "evidenceAccepted": true,
  "artifact": "KVS OUTPUT"
}

Happy output

A valid unique record produces one licensed_job_record Dataset item. The full checked example ships with the Actor under examples/dataset-item.json; the following excerpt highlights the decision and evidence boundary:

{
  "schemaVersion": "2.0.0",
  "recordType": "licensed_job_record",
  "stableId": "licensed-job:…",
  "input": "mx:ventas",
  "found": true,
  "title": "Account Executive",
  "company": "Example Employer SA de CV",
  "location": "Ciudad de México",
  "sourceJobId": "demo-sales-001",
  "sourceCountry": "mx",
  "observedAt": "2026-08-13T10:00:00.000Z",
  "freshness": {
    "status": "fresh",
    "basis": "buyer_supplied_source_retrieval_time"
  },
  "change": {
    "status": "not_measured",
    "basis": "single_authorized_export_record"
  },
  "decision": {
    "outcome": "review_required",
    "priority": "normal",
    "safeToAutomate": false
  },
  "billing": {
    "billingEligible": true,
    "billingIntent": "linked_push_result_found",
    "eventName": "result-found",
    "settlementSource": "current_run_kvs_output"
  }
}

The Dataset item records delivery intent. It does not claim that settlement was paid. Read current-run KVS OUTPUT for that fact.

Partial output

A run becomes PARTIAL when it delivers a free diagnostic, suppresses duplicates, rejects invalid records, stops at the buyer’s budget, or otherwise processes less than the requested valid work without a fatal terminal error.

Examples:

• a batch with one valid row and one invalid object can deliver one paid job row plus one free invalid-record diagnostic;
• two identical source identities produce one eligible job row plus one free duplicate diagnostic;
• a legacy items request produces a free migration diagnostic and no paid job row;
• a budget stop can preserve already confirmed rows while recording remaining rows as withheld.

Free diagnostics have recordType: job_export_advisory, found: false, null job fields, billingEligible: false, and a closed failureDiagnostics object.

Failure output

Fatal failures are recorded in KVS OUTPUT when the current-run store is available. Examples include:

• missing or invalid hosted run identity;
• missing current Dataset identity;
• semantically invalid input;
• pricing or named-counter mismatch before delivery;
• unknown linked-push outcome;
• unreadable or contradictory post-push settlement;
• primary KVS write failure after one bounded recovery attempt;
• platform exit failure.

A thrown paid push is treated as unknown_delivery; it is never blindly retried. A returned push with an unreadable settlement counter is treated separately as settlement_unknown: the Dataset write may be known while payment remains unproven. In both cases, replaySafe is false after a push attempt.

Field dictionary

Backward-compatible fields

Field	Meaning
input	Normalized country:sourceQuery, or the country when no source query is supplied. Null on diagnostics.
found	True only for a normalized licensed job record.
title	Supplied job title.
company	Supplied company name or null.
companyRating	Supplied numeric rating or null; not verified.
location	Supplied location or null.
postedAt	Supplied UTC posting timestamp or null.
url	Recorded HTTPS job URL or null; never fetched.
scrapedAt	Compatibility alias for observedAt. The current Actor does not scrape.
error	Null on job records; diagnostic summary on free advisory rows.

Identity and contract fields

Field	Meaning
schemaVersion	Dataset contract version 2.0.0.
recordType	licensed_job_record or job_export_advisory.
stableId	Deterministic identity derived from source name and source job ID.
sourceJobId	Identifier supplied by the licensed source export.
sourceCountry	Supplied regional code.
rowDigest	SHA-256 digest of the complete row excluding the digest field itself.

Job content fields

Field	Meaning
employmentType	Supplied employment-type label or null.
descriptionSnippet	Supplied bounded snippet or null. It may still contain personal information; minimize before submission.

Provenance fields

Field	Meaning
sourceName	Buyer-supplied source/export name.
sourceUrl	Recorded provenance URL. No fetch or control verification occurs.
sourceLicense	Buyer-supplied authorization or licence statement.
sourceRetrievedAt	Buyer-supplied retrieval timestamp used for freshness.
changesMade	Buyer-supplied transformation disclosure.
evidence.entityId	Deterministic entity identity.
evidence.inputDigest	Digest of the normalized source record.
evidence.requestDigest	Digest of the normalized run request without raw legacy queries.
evidence.sourceContext	Selected source-rights context.
evidence.networkRequestsMade	Always zero.
evidence.sourceFetchedByActor	Always false.

Freshness and change fields

Field	Meaning
observedAt	Time this Actor processed the supplied record.
freshness.status	fresh, stale, or unknown.
freshness.sourceRetrievedAt	Buyer-supplied source retrieval time.
freshness.ageSeconds	Nonnegative difference between processing and retrieval time. Future retrieval timestamps clamp to zero; they are not independently verified.
freshness.thresholdSeconds	freshnessHours × 3,600.
freshness.basis	Explicitly buyer-supplied retrieval time or no delivered record.
change.status	Always not_measured; this Actor has no persistent cross-run baseline.
change.basis	Single-record evidence or diagnostic-only basis.

Confidence and decision fields

Field	Meaning
confidence.score	Deterministic contract-completeness score from 0 through 1, not an accuracy probability.
confidence.basis	States that the score reflects contract completeness and buyer-asserted provenance.
confidence.gaps	Concrete missing or unverified evidence conditions.
decision.outcome	review_required for job rows or input_action_required for diagnostics.
decision.summary	Evidence-bounded explanation.
decision.priority	normal for fresh evidence, high for stale or diagnostic evidence.
decision.safeToAutomate	Always false.
decision.recommendedAction	Human-review action.
summary	Top-level compatibility copy of the decision summary.
recommendedAction	Top-level compatibility copy of the action.
priority	Top-level compatibility copy of the priority.
safeToAutomate	Always false.

Diagnostics and billing fields

Field	Meaning
failureDiagnostics	Null on paid candidates; closed legacy/invalid/duplicate detail on free diagnostics.
billing.billingEligible	Whether the row was eligible for linked paid delivery.
billing.billingIntent	Linked paid push or free diagnostic write.
billing.eventName	result-found for eligible rows; null for diagnostics.
billing.unit	One delivered normalized licensed job record, or null.
billing.settlementSource	Always current_run_kvs_output.

KVS OUTPUT contract

The OUTPUT record belongs to the current run and is the authoritative reconciliation surface.

Input counters

• requestedCount — raw modern job objects received.
• uniqueCount — valid unique source identities eligible for paid work.
• duplicateCount — valid duplicate identities suppressed before billing.
• invalidCount — malformed modern records excluded from paid work.
• legacyItemCount — legacy search strings received; modern counters remain zero in legacy mode.

For modern input:

requestedCount = uniqueCount + duplicateCount + invalidCount

Run counters

• attemptedCount
• successfulCount
• failedCount
• deliveredRowCount
• paidRowCount
• freeRowCount
• withheldRowCount
• unknownDeliveryCount
• unknownSettlementCount
• normalizedJobCount

The semantic validator requires exact work and delivery partitions. It does not merely check that each value is nonnegative.

Delivery counters

• event name must be exactly result-found;
• initial named result count must be zero for the no-retry canary contract;
• every paid row requires the counter before the push to equal the already confirmed paid count;
• a paid row requires named counter delta exactly +1;
• the linked SDK aggregate receipt must equal two events: one Dataset delivery plus one named result event;
• a zero delta with aggregate zero and charge limit reached is a confirmed withheld operation;
• all other combinations are unknown or anomalous and fail closed.

Terminal fields

terminal records:

• outcome
• failureStage
• primaryKvsWrite
• recoveryKvsWrite
• exit

The Actor performs at most one bounded recovery write for terminal KVS failure. It does not loop, and it does not retry an ambiguous Dataset push.

Pricing

The automatic Actor start event is separate from the result unit. result-found means one delivered normalized licensed job record with exact current-run settlement proof. Free migration, invalid-record, and duplicate-record diagnostic rows do not intentionally emit result-found.

Current pricing is tiered. The base FREE-tier prices are:

• Actor start: $0.005
• one normalized job record: $0.002

Higher subscription tiers receive the live Store discounts. Always treat the pricing panel and current-run KVS receipt as authoritative; do not hard-code an estimate from this README into billing automation.

Base-tier examples before discounts:

Delivered normalized records	Result events	Result subtotal	Start	Total
1	1	$0.002	$0.005	$0.007
10	10	$0.020	$0.005	$0.025
50	50	$0.100	$0.005	$0.105
100	100	$0.200	$0.005	$0.205

Actual platform usage, subscription pricing, and optional downstream system costs are separate. This Actor has no proxy, browser, external API, or LLM variable cost.

Evidence and boundaries

Source truth

The Actor transforms only data present in the submitted input. It does not confirm that a named source issued the record, that the source URL is controlled by that source, or that the supplied licence statement is sufficient. Preserve your authorization evidence outside this Actor.

Computrabajo boundary

The legacy slug does not grant Computrabajo access or redistribution rights. The current runtime does not request Computrabajo pages. Do not describe the output as Computrabajo-verified unless you independently hold written authorization and your own source evidence supports that statement.

Freshness boundary

Freshness measures time since the buyer-supplied sourceRetrievedAt. It does not prove vacancy activity, employer confirmation, page availability, or source recrawl.

Confidence boundary

The score is deterministic contract completeness. It is not model accuracy, truth probability, fraud detection, or candidate-fit confidence.

Decision boundary

Every normalized row remains review-required. safeToAutomate is false because the Actor does not verify the vacancy, employer, licence, applicant impact, or downstream policy.

Privacy and responsible use

Job records can contain personal data, recruiter names, direct contacts, free-text personal information, or URLs with identifiers. Before submission:

• remove candidate data; this product is for job records, not candidate scoring;
• remove recruiter phone numbers, emails, and personal profiles unless strictly necessary and lawfully processed;
• do not put API keys, tokens, session IDs, personal data, or confidential terms in URLs;
• minimize descriptionSnippet to the information needed for the review purpose;
• establish a lawful purpose, retention period, deletion procedure, and access controls;
• honor correction, deletion, objection, and source-specific obligations that apply to you;
• do not use the output for unlawful discrimination, protected-trait inference, harassment, spam, or automated employment decisions;
• remember that SHA-256 digests and stable IDs are pseudonymous linkage tools, not anonymization.

Apify stores Actor input and run storage according to your platform configuration. Do not submit secrets merely because a field is not shown in the Dataset.

Sources and rights

You are responsible for confirming that your source permits:

1. automated or manual export;
2. processing by your Apify workspace;
3. transformation into this Dataset;
4. commercial use when applicable;
5. downstream sharing with your intended recipients;
6. retention for your intended period;
7. any required attribution, licence link, or indication of changes.

Good source contexts include an employer-owned ATS export, a contractual recruiting partner feed, an internal buyer-owned vacancy database, or another feed whose written licence covers your use. Public visibility alone is not a redistribution licence. Robots allowance alone is not a commercial licence. Buyer authorization cannot substitute for authorization from a rights holder when that is required.

Decision routing

Fresh, complete record

Route to a human reviewer with normal priority. Verify vacancy status and source rights before external publication, outreach, or automation.

Stale export

Route with high priority for refresh. Do not infer that the vacancy remains active merely because the row normalized successfully.

Missing company or location

Keep the record review-required. Use the listed confidence gaps to request missing evidence from the authorized provider.

Duplicate source identity

Use the free diagnostic to correct the upstream export. The Actor suppresses duplicate paid work but does not decide which source version is more current.

Invalid record

Inspect the closed schema requirements, correct the upstream record, and submit a new run only when it is safe to incur a new start event.

Unknown delivery or settlement

Do not blind-retry. Read the current run, Dataset, named-event counters, and KVS OUTPUT; reconcile manually before deciding whether a new run is appropriate.

Commercial playbooks

Employer ATS quality gate

1. Export only approved vacancies from the employer system.
2. Map source IDs, titles, company, location, timestamps, URLs, and licence metadata.
3. Run this Actor with sourceContext: employer_authorized_export.
4. Filter Dataset rows by freshness and confidence gaps.
5. Verify each vacancy against the employer workflow.
6. Route approved records onward using the stable ID as the idempotency key.

Licensed feed onboarding

1. Archive the provider agreement and field documentation.
2. Document permitted countries, fields, recipients, and retention.
3. Populate sourceLicense and changesMade precisely.
4. Test a single record first.
5. Reconcile Dataset and KVS OUTPUT.
6. Increase the batch only after the contract and unit economics are understood.

Regional data cleanup

1. Keep original sourceCountry rather than inferring country from text.
2. Preserve source IDs exactly.
3. Normalize timestamps upstream to UTC.
4. Keep ambiguous locations as supplied or null.
5. Use diagnostics to fix invalid rows rather than coercing them silently.

Migration from legacy searches

1. Existing items integrations continue to parse.
2. Observe the free migration diagnostic.
3. Replace search strings with an authorized structured export.
4. Add source rights and transformation metadata.
5. Validate one paid record with current-run reconciliation.
6. Remove assumptions that this Actor crawls a public job board.

Integration recipes

Apify API

Start a run with the modern JSON object. Poll that exact run to terminal. Read both:

GET /v2/datasets/{defaultDatasetId}/items
GET /v2/key-value-stores/{defaultKeyValueStoreId}/records/OUTPUT

Bind the KVS runId and Dataset ID to the current platform run before accepting the result.

Webhook receiver

Use a run-finished webhook only as a notification. The receiver should fetch OUTPUT, require an expected terminal status, verify the run identity, inspect unknown counts, then read Dataset rows. A webhook event by itself is not delivery proof.

Data warehouse

Recommended natural key:

stableId

Recommended immutable audit columns:

rowDigest
evidence.inputDigest
evidence.requestDigest
sourceRetrievedAt
observedAt

Do not overwrite an older source version solely because a new row has the same stable ID. Compare timestamps, digests, licence context, and changes made.

CRM or ATS import

Treat the Dataset as a review queue, not an import-ready command. Require a reviewer to verify target schema, vacancy state, source rights, and field mapping. Keep safeToAutomate: false in the control logic.

Spreadsheet review

The overview view exposes the fields most useful for triage: job identity, title, company, location, posting time, URL, freshness, confidence, action, evidence, failure, and billing intent. Preserve nested JSON columns when exporting to CSV or another lossy format.

Idempotent consumer

Use stableId + rowDigest:

• same stable ID and same row digest: already processed version;
• same stable ID and different digest: review as a changed supplied record;
• different stable ID: new source identity.

That is downstream idempotency guidance, not cross-run billing idempotency. Every new Actor run incurs a new automatic start event and may emit new result events.

Operating guide

Before the first run

• Confirm source rights in writing.
• Minimize personal and confidential data.
• Normalize timestamps to UTC.
• Use durable source IDs.
• Decide the freshness threshold.
• Set a bounded maximum run charge.
• Start with one record.

After a run

1. Check platform run status.
2. Read KVS OUTPUT from the same run.
3. Confirm runId and Dataset URL.
4. Inspect requested, unique, duplicate, and invalid counters.
5. Inspect delivered, paid, free, withheld, and unknown counters.
6. Require named counter +1 per accepted paid row.
7. Review any fatal error or partial state.
8. Read Dataset rows only after the receipt is understood.
9. Do not retry an unknown operation automatically.

Monitoring suggestions

Alert when:

• status is FAILED;
• unknownDeliveryCount or unknownSettlementCount is nonzero;
• fatalError is non-null;
• withheldRowCount is nonzero unexpectedly;
• invalid or duplicate counts rise;
• stale records exceed your internal threshold;
• source licence or transformation text changes;
• Dataset count and confirmedDatasetWrites disagree.

Reliability model

The runtime is deliberately fail-closed around money and identity:

• hosted run ID is required;
• current Dataset ID is required;
• only the exact two-event PAY_PER_EVENT map is accepted;
• tier prices must match the configured six-tier schedule;
• start spend must already be visible before paid work;
• initial named result counter must be zero for the bounded canary contract;
• the pre-push counter must equal confirmed paid work;
• paid settlement requires named +1 and aggregate two;
• no paid push is retried;
• KVS output is semantically validated before every write;
• one recovery KVS write is attempted after primary failure;
• terminal failure requests a failed platform run rather than reporting success.

Schema validation is the structural stage. Runtime validateRow and validateOutput are the mandatory semantic stage for digest, counter, delivery, source, and terminal relations.

FAQ

Does this still scrape Computrabajo?

No. The current runtime makes zero external source requests. The slug is retained for compatibility, and legacy searches receive a free migration diagnostic.

Is this affiliated with Computrabajo or DGNET?

No. It is an independent normalization tool and does not imply affiliation, endorsement, access, or authorization.

Can I use a Computrabajo export?

Only if you have rights that cover the export, processing, commercial use, and downstream sharing you intend. The Actor does not grant those rights and does not verify them.

What sources can I use?

Buyer-owned records, employer-authorized exports, ATS-authorized exports, and other licensed exports are supported. Your agreement and applicable law determine what is allowed.

Does the Actor verify the job is open?

No. It never fetches the job URL. Vacancy-open status is always an explicit confidence gap.

Why is safeToAutomate false?

The Actor validates data structure and records provenance, but does not verify the source, employer, licence, vacancy, applicant impact, or target-system policy.

Is the confidence score an accuracy probability?

No. It is a deterministic contract-completeness score. Read its basis and gaps.

Why require sourceLicense and changesMade?

They make the provenance boundary visible. Some licences require attribution or indication of changes, and every buyer benefits from knowing how an export was transformed.

Does an HTTPS URL prove the source is safe?

No. The Actor validates syntax and never fetches the URL. It does not verify domain ownership, DNS, content, or control.

Are duplicate records billed?

Valid duplicates by case-insensitive source name plus source job ID are suppressed before paid work. A free diagnostic reports duplicate suppression.

Are invalid records billed?

They are excluded from paid work. A free diagnostic can be written when the Dataset write channel is confirmed unpriced.

Does a Dataset row prove payment?

No. The row contains billing eligibility and intent. Current-run KVS OUTPUT is the settlement source.

What happens at the budget limit?

The Actor stops before the next paid operation when the remaining cap cannot cover it. Confirmed earlier rows remain recorded; remaining eligible rows are counted as withheld.

Can I retry after a failed push?

Do not retry blindly. A thrown linked push can leave delivery unknown. Reconcile the exact run, Dataset, named-event counter, and KVS receipt first.

Is a new run replay-safe?

No. replaySafe describes the current run after its own push attempts. A new run incurs a new start event and can deliver and charge the same supplied records again.

Does the Actor retain a cross-run baseline?

No. change.status is not_measured. Use stable IDs and row digests in your own authorized storage if you need version tracking.

Can I submit candidate CVs or profiles?

No. This contract is for job records. Do not use it for candidate scoring, protected-trait inference, or automated employment decisions.

Why is scrapedAt still present?

It is retained for backward compatibility and equals observedAt. The current Actor does not scrape.

Does the Actor translate Spanish job content?

No. It preserves supplied text after bounded whitespace normalization.

Can I process more than 100 records?

Split the authorized export into bounded batches. Reconcile every run independently and account for a separate start event on each run.

Which countries are supported?

The historical LatAm codes mx, co, cl, ar, and pe remain, plus other for a licensed source outside those codes. Country is buyer-supplied, not inferred.

Does sourceCountry restrict the URL host?

No. An employer ATS may use a global domain. The Actor records the value and URL without fetching either.

What if sourceRetrievedAt is in the future?

The calculated age clamps to zero. The timestamp remains buyer-asserted and should be reviewed; the Actor does not have an external time authority for the source.

What should I store for an audit?

Keep the original authorized export, licence or permission evidence, Actor input, exact build and run IDs, Dataset and KVS IDs, OUTPUT, row digests, and your downstream review decision.

Can the Actor send results to my ATS automatically?

No. Use your own reviewed integration after validating the target schema and policy. The result explicitly remains unsafe for blind automation.

Where is the authoritative run result?

Use both surfaces: Dataset for rows, current-run KVS OUTPUT for work and settlement. Bind both to the same platform run.

Support checklist

When reporting an issue, provide non-secret versions of:

• Actor build ID and run ID;
• terminal platform status;
• KVS OUTPUT status and failure code;
• Dataset row count;
• input, duplicate, invalid, paid, free, withheld, and unknown counts;
• whether the input used modern or legacy mode;
• the affected stable ID and row digest;
• expected versus observed behavior.

Do not include access tokens, API keys, confidential licence text, candidate data, or personal contact details in a public support message.

Final operating boundary

This Actor is useful when you already possess a structured job export and need a disciplined normalization, evidence, review, and settlement layer. It is not a licence acquisition service, crawler, vacancy verifier, ATS connector, candidate-ranking tool, or legal opinion. The buyer remains responsible for source rights, privacy, employment-law compliance, review, retention, and downstream use.