Skip to content

Estate governance: boundaries, evidence, and automation authority #4

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
angellllkr-eng wants to merge 1 commit into from
Closed

Estate governance: boundaries, evidence, and automation authority #4

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
33 changes: 33 additions & 0 deletions ESTATE_CONSTITUTION.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,33 @@
# Mind-Reply Estate Constitution — 2026

## Purpose
Keep public products, private operations, personal systems, experiments, and customer data separate while allowing shared engineering standards.

## Estate classes
- PUBLIC: customer-facing products, documentation, brand surfaces, no secrets or private context.
- PRODUCT-PRIVATE: product source, integrations, customer-safe operational logic.
- OWNER-PRIVATE: A.K.-only control, personal context, approvals, credentials, financial/legal records.
- LAB: experiments and forks; never presented as production capability.
- ARCHIVE: preserved for provenance; no deployment authority.

## Non-negotiables
1. No claim of live, deployed, connected, certified, compliant, profitable, or monitored unless machine-verifiable evidence exists.
2. No secret, customer data, personal memory, or private-agent context crosses a boundary without explicit policy.
3. Every automated action has an owner, scope, risk class, audit record, rollback path, and observable result.
4. Production changes require tests, security checks, health evidence, and a rollback route.
5. A 404, broken CTA, dead webhook, stale integration, or misleading status is a release defect.

## Automation authority
- OBSERVE: read-only checks and evidence collection.
- RECOMMEND: create issues/PRs and proposed changes.
- EXECUTE-SAFE: reversible maintenance inside an approved repository.
- EXECUTE-SENSITIVE: billing, DNS, access, deletion, legal, or production-impacting actions require owner approval.

## Vocabulary rule
Each product owns its own nouns, metaphors, interaction names, and visual language. Shared infrastructure terms remain technical and are never forced into product copy.

## Evidence vocabulary
`observed` = directly checked; `derived` = calculated from observed evidence; `proposed` = not applied; `applied` = committed; `live` = externally verified; `unknown` = not checked.

## Long-term operating loop
observe → classify → propose → test → approve when required → apply → verify → record → learn.