jumpstart-mode 1.1.13 → 1.1.14

package/.jumpstart/skills/data-readiness-assessor/examples/example-claims-rag-readiness.md

@@ -0,0 +1,74 @@
+# Example: Claims-Adjuster RAG Readiness
+
+This is an illustrative output for a property-and-casualty insurance client exploring a claims-adjuster RAG copilot. It shows the expected shape and depth of a data readiness assessment.
+
+## 1. Use Case In Scope
+
+Surface the right policy language, prior claim notes, and SOP guidance to a Tier-2 claims adjuster while they are on a call with a claimant, so they can decide coverage and next-best-action faster. **Delivery window:** 8-week Jump Start, ending in a working prototype with eval harness against a labeled set of 75 historical claims.
+
+## 2. Sources In Scope
+
+| # | Source | System of record? | Owner | Access path | Environment available | Sensitivity class | Refresh cadence at consumed layer | Verdict |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| 1 | Policy documents (Guidewire PolicyCenter PDFs) | Yes | Underwriting Ops | Nightly export to SharePoint | Non-prod copy reachable | PII, customer-confidential | Daily | Conditional |
+| 2 | Claim notes (Guidewire ClaimCenter) | Yes | Claims Ops | API, OAuth client-credentials | Non-prod available | PII, sensitive personal (medical mentions in injury claims) | Near real-time | Conditional |
+| 3 | SOP and adjudication guidance (Confluence) | Yes | Claims COE | Confluence API | Prod only | Internal | Ad hoc, edited weekly | Ready |
+| 4 | Coverage decisions database (BI extract from ClaimCenter) | No (downstream copy) | Analytics team | Snowflake | Prod only | PII | Daily, 24h lag | Conditional |
+| 5 | External regulatory bulletins (state DOI sites) | External | Compliance | Manual download | N/A | Public | Monthly | Ready |
+
+## 3. Dimension Scores And Evidence
+
+**Source 1 — Policy documents (Guidewire PDFs)**
+
+- Availability: `3 / evidence` — non-prod export confirmed, service principal can be provisioned in week 1.
+- Quality: `2 / evidence` — sample of 20 PDFs reviewed; structure is consistent for new business but legacy policies (pre-2018) carry inconsistent endorsement formatting and scanned image artifacts.
+- Lineage: `3 / evidence` — Guidewire is the system of record; export-to-SharePoint job is documented and owned.
+- Sensitivity: `2 / attested` — contains insured PII; security has approved a dedicated tenant-scoped processing pattern, contract terms still under legal review.
+- Refresh cadence: `3 / evidence` — daily export aligns with the decision tolerance for policy lookup.
+
+**Source 2 — Claim notes**
+
+- Availability: `2 / attested` — API access promised by week 2; client has not yet provisioned the non-prod app registration.
+- Quality: `2 / evidence` — free-text, mixed-language (English / Spanish), with adjuster shorthand. Sample shows useful retrieval signal but inconsistent structure.
+- Lineage: `3 / evidence` — Guidewire ClaimCenter is the system of record.
+- Sensitivity: `2 / evidence` — includes injury descriptions and treatment notes; HIPAA exposure is bounded but real. Logging policy must redact body before tracing.
+- Refresh cadence: `3 / inferred` — API supports near real-time read; propagation from adjuster save to API surface assumed under one minute.
+
+**Source 3 — SOP guidance**
+
+- Availability `3 / evidence`, Quality `3 / evidence`, Lineage `3 / evidence`, Sensitivity `3 / evidence`, Refresh `3 / evidence`.
+
+**Source 4 — Coverage decisions BI extract**
+
+- Availability `3 / evidence`. Quality `2 / attested` — analytics team confirms downstream transformations may drop fields the use case needs. Lineage `2 / evidence` — extract is a downstream copy with 24h lag and limited change control. Sensitivity `2 / evidence` — same PII class as source 2. Refresh `2 / evidence` — 24h lag is workable for retrospective lookup but not for in-call decisions; consider falling back to ClaimCenter API for live calls.
+
+**Source 5 — Regulatory bulletins**
+
+- All `3 / evidence`. Manual monthly refresh is acceptable given regulatory change cadence.
+
+## 4. Sensitivity And Handling Constraints (Cross-Cutting)
+
+- **Environment.** Solution must run inside the client's Azure tenant, in a US East region, with no data egress to external model providers. Drives the choice of Azure OpenAI with content-filtering and a tenant-scoped Azure AI Search index.
+- **Residency.** All embeddings and indexes remain in US East. No EU sub-processors in the path.
+- **Logging.** Prompts and completions logging must redact insured names, addresses, dates of birth, and free-text injury descriptions before persistence. Retention capped at 30 days for traces, 90 days for eval sets.
+- **HITL.** Coverage and adjudication answers must surface citations and require adjuster confirmation. The system never auto-decides coverage.
+- **Contract.** BAA-equivalent and DPA terms required with the platform vendor before non-prod data lands in the index.
+
+## 5. Use-Case Readiness Verdict
+
+**Buildable with remediation.** The 8-week Jump Start window is workable, but four named conditions must close in the first two weeks to keep the prototype on track.
+
+## 6. Conditions, Owners, And Sequencing
+
+| Source | Condition | Owner | By when | Effect on scope |
+| --- | --- | --- | --- | --- |
+| 1 | Sign off on tenant-scoped processing pattern and BAA-equivalent contract | Client Legal + Security | End of week 2 | Without this, no non-prod data can land in the index; prototype falls back to synthetic policies and loses fidelity. |
+| 2 | Provision ClaimCenter non-prod app registration | Client Claims IT | End of week 1 | Slip pushes retrieval testing to week 4 and shortens eval window. |
+| 1 | Decide handling of pre-2018 legacy policy formats (in scope or excluded) | Pod Architect + Underwriting Ops | End of week 1 | If in scope, adds an OCR and normalization workstream and a labeled eval subset. |
+| 4 | Confirm whether BI extract is needed at all, given live ClaimCenter access | Pod Architect | End of week 2 | If excluded, removes a lineage risk and a 24h-lag failure mode. |
+
+## 7. Assumptions, Unknowns, And Recommended Next Step
+
+- **Assumptions.** Azure OpenAI in US East is acceptable to client security. Adjusters will accept a citations-required UX. Spanish-language claim notes will not be in the labeled eval set for the prototype.
+- **Unknowns.** Volume and quality distribution of pre-2018 policy PDFs. Exact PHI exposure inside claim notes for non-injury claim types. Whether any state regulatory bulletins must be treated as sources of record rather than reference.
+- **Recommended next step.** A 90-minute working session with Claims Ops, Security, and Legal in week 1 to lock the four conditions above. Bring a 20-policy sample and a 50-claim-note sample for live inspection so the quality and sensitivity scores move from `attested` to `evidence`.

package/.jumpstart/skills/data-readiness-assessor/references/scoring-rubric.md

@@ -0,0 +1,87 @@
+# Scoring Rubric
+
+Use these bands and cues to score each source on each of the five dimensions. The rubric is a decision aid, not a ceremony — every score should carry a short evidence clause and a confidence flag.
+
+## Score Bands
+
+- `1` — **Blocking.** The dimension is not workable inside the delivery window without a separate workstream.
+- `2` — **Conditional.** Workable, but requires a named change, accommodation, or accepted risk before the use case can be built reliably.
+- `3` — **Ready.** No material concern for the proposed use case in the proposed window.
+
+Use `?` instead of a number when the team has no evidence at all. A `?` is more honest than a guessed `2`.
+
+## Confidence Flags
+
+Mark every score with one of:
+
+- `evidence` — based on something the team has actually seen (sample data, system access, documented governance, observed query, lineage doc, signed-off classification).
+- `attested` — based on a credible client statement that has not yet been verified.
+- `inferred` — based on indirect signals (industry norms, similar engagements, the shape of the systems involved).
+
+A row of `attested` or `inferred` scores is not a finished assessment. It is a hypothesis that names the next validation step.
+
+## Dimension Cues
+
+### 1. Availability
+
+What it covers: system access, API or export path, auth pattern, environment (prod, non-prod, sandbox), network reachability, legal or procurement gating, ability to land data in the environment the AI will run in.
+
+| Band | Cues |
+| --- | --- |
+| 3 | Documented access path exists, credentials or service principal can be provisioned in days, sandbox or non-prod copy is reachable, no legal or procurement gating in the path. |
+| 2 | A path exists but is partial — non-prod is missing, access requires a ticket and SME time, the export path is manual, or the auth pattern is unclear. |
+| 1 | No usable access in the delivery window, the only path is through a third party, the data sits in a system the team cannot touch, or legal or procurement is a hard gate. |
+
+### 2. Quality
+
+What it covers: completeness, accuracy, structure, consistency, deduplication, language and format normalization, and whether ground truth or labels exist for evaluation.
+
+| Band | Cues |
+| --- | --- |
+| 3 | Fields are populated as expected, structure is stable, duplicates are managed, and a credible source of ground truth exists for evaluation. |
+| 2 | Usable for the use case after named cleanup — missing fields, inconsistent codes, mixed languages, OCR or scanned content, partial ground truth, or known noise that the team can characterize. |
+| 1 | Quality unknown or known to be poor enough that the use case cannot be evaluated, no ground truth path exists, or the data is too unstructured for the proposed pattern without a separate labeling or extraction effort. |
+
+### 3. Lineage
+
+What it covers: documented sources, transformation visibility, ownership, change-control posture, and whether a downstream copy is the right thing to use vs. the system of record.
+
+| Band | Cues |
+| --- | --- |
+| 3 | System of record is named, transformations to the layer the AI will use are documented, ownership is clear, and change control is in place. |
+| 2 | System of record is known but transformations to the consumed layer are partly opaque, ownership exists but change control is informal, or a downstream copy is used and the lag or drift is understood. |
+| 1 | The team cannot tell where the data came from, transformations are undocumented, ownership is contested, or the only accessible layer is a copy of unknown fidelity. |
+
+### 4. Sensitivity
+
+What it covers: regulated classes (PII, PHI, PCI, financial, IP, export-controlled, union or HR sensitive), residency, retention, allowable processors, and whether the data can leave the source environment.
+
+Sensitivity is a constraint, not a quality score. Treat the bands as severity, not as goodness.
+
+| Band | Cues |
+| --- | --- |
+| 3 | No regulated class, public or internal-only content, no residency or retention constraint that affects the proposed environment. |
+| 2 | Contains regulated or sensitive content with known handling rules that the proposed environment can satisfy with documented controls (masking, scoping, residency-aligned region, contract terms). |
+| 1 | Regulated or sensitive content that the proposed environment cannot host without a separate compliance workstream, or where allowable processors, residency, or retention rules are still unknown. |
+
+A `1` here typically gates environment, residency, and contract decisions for the whole engagement, regardless of the other scores.
+
+### 5. Refresh cadence
+
+What it covers: update frequency at source, propagation delay to the layer the AI will use, staleness tolerance for the decision, and whether near real-time or event-driven access is required.
+
+| Band | Cues |
+| --- | --- |
+| 3 | Refresh cadence at the consumed layer is at or better than the staleness tolerance of the AI decision, with headroom for retries and reprocessing. |
+| 2 | Cadence is workable for the use case but tight — propagation delay is close to the tolerance, batch windows constrain the user experience, or the team must accept eventual consistency. |
+| 1 | Cadence is wrong for the decision — daily batch when the decision is intraday, weekly extract when the agent runs continuously, or no understood propagation guarantee. |
+
+## Use-Case Verdict Logic
+
+After scoring every source, translate to a single use-case verdict:
+
+- **Buildable** — every source is `Ready` on the dimensions that matter for the use case, sensitivity is satisfied by the proposed environment, and refresh cadence meets the decision tolerance.
+- **Buildable with remediation** — at least one source is `Conditional` with a named change, owner, and timing that fit the delivery window. No `Blocking` findings.
+- **Not buildable in this window** — at least one source is `Blocking` for the use case, or sensitivity rules cannot be satisfied by the proposed environment in the available time.
+
+A `Not buildable in this window` verdict should be paired with a smaller, safer motion the team can credibly recommend instead — typically a Jump Start scoped around closing the blocking finding, a data-readiness sprint, or a narrower MVP that avoids the blocking source.

package/.jumpstart/skills/data-readiness-assessor/references/sensitivity-classification.md

@@ -0,0 +1,44 @@
+# Sensitivity Classification
+
+Sensitivity is a constraint that gates architecture, environment, residency, contracting, and operating decisions. Use this reference when scoring the sensitivity dimension and when surfacing cross-cutting handling constraints in the final output.
+
+## Common Sensitivity Classes
+
+- **Public / Internal** — non-regulated, non-confidential, or routine internal content. Default handling is sufficient.
+- **Confidential business** — pricing, strategy, commercial terms, internal financials, M&A, legal correspondence. Restrict by need-to-know; vendor processing typically allowed under NDA.
+- **Personal data (PII)** — names, contact info, identifiers, behavioral data tied to a person. Triggers privacy obligations such as GDPR, state privacy laws, or sector overlays.
+- **Sensitive personal data** — categories such as health, biometrics, sexual orientation, religion, union membership, immigration status. Higher consent and minimization bar.
+- **PHI** — protected health information under HIPAA or equivalent. Requires BAA, controlled environments, and audit trail.
+- **PCI** — cardholder data. Tightly scoped environments, tokenization expected; raw PAN should rarely be in an AI flow.
+- **Financial / SOX-relevant** — data feeding controlled financial reporting. Change control and segregation of duties matter.
+- **IP / trade secret** — source code, formulas, models, designs, unreleased product info. Often the binding constraint on which processors and regions are usable.
+- **Export-controlled** — ITAR, EAR, dual-use technical data. National-person and residency rules apply.
+- **HR / employee** — performance, compensation, grievance, union, immigration. Works council and union consultation may be required.
+- **Customer-confidential** — third-party data the client holds under contract. Handling is governed by the client's own contracts, not just regulation.
+
+## Constraint Patterns To Surface
+
+When a source carries a sensitivity class, capture the constraints that follow. These usually drive solution decisions before they drive data decisions.
+
+- **Environment** — must the data stay inside a specific tenant, subscription, VPC, or region?
+- **Residency** — does the data have to remain in a country or economic area? Are cross-border transfers gated by SCCs, BCRs, or local law?
+- **Allowable processors** — which model providers, vector stores, and tools are permitted? Are sub-processors disclosed and approved?
+- **Retention** — how long can prompts, completions, embeddings, traces, and eval sets be kept? Is logging governed?
+- **Minimization** — can the use case be satisfied with a redacted, masked, or tokenized view rather than raw data?
+- **Consent and purpose** — is the original consent compatible with the AI use case, or is a new lawful basis or notice required?
+- **Audit and traceability** — what evidence must be produced if a regulator or auditor asks how the data was used?
+- **Human review and override** — does the regulated class require human-in-the-loop checkpoints regardless of model performance?
+
+## How To Reflect Sensitivity In The Output
+
+- Score the dimension on the 1–3 band per source, with confidence flag.
+- In the cross-cutting "Sensitivity and handling constraints" section, list the constraints that bind the engagement as a whole — not per source.
+- Connect each binding constraint to a downstream decision: environment choice, region, model provider, contract terms, logging posture, or a HITL design point.
+- If sensitivity rules cannot be satisfied by the proposed environment in the delivery window, mark the affected source `Blocking` and escalate the finding into the use-case verdict.
+
+## Anti-Patterns
+
+- Treating "we use Azure" or "we use AWS" as a sensitivity answer. Cloud is necessary, not sufficient.
+- Assuming a vendor's enterprise tier automatically satisfies HIPAA, FedRAMP, or residency. Confirm scope and contracts.
+- Letting "the data is anonymized" stand without a re-identification check, especially in low-volume or rare-condition data.
+- Logging full prompts and completions in environments where the underlying data class forbids it.

package/.jumpstart/skills/data-readiness-assessor/templates/data-source-inventory.md

@@ -0,0 +1,44 @@
+# Data Source Inventory Template
+
+Use this template to capture each data source in scope before scoring. Keep entries short. Missing fields are themselves a finding — note them as unknowns rather than guessing.
+
+## Header
+
+- **Use case:** <one or two sentences naming the decision or output the AI will produce>
+- **Delivery window:** <Jump Start window, MVP window, pilot window, etc.>
+- **Assessment date:** <YYYY-MM-DD>
+- **Assessor:** <name or role>
+
+## Source Inventory Table
+
+| # | Source name | System of record? | Owner | Access path | Environment available | Sensitivity class | Refresh cadence at consumed layer | Known constraints |
+| --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| 1 | | | | | | | | |
+| 2 | | | | | | | | |
+
+## Per-Source Scoring Table
+
+For each source, score on the five dimensions using the rubric. Include a one-clause evidence statement and a confidence flag (`evidence`, `attested`, `inferred`).
+
+| # | Source | Availability | Quality | Lineage | Sensitivity | Refresh cadence | Verdict |
+| --- | --- | --- | --- | --- | --- | --- | --- |
+| 1 | | 3 / evidence: <clause> | 2 / attested: <clause> | 2 / inferred: <clause> | 2 / evidence: <clause> | 3 / evidence: <clause> | Conditional |
+
+## Conditions, Owners, And Sequencing
+
+For every `Conditional` source, capture:
+
+- **Condition** — the named change required.
+- **Owner** — the person or role accountable for closing it.
+- **By when** — date or milestone.
+- **Effect on scope** — what changes in the engagement if this does not close.
+
+| Source | Condition | Owner | By when | Effect on scope |
+| --- | --- | --- | --- | --- |
+| | | | | |
+
+## Assumptions And Unknowns
+
+- **Assumptions** — what the team is taking as true without direct evidence.
+- **Unknowns** — what must be confirmed before the readiness verdict is reliable.
+- **Recommended next validation step** — the single most important artifact, sample, or conversation that closes the largest unknown.

package/.jumpstart/skills/database-schema-designer/README.md

@@ -0,0 +1,212 @@
+# Database Schema Designer
+
+A comprehensive skill for designing production-ready database schemas with built-in best practices for both SQL and NoSQL databases.
+
+## Purpose
+
+The Database Schema Designer skill helps you create robust, scalable database schemas by providing:
+
+- **Normalization guidance** - Apply proper normal forms (1NF, 2NF, 3NF) to eliminate data redundancy
+- **Indexing strategies** - Optimize query performance with the right indexes
+- **Migration patterns** - Evolve schemas safely with reversible, zero-downtime migrations
+- **Constraint design** - Ensure data integrity with proper foreign keys, checks, and unique constraints
+- **Performance optimization** - Design for your specific access patterns (OLTP vs OLAP)
+
+Whether you are starting a new project or evolving an existing database, this skill ensures your schema follows industry best practices and avoids common pitfalls.
+
+## When to Use
+
+Use this skill when you need to:
+
+- Design a new database schema from scratch
+- Normalize an existing table structure
+- Add indexes to improve query performance
+- Create migration scripts for schema changes
+- Review and audit existing schemas
+- Choose between SQL and NoSQL approaches
+
+### Trigger Phrases
+
+| Trigger | Example |
+|---------|---------|
+| `design schema` | "design a schema for user authentication" |
+| `database design` | "database design for multi-tenant SaaS" |
+| `create tables` | "create tables for a blog system" |
+| `schema for` | "schema for inventory management" |
+| `model data` | "model data for real-time analytics" |
+| `I need a database` | "I need a database for tracking orders" |
+| `design NoSQL` | "design NoSQL schema for product catalog" |
+
+## How It Works
+
+The skill follows a four-phase process:
+
+### Phase 1: Analysis
+- Identify entities and their relationships
+- Determine access patterns (read-heavy vs write-heavy)
+- Choose SQL or NoSQL based on requirements
+
+### Phase 2: Design
+- Normalize to 3NF for SQL or determine embed/reference strategy for NoSQL
+- Define primary keys and foreign keys
+- Choose appropriate data types
+- Add constraints (UNIQUE, CHECK, NOT NULL)
+
+### Phase 3: Optimize
+- Plan indexing strategy based on query patterns
+- Consider denormalization for read-heavy queries
+- Add audit timestamps (created_at, updated_at)
+
+### Phase 4: Migrate
+- Generate reversible migration scripts (up + down)
+- Ensure backward compatibility
+- Plan for zero-downtime deployment
+
+## Key Features
+
+### SQL Schema Design
+- **Normalization** - Automatic application of 1NF, 2NF, and 3NF rules
+- **Data Types** - Appropriate type selection (DECIMAL for money, proper VARCHAR sizing)
+- **Constraints** - Foreign keys with ON DELETE strategies, CHECK constraints, UNIQUE constraints
+- **Indexes** - B-Tree, Hash, Full-text, and Partial index recommendations
+
+### NoSQL Schema Design (MongoDB)
+- **Embedding vs Referencing** - Guidance on when to embed documents vs use references
+- **Index Strategies** - Single field, composite, text search, and geospatial indexes
+- **Document Structure** - Optimal document design based on access patterns
+
+### Relationship Patterns
+- One-to-Many relationships
+- Many-to-Many with junction tables
+- Self-referencing hierarchies
+- Polymorphic associations
+
+### Migration Support
+- Zero-downtime migration patterns
+- Reversible migration templates
+- Safe column addition/rename strategies
+- Backward compatible changes
+
+## Usage Examples
+
+### Basic Schema Design
+
+```
+design a schema for an e-commerce platform with users, products, orders
+```
+
+Output:
+
+```sql
+CREATE TABLE users (
+  id BIGINT AUTO_INCREMENT PRIMARY KEY,
+  email VARCHAR(255) UNIQUE NOT NULL,
+  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
+);
+
+CREATE TABLE orders (
+  id BIGINT AUTO_INCREMENT PRIMARY KEY,
+  user_id BIGINT NOT NULL REFERENCES users(id),
+  total DECIMAL(10,2) NOT NULL,
+  INDEX idx_orders_user (user_id)
+);
+```
+
+### Available Commands
+
+| Command | Purpose |
+|---------|---------|
+| `design schema for {domain}` | Generate a complete schema from scratch |
+| `normalize {table}` | Apply normalization rules to fix an existing table |
+| `add indexes for {table}` | Generate an index strategy for performance |
+| `migration for {change}` | Create reversible migration scripts |
+| `review schema` | Audit an existing schema for issues |
+
+### Request Tips
+
+Include these details in your request for best results:
+
+- **Entities** - users, products, orders
+- **Key relationships** - users have orders, orders have items
+- **Scale hints** - high-traffic, millions of records
+- **Database preference** - SQL or NoSQL (defaults to SQL if not specified)
+- **Access patterns** - read-heavy analytics, write-heavy transactions
+
+## Prerequisites
+
+No special tools or dependencies required. The skill generates standard SQL or NoSQL schema definitions that work with:
+
+- MySQL / MariaDB
+- PostgreSQL
+- SQLite
+- MongoDB
+- And other compatible databases
+
+## Output
+
+The skill produces:
+
+1. **Schema DDL** - Complete CREATE TABLE statements with all constraints
+2. **Index Definitions** - Optimized indexes for your query patterns
+3. **Migration Scripts** - Reversible UP and DOWN migrations
+4. **Mermaid Diagrams** - Entity-relationship diagrams (when requested)
+5. **Verification Checklist** - Items to review before deploying
+
+### Verification Checklist
+
+After designing a schema, verify:
+
+- [ ] Every table has a primary key
+- [ ] All relationships have foreign key constraints
+- [ ] ON DELETE strategy defined for each FK
+- [ ] Indexes exist on all foreign keys
+- [ ] Indexes exist on frequently queried columns
+- [ ] Appropriate data types (DECIMAL for money, etc.)
+- [ ] NOT NULL on required fields
+- [ ] UNIQUE constraints where needed
+- [ ] CHECK constraints for validation
+- [ ] created_at and updated_at timestamps
+- [ ] Migration scripts are reversible
+- [ ] Tested on staging with production data
+
+## Best Practices
+
+### Do
+
+- Start with domain modeling, not UI requirements
+- Normalize to 3NF first, then selectively denormalize
+- Use DECIMAL for money (never FLOAT)
+- Always define foreign key constraints
+- Index every foreign key column
+- Size VARCHAR columns appropriately
+- Store dates in DATE/TIMESTAMP types
+- Always write reversible migrations
+- Test migrations on staging with production-like data
+
+### Avoid
+
+| Anti-Pattern | Problem | Solution |
+|--------------|---------|----------|
+| VARCHAR(255) everywhere | Wastes storage, hides intent | Size appropriately per field |
+| FLOAT for money | Rounding errors | DECIMAL(10,2) |
+| Missing FK constraints | Orphaned data | Always define foreign keys |
+| No indexes on FKs | Slow JOINs | Index every foreign key |
+| Storing dates as strings | Cannot compare/sort properly | Use DATE/TIMESTAMP types |
+| Non-reversible migrations | Cannot rollback safely | Always write DOWN migration |
+
+## Key Terminology
+
+| Term | Definition |
+|------|------------|
+| **Normalization** | Organizing data to reduce redundancy (1NF to 2NF to 3NF) |
+| **3NF** | Third Normal Form - no transitive dependencies between columns |
+| **OLTP** | Online Transaction Processing - write-heavy, needs normalization |
+| **OLAP** | Online Analytical Processing - read-heavy, benefits from denormalization |
+| **Foreign Key (FK)** | Column that references another table's primary key |
+| **Index** | Data structure that speeds up queries (at cost of slower writes) |
+| **Access Pattern** | How your app reads/writes data (queries, joins, filters) |
+| **Denormalization** | Intentionally duplicating data to speed up reads |
+
+## License
+
+MIT