DEVELOPMENT PROCESS DOCUMENTATION

1. PURPOSE AND SCOPE

This document describes the formal development process used by MILLIONHARI LLC to design, build, review, test, and release changes to the Police Narratives AI platform. It satisfies the references in the MILLIONHARI LLC Secure Development Policy to a "code review and approval process" and serves as the operating procedure for all internal and external engineers contributing to MILLIONHARI LLC software.

This process applies to all source code, configuration, and infrastructure-as-code changes that affect the Police Narratives AI web client, API server, mobile application, and supporting AWS Lambdas.

2. ROLES AND RESPONSIBILITIES

• Founder / Technical Lead — Final approver for production releases, owner of this policy, and the senior reviewer for significant code changes.
• Engineers and Developers (internal and outsourced) — Responsible for implementing changes in accordance with this process, the Secure Development Policy, and MILLIONHARI LLC coding standards.
• Reviewers — Engineers other than the change author who are responsible for reviewing pull requests for correctness, security, and adherence to engineering standards.

Development, review, and deployment of a single change must not be performed end-to-end by the same individual without independent approval and oversight, in accordance with the Secure Development Policy.

3. SOURCE CONTROL AND BRANCHING

• All Police Narratives AI source code is maintained in a central Git repository hosted on GitHub. Access is granted on a least-privilege basis tied to the contributor's role.
• Trunk: The master branch is the integration branch and the source for production deployments. Direct pushes to master are restricted; changes land via pull request only.
• Feature branches: Engineers create short-lived feature branches off of master using a descriptive naming convention (for example, {date}-{short-description}) and rebase or merge from master regularly.
• All code is written, executed, and validated in a local environment before being synced to the central repository. Local commits include descriptive commit messages that capture the "why" of the change.
• Database migration files, once committed and merged, are immutable; new schema changes are introduced through new migrations.

4. CHANGE CLASSIFICATION

Changes are classified to determine the level of review and testing required:

5. PULL REQUEST AND CODE REVIEW PROCESS

All changes — regardless of size — are integrated through GitHub pull requests. The pull request is the system of record for review, approval, and audit trail.

5.1 Author responsibilities

• Open the pull request against master with a clear title and a description that includes the motivation, summary of changes, and a test plan.
• Confirm the change has been built and exercised locally and that type checks, linters, and the relevant test suites pass.
• Identify whether the change is Trivial, Standard, or Significant (see Section 4) and request appropriate reviewers.
• Disclose any new third-party dependencies, new environment variables, new IAM permissions, or new data the system will collect.
• Ensure no secrets, credentials, or customer data are committed.

5.2 Reviewer responsibilities

• Verify the change addresses the stated motivation and does not introduce unrelated changes.
• Review for correctness, readability, adherence to MILLIONHARI LLC coding standards, and the Secure Development Policy.
• Apply the OWASP-aligned security checklist in Section 7 of this document and the Engineering Documentation security guidelines.
• For Significant changes, escalate to the Technical Lead before granting approval.
• Block merge if the change introduces unmitigated security risk, lacks tests for non-trivial behavior, or is missing the Release Checklist.

5.3 Approval and merge

• A pull request is eligible for merge after it has received the required approval(s) and all required automated checks (build, tests, linting, type-check) have passed.
• Significant code changes must be reviewed and approved by a senior developer or Technical Lead before being merged into any production branch.
• The author is responsible for performing the merge, except in cases where the author is also the sole approver, in which case a second individual completes the merge to enforce separation of duties.
• Merge commits and the PR review thread are retained as the audit record of the change.

6. ENVIRONMENTS AND SEPARATION OF DUTIES

MILLIONHARI LLC maintains logically segregated environments across the development lifecycle:

• Development — Engineer workstations and local services, including a local PostgreSQL instance and a local Redis session store. No production data is permitted in this environment.
• Test / Staging — Used for integration testing and user acceptance prior to production release.
• Production — The live ECS cluster (PoliceNarrativesAIProd) running the client and server container images from Amazon ECR, with production AWS Lambda functions, S3 buckets, and PostgreSQL database.

Credentials, IAM roles, and database connection strings are scoped per environment. Customer data must not be copied from production into development or test environments without the explicit written permission of the data owner and the Founder.

7. SECURITY REVIEW CHECKLIST

Reviewers apply the following checklist on every pull request and escalate to the Technical Lead if any item cannot be confirmed:

• Authorization: Every new endpoint enforces authentication and the appropriate role-based access control (Officer vs. Records vs. Agency Admin) and respects the caseAccess rules.
• Session and MFA: Endpoints that touch protected data are gated by the MFA guard and respect the CJIS session timeout and inactivity middleware.
• Injection: All database access goes through parameterized queries via Drizzle ORM. No string concatenation into SQL or shell commands.
• Cross-site scripting: User-supplied content is rendered through React (which escapes by default) or sanitized before being passed into rich-text editors.
• Cross-site request forgery: State-changing endpoints rely on session cookies with appropriate SameSite behavior; sensitive flows include explicit anti-CSRF measures.
• Insecure session IDs: Sessions are issued by Passport and stored in Redis; session identifiers are not exposed in URLs or logs.
• Authorization bypass: No endpoint trusts a client-provided user, agency, or case identifier without re-authorizing against the authenticated session.
• Vulnerable libraries: New or upgraded dependencies have been reviewed for known CVEs; yarn audit issues are triaged before merge.
• Secrets: No credentials, API keys, or environment values are committed; new configuration is added to .env.sample only.
• Logging: Sensitive data (passwords, tokens, MFA codes, customer narrative content) is not logged.
• Fail securely: Error paths default to denial; user errors are surfaced without leaking stack traces or internal identifiers.

8. TESTING REQUIREMENTS

• Type checks (TypeScript) must pass for both client/ and server/ before a pull request is eligible for merge.
• Unit and integration tests must be added or updated for new non-trivial behavior. Authentication, authorization, MFA, billing, and case-access logic require test coverage.
• Manual verification is required for changes affecting the editor, audio upload pipeline, transcription Lambdas, or the form designer and filler.
• Database migrations are tested by running yarn migrate against a fresh local database and a copy of the staging schema before being applied to production.
• No code is deployed to production without documented, successful test results and evidence that any identified security issues have been remediated.

9. RELEASE CHECKLIST

Prior to deploying a change to production, the responsible engineer confirms each of the following items. The completed checklist is retained in the pull request or release ticket as evidence of acceptance testing.

• Pull request approved by required reviewer(s).
• All automated checks (build, lint, type-check, tests) green.
• Security review checklist (Section 7) reviewed; any findings have been resolved or formally accepted.
• Database migrations reviewed, generated with yarn generate, and tested against a non-production database.
• Schema changes synced to client and mobile (auto-handled by yarn migrate) and verified.
• New environment variables, IAM permissions, or AWS resources are documented and provisioned in the target environment.
• Sentry release tagged where applicable and rollback plan documented.
• For Significant changes: explicit sign-off from the Technical Lead recorded on the pull request.

10. DEPLOYMENT PROCEDURE

Production deployments use the GovCloud AWS profile and follow a repeatable, documented procedure:

1. Merge approved pull request to master.
2. Build the relevant Docker image (client or server) with --no-cache.
3. Tag the image and push to the MILLIONHARI LLC ECR registry in us-gov-west-1.
4. Force a new deployment of the corresponding ECS service in the PoliceNarrativesAIProd cluster.
5. Apply outstanding database migrations against the production database using yarn migrate; never use yarn push against production.
6. Monitor Sentry, application logs, and key user flows for the first 30 minutes following the rollout to detect regressions.

Lambda code (audio processing, Amazon Transcribe, completion handler, Bedrock) is deployed independently from the API server and follows the same review and approval requirements.

11. EMERGENCY (HOTFIX) CHANGES

When a defect causes a production incident, the Technical Lead may authorize an expedited release under the following conditions:

• A short-lived hotfix branch is created from master and scoped strictly to the fix.
• A pull request is opened, reviewed, and approved on the same shortened cycle. Out-of-band approval (verbal or chat) is permitted but must be documented in the pull request after the fact.
• A retrospective note describing the root cause and the fix is added within five business days of the deployment.

12. OUTSOURCED DEVELOPMENT

External engineers and contractors operate under the same code review, testing, and release rules as internal staff. Their work is supervised and monitored by the Technical Lead, who reviews all material pull requests and audits commit history during the engagement.

13. CHANGES TO THIRD-PARTY PACKAGES

MILLIONHARI LLC discourages forks or local modifications of third-party business application packages. Where modification is unavoidable, the change is documented, scoped to the minimum necessary, and reviewed under the Significant change classification. Updates to third-party packages are evaluated against the Third-Party Management Policy.

14. EXCEPTIONS

Any deviation from this process must be requested from and approved by the Founder in writing. Approved exceptions are recorded with their rationale and an expiration date.

15. RELATED DOCUMENTS

• Engineering Documentation — Architecture, secure-by-design and privacy-by-design principles, and technical references.
• Privacy Policy — Data collection, processing, and user rights.
• MILLIONHARI LLC Secure Development Policy (internal).
• MILLIONHARI LLC Operations Security Policy (internal).
• MILLIONHARI LLC Third-Party Management Policy (internal).

16. CONTACT

Questions about this Development Process Documentation should be sent to support@policenarratives.ai.