--- id: TST-PFM-SEC-074 title: Security definition integrity database and service checks kind: integration product_area: platform module: security revision: 2 status: draft source_sha: services-platform: ad3f6a6582843008ed0f5a17b131878d15829af1 repository: services-platform files: - modules/security/tests/integration/db/security-definition-integrity.integration.spec.js implements: - ATS-PFM-SEC-012-02 - ATS-PFM-SEC-012-05 - ATS-PFM-SEC-013-09 environment: local implementation_state: implemented latest_result: not-run latest_run_at: null latest_run_ref: null conformance: not-verified estimated_minutes: 3 isolation: Use the prepared test database and suite-owned fixture rows; retain shared seed records. assertion_evidence: - provenance: test source: >- services-platform:modules/security/tests/integration/db/security-definition-integrity.integration.spec.js#platform security definitions: the integrity triggers - provenance: test source: >- services-platform:modules/security/tests/integration/db/security-definition-integrity.integration.spec.js#security_role_policies_ownership_check: what a role may be made of - provenance: test source: >- services-platform:modules/security/tests/integration/db/security-definition-integrity.integration.spec.js#attaches the role's own customer's policy and Rhythm's, which is the whole of what it may hold - provenance: test source: >- services-platform:modules/security/tests/integration/db/security-definition-integrity.integration.spec.js#refuses another customer's policy, the one way authority could cross a wall through a definition - provenance: test source: >- services-platform:modules/security/tests/integration/db/security-definition-integrity.integration.spec.js#refuses a customer's policy on a built-in role, which must mean the same thing for everybody - provenance: test source: >- services-platform:modules/security/tests/integration/db/security-definition-integrity.integration.spec.js#refuses an archived policy, because an attachment is a live grant - provenance: test source: >- services-platform:modules/security/tests/integration/db/security-definition-integrity.integration.spec.js#refuses a policy moved onto a role it does not belong to, not only one attached there - provenance: test source: >- services-platform:modules/security/tests/integration/db/security-definition-integrity.integration.spec.js#security_assignments_role_ownership_check: whose role a user may be granted - provenance: test source: >- services-platform:modules/security/tests/integration/db/security-definition-integrity.integration.spec.js#grants a user its own customer's role and Rhythm's built-in, which is every role it may hold - provenance: test source: >- services-platform:modules/security/tests/integration/db/security-definition-integrity.integration.spec.js#refuses a role belonging to a customer other than the user's - provenance: test source: >- services-platform:modules/security/tests/integration/db/security-definition-integrity.integration.spec.js#refuses an assignment moved onto another customer's role, not only one created with it - provenance: test source: >- services-platform:modules/security/tests/integration/db/security-definition-integrity.integration.spec.js#judges nothing for a statement that cannot see the user, the limit row-level security puts on it - provenance: test source: >- services-platform:modules/security/tests/integration/db/security-definition-integrity.integration.spec.js#the catalog writer’s window: a built-in is Rhythm’s - provenance: test source: >- services-platform:modules/security/tests/integration/db/security-definition-integrity.integration.spec.js#refuses an insert, an update and a delete of a built-in policy outside a reconciliation - provenance: test source: >- services-platform:modules/security/tests/integration/db/security-definition-integrity.integration.spec.js#allows the same writes inside one, which is how the reconciler maintains the catalog - provenance: test source: >- services-platform:modules/security/tests/integration/db/security-definition-integrity.integration.spec.js#leaves a customer's own policy alone: the window is about Rhythm's rows, not about the table - provenance: test source: >- services-platform:modules/security/tests/integration/db/security-definition-integrity.integration.spec.js#refuses an insert, an update and a delete of a built-in role outside a reconciliation - provenance: test source: >- services-platform:modules/security/tests/integration/db/security-definition-integrity.integration.spec.js#refuses a rule of a built-in outside a reconciliation, and allows the same rule inside one - provenance: test source: >- services-platform:modules/security/tests/integration/db/security-definition-integrity.integration.spec.js#leaves a customer's own rules alone, which is what a customer administrator writes all day - provenance: test source: >- services-platform:modules/security/tests/integration/db/security-definition-integrity.integration.spec.js#refuses an attachment on a built-in role outside a reconciliation: what a built-in is made of is Rhythm's - provenance: test source: >- services-platform:modules/security/tests/integration/db/security-definition-integrity.integration.spec.js#leaves a customer's role attaching a built-in policy alone: the role decides whose attachment it is - provenance: test source: >- services-platform:modules/security/tests/integration/db/security-definition-integrity.integration.spec.js#closes the window at the end of the transaction, so the next statement on the same pool is an ordinary one - provenance: test source: >- services-platform:modules/security/tests/integration/db/security-definition-integrity.integration.spec.js#what the migration found when it applied - provenance: test source: >- services-platform:modules/security/tests/integration/db/security-definition-integrity.integration.spec.js#left every definition the database already held, all of them rows the triggers accept - provenance: test source: >- services-platform:modules/security/tests/integration/db/security-definition-integrity.integration.spec.js#holds no row the triggers would refuse, which is the condition it applied under dependency_evidence: >- The prepared PostgreSQL database supplies the persisted fixtures and constraints exercised here. The file declares no substituted collaborators. evidence: - >- services-platform:modules/security/tests/integration/db/security-definition-integrity.integration.spec.js - >- Static review at the recorded source revision; executable results remain not-run and conformance remains not-verified. binding_note: >- Each binding names the scenario to which this file contributes assertions. A binding is not a recorded pass and does not extend the file’s dependency boundary. examiner: codex examined_at: '2026-10-23' final_text: OpenAI dependency_review: provenance: test source: >- services-platform:modules/security/tests/integration/db/security-definition-integrity.integration.spec.js explicit_no_doubles: true identified_double_boundaries: [] --- # Security definition integrity database and service checks ## Verification Boundary The file exercises database or service behavior through the local integration harness. The assertion references identify the source checks for security definition integrity. ## What This Suite Proves The source assertions support the observations named in the bound scenarios. A scenario spanning multiple files must retain the other files’ contributions. ## What It Does Not Prove This examination does not run the suite. Passing behavior, deployed conformance and the behavior of substituted dependencies require separate execution evidence. ## Real Dependencies and Test Doubles The prepared PostgreSQL database supplies the persisted fixtures and constraints exercised here. The file declares no substituted collaborators. ## Must Not Be Doubled Keep the queried database, applicable constraints and transaction boundaries real. Provider substitutes cannot establish delivery, cloud execution or cross-service recovery.