Project Guide | Memory Test Master Change Impact Gate

Live Demo

• Open the public GitHub Pages demo
• Scope a private industrial validation discovery
• Scope: credential-free demonstration with synthetic data.
• Inquiry boundary: do not submit credentials, plant data, customer records, or production logs.

A change-control Streamlit platform that dry-runs memory test master data changes before they break yield marts, dashboards, alert routing, lineage APIs, or customer-facing qualification reports.

System Overview

A manufacturing change gate that makes risky process changes reviewable before they reach production operations.

Evaluation Path

• Start here: Open the release gate, customer reporting risk, and rollback plan for stage_code_delete.
• Local demo: Run make install && make run, then open the Streamlit app at its printed local URL.
• Checks: Run make verify, then make export-review and make export-bundle for evidence artifacts.

Technical Notes

• Technical guide summarizes the system scope, first files to inspect, verification commands, and known boundaries.
• Quality notes lists the local checks, CI surface, and release expectations for this repository.
• Enterprise readiness notes outlines security, data, operations, integration, and handoff expectations.

Public-Lite Release Path

• Plan: `docs/public-lite-release-plan.md`
• Goal: preserve the change-impact logic, approval model, and signed review bundle flow while stripping tenant-specific labels, secrets, and customer-facing delivery identifiers

The specific pain point

In memory manufacturing IT, changes to bin codes, spec names, fail classes, and stage codes are often treated like small metadata edits. In reality, those values are embedded across ETL jobs, dashboards, alert rules, traceability APIs, and customer exports. A change that looks harmless can silently corrupt downstream interpretation.

This project models that exact problem and answers one question:

If a memory-test master value changes, what downstream systems break, who must approve the change, and should the release be blocked?

What the project demonstrates

• Software development: a multipage review application with modular analysis logic
• Platform engineering: dry-run impact analysis before runtime breakage happens
• Data engineering: deterministic change validation across ETL, dashboards, APIs, and exports
• Master data governance: release gates for traceability, analytics, alerting, customer reporting, and ownership readiness
• Verifiable evidence: signed bundle export with manifest and checksums
• Operational realism: approval workflow, rollback steps, and seeded benchmark expectations
• Synthetic realism: versioned master records, downstream asset catalog, approval policy matrix, and validation cases stored as explicit input files

Key pages

• Master Registry & Consumers — master values and who depends on them
• Dependency Map — which downstream paths are touched by the change
• Change Dry Run — scenario-specific impact narrative
• Impact Matrix — all deterministic findings by asset and severity
• Release Gate — pass/review/block decision surface
• Customer Reporting Risk — customer-visible downstream exposure
• Review Pack — markdown/json/zip exports
• Scenario Comparison — compare five seeded changes side by side
• Version Diff — before/after framing for the target master value
• Approval Workflow — required and advisory sign-off owners
• Rollback Plan — deterministic recovery plan if the change fails
• Benchmark — expected vs actual decisions across the seeded scenarios
• Exception Queue — blocking/review items with remediation hints
• Owner Blast Radius — who is hit hardest by the proposed change
• Release Checklist — what must be true before promoting the change
• Synthetic Data Pack — input data resources and validation cases
• Policy Matrix — release approval rules by category and change type

Scenario set

• owner_metadata_update → should pass
• bin_code_rename → should require review
• spec_name_remap → should require review
• stage_code_delete → should block release
• new_test_item_addition → should require review

Deployment

The project is optimized for Streamlit.

make install
make verify
source .venv/bin/activate
streamlit run streamlit_app.py

Example export

source .venv/bin/activate
PYTHONPATH=. python -m scripts.export_review_pack --scenario stage_code_delete --format markdown
PYTHONPATH=. python -m scripts.export_review_bundle --scenario stage_code_delete

Palantir Foundry dataset delivery

The repo now includes an env-gated Foundry sync path for the review bundle and seeded source data. Because ONTOLOGY_READY=no and DATASET_READY=yes, the integration targets datasets first rather than ontology-backed apps.

Local setup

cp .env.example .env

## fill in Foundry values locally; do not commit secrets
export $(grep -v '^#' .env | xargs)
make foundry-plan
make foundry-sync

PALANTIR_* keys are the canonical names, but FOUNDRY_TOKEN, FOUNDRY_CLIENT_ID, and FOUNDRY_CLIENT_SECRET aliases are also accepted for local setup.

If your Foundry tenant uses a custom trust chain, set PALANTIR_CA_BUNDLE=/path/to/ca.pem. Use PALANTIR_SKIP_SSL_VERIFY=yes only as a last-resort local troubleshooting path.

What gets published

• review markdown pack
• review JSON pack
• signed review bundle zip
• source data files under source-data/*
• a small Foundry sync manifest describing scenario, decision, and target datasets

In-app reviewer surface

Open Palantir Foundry Delivery in the Streamlit sidebar to inspect:

• a compact delivery brief with the active run label and primary dataset targets
• Foundry auth/config readiness
• estimated target dataset paths
• file-level upload plan
• operator commands for dry-run vs live sync

Public deployment

The repo includes a self-healing public deployment supervisor:

make deploy-public
make deploy-status
make deploy-install-agent

• deploy-public starts Streamlit and keeps a public tunnel alive.
• deploy-status prints the current public URL and process ids.
• deploy-install-agent installs a macOS LaunchAgent so the public deployment restarts at login.

Technical positioning

This is not a generic AI demo. It is a focused manufacturing-IT control surface for a very specific problem: master data changes in memory test flows causing downstream semantic breakage.

Built-in synthetic resource pack

The repo now ships with explicit input resources under data/:

• master_registry.csv
• downstream_assets.csv
• change_requests.csv
• approval_policies.csv
• validation_cases.json

These files make the project easier to inspect, extend, and benchmark without needing private fab data.

Cloud + AI Architecture

• Cloud + AI architecture blueprint
• Machine-readable architecture manifest
• Validation command: python3 scripts/validate_architecture_blueprint.py

Enterprise Productization

• Product operating model defines the product scope, trust boundary, operating checks, and service path for this repository.

Service Architecture

• Service architecture defines the cloud resources, account information, cost controls, and production guardrails needed to turn this repo into a scoped service without publishing public financial assumptions.