Missed-Run Audit
of Scheduled & Map/Reduce Processing

1. Executive summary

Objective. Determine whether the account's unattended processes ran when the business expected them to — not merely whether recorded executions succeeded — and whether a control exists to detect their absence.

Results. The account has 680 Scheduled or Map/Reduce deployments, 28 of them live on a schedule. Nine were tested as critical. Every daily critical deployment started on every one of the 30 days reviewed, and no instance failed or was cancelled. That clean record conceals two problems it cannot express: one scheduler completed daily but has produced no business output since 17 July after 85 unrecorded downstream failures, and one process ran six times a day against an empty input table. Two monthly deployments show no run in their August windows. Six deployments are dormant and can never fire. Outside the critical set, a workflow-context process is rewriting the same three subsidiary records 3,552 times a day.

Overall assessment: Needs improvement. Job scheduling is operating effectively for daily work. The detective control — knowing when a job did not run, or ran and did nothing — does not exist, and the account's own telemetry (4-day script log, 30-day instance table) cannot substitute for it.

Sources: R1, R2, R4, R6, Q17, Q19, S7z, Q3. Recorded failures outside the period: 85 dispatched-job FAILED transitions Jan–Jul (Q21); 4 FAILED instances Aug 2025 (Q18).

Priority actions

2. Contents

3. Background, objectives & scope

Background. Error dashboards describe executions that exist. A disabled deployment, an expired schedule or a missed trigger produces no run to inspect, so a clean error log proves only that no recorded execution failed. For unattended work the first telemetry question is whether the job showed up when the business expected it (Appendix F, source 1).

Objectives. (1) Inventory every mechanism by which unattended work runs. (2) Establish what the business expects of each critical process. (3) Compare expected against observed runs. (4) Confirm that completed runs did their work. (5) Rate exceptions and propose a permanent absence-detection control.

Scope. All Scheduled Script and Map/Reduce deployments (680), workflows with a scheduled trigger (2), and — at count level only — RESTlet integration surface. Review period 5 Aug – 3 Sep 2026, bounded by instance-table retention. Nine processes tested in depth.

Criteria. COBIT 2019 DSS01 Managed Operations (scheduling and monitoring of batch processing); ITIL 4 Monitoring and event management; SOC 2 CC7.2 (monitoring of system components for anomalies). In this account no documented run expectations existed; they were set at Gate 1 (§5) and are the criteria against which results are measured.

Approach and independence. Read-only throughout. No record, field, script, deployment, workflow or saved search was created or changed. Two gates were held with the account owner (inventory; draft observations).

4. Methodology & definitions

Run-outcome taxonomy

Evidence grading

VERIFIED — observed live in this account and cited to a workpaper id (S, Q or R). DERIVED — computed from verified data; formula shown. ASSUMED — a judgement not confirmed by the account owner; listed in Appendix C with impact-if-wrong. Every figure in this report carries one of these grades, explicitly or by its workpaper citation.

Windows, baselines, thresholds

Observability budget of this account

5. Run expectations (control baseline)

At Gate 1 the account owner replied verbatim: “Use your suggestions and/or decisions based on best practices.” Every row is therefore ASSUMED (A1–A4). Windows are anchored on the observed steady-state start time rather than the deployment's stored startTime, because the two differ by 0 or 4 hours depending on the deployment (A3).

6. Results at a glance

7. Inventory & dormant deployments

The 28 live scheduled deployments

Dormant deployments

Scheduled workflows

VERIFIED Two workflows carry initonschedule='T', both on the Subsidiary record (−117), both runasadmin='T': customworkflow_atlas_finwb_translations (216, RELEASED, logging off) and customworkflow_atlas_prowb_translations (316, TESTING, logging on). Frequency is not exposed on the workflow table (Q2, Q26). See observation 7.

8. Detailed observations

Observations are rated with the FMEA-style RPN defined in §4 and written in Condition · Criteria · Cause · Effect · Recommendation form. Management response and target date are left for the process owner.

Observation 1 — Benchmark 360 Job Scheduler High

Observation 7 — Workflow-context runaway on Subsidiary High

Observation 2 — Cash 360 lead-time calc, 29-day gap Medium

Observation 3 — Payment Batch Processing, no input Medium

Observation 4 — Monthly deployments, August windows Medium

Observations 5 and 6 — Dormant deployments Medium / Low

Observation 8 — Item360 threshold artefact Low

VERIFIED 119 items updated on 15 of 30 days; baseline median 1 item/day with spikes of 35 (10 Aug) and 54 (1 Sep) (R6; Figure 5). The script's input is items whose alert counts changed (S10), so zero-write days are correct behaviour. The default no-output threshold is inappropriate for volume-driven signals; the heartbeat should carry an objects-processed count so that 0 is distinguishable from “no candidates”.

Observation 9 — STE Data Update duration anomaly Low

VERIFIED Deployment 1986 ran 52 minutes on 28 Aug against a 0-minute median (R4); four FAILED instances at Get Input Data on 10–13 Aug 2025 (Q18). No action beyond monitoring.

Observation 10 — Telemetry retention Medium

VERIFIED Table 1. The account cannot answer “did this job run in July?” from its own data. Recommendation: the heartbeat record in §11, which persists indefinitely and is owned by the account.

9. Business-state verification

Attribution method: systemnote rows with context SCH or MPR since 24 June, grouped by record type and field (Q12, R6). Source files for five of nine critical scripts are access-restricted (Appendix D), so purpose and target objects come from the system-note footprint and, where readable, source archaeology (S10).

Draft saved searches — independent business-state monitors (not created)

10. Management action plan

11. Recommended control design — heartbeat monitor

Design only. Nothing in this section has been built, created or deployed. The pattern is the dead-man's-switch (“cron monitoring”) model used by Cronitor, Healthchecks and similar services, implemented natively.

Design constraints

• Alert on absence, not only on exceptions.
• Independent of the monitored script's own logging (retained 4 days here).
• Verifiable by a human without the agent: a saved search over a custom record.
• The heartbeat must never break the job it monitors.

11.1 Custom record customrecord_sonar_heartbeat — one row per critical process

11.2 Heartbeat contract — two calls per monitored script

// heartbeat.js — shared module, SuiteScript 2.1
define(['N/record','N/search','N/log'], (record, search, log) => {
  function find(depId) {            // 1 search, ~10 units
    let id = null;
    search.create({ type:'customrecord_sonar_heartbeat',
      filters:[['custrecord_hb_deployment','is',depId]], columns:['internalid'] })
      .run().each(r => { id = r.id; return false; });
    return id;
  }
  function stamp(depId, values) {   // submitFields, ~10 units
    try {
      const id = find(depId); if (!id) return;               // unregistered → silent no-op
      record.submitFields({ type:'customrecord_sonar_heartbeat', id, values,
        options:{ enableSourcing:false, ignoreMandatoryFields:true } });
    } catch (e) { log.error('heartbeat', e.message); }      // NEVER rethrow
  }
  return {
    start:    depId => stamp(depId, { custrecord_hb_last_start: new Date() }),
    complete: (depId, n) => stamp(depId, { custrecord_hb_last_complete: new Date(),
                                          custrecord_hb_last_objects: n })
  };
});

// in the monitored script
// getInputData / execute():  heartbeat.start(runtime.getCurrentScript().deploymentId);
// summarize / end:           heartbeat.complete(deploymentId, objectsProcessed);

Governance: ≈ 20 units per call, 40 per run — under 0.5 % of a 10,000-unit scheduled-script budget. Failure behaviour: every path is wrapped; an unregistered deployment is a no-op; a heartbeat exception is logged and swallowed. For bundle-owned scripts whose source cannot be edited, the monitor itself stamps START/COMPLETE by reading scheduledscriptinstance through N/search — the same join used in R2.

11.3 Absence monitor customscript_sonar_hb_monitor — Scheduled Script, every 30 min

1. Load heartbeat rows where custrecord_hb_muted_until is empty or past.
2. Compute the most recent expected window from cadence, days mask and window start/end.
3. Window end passed and last_start < window start → MISSED. last_start set, last_complete < last_start, now > window end + grace → HUNG. last_objects < min_objects → NO OUTPUT.
4. Debounce on custrecord_hb_last_alert; email owner, cc escalation; log AUDIT.
5. Who monitors the monitor: the monitor stamps its own row (custrecord_hb_deployment = customdeploy_sonar_hb_monitor, cadence HOURLY). A saved search “Heartbeat monitor stale” (last_start older than 90 min) is scheduled through NetSuite's native saved-search email — a mechanism independent of SuiteScript.

11.4 Second layer — business-state monitors

Table 9 saved searches, scheduled as shown. They confirm the work, not the run, and require no code.

11.5 Roll-out, test, rollback

• Roll-out: (1) create record type and nine rows from Table 2; (2) deploy the monitor alerting the administrator only; (3) instrument the four local scripts (C2, C3, C6, C7); (4) after two clean weeks, switch recipients to owners; (5) add the saved-search layer.
• Test plan: set a row's window to a past time → MISSED within 30 min; stamp start without complete → HUNG after grace; set min_objects above a known run → NO OUTPUT; set muted_until tomorrow → silence; disable the monitor deployment → native saved-search email within 90 min.
• Rollback: set the monitor Not Scheduled; heartbeat calls become no-ops if the record type is removed (find() returns null). No monitored job can be broken by rollback.

12. Positive assurance & next checkpoints

VERIFIED The following were tested and found operating as expected for the review period:

• All seven daily or intra-day critical deployments (C1–C6 at instance level; C7 weekly) started in every expected window: 0 missed runs, 0 recorded failures, all durations ≤ 3 min (R4).
• Business output confirmed daily for C2 (Cash 360 stamp, Q20), the FAM diagnosis scan (R6) and Request License (R6); confirmed on volume-appropriate days for C3 (R6); confirmed via downstream task instances for C4 (R4).
• Of the 28 live deployments, 24 show the instance cadence their schedule implies (Table 5); the exceptions are the two monthly deployments (obs. 4), the expired CPN Cleaner (obs. 5) and the quarterly ELK cleanup not due in the period.
• Where the script execution log overlaps the review period (1–4 Sep), log activity matches instance activity for every scheduled deployment that logs (R5).

Appendix A — Workpapers (evidence log)

All timestamps 2026-09-04, US Eastern. Row counts as returned. Schema probes S1–S5 were SELECT * … FETCH FIRST 1 ROWS ONLY.

A.1 Schema probes and record reads

A.2 Queries (verbatim)

-- Q1 (19:37) 680 rows — inventory of Scheduled/MR deployments
SELECT s.id AS script_id, s.scriptid AS script_scriptid, s.name AS script_name, s.scripttype,
       s.frombundle, s.owner, s.isinactive AS script_inactive, s.scriptfile,
       d.primarykey AS deployment_pk, d.id AS deployment_seq, d.scriptid AS deployment_scriptid,
       d.title, d.status, d.isdeployed, d.queueid, d.priority, d.loglevel, d.executioncontext
FROM scriptdeployment d
JOIN script s ON s.id = d.script
WHERE s.scripttype IN ('SCHEDULED','MAPREDUCE')
ORDER BY s.frombundle NULLS FIRST, s.name, d.primarykey

-- Q2 (19:37) 2 rows — scheduled workflows
SELECT w.internalid, w.scriptid, w.name, w.releasestatus, w.isinactive, w.initonschedule,
       w.initoncreate, w.initonvieworupdate, w.recordtype, w.frombundle, w.owner, w.datemodified
FROM workflow w WHERE w.initonschedule = 'T' ORDER BY w.name

-- Q3 (19:38) 33 rows — deployments with status SCHEDULED
SELECT s.id AS script_id, s.scriptid AS script_scriptid, s.name AS script_name, s.scripttype,
       s.frombundle, s.owner, s.scriptfile, d.primarykey AS deployment_pk,
       d.scriptid AS deployment_scriptid, d.status, d.isdeployed
FROM scriptdeployment d JOIN script s ON s.id = d.script
WHERE s.scripttype IN ('SCHEDULED','MAPREDUCE') AND d.status = 'SCHEDULED'
ORDER BY d.isdeployed DESC, s.frombundle NULLS FIRST, s.name

-- Q4 (19:39) 1 row — instance_rows 4965, oldest_start 2025-08-10, newest_start 2026-09-04
SELECT COUNT(*) AS instance_rows,
       TO_CHAR(MIN(ssi.datecreated),'YYYY-MM-DD') AS oldest_created,
       TO_CHAR(MAX(ssi.datecreated),'YYYY-MM-DD') AS newest_created,
       TO_CHAR(MIN(ssi.startdate),'YYYY-MM-DD') AS oldest_start,
       TO_CHAR(MAX(ssi.startdate),'YYYY-MM-DD') AS newest_start
FROM scheduledscriptinstance ssi

-- Q5 (19:39) 3 rows — COMPLETE 4910, CANCELED 51, FAILED 4
SELECT ssi.status, COUNT(*) AS n FROM scheduledscriptinstance ssi
GROUP BY ssi.status ORDER BY COUNT(*) DESC

-- Q6 (19:41) 23 rows — deployment field-change notes (2 deployments, both creations)
SELECT sn.id, TO_CHAR(sn.date,'YYYY-MM-DD HH24:MI') AS changed, sn.recordid, sn.record, sn.field,
       sn.oldvalue, sn.newvalue, sn.name AS changed_by, sn.role, sn.context, sn.recordtypeid
FROM systemnote sn
WHERE sn.recordid IN (5344,3644,4959,3749,3750,1197,1199,4057,3999,4001,4000,4004,3996,4010,2482,
                      3793,2679,2672,2673,492,3139,936,4103,1188,2543,4722,1970,4774,2700,2742,2692,2747,3304)
  AND (UPPER(sn.field) LIKE '%DEPLOY%' OR UPPER(sn.field) LIKE '%STATUS%'
       OR UPPER(sn.field) LIKE '%SCHEDUL%' OR UPPER(sn.field) LIKE '%RECURR%')
ORDER BY sn.date DESC FETCH FIRST 200 ROWS ONLY

-- Q7 (19:42) 2 rows — 5344 (9 notes 2026-06-20 by 3894), 4959 (13 notes 2026-01-27 by -5)
SELECT sn.recordid, sn.record, COUNT(*) AS notes, TO_CHAR(MIN(sn.date),'YYYY-MM-DD') AS first_note,
       TO_CHAR(MAX(sn.date),'YYYY-MM-DD') AS last_note, MAX(sn.name) AS last_by
FROM systemnote sn
WHERE sn.recordtypeid = -418 AND sn.recordid IN (…same 33 ids…)
GROUP BY sn.recordid, sn.record ORDER BY MAX(sn.date) DESC

-- Q8 (19:42) 1 row — n 1255, oldest 2026-01-08, newest 2026-09-03
SELECT COUNT(*) AS n, TO_CHAR(MIN(sn.date),'YYYY-MM-DD') AS oldest, TO_CHAR(MAX(sn.date),'YYYY-MM-DD') AS newest
FROM systemnote sn WHERE sn.recordtypeid = -418

-- Q9 (19:45–19:47) five variants grouping scriptnote by script / scriptdeployment:
--    all returned "An unexpected SuiteScript error has occurred". Replaced by R5.
-- Q9a (19:47) 3 rows — AUDIT 427, ERROR 161, DEBUG 100
SELECT sn.type, COUNT(*) AS entries FROM scriptnote sn GROUP BY sn.type ORDER BY COUNT(*) DESC

-- Q10 (19:45) 1 row — n 684, oldest 2026-09-01, newest 2026-09-04, errors 157
SELECT COUNT(*) AS n, TO_CHAR(MIN(sn.date),'YYYY-MM-DD') AS oldest, TO_CHAR(MAX(sn.date),'YYYY-MM-DD') AS newest,
       SUM(CASE WHEN sn.type = 'ERROR' THEN 1 ELSE 0 END) AS errors
FROM scriptnote sn

-- Q11 (19:49) 8 rows — SWF 233100, (null) 32430, UIF 1706, SCH 614, MPR 493, SLT 286, SDF 23, RST 1
SELECT sn.context, COUNT(*) AS notes, COUNT(DISTINCT sn.recordtypeid) AS record_types,
       TO_CHAR(MIN(sn.date),'YYYY-MM-DD') AS oldest, TO_CHAR(MAX(sn.date),'YYYY-MM-DD') AS newest
FROM systemnote sn WHERE sn.date >= TO_DATE('2026-07-01','YYYY-MM-DD')
GROUP BY sn.context ORDER BY COUNT(*) DESC

-- Q12 (19:49) 26 rows — record/field footprint of SCH and MPR contexts (Table 8)
SELECT sn.context, sn.recordtypeid, sn.field, COUNT(*) AS notes,
       COUNT(DISTINCT TO_CHAR(sn.date,'YYYY-MM-DD')) AS active_days, TO_CHAR(MAX(sn.date),'YYYY-MM-DD') AS last_day
FROM systemnote sn
WHERE sn.date >= TO_DATE('2026-07-01','YYYY-MM-DD') AND sn.context IN ('SCH','MPR','MAPREDUCE','SCHEDULED')
GROUP BY sn.context, sn.recordtypeid, sn.field ORDER BY COUNT(*) DESC FETCH FIRST 60 ROWS ONLY

-- Q13 (19:50) 7 rows — 159 CUSTOMRECORD_8299_CLIENT_AUDIT_TRAIL, 163 CUSTOMRECORD_OB_ORG_TREE,
--    1959 CUSTOMRECORD_B360_SCHEDULED_JOB, 2107 CUSTOMRECORD_FAM_RECENT_DIAGNOSIS, 2117 CUSTOMRECORD_FAM_PROCESS,
--    2170 CUSTOMRECORD_C360_GLOBAL_CONFIG, 2171 CUSTOMRECORD_CASH360_ENTITY_DATA
SELECT crt.internalid, crt.scriptid, crt.name FROM customrecordtype crt
WHERE crt.internalid IN (1959,2170,2171,2117,2107,159,163) ORDER BY crt.internalid

-- Q14 (19:50) 40 rows — B360 job record 1 transitions 13–17 Jul (FAILED→RUNNING→COMPLETED on 17 Jul)
SELECT sn.recordid, sn.record, sn.field, sn.oldvalue, sn.newvalue, TO_CHAR(sn.date,'YYYY-MM-DD HH24:MI') AS changed, sn.context
FROM systemnote sn WHERE sn.recordtypeid = 1959 AND sn.date >= TO_DATE('2026-07-10','YYYY-MM-DD')
ORDER BY sn.date DESC FETCH FIRST 40 ROWS ONLY

-- Q15 (19:51) 2 rows — 2026-09-08: 1, 2026-09-10: 6
SELECT TO_CHAR(fa.created,'YYYY-MM-DD') AS d, COUNT(*) AS batches
FROM customrecord_2663_file_admin fa WHERE fa.created >= TO_DATE('2026-06-24','YYYY-MM-DD')
GROUP BY TO_CHAR(fa.created,'YYYY-MM-DD') ORDER BY TO_CHAR(fa.created,'YYYY-MM-DD')

-- Q16 (19:51) 1 row — total 7, last_created 2026-09-10
SELECT COUNT(*) AS total, TO_CHAR(MAX(fa.created),'YYYY-MM-DD') AS last_created,
       TO_CHAR(MAX(fa.lastmodified),'YYYY-MM-DD') AS last_modified
FROM customrecord_2663_file_admin fa

-- Q17 (19:51) 1 row — due_schedules 0
SELECT COUNT(*) AS due_schedules FROM customrecord_2663_payment_schedule ps

-- Q18 (19:52) 5 rows — FAILED 2025-08-10..13 (1 each); CANCELED 51 with null date
SELECT TO_CHAR(ssi.startdate,'YYYY-MM-DD') AS d, ssi.status, COUNT(*) AS n
FROM scheduledscriptinstance ssi WHERE ssi.status <> 'COMPLETE'
GROUP BY TO_CHAR(ssi.startdate,'YYYY-MM-DD'), ssi.status ORDER BY 1

-- Q19 (19:52) 4 rows — 2025-08: 4, 2026-08: 4368, 2026-09: 544, null: 51
SELECT TO_CHAR(ssi.startdate,'YYYY-MM') AS m, COUNT(*) AS n
FROM scheduledscriptinstance ssi GROUP BY TO_CHAR(ssi.startdate,'YYYY-MM') ORDER BY 1

-- Q20 (19:52) 67 rows — daily 06-01..06-24, gap, daily 07-24..09-04
SELECT TO_CHAR(sn.date,'YYYY-MM-DD') AS d, COUNT(*) AS writes
FROM systemnote sn
WHERE sn.recordtypeid = 2170 AND sn.field = 'CUSTRECORD_CASH360_CONF_LAST_MR_RUN'
  AND sn.date >= TO_DATE('2026-06-01','YYYY-MM-DD')
GROUP BY TO_CHAR(sn.date,'YYYY-MM-DD') ORDER BY 1

-- Q21 (19:52) 3 rows — RUNNING 97, FAILED 85, COMPLETED 12 (2026-01-01..07-17)
SELECT sn.newvalue AS status, COUNT(*) AS n, TO_CHAR(MIN(sn.date),'YYYY-MM-DD') AS first_d, TO_CHAR(MAX(sn.date),'YYYY-MM-DD') AS last_d
FROM systemnote sn WHERE sn.recordtypeid = 1959 AND sn.field = 'CUSTRECORD_B360_JOB_LAST_RUN_STATUS'
GROUP BY sn.newvalue ORDER BY COUNT(*) DESC

-- Q22 (19:53) 1 row — -117 SUBSIDIARYNEXUSMAP.KNEXUS, 233100 notes, 3 records
SELECT sn.recordtypeid, sn.field, COUNT(*) AS notes, COUNT(DISTINCT sn.recordid) AS recs,
       TO_CHAR(MIN(sn.date),'YYYY-MM-DD') AS first_d, TO_CHAR(MAX(sn.date),'YYYY-MM-DD') AS last_d
FROM systemnote sn WHERE sn.context = 'SWF' AND sn.date >= TO_DATE('2026-07-01','YYYY-MM-DD')
GROUP BY sn.recordtypeid, sn.field ORDER BY COUNT(*) DESC FETCH FIRST 10 ROWS ONLY

-- Q23 (19:53) 16 rows — 3552/day 20 Aug..3 Sep (3478 on 21 Aug), 2368 on 4 Sep to 16:31; user -4
SELECT TO_CHAR(sn.date,'YYYY-MM-DD') AS d, COUNT(*) AS notes, COUNT(DISTINCT sn.recordid) AS recs,
       MIN(sn.name) AS by_min, MAX(sn.name) AS by_max
FROM systemnote sn WHERE sn.context = 'SWF' AND sn.recordtypeid = -117 AND sn.date >= TO_DATE('2026-08-20','YYYY-MM-DD')
GROUP BY TO_CHAR(sn.date,'YYYY-MM-DD') ORDER BY 1

-- Q24 (19:53) 1 row — n 1613940, first_d 2026-01-01
SELECT COUNT(*) AS n, TO_CHAR(MIN(sn.date),'YYYY-MM-DD') AS first_d
FROM systemnote sn WHERE sn.context = 'SWF' AND sn.recordtypeid = -117

-- Q25 (19:55) 3 rows — sub 1: 64 notes, 1 value; sub 2: 1152 notes, 18 values; sub 3: 1152 notes, 18 values
SELECT sn.recordid, sn.record, COUNT(*) AS notes, COUNT(DISTINCT sn.oldvalue) AS distinct_old,
       MIN(sn.oldvalue) AS sample_old, MIN(sn.newvalue) AS sample_new,
       TO_CHAR(MIN(sn.date),'YYYY-MM-DD HH24:MI') AS first_d, TO_CHAR(MAX(sn.date),'YYYY-MM-DD HH24:MI') AS last_d
FROM systemnote sn WHERE sn.context = 'SWF' AND sn.recordtypeid = -117 AND sn.date >= TO_DATE('2026-09-04','YYYY-MM-DD')
GROUP BY sn.recordid, sn.record ORDER BY sn.recordid

-- Q26 (19:55) 2 rows — 216 RELEASED runasadmin T; 316 TESTING runasadmin T islogenabled T
SELECT w.internalid, w.scriptid, w.name, w.releasestatus, w.recordtype, w.initonschedule, w.runasadmin, w.islogenabled
FROM workflow w WHERE w.recordtype = -117 AND w.isinactive = 'F' ORDER BY w.internalid

A.3 Reducers and searches

-- R1 (19:38) sqlReduce over Q1's SELECT (680 rows) — status banding
const r = rows.main;
const prov = x => x.frombundle ? ('bundle ' + x.frombundle) : 'local';
const band = x => {
  if (x.script_inactive === 'T') return 'A-script-inactive';
  if (x.isdeployed !== 'T') return 'B-undeployed';
  if (x.status === 'SCHEDULED') return 'D-scheduled-live';
  if (x.status === 'TESTING') return 'C-testing';
  return 'C-notscheduled';
};
const byBand = H.countBy(r, band);
const byStatus = H.countBy(r, x => (x.status||'NULL') + '|isdeployed=' + (x.isdeployed||'NULL'));
const byProv = H.countBy(r, prov);  const byType = H.countBy(r, 'scripttype');
const local = r.filter(x => !x.frombundle);
const live = r.filter(x => band(x) === 'D-scheduled-live').map(x => ({ /* script, dep, status, queue, pri, log, file */ }));
const bundles = H.countBy(r.filter(x=>x.frombundle), 'frombundle');
return { total:r.length, byBand, byStatus, byProv:{local:byProv.local||0, bundleOwned:r.length-(byProv.local||0),
         distinctBundles:Object.keys(bundles).length, bundles}, byType, liveCount:live.length, live, localCount:local.length };
-- Result: total 680; D-scheduled-live 28; B-undeployed 26; C-notscheduled 626; local 37; bundles 15.

-- R2 (19:41) scriptEval N/search scheduledscriptinstance, all rows (4,914), grouped per deployment:
--   n, complete, canceled, failed, first/last start, lastComplete(End), d30, d60, median/p90 duration (min).
--   Columns: scriptdeployment.internalid, scriptdeployment.scriptid, script.internalid, script.name, status,
--   startdate, enddate, datecreated, percentcomplete. runPaged pageSize 1000. Dates parsed from "M/D/YYYY h:mm am".
-- R2b (19:41) same search restricted to deployments 1188,4103,3749,3750,1197,2672,4001,2543,3164,3999,4010:
--   1188 n30; 1197 n20 (5×4 Sundays); 3749 n20; 3999 n31; 4010 n31; 4103 n31; 3750, 4001, 2672, 2543 absent.

-- R3 (19:45) scriptEval N/search, startdate onorafter 7/1/2026, per-day matrix for
--   936,4959,2482,4722,4010,3644,5344,3750,4001,2543,1986 — n, ok, fail, start hours, maxDur per day.

-- R4 (19:46) scriptEval N/search (full table), calendar 2026-08-05..2026-09-03:
var want={'936':1,'4959':1,'2482':1,'4722':1,'4010':1,'3644':1,'5344':1,'3750':1,'4001':1,'2543':1,'1986':1,'1984':1,'1988':1};
… per deployment: perDayCal (instances per expected day), missingDays, failed[], hours{}, medMin, p90Min, maxMin,
   degraded = durations > max(3*median, 5) …
-- Result: missingDays [] for 936, 4959, 2482, 4722, 4010, 3644, 1984, 1986, 1988; 5344 Mondays only (4/4);
--   3750, 4001, 2543 absent; degraded: 1986 on 2026-08-28 (52 m); failed: 1986 ×4 in Aug 2025.

-- R5 (19:47) scriptEval N/search scriptexecutionlog (692 rows, 1–4 Sep) grouped by deployment/script/level.
--   Sonar AI dep 5336 (359 Audit, 129 Error — the agent's own audit trail); PackShip UE 3097 (36 Error);
--   B360 3644 (32 Audit); FAM 4057 (15 Debug, 15 Audit); SCM 1188 (15 Debug); FAM 3999 (12); 2673 (6); 4000 (4); 4010 (3).

-- R6 (19:50) sqlReduce — business-object series
SELECT TO_CHAR(sn.date,'YYYY-MM-DD') AS d, sn.context, sn.recordtypeid, sn.field, COUNT(*) AS n, COUNT(DISTINCT sn.recordid) AS recs
FROM systemnote sn
WHERE sn.date >= TO_DATE('2026-06-24','YYYY-MM-DD') AND sn.context IN ('SCH','MPR')
GROUP BY TO_CHAR(sn.date,'YYYY-MM-DD'), sn.context, sn.recordtypeid, sn.field            -- 506 rows
const r = rows.main.map(x=>({d:String(x.d), c:String(x.context), t:String(x.recordtypeid), f:String(x.field), recs:H.num(x.recs)}));
const sig = {
  item360: x => x.c==='MPR' && x.t==='-10' && x.f==='CUSTITEM_ORDER_DELAY_COUNT',
  cash360: x => x.c==='MPR' && x.t==='2170',
  b360:    x => x.c==='MPR' && x.t==='1959' && x.f==='CUSTRECORD_B360_JOB_LAST_RUN',
  famDiag: x => x.c==='SCH' && x.t==='2107',
  famProc: x => x.t==='2117',
  license8299: x => x.c==='SCH' && x.t==='159' && x.f==='CUSTRECORD_8299_CAT_DETAILS',
  orgBrowser: x => x.t==='163',  c360: x => x.t==='2171' };
const days=[]; for(let t=new Date(Date.UTC(2026,5,24)); t<=new Date(Date.UTC(2026,8,4)); t.setUTCDate(t.getUTCDate()+1)) days.push(t.toISOString().slice(0,10));
for (const k in sig) { const m={}; r.filter(sig[k]).forEach(x=>{ m[x.d]=(m[x.d]||0)+x.recs; });
  const base = days.slice(0,42).map(d=>m[d]||0); const obsD = days.slice(42,72);
  const bs = H.stats(base); const med = bs.median;
  const flagged = obsD.filter(d=>{ const v=m[d]||0; return med>0 && v < 0.5*med; });
  out[k]={ baselineMedian:med, p25:bs.p25, p75:bs.p75, baseDaysActive, baseTotal, obsTotal, obsDaysActive, obsMedian, firstActive, lastActive, flaggedDays:flagged, obsSeries }; }
-- Result: item360 median 1 (IQR 0–2.75), obs 119 items / 15 active days, 15 flagged, series
--   0,0,0,0,2,35,1,3,0,0,0,0,4,0,2,2,1,2,0,1,4,3,0,0,0,3,0,54,2,0;
--   cash360 obs 30/30; b360 base 12 (to 17 Jul), obs 0/30; famDiag median 2, 30/30; famProc Sundays 4;
--   license8299 median 2, 30/30; orgBrowser 2 on 3 Sep; c360 6 on 3 days.
-- (A first R6 run compared recordtypeid as string vs number and returned all zeros; discarded as a coding error.)

Appendix B — Schema verification log

Every table, column, field id and record type referenced in this report, and how it was verified against the live account. Proposed identifiers in §11 are marked as such and do not exist.

Appendix C — Assumptions

Appendix D — Scope limitations

• Instance table retention ≈ 30 days. 4,368 rows Aug 2026, 544 Sep 2026, 4 FAILED rows Aug 2025, 51 CANCELED with no dates (Q19, Q18). Nothing before 5 Aug 2026 is observable at the instance level.
• Script execution log retention 4 days (684 rows, 1–4 Sep; Q10). The instance × log cross-classification was possible only for 1–4 Sep (R5). 129 of the 161 ERROR rows are this agent's own tool-error audit entries.
• No script/scriptdeployment column on scheduledscriptinstance in SuiteQL (S3b; S3c errors). Attribution via N/search joins (S8b).
• scriptnote.script and .scriptdeployment error in SuiteQL today (Q9). N/search on scriptexecutionlog used instead (R5).
• Deployment schedule is the recurringevent JSON on the record, not a SuiteQL column; next scheduled run is not exposed (S6, S7).
• System notes for deployments start 2026-01-08 and exist for 2 of 33 scheduled deployments (Q7, Q8).
• Source access: files 89907, 24931, 24958, 91219, 25732 returned “You do not have access to the media item” to the Administrator role (S10). Only 4063 (EBP), 75871 (STE) and 15770/15769 (Item360) were readable.
• Workflow frequency is not on the workflow table (Q2).
• Baseline 6 weeks, not 8: no system-note history before 24 June for the Cash 360 and Item360 signals.
• Amount-based backlog was not meaningful: no critical process creates transactions.

Appendix E — Glossary

Dead-man's switch / heartbeat monitor

A monitor that expects a periodic signal and alerts when the signal does not arrive — detecting absence rather than error.

Dormant deployment

A script deployment that cannot fire again under its current configuration.

FMEA · RPN

Failure Mode and Effects Analysis; Risk Priority Number = Severity × Occurrence × Detection. Adapted here as Severity × Detectability × Impact.

Instance

A row in scheduledscriptinstance: one attempt to run a scheduled or map/reduce deployment (map/reduce runs produce one row per stage).

Missed run

An expected window with no instance. The essay's “silent failure”.

No-output run

A completed instance that changed no business objects. The brief's “zombie run”.

RAG

Red / Amber / Green status convention. In this report: red = High, amber = Medium or attention, blue (brand) = healthy.

Recorded failure

A failure that produced evidence — a FAILED/CANCELED instance or an ERROR log entry. The brief's “loud failure”.

System note

NetSuite's field-level audit trail (systemnote): who changed which field on which record, when, in which execution context.

5C

Condition · Criteria · Cause · Effect · Recommendation — the standard structure of an audit observation.

Appendix F — Source documents & design tokens

F.1 Source document 1 — the silence essay (verbatim)

Silence is a NetSuite failure mode: the scheduled script never started, so it logged no error.

Error dashboards can only describe executions that exist. A disabled deployment, broken schedule, expired credential, or missed trigger may produce no run to inspect. The absence of failures looks reassuring because the work never entered the measurement system.

Give every critical scheduled process a heartbeat. Record the expected start window, the last successful start, the last successful completion, the number of business objects processed, and the owner of a missed run.

Alert on absence, not only on exceptions. Then use a saved search to confirm that the expected invoices, fulfillments, allocations, or journals appeared in the business state.

A clean error log proves only that no recorded execution failed. It does not prove that the process ran. For unattended work, the first telemetry question is simple: did the job show up when the business expected it?

F.2 Source document 2 — Clarity Blue branding guidelines (verbatim)

Tone & Style: minimalist, modern, polished; avoid clutter; short sentences, precise wording, whitespace to guide attention.
Voice: neutral and professional, focused on clarity; present facts first, then insights.
Typography: Headlines Inter Bold or Helvetica Neue Bold 24–32pt; Subheads Inter SemiBold 18–22pt; Body Inter Regular or Helvetica Neue Regular 11–12pt, 1.6× line height; Callouts Inter Medium italic or small highlight block.
Layout & Spacing: heavy whitespace, generous margins (1.5–2 inches); single-column layout with clear section breaks; safe area for footer text (24px bottom/right).
Color Palette: Base White #FFFFFF; Text Charcoal #212121; Accent Electric Blue #007AFF used sparingly (charts, key metrics); Neutral Light Gray #EAEAEA for subtle dividers.
Charts & Graphs: simple line or bar charts with minimal gridlines; Electric Blue to highlight key trends or metrics; axes and labels Charcoal 9–10pt, no bold; avoid pie/donut charts.
Callouts & Transparency: key findings in a small highlight box (Light Gray border and background); risks/assumptions in italic text or a light-gray info box; disclaimer text 9pt Charcoal at bottom.
Branding: company name bottom-right, small (8–9pt); no logo or watermark unless requested.

F.3 Clarity Blue · Assurance extension (applied in this version)

The base palette, typography, spacing and chart rules above are unchanged. The following were added for audit communication; each is documented so the deviation is deliberate and reversible.

F.4 Field notes relied upon (excerpt, verbatim)

- Script execution logs live in the `scriptnote` table (cols: script, scriptdeployment, type, date, title, detail).
- Scripts: SCRIPTLET 384, RESTLET 183, USEREVENT 181, MAPREDUCE 143, CLIENT 101, SCHEDULED 97 — mostly bundle-owned.
- Primary user Tim Dietrich (employee 158), role 3 Administrator, default subsidiary 2.
- Subsidiaries: 1 Parent Company, 2 Subsidiary 1, 3 Subsidiary 2, 4 xElim.

Disclaimer

This is a read-only, point-in-time review performed on 4 September 2026 under the Administrator role. No record, field, script, deployment, workflow or saved search was created, modified or deleted. Results are measured against the run expectations in §5, which in this engagement were delegated by the account owner and are therefore assumed. Retention limits of the instance table (about 30 days) and the script execution log (4 days) bound what could be observed. The control design in §11 is a proposal; nothing described in it has been implemented. Version 2.0 restructures and re-presents the same evidence as version 1.0; no figure has changed.