oracle-deep-data-security-lab/CONTRIBUTING.md

Contributing New Labs

Treat this repository as an internal enablement product. Each scenario should be independent, resettable, easy to present, and clear enough for a consultant who is not a database specialist.

Suggested Git Flow

git checkout -b feature/scenario-05-rag-vector-access
git add .
git commit -m "Add RAG vector access lab scenario"
git push -u origin feature/scenario-05-rag-vector-access

Open a pull request to main with:

• scenario objective
• expected evidence
• expected infrastructure impact
• positive and negative tests executed
• known limitations

New Scenario Checklist

• README.md with business narrative and execution instructions.
• RUNBOOK.md with before/after steps, evidence, and official references.
• metadata.yaml with ID, criticality, dependencies, and estimated time.
• sql/00_schema.sql, when creating scenario-specific objects.
• sql/01_seed_data.sql, when seed data is needed.
• sql/02_identities.sql, when creating local end users or data roles.
• sql/03_data_grants.sql, for Oracle Deep Data Security policies.
• sql/04_test_queries.sql, for demo queries.
• sql/99_reset.sql, for rollback.
• tests/positive_tests.sql.
• tests/negative_tests.sql.
• evidence/expected-results.md.

Rules

• Do not commit passwords, wallets, .tfvars, private keys, or real customer evidence.
• Keep SQL idempotent where possible.
• Separate Oracle Deep Data Security product demos from complementary controls such as TDE, Database Vault, Data Safe, and AVDF.
• Use simple language in guides; the demo must work for both CISO and DBA audiences.