Sheepdog Prosperity Partners
Due Diligence

Foundry Actions Framework for Audit-Trail Discipline: Risk-Rating Changes, Regulatory Documentation, and the Examiner-Ready Audit Log

by | May 15, 2026 | DD Tech Lab | 0 comments

What you’ll be able to do after reading this. Read an ActionType specification and understand what state change it captures. Recognize the bypass paths that exist in any platform deployment and the controls the institution must add separately. Read an AuditEntry record and verify it captures the regulatory-defensibility minimums. Run the ten examiner-ready queries from the companion bundle against the institution’s audit log. Document the institution’s audit-trail discipline in workpapers that survive SR 11-7 §V documentation review, PCAOB AS 2201 internal-controls audit, and FFIEC BSA/AML examination.

Terms anchored before the article walks them.

  • ActionType — a configured state-change verb (ElevateRiskRating, DismissSanctionsHit, EscalateToEDD). Each ActionType specifies a target ontology object, required inputs, authorization level, and the audit-entry side effect.
  • AuditEntry — the immutable record produced when an ActionType fires. Conceptually equivalent to a workpaper note recording who made what change to what record with what supporting evidence.
  • ObjectSet — a structured set of ontology objects passed as input to an ActionType. The platform validates that the set is non-empty and contains allowed types; the validation translates the institution’s evidence-linkage expectation into a platform-level gate.
  • RBAC (Role-Based Access Control) — the institution’s structured permission system. The Actions framework checks the executing user’s RBAC role against the ActionType’s authorization_level requirement at submission time.
  • Bypass path — any way to change ontology state that does NOT fire an ActionType. The companion bundle enumerates six bypass paths (direct dataset edits, admin overrides, transform redeployments, emergency backfills, API direct writes, ontology object undelete). Closing the bypass paths through institutional controls is non-optional.
  • SR 11-7 / OCC 2011-12 — joint Federal Reserve and Office of the Comptroller of the Currency guidance on model risk management. §V covers documentation expectations; this article’s audit-trail discipline supports §V compliance but does not, by itself, satisfy §V.
  • PCAOB AS 2201 — Public Company Accounting Oversight Board Auditing Standard 2201 — An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements. The AuditEntry population is what external auditors sample from for SOX §404 testing.

A risk-rating change is a regulated event. So is an escalation to enhanced due diligence, a sanctions-hit dismissal, a beneficial-ownership update, and a hundred other state changes that flow through a due-diligence workflow on any given day. Each one requires a documented chain: a named analyst, an identifiable set of supporting evidence, an approval at the appropriate authority level, and a timestamp the examiner can rely on later. The cost of failing to produce that chain when asked is material. SR 11-7 §V deficiency findings, SOX §404 control-failure citations, FFIEC examination criticism, and in extreme cases enforcement actions tied to specific named transactions all start with the same question: show me the documentation.

Most institutions implement this documentation chain through some combination of email, ticketing systems, spreadsheet logs, and informal notes in case-management tools. The fragmentation produces predictable failure modes. The analyst who made the change has since left the firm. The supporting-evidence link points to a deprecated SharePoint location nobody can reach. The approval was given verbally in a Tuesday standup and nobody wrote it down. Each individual gap is recoverable; the cumulative pattern across thousands of decisions per year is what regulators find under any serious examination — and the consequences of the cumulative pattern are what the institution actually has to pay.

This article walks the Foundry Actions framework as a primitive for replacing the fragmented documentation pattern with a single native mechanism that ties every state change in the ontology to a structured, immutable audit entry. The framework is configuration-heavy and code-light, which is part of why it works at scale — but the editorial center of this article is not the configuration. The center is the discipline the institution has to maintain on top of the framework’s primitives. The framework provides primitives; the institution provides the discipline. Either alone is insufficient.

The audit-trail problem regulators actually examine

Examiners do not ask whether the institution has an audit trail in the abstract. They ask whether the institution can reconstruct a specific decision, on a specific date, by a specific analyst, with specific supporting evidence, on demand.

Consider what that question looks like in practice. The examiner has selected counterparty 0042 from a sample of forty. The institution elevated this counterparty’s risk rating from B+ to high on April 15. The examiner asks: who made that decision, what was the documented justification, what evidence supported it, and what was the approval chain. The institution has thirty minutes before the meeting moves on. The institution either produces the chain in one query or it doesn’t.

Across the past decade of public bank enforcement actions where audit-trail deficiencies appear as a contributing finding — including the 2020 Office of the Comptroller of the Currency enforcement action against Capital One on AML program deficiencies, the 2018 New York Department of Financial Services action against Standard Chartered on transaction monitoring, and the 2024 FinCEN action against TD Bank on multi-year BSA program failures — the consistent thread is the same. The deficiency is rarely “we did not have an audit trail.” The deficiency is “we had an audit trail but could not reconstruct the specific decision the examiner asked about, on demand, within the time the examination allowed.”

The Foundry Actions framework is one platform-level answer to that problem. It does not eliminate the documentation expectation, and it does not substitute for the institution’s control environment. It changes where the documentation lives and how the institution constructs it.

Actions framework primitives

The framework rests on four primitives. Understanding what each one does — and what each one does not do — is the foundation for everything else in this article.

An ActionType is a configuration object that names a category of state change: ElevateRiskRating, DismissSanctionsHit, EscalateToEDD, ChangeBeneficialOwner, TerminateEDD, and so on. A note on the names themselves. Palantir Foundry does not ship a canonical list of pre-defined ActionTypes; the framework provides the ActionType primitive and the institution defines the specific names that map to its actual decision workflows. The names above are illustrative — they are the names this article and the DD Tech Lab sub-series use consistently, but a different institution could legitimately use RaiseRiskTier, ClearSanctionsMatch, InitiateEnhancedDueDiligence, or any other PascalCase verb-phrase that reads naturally to the analysts who invoke them. The convention is institutional; the rigor is in the configuration, not in the lexical choice. Each ActionType specifies a target ontology object (typically Counterparty), required inputs, authorization level, side effects, and post-execution hooks. An ActionType is the platform-level definition of a regulated event class.

The required-inputs constraint set is the platform’s enforcement of what evidence the analyst must collect before the state change can fire. For the ElevateRiskRating ActionType, the required inputs typically include the new rating value (constrained to an enum strictly higher than the current rating), a justification text field with a minimum length, and a supporting-evidence ObjectSet that must contain at least one of {AdverseMediaMention, SanctionsHit, TransactionAnomaly}. The platform enforces these constraints at submission time. The analyst cannot bypass them by working around the UI.

The side-effects specification is the chain of writes the ActionType produces when it fires. Three writes typically: an update to the target object’s risk-rating field, an update to its last-risk-change timestamp, and the creation of a new AuditEntry ontology object containing the full decision record. The AuditEntry is the documentation artifact the examiner ultimately reads.

The post-execution hooks are conditional notifications and queue routings: critical-rating elevations notify the compliance committee distribution list; supporting evidence containing a SanctionsHit routes the case to the regulatory-filing review queue with a one-business-day SLA. These hooks connect the documentation event to downstream operational workflows without requiring custom code.

The companion repository at /articles/005_actions_framework_audit_trail_discipline/action_templates/risk_rating_change_action.yaml ships a full ElevateRiskRating specification implementing all four primitives. Here is the core of that specification, annotated so the practitioner can read it without prior Foundry exposure:

ActionType: ElevateRiskRating              # the name of this state-change verb
target_object: Counterparty                # which ontology object this acts on
authorization_level: senior_analyst_or_above  # who's permitted to invoke it

required_inputs:                           # the analyst MUST provide all of these before submission
  new_risk_rating:
    type: enum
    allowed_values: [medium, high, critical]
    constraint: must be strictly higher than current Counterparty.risk_rating
  justification:
    type: text
    min_length: 200_characters             # platform-enforced floor; substantive justifications typically run 400-800
  supporting_evidence:
    type: ObjectSet                        # a structured set of ontology objects
    constraint: must contain at least one of the allowed_types listed below
    allowed_types:
      - AdverseMediaMention
      - SanctionsHit
      - TransactionAnomaly
      - InternalEscalationNote
  dual_approval_required:
    type: boolean
    derived: auto-computed (true if new_risk_rating == "critical")

side_effects:                              # what fires when the action submits and validates
  - update:   Counterparty.risk_rating ← new_risk_rating
  - update:   Counterparty.last_risk_change_timestamp ← current_timestamp
  - create:   AuditEntry (immutable=true) capturing actor, role, timestamp, prior/new state, justification, evidence IDs

post_execution:                            # conditional hooks that fire AFTER the side effects
  - condition: new_risk_rating == "critical"
    action: notify compliance_committee_distribution_list
  - condition: any(e.object_type == "SanctionsHit" for e in supporting_evidence)
    action: queue_for_review (regulatory_filing_review, SLA = 1 business day)

What the practitioner does with this specification. Read it as the regulator-defensible contract for what happens when an analyst elevates a counterparty’s risk rating. Every field maps to a regulatory expectation: justification to SR 11-7 §V documentation; supporting_evidence to FFIEC BSA/AML evidence-linkage expectations; dual_approval_required for critical to segregation-of-duties under PCAOB AS 2201; the immutable AuditEntry to SOX §404 internal-controls evidence retention. The platform-level enforcement of each constraint is what distinguishes this from an honor-system documentation pattern in spreadsheets or email.

Immutability and audit-entry design

The single most important property of an AuditEntry is that it is immutable. Once written, the entry cannot be edited, deleted, or altered. If the institution discovers that the AuditEntry recorded a wrong value — wrong counterparty ID, wrong analyst attribution, wrong supporting-evidence reference — the institution does not fix the entry. The institution creates a new AuditEntry that supersedes the prior one, referencing the prior action_id in its superseded_by field. The prior entry remains in the audit log indefinitely. The institution’s supersession chain becomes part of the audit record.

This is the editorial centerpiece of the framework, and it is also where institutions most often confuse the platform’s behavior with their own discipline obligations. The platform stores the AuditEntry as a row in an ontology-backing dataset. That dataset is, at the storage layer, a file (or set of files) on a cloud object store. Files on cloud object stores can be edited by sufficiently privileged administrators. The immutability that matters for regulatory purposes is the institution’s discipline of routing every regulated state change through an ActionType and never editing AuditEntry rows directly. The platform supplies the primitive — the AuditEntry’s immutable=true flag, the supersession-via-new-entry pattern, the retention policy. The institution supplies the discipline — the bypass-control framework that ensures the platform-level primitive is the only path that actually fires for regulated changes.

The companion bundle’s bypass_controls/bypass_audit_controls.yaml enumerates six bypass paths that exist in any Foundry deployment and the controls the institution must implement separately. They include direct dataset edits via Pipeline Builder or Code Repositories, administrative overrides via the platform-admin console, transform redeployments that change regulated fields in batch logic, emergency backfills via operations-team escalation, API direct writes via service-account credentials, and ontology-object undelete operations. Each path has its own recommended control. Skipping the bypass-control work is the single most common reason institutions believe they have an audit trail but cannot pass an examination.

The AuditEntry schema itself is straightforward: action_id (UUID), action_type, actor and actor_role (snapshot at execution time, not retroactively altered by later role changes), approver and approver_role for dual-approval flows, timestamp, target_object_id, prior_state and new_state field snapshots, justification text, supporting_evidence_ids (array of ontology object IDs), supporting_evidence_snapshot_uri (URI to a frozen snapshot of the evidence content as of decision time), immutable flag, superseded_by, and retention_policy. The full JSON Schema is in the companion bundle at audit_log/risk_decision_audit_log_schema.json. The supporting_evidence_snapshot_uri field deserves particular attention: it preserves the evidence content as the analyst actually saw it, separate from the underlying ontology objects which may drift, get re-resolved, or get deleted afterward. Without the snapshot, the examiner asking “what did the analyst actually rely on?” gets answered by current evidence content, which may bear no resemblance to what the analyst saw.

Authorization-level enforcement

The Foundry Actions framework enforces authorization at submission time by evaluating the executing user’s RBAC role against the ActionType’s authorization-level requirement. The framework does not define the institution’s RBAC model; the institution defines its own role hierarchy and maps generic Foundry-side role names like senior_analyst and compliance_manager to its actual organizational roles in deployment configuration.

This separation matters for two reasons. First, it lets the same ActionType definition work across institutions with materially different RBAC structures (a Tier-1 bank with twelve analyst tiers and a regional advisory shop with three may both deploy the same ElevateRiskRating template). Second, it puts the segregation-of-duties enforcement at the institution’s RBAC layer, where the institution has the necessary context to enforce it correctly. The framework verifies role membership; the institution defines which roles can co-exist on the same individual.

For critical-rating elevations and other high-impact actions, the framework supports dual-approval flows. An ActionType can declare dual_approval_required: true (or derive the flag conditionally — true when new_rating equals “critical”, false otherwise). When dual approval is required, the action does not fire on the executing analyst’s submission alone; it routes to an approver whose role is named in the dual_approver_role field. The approver must be a different user than the executor (the framework enforces this), and the approver must hold the required role at the moment of approval (the framework re-checks). The resulting AuditEntry captures both users and both roles, so the segregation-of-duties trail is preserved.

The companion bundle’s retention/retention_and_approvals_matrix.yaml ships approval rules for five ActionTypes: ElevateRiskRating (single auth for medium/high, dual for critical), DismissSanctionsHit (dual auth — a dismissed-but-true-positive sanctions hit is among the most consequential audit findings possible), EscalateToEDD (single auth — escalation is conservative), TerminateEDD (dual auth — de-escalation requires the higher bar), and ChangeBeneficialOwner (dual auth — beneficial-ownership data drives SAR/CTR filing decisions). The institution should treat these as starting points and adapt to its own segregation-of-duties policy.

Supporting-evidence linking

Every state-changing action requires a linked evidence ObjectSet. The framework enforces this at the platform level: the supporting_evidence input field on the ActionType specifies an ObjectSet constraint with allowed_types (typically AdverseMediaMention, SanctionsHit, TransactionAnomaly, InternalEscalationNote). An empty ObjectSet is rejected at submission. The framework cannot tell whether the evidence is sufficient — that judgment remains the analyst’s — but it can ensure that the evidence exists, is identifiable, and is logged.

The FFIEC BSA/AML Examination Manual is explicit on this point: risk-rating elevations must tie to specific, identifiable evidence, not to undocumented analyst judgment. The ObjectSet constraint translates that examination expectation into a platform-level gate. An analyst who reaches the elevation screen with no linked evidence cannot proceed.

The deeper discipline question is what counts as evidence for a given action category. An AdverseMediaMention from a credible source citing a specific allegation against a specific counterparty is straightforward evidence. An InternalEscalationNote that simply says “concerned about counterparty 0042 based on overall pattern” is technically a linkable ObjectSet entry, but it is also exactly the kind of thin evidence an examiner will challenge. The framework does not enforce evidentiary substance. The institution’s analyst-training program does. The framework’s contribution is structural: it ensures evidence is linked, identifiable, and retrievable. The institution’s training contribution is qualitative: it ensures the evidence is actually substantive.

A useful operating standard is that any AuditEntry’s supporting_evidence_ids should be sufficient that another analyst, unfamiliar with the case, could read the linked evidence and reach the same risk-rating conclusion. The justification text is the bridge: it ties the evidence to the conclusion. The 200-character minimum on justification length is a regulatory-defensible floor, not a quality measure. Most substantive justifications run 400-800 characters; the analyst-training program should target substantive content, not minimum length.

Regulatory mapping

The Actions framework is one platform-level contribution to satisfying several distinct regulatory documentation expectations. The framing matters: Foundry Actions provides the primitives the institution uses to build a discipline consistent with these regulations. It does not, by itself, satisfy any specific regulator’s requirements.

SR 11-7 §V (Federal Reserve, Supervisory Guidance on Model Risk Management, jointly issued with OCC Bulletin 2011-12 in April 2011) requires model risk management documentation “sufficient to allow parties unfamiliar with the model to understand how the model operates, its limitations, and key assumptions.” For risk-rating models, the AuditEntry’s actor + actor_role + timestamp captures the analyst lineage. The justification field captures the rationale. The supporting_evidence_ids array captures the evidence linkage. The retention_policy ensures the seven-year regulatory minimum. What the framework does not capture is the broader model documentation — model-validation work product, model-development records, ongoing-monitoring documentation — which the institution must maintain separately.

OCC Bulletin 2011-12 is the OCC’s parallel issuance of SR 11-7 §V. The expectations are the same; the Actions framework’s contribution is the same.

SOX §404 (Sarbanes-Oxley Act of 2002, Section 404, Management Assessment of Internal Controls) requires that internal controls over financial reporting be documented, tested, and reported annually. The PCAOB’s auditing standard for SOX work, AS 2201 (An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements), expects the external auditor to sample from a defined population of controls. The AuditEntry table is a queryable, immutable population. The companion bundle’s examiner_ready_query_templates.md provides ten standard queries the auditor will typically run against that population. For the institution’s annual SOX §404 testing, the AuditEntry queries provide the evidentiary substrate; the institution must still test the operating effectiveness of the ActionType controls and the bypass-control discipline. The framework does not test itself.

FFIEC BSA/AML Examination Manual, in its Customer Due Diligence and Enhanced Due Diligence sections, expects that KYC documentation captures the institution’s risk-based determinations, the supporting evidence, and the decision authority. The ElevateRiskRating ActionType’s supporting_evidence ObjectSet constraint translates the evidence expectation into a platform-level gate. The DismissSanctionsHit dual-approval requirement translates the authority expectation. The retention discipline ensures the records survive examination cycles. The piece the institution must add separately is the connection between an AuditEntry-triggered determination and the institution’s actual SAR-filing workflow — the post-execution hook is the platform-side wiring, but the FinCEN-facing filing is institution-side.

FinCEN Customer Due Diligence Rule (31 CFR §1010.230, effective May 11, 2018) imposes beneficial-ownership identification, verification, customer risk-profile development, and ongoing monitoring. The ChangeBeneficialOwner ActionType captures the state-change discipline. Ongoing-monitoring AuditEntries (periodic re-risk-rating actions) capture the §1010.230(b)(5) expectation. Identity verification itself is process-level and happens upstream of the ActionType.

The companion bundle’s regulatory_mapping/regulatory_mapping.yaml walks each regulation in detail, separating Foundry’s contribution from institution responsibility line by line. The discipline of doing this separation explicitly — rather than collapsing platform capability and institutional discipline into a single claim — is what distinguishes a defensible regulatory framing from an overclaim.

Examiner-ready audit log

The audit log is queryable. The institution should not wait for an examination to discover whether the AuditEntry data answers the questions an examiner will ask. The examiner-ready discipline is that the institution runs the standard examiner queries on its own schedule, continuously, before any examination requests them.

The companion bundle’s audit_log/examiner_ready_query_templates.md ships ten queries that examiners typically run within the first hour of an audit-trail review. They include the per-counterparty rating history for the last twenty-four months, every action a specific analyst took in a date range, every sanctions-hit dismissal with its reviewer, every EDD escalation triggered by adverse-media findings in a quarter, every critical-rating elevation with its dual-approval chain in the last twelve months, the data-quality screens for AuditEntries with missing supporting evidence or justifications below the length floor, the supersession-lineage view, the same-day-Action-volume-per-actor segregation-of-duties anomaly screen, and the action-vs-bypass reconciliation across the warehouse and ontology layers.

The tenth query — the action-vs-bypass reconciliation — is the operational discipline that distinguishes an audit log from theatre. The query joins two sets: every Counterparty.risk_rating change captured by the Actions framework (the AuditEntry set), and every Counterparty.risk_rating change reflected in the underlying ontology object’s history (the platform’s native change-history view). Rows that appear in the ontology-history set but not in the AuditEntry set are bypass events: changes that occurred without firing the ElevateRiskRating ActionType. Any non-zero result is an internal-audit ticket the institution should generate the same business day. Running this query continuously, rather than only when an examiner asks, is the operating discipline that the framework’s immutability primitive alone does not produce.

A useful service-level expectation is that any of the ten queries returns in under thirty seconds at typical institutional scale (tens of millions of AuditEntries). If the deployment fails that SLA, the institution should examine the AuditEntry indexing and the supporting-evidence snapshot storage strategy before an examiner asks. The deeper observation is that response time within an examination matters more than any other property of the audit log. An accurate, complete audit log that takes four hours to query is not, operationally, an examiner-ready audit log.

Worked example

Consider counterparty 0042 — fully synthetic; any resemblance to real organizations is coincidental — incorporated in Singapore as Meridian Holdings (Pte) Ltd. A senior analyst, analyst.kowalski, decides on May 15, 2026, to elevate the counterparty’s risk rating from B+ to high. The trigger is an aggregate adverse-media review (the analyst has reviewed an AIP-generated summary from the companion bundle to AIP-Driven Adverse-Media Summarization) showing three open signals: a civil complaint at pleadings stage, a high count of port-documentation holds on the Q1 regulator named-firms list, and an unaddressed disclosure pattern in the company’s Q1 revenue announcement.

The analyst submits ElevateRiskRating with new_risk_rating=high, justification text running 847 characters (covering the three signals and explaining why “high” but not “critical”), and a supporting_evidence ObjectSet containing five items: four AdverseMediaMention objects (AM-001 through AM-004) and one AIPSummary object (ams-2026-05-15-CP-SYNTH-00042).

The framework validates: the analyst’s role (senior_analyst) meets the authorization_level requirement; the new rating exceeds the current rating; the justification length exceeds 200 characters; the evidence set is non-empty and contains allowed types; and dual approval is not required because the new rating is “high” not “critical.” Validation passes.

The side effects fire. Counterparty.risk_rating updates from B+ to high. Counterparty.last_risk_change_timestamp updates to 2026-05-15T15:42:18+00:00. A new AuditEntry is created with action_id a1f7c3d4-9b22-4e58-a3c1-7f2a8d6e4901, capturing the actor, actor_role, timestamp, prior and new states, full justification, supporting_evidence_ids array, supporting_evidence_snapshot_uri pointing to a frozen snapshot of the five evidence objects, immutable=true, and retention_policy=regulatory_7_year_minimum.

The post-execution hooks evaluate. The new rating is not “critical,” so the compliance-committee notification does not fire. The supporting evidence does not contain a SanctionsHit, so the regulatory-filing review queue routing does not fire. The action completes.

Eighteen months later, during a routine FFIEC examination, the examiner asks for the rating history of counterparty 0042 over the prior twenty-four months. The institution runs Query 1 from the companion bundle’s examiner_ready_query_templates.md. The query returns in 1.8 seconds with two rows: the May 15, 2026, elevation from B+ to high, and a prior elevation from B to B+ in November 2025. The examiner drills into the May 15 row. The AuditEntry view shows the actor, the actor’s role at execution time, the justification text, the linked evidence with snapshot URIs preserved, and the absence of a supersession entry (the rating remains at “high”). The examiner moves to the next sample.

This is the operational success state. It does not happen because the framework is in place; it happens because the framework is in place and the institution has maintained the discipline that the framework’s primitives require — the bypass controls, the analyst-training program for substantive justifications, the quarterly self-assessment of the action-vs-bypass reconciliation, the segregation-of-duties enforcement at the RBAC layer. The framework provides the foundation. The institution provides the discipline.

The full worked example, including the example AuditEntry JSON, the linked synthetic evidence corpus from AIP-Driven Adverse-Media Summarization, and the screenshot equivalents showing the analyst-side and examiner-side surfaces, lives in the companion bundle at articles/005_actions_framework_audit_trail_discipline/synthetic_data/example_audit_entry.json. Reading it alongside this article is the operational onramp; deploying it requires the institutional work the framework cannot do on the institution’s behalf.

Grounding cases: when audit-trail failures appeared in enforcement

Four cases ground the audit-trail discipline this article walks. Each carries the agency record, news corroboration, the specific data-pattern signal that a working audit-trail surface would have surfaced (or that the institution’s actual audit trail failed to surface), and a reference to either real public data or the companion bundle’s synthetic-data corpus that an analyst can use to reproduce the technique.

Case 1: Capital One — AML program documentation gaps (2020-2021)

Case 2: Standard Chartered — sanctions-screening evidence chain (2018, with prior 2012 action)

Case 3: TD Bank — BSA program multi-year reconstruction failures (2024)

Case 4: Wells Fargo cross-selling — account-creation audit chain (2016-2020)

What the practitioner does with these references

Each case above pairs an audit-trail failure mode with the data-pattern signal a working AuditEntry surface would have flagged. The workpaper documentation for any Foundry Actions framework deployment should: (1) cite at least two of the cases above as the operational threat scenarios the institution’s audit-trail discipline is designed to detect; (2) document which of the ten examiner-ready queries are run on what cadence to surface each pattern; (3) document the institution’s bypass_controls/ discipline that closes the holes the cases reveal; (4) demonstrate the institutional quarterly self-assessment that runs all four data-pattern signals against the 90-day rolling window.

The framework provides the primitives. The institution provides the discipline. The cases above are not historical curiosities — they are the operational threat scenarios that justify the discipline.

Authority

Companion repository

Foundry Actions Framework‘s full companion bundle lives at github.com/noahrgreen/dd-tech-lab-companion/articles/005_actions_framework_audit_trail_discipline/. It ships the ElevateRiskRating ActionType specification, the AuditEntry JSON Schema, the ten examiner-ready query templates, the six-path bypass-control framework, the retention + approvals matrix, the regulatory mapping, and the worked example AuditEntry that cross-references AIP-Driven Adverse-Media Summarization‘s adverse-media summary. Code Repositories in Foundry covers the Foundry Code Repositories pattern for the cases where an ActionType’s side-effect logic exceeds what the no-code Action editor handles.

Submit a Comment

Your email address will not be published. Required fields are marked *