605 - What a run may do, and the record it leaves

• 601Do not spend AI on what a script can doThe automation gap, what integration platforms and laptop scripts each cost, and the division of labor: a script for the deterministic part, the model for writing it and for judgment.
• 602The agent writes the first scriptThe loop from a recorded draft through tests to the save, what a save requires, what validate and a dry run report, the dialect’s deliberate absences, the traps that fail a draft, and the script’s page in the portal.
• 603Outputs: feeds, reports, and dashboards that refresh themselvesOutput identity across runs, tables and documents, the semi-dynamic dashboard and its data region, the referencing pattern, version caps, and delivery to a bucket drop.
• 604Running it: by hand, from the portal, and on a scheduleThree triggers, the cadence builder, the pinned fire date, what a schedule guarantees, and the run history with every trigger, duration, output, and log.
• 605What a run may do, and the record it leavesThe authority a run carries, what a save refuses, why the language cannot reach out, the lifecycle, ownership and transfer, and the administrator’s view.
• 606Scripts as skills: the weekly review the agent runs on your businessThree scripts attached to one prompt, the agent running them and reading the outputs against the knowledge graph, and a weekly list of action items with the figures behind them.
• 607Events in: a webhook source, its table, and an automation that reads itCreating a source, how a sender proves itself and what it is told, the table that serves events from acknowledgement, compaction and retention, the Webhooks page, and an automation that reads only what is new.
• 608Results out: notification channels and signed delivery to other systemsChannel kinds and who may send to them, sending from a session and from an automation, the delivery history and the retry rule, the JSON envelope a system routes on, signed requests, and delivery to another deployment.

1. 1

   A run executes as the script’s own principal

   Not as you, and not with your session. It authenticates as script:<name>, and that is the name audit records and the name its outputs belong to.

2. 2

   It presents the roles its author held at the save

   The roles are captured on the version when it is saved and cannot be set any other way. A script can never do unattended what the person who wrote it could not do themselves.

3. 3

   Every call is authorized at the moment it is made

   Each query, export, and tool call a run makes crosses the same authorization an agent’s call crosses, against the persona those roles resolve to. There is no script-side allow list to keep in step.

4. 4

   Narrowing the persona takes effect on the next run

   Remove a connection or a tool from the persona and the script’s next run is refused at that call, in the persona filter’s own words. Nothing about the script has to change.

5. 5

   A cadence carries no authority of its own

   Re-timing a script reaches nothing the script could not already reach; the run gate and the persona are re-read at every fire.

• One format

  Rewritten, never refused.

  The source is stored in one canonical layout, every comment kept, so what is read back is what runs and a diff between two versions shows only what changed. Source already in that layout is stored byte for byte.

• The work in main()

  Refused until it is.

  The platform calls main() after the script loads. The top level holds functions, constants written as literals, and docstrings, which keeps each part of the script testable on its own. A source with no main() is saved as a library.

• The structural rules

  Refused, naming the rule, the line, and the fix.

  Functions that are too long, too branched, or nested too deep; a local or parameter never read; a name that hides a built-in; a function with no docstring; SQL assembled from values instead of bound with params; a platform call made once per element of a collection.

• Tests that pass and reach the code

  Refused, naming the lines no test reached.

  At least one test, every test passing, and at least 80% of the script’s statements reached. A test that makes no assertion is refused.

• Tests that read the data

  Refused, naming what went unread.

  A test that still passes when the rows it replays are altered (the last row dropped, the first row’s values changed) is blind to its data and is refused. Together the tests must assert on every output they produce: each column of each export, the staged state, each notification, and the run’s result.

• Recorded calls

  What a test runs against.

  Every draft run and every run records each host call it makes and the answer it got. A test replays a recording, or declares the answer a call gets with testing.answer, so a test never reaches an upstream and can take the branch no draft takes.

• No credential-shaped literal

  Refused for a known format; a warning for a name.

  A private key header, a cloud access key id, a well-known token format, or a URL with a password in it blocks the save. A variable merely named like a secret is a warning. The scan is a tripwire that catches a paste, not a guarantee; scripts name connections, and Plexara holds the credentials.

• Source that parses

  Refused at the keyboard.

  Code that cannot run is refused rather than stored, so the failure surfaces while somebody is looking at it instead of at the next fire.

• No network

  A script opens no socket and supplies no endpoint. An external API is reached only through a connection Plexara already holds, with platform.call, so what a script can reach is what its author can reach.

• No filesystem

  A file is read through the registered table or a platform call, and written as an output. Nothing lands anywhere the platform does not record.

• No clock, no randomness

  The fire time is pinned on the run, so the same version with the same parameters asks the same question. A run may ask how long it has left before its time limit, and that answer is recorded with the run like any call’s, so a replay reads the same number. A run nobody can reproduce is not a governed run.

• No imports, only libraries

  A script starts with platform, json, xml, date, run, sum, and fail, and a test also has testing and assert. load() brings in a saved library at a named version and nothing else, and a library version never changes, so the program is the source on the version plus library code that cannot move under it.

1. 1

   Active

   The saved version runs: from any session, from the Run button, and on its schedule.
2. 2

   Disabled

   Nothing executes it. The run gate refuses in its own words on every surface, and a cadence set on a disabled script saves and stays inert, which the tool and the page both say plainly.
3. 3

   Deprecated

   Taken out of service and marked as such. The record stays; runs are refused.
4. 4

   Superseded

   Retired in favor of a named replacement. The reference to the old script still resolves, and says which script replaced it.

• Everyone signed in

  Every automation and schedule, and each script’s definition: what it is, its parameters, whether a run would be admitted, its schedule, its source, and its version history. Its run history too, as how each run went, when, how long it took, and why one failed. Reading a script grants nothing; a run still presents its author’s captured roles.

• Its owner and administrators

  What each run was given, printed, and wrote; the state; the roles each version’s author held at the save; and every action: running, editing, scheduling, granting, and deleting.

• A persona, role, or API key granted its runs

  The right to start a run and read the runs it started, with their outputs. A grant decides who may ask for a run, never what the run may reach, and it cannot change the script.

• Whoever asked for one run

  That run: its parameters, outputs, and log.

• The team

  The outputs, under the sharing model of every other asset, and the libraries. Anyone can load any library, so the pagination, date windows, and table shaping many scripts repeat are written once and shared.

• Only an administrator moves a script

  From the script’s page, choosing the new owner from the people who have signed in to your deployment at least once. An owner cannot give a script away.

• The whole script moves at once

  What the owner sees, edits, runs, and schedules, and the history: the new owner reads the run records and dry-run accounts the previous owner produced.

• The move is a version, authored by the administrator

  From then on a run presents that administrator’s roles. Moving a script to an administrator is how it comes to run with an administrator’s reach.

• A name clash is refused

  If the receiving owner already keeps a script of the same name, the transfer does not happen.

• It is audited

  Like every other administrative write, the transfer is recorded in the audit log.

run_script name=acme-supplier-margin args={"month":"2025-12-01","conn":"acme","mode":"refresh"}
→ status succeeded   version 6   trigger tool   duration 8,231 ms
  outputs
    supplier-margin-by-category   csv    asset 871da875-cd99-44f9-b6d9-55732b4e9086  version 3
    supplier-margin-feed          json   asset 589855b4-cfe1-4355-af26-ae68cbc5770f  version 3
    supplier-margin-dashboard     refresh  asset bab7c8e7-67e6-4561-834a-32524f203fc8  version 2
  audited as script:acme-supplier-margin, presenting the roles captured at the save of version 6

Who saved it, and their roles

The author and the roles they held at the save, which are the roles a run of the version presents.

The test report

How each test did at the save and the share of statements they reached, with the lines no test reaches. The Tests tab shows it, and the flow diagram marks each step the tests miss. A version saved without a source change, such as an ownership transfer, keeps the report of the version before it.

The change summary

When the version changed what the automation does: the plain-language summary, and when the person agreed to it.

Who ran it, and when

The author’s own identity, under their own persona.

How it ended

Succeeded, or the failure and the line it failed on.

What it printed

The bounded log, head kept, tail dropped with a marker when it overflows.

The shape of its outputs

Each export’s format, row count, and size, measured without being written.

Which source it executed

The account is keyed to the exact source, so it attaches to whichever version later carries that code. A version with no account is code that first executed unattended, and the version detail says so.

• platform.save_state(obj)

  Committed only when the run succeeds.

  Applied in the same step that marks the run succeeded, with a compare-and-set on the revision the run read. A failed run leaves the state where it was, so a watermark never moves past work that did not happen.

• platform.checkpoint(obj)

  Committed however the run ends.

  Stages progress the platform keeps when the run fails or is halted at its time limit, so a pipeline that merged half its pages does not lose its place for all of them. A successful run commits its save_state, or its last checkpoint if it never called save_state.

• A checkpoint that loses the compare-and-set

  The run stays failed for its own reason.

  Another run wrote the state first. The checkpoint is refused and the refusal is recorded beside the run’s own failure, which it does not replace.

• platform.remaining_ms()

  How long the run has left.

  A script has no clock, so this is how a long job decides to checkpoint and stop before its time limit rather than be halted mid-page. The value is recorded with the run, so a test replays it exactly.

• fail() after save_state

  A warning at the save, not a refusal.

  A failed run’s save_state is discarded, so a function that saves state and then fails never writes it. The save says so, and a draft run reports the staged value as discarded rather than saved.