Security Posture Score Computation Integrity Automation: A Feature That Had Never Once Computed Anything

A function that dies on its very first database call produces the same outward silence as a feature that genuinely has nothing to report yet — a security-posture score of zero categories computed looks, from a dashboard, exactly like a workspace that simply has not been scored recently. The difference between "nothing has happened yet" and "this has never once worked" is invisible from the outside precisely when the failure happens at the earliest possible point, before anything the feature does could leave a partial, diagnosable trace.

The security-posture scoring function's job is to compute a category-by-category score describing how well a workspace's own security practices measure up, then store that computed score for the dashboard to display. Its very first step — before any of that scoring logic runs — looks up the list of accounts it needs to score. That lookup queried a table by a name that does not exist in the real, live database at all; the real table holding account records lives under a different name entirely. Every single invocation of the function threw an error at that exact first line and terminated immediately, meaning none of the scoring logic beneath it had ever executed, for any workspace, since the feature existed.

Correcting the table name alone surfaced a second, smaller defect in the same code path: the final step, an upsert meant to save a scoring recommendation, specified a combination of columns to resolve conflicts against that had no matching unique index in the live database — meaning even after the table lookup was fixed, this specific write would still have failed with nothing to conflict against. A migration adding the missing index closed that gap in the same pass.

A distinct but closely related defect, found in the same broader investigation into database-write mismatches, lived in a completely different function: an automation rule capable of adjusting a contact's lead score wrote its adjustment to a table name that also does not exist under that name in the real schema — the correct table uses a different name entirely, and stores the point adjustment under a different column name than the code supplied. Every automation-triggered score adjustment failed identically and silently, for the same underlying reason as the posture-scoring defect: a name in the code that had drifted away from the name in the actual, live database.

Both fixes were confirmed, not merely asserted, by a direct production probe run after they shipped: the corrected posture-scoring function was invoked for real and measured writing an actual score — a specific overall number and its underlying category recommendations — for the first time since the feature existed.

A workspace opens its own security-posture dashboard expecting to see a scored breakdown across categories — access control, data handling, and others the feature is designed to evaluate. Before the fix, the underlying computation function has already failed and exited at its very first database call, every time it has ever run, so there is nothing to show and no specific error pointing at why. After the fix, the identical dashboard request triggers a function that successfully looks up the account, computes a real category-by-category score, and saves both the overall number and the specific recommendations behind it — visible for the first time since the feature was built.

Centriu Flow's security-posture scoring function now executes its full computation rather than terminating on its first database call, and automation-triggered lead-score adjustments are now actually recorded — closing a gap where two related scoring mechanisms had produced zero real output since they existed.

This automation restores the ability of two scoring computations to actually execute and record their results — it does not change what categories a posture score evaluates or how lead-score point values are decided; those design choices were already correct and are unaffected by this fix.

A dashboard showing no computed score is ambiguous by default — it could mean nobody has triggered the computation yet, or it could mean the computation has never once been capable of succeeding. Centriu's fix was found precisely by refusing to accept that ambiguity: tracing the function's own first line of execution directly, rather than inferring from an empty dashboard that the feature simply hadn't been used.