Everything you need to act on one signal, in a single call — written for an agent that knows nothing about this company yet. It returns the signal and its repair steps, the objects it concerns with their fields and PII flags, the verified join path between each pair of them, the process and the step involved, the open findings on those objects, the metric and its recorded values where the signal is about a number, what was done the last time this same thing came up, the playbooks your human wrote for this kind of work or anchored on the objects it concerns (playbooks — their own words on how the work should go, guidance and not a limit on what you may do; for a routine_due signal, exactly the scheduled playbook it names; where one names what its work is typically worth, typical_value with a reminder to pass that figure as record_action's value when your human's systems state it, never an estimate), for a rule that fired the operation the rule suggests with your key's policy for it and what request_action would decide (suggested_action — a forecast, not the decision, plus a refusal of its own where the rule has changed since the signal fired or the signal is the summary of the groups past a rule's cap), for a map a workspace admin rolled back which older scan the map is now, whether it still is, and what to look up again (rollback), and a trust summary naming the weak joins and the fields you must not quote back. It is still metadata: fetch the rows themselves in your human's own systems, using the routes. It also carries lifecycle: the signal's state, who holds it and until when (or who planned it and by when), its episode, whether it changed while held, whether a reported fix still waits for a scan to confirm it, and every earlier episode's resolution with its summary. And handling: whether Maplith's own check closes the signal once its cause is gone (which check, when, on what), your own earlier requests about it, and work in hand on the map that may already cover it — read it before you ask a person to act. Start from list_signals, then call this for the signal you mean to work on. The finding the signal names is always here if your key may see it; the other findings are a relevance selection, and when there were more open findings than it reads, truncated is true and truncated_note says so. For a support or helpdesk case that did not start as a signal, pass case instead of signal_id: the KIND of identifier you hold for the customer and the KIND of case, never their values (case: {identifier: "email", topic: "return"}). It returns where to look the customer up (lookup: the objects, systems and fields that carry that identifier, and whether a field identifies one row), the routes from there to the objects the case is about, the playbooks your human wrote for that kind of case, the open findings and signals on those objects, and every action your key may request (actions: its policy, and what request_action would decide — a forecast, not the decision). Still metadata: look the customer up in your human's own systems.