socmint

Showing 25 of 33 from the live probe.

• Get Capabilities

  What this engine can actually collect, platform by platform. Per platform it gives: collectPackages (the collectors that can run, each with mode='watch' — sweeps the environment's watch targets — or mode='search', plus secretResolved, which says whether that package's vendor credential is actually configured on THIS engine); scoutMethod, how Discover finds posts at all; limitations, the standing gaps that will show up in a run's meta; and knobs, the run flags that mean anything for that platform

• List Runs

  List recent SOCMINT collection runs, newest first. Returns run ids, environment, status and per-stage counts. Start here to find a run id. Each row also carries what the run cost: vendor_calls, credits_estimated, credits_basis and credits_complete. null there means nobody counted (a dry run, or a run older than the record) — never that the run was free; credits_complete false means the number is a floor.

• Get Run Meta

  One run's meta document, verbatim: who asked for it (createdBy), the run flags, per-stage status and counts. A `limitations` block stating what each platform's vendor path could not provide is present ONLY if this run exported raw Candidates — its absence is not a claim that the vendor had no limits. `get_capabilities` states them per package. `vendorCalls` and `creditsEstimated` say what the run asked the paid vendor path for; the credit figure carries the basis it was derived from, and free lo

• Get Discover

  The Discover stage's hits for one run: the posts the watch surface turned up inside the monitoring window, before Collect deepened them.

• Get Candidates

  The Collect stage's Candidates for one run: collected posts with author, content, times, engagement (nulls mean unknown, never zero), a comment sample and provenance. Collection evidence only — these documents carry no analysis, sentiment or risk judgment. newOnly=true narrows the answer to the posts THIS run saw first, which is what a daily series wants: every row carries firstSeenRunId, so day two reads as what is new instead of the whole run read again. It is a question about the environment'

• Get Run Timeseries

  Per-post metric history stitched across this deployment's previous runs (velocity per post): each post the given run collected, joined against the same post's engagement readings in the runs before it. The history window spans ALL Environments' runs, not only the given run's own Environment — on a deployment running several Environments, other Environments' runs occupy window slots, so raise runs to reach the same distance back. It is NOT a session aggregate — it answers 'is this post climbing?'

• Export Candidates Csv

  Build (or rebuild) the raw CSV product for a run and return it as text. file='candidates' is one row per post; file='comments' is one row per sampled comment, joinable on native_post_id/post_url. redact=true replaces author names and handles with a stable hash — it hides the author columns, not the permalink. This re-reads documents already on disk and makes no vendor call.

• Get Report

  The newest analysed run: its Findings ranked by risk, with the headline, summary, rakyat sentiment and recommended actions the analysis produced. This is the analysed layer (Product B); an operator or coordinator credential is refused it by the engine.

• Get Findings

  One run's Findings: the selected posts with the analysis attached — risk, sentiment, recommended actions and any human review mark. Evidence and judgment are separate documents underneath; a Finding is the frozen evidence plus the judgment made about it. This is the analysed layer (Product B), refused by the engine for a credential that does not reach it.

• Export Socmint Csv

  Build (or rebuild) the analysed eleven-column RISIK-AI CSV for a run and return it as text. It re-reads Findings already on disk and makes no vendor call. This is the analysed layer (Product B) — for the raw collected posts and comments, use export_candidates_csv instead, which every role can reach.

• List Environments

  List the Environments this engine can run: id, display name, kind (kawasan = a place watched continuously, isu = a story followed while it runs), collectionMethod (pantau = it reads a named list of accounts, carian = it asks the vendor for keywords), the monitoring window, keywords and watch-target counts. Read collectionMethod before you read the counts: a carian Environment reports zero watch targets and is working correctly, because the search path does not read an account list at all. An Env

• Create Environment

  Create an Environment. It writes a configuration file and calls no vendor — but an Environment created from half an answer collects nothing, and the person only finds out after a run. So ASK BEFORE YOU CREATE, in the conversation, unless the person has already said: (1) WHICH ACCOUNTS to watch — this is the one that silently produces an empty Environment, because Discover reads the watch list and nothing else; an Environment with no watchTargets and no copyWatchFrom cannot collect a single post

• Update Environment

  Update the operator-scope fields of one Environment: display name, notes, monitoring window, keywords, and which watch targets are enabled. mustAny/shouldAny/operatorExtra REPLACE the existing list rather than adding to it — read the environment first and send the whole list you want. An ADMIN may also set this Environment's collection and quality limits here (maxCandidatesByPlatform, platformPriority, minimums, minimumsMode, fallbackTopN) and which collection paths serve it (collectRoutes, rout

• Start Run

  Run the collection pipeline (Discover → Collect → Select) for one Environment. A DRY run — the default — returns the run id and per-stage counts directly: it needs no approval, calls no vendor at all, replays recorded fixtures, and is how you check that an environment is shaped correctly before a live run is ever proposed. A LIVE run returns a sessionId and a PLAN instead, never the result — every live run is a session, even a one-platform one — because a live sweep runs longer than the network

• Get Session

  How far a multi-platform collection session has got — the answer to a `start_run` that carried `platforms`. **`finishedAt` non-null means the session is over**; that is the signal, not `status`. `runs[]` carries one entry per platform with its own `runId` and its own `status`, quoted from that run's own metadata: `ok`, `dry_run_ok` for a fixture rehearsal, `hard_fail` when a gate refused the evidence, `error` when the machine stopped. `pending` and `running` mean it has no answer yet, and `skipp

• Get Harvest Pack

  The sweep's real numbers, already laid out in the client's own six-row sentiment table — call this INSTEAD of reading the platforms by hand for any row it can answer. Pass `sessionId` for a whole multi-platform sweep, or `runId` for one platform. The rows come back in the client's order and under the client's own names: `Facebook [BM]`, `Threads`, `X (Twitter)`, `TikTok / YouTube`, `Portal + ruangan komen`, `AGREGAT NASIONAL`. Each row says which of three things it is. **`diukur`** — the engine

• Submit Report

  Archive a finished report on the server, against the runs that evidence it. SHOW THE DRAFT TO THE HUMAN AND GET THEIR WORD BEFORE YOU CALL THIS. The archive is immutable, so a report filed and then corrected leaves two documents and the wrong one keeps its place in the record — the cheapest correction is the one made before this call. The report MUST cite runIds that really exist — the engine refuses a report whose evidence is not there, and that refusal is the point of the archive, not an obsta

• Render Report

  Render ONE of the client's three daily PDFs with the client's own locked renderer, and file it in the archive. Do not build these documents by hand, do not write your own HTML, and do not edit the scripts or templates: the three PDFs their office reads every day look identical because that renderer never moves, and this tool refuses to run a bundle whose bytes have changed. `bentuk` is `intrep`, `persada` or `kit`, and each takes a different `input`. **intrep** takes an object `{content, charts}

• Generate Report

  Ask the server to WRITE a report from runs it already holds, follow the recipe you name, check it against its own evidence, and archive it. This is the same generator the dashboard button uses — one generator, two doors — so a report made here and one made there are the same document. The answer is a JOB, never the report: writing one takes minutes, and a request held open that long is cut by the proxy and leaves you nothing to poll while the server keeps working and keeps spending. You get `rep

• Get Report Job

  How far a report job has got. `status` is queued, running, done or failed. **`done` always carries a `reportId`** — a job that finished with nothing to show is recorded as failed, so 'done with no report' is not a state you have to handle. `verdict` is the exit check the document was held to, naming any line of the recipe's own checklist it did not pass; `gaps` lists sections that shipped as a stated absence and still need a human. `usage` and `modelId` say what it spent, on failures too — `usag

• List Reports

  The report archive: reports filed back to the server, newest first, each with the runs that evidence it and the post/comment counts of those runs at this moment. Reading the archive is limited to admin and coordinator accounts — an operator can file a report and will be refused this list, which is the engine's design and not a fault to work around. A run shown as found=false no longer exists: report that, do not treat it as zero. The list can be narrowed: reportType (the free-form label the repo

• List Lenses

  The analysis lenses this engine can fit. A lens is the one part of this pipeline that knows what politics is: a persona, a perspective, the questions the rationale must answer, and a CLOSED set of risk grades the model may answer with. Read this before describing a Finding's judgement to anybody. Each row carries prinsipal — the party the judgement is read FROM: a Finding's polarityVsPh keeps that field name and means a leaning toward this principal, so 'negatif' cannot be read without knowing w

• Get Lens

  One lens in full, including promptTerkumpul — the composed system prompt the model is actually given. ADMIN ONLY; an operator or coordinator token is refused, and that is the engine's design, not a fault to work around. Read it before editing a lens, so an edit changes the one thing it means to change. The last part of the prompt is the ph_v1 output contract (the JSON shape, the closed polarity set, the invent ban) and it is NOT the lens's to reword: it is what the validator, the export adapter

• Create Lens

  Create a new analysis lens as a data file — a new question this engine can be asked to judge with, without a build. ADMIN ONLY, free, calls no vendor. ASK A HUMAN FIRST: a lens decides what every later Finding under it says, and its principal decides what the word 'negatif' will mean in every report that quotes it. gred is a CLOSED set, most severe first, at least two rows — the model may answer with nothing else, and a grade outside it is refused and re-asked. gredEskalasi3R must be one of thos

• Update Lens

  Edit one lens — ADMIN ONLY, free, PARTIAL: only the keys you send move, and the previous file is kept. Read it with get_lens first and send the one thing you mean to change; gred, soalan, slot and sentimen REPLACE the stored list rather than adding to it. Every save raises versi by one, and FINDINGS ALREADY JUDGED KEEP THE LENS THAT PRODUCED THEM — a run records the lens and its version, so editing never relabels evidence somebody already paid for. A lens compiled into the build has no file and