Skip to content

Commit eea4a81

Browse files
denisecasedenisecase
authored
README
1 parent 2512506 commit eea4a81

1 file changed

Lines changed: 1 addition & 200 deletions

File tree

‎profile/README.md‎

Lines changed: 1 addition & 200 deletions
Original file line numberDiff line numberDiff line change
@@ -518,221 +518,22 @@ All repositories in this diagram declare an `SE_MANIFEST.toml` conforming to
518518
[`se-manifest-schema`](https://github.com/structural-explainability/se-manifest-schema),
519519
which has no upstream SE dependencies.
520520

521-
## Roles
522-
523-
This organization is structured around roles:
524-
525-
| Role | Purpose |
526-
| ------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
527-
| [**Manifests and Schema**](#repository-manifests) | Define the manifest format every SE repository declares against. |
528-
| [**Theory Derivation**](#theory-formal-derivation-layer) | Derive and justify the formal contract. |
529-
| [**Formal Contract and Operational Foundations**](#formal-contract-and-operational-foundations) | Export and enforce the neutral structural constraints used by operational layers. |
530-
| [**Regime Execution**](#regime-execution) | Provide executable identity and persistence regimes for stress-testing and mapping evaluation. |
531-
| [**Reference Implementations and Formal Anchors**](#reference-implementations-and-formal-anchors) | Provide optional foundation, interface, and boundary implementations for systems that need shared implementation layers. |
532-
| [**Specifications**](#normative-and-informative-specifications) | Define structural constraints for admissible representation. |
533-
| [**Shared Contract Tooling**](#shared-contract-tooling) | Package, validate, and distribute machine-readable contract artifacts across repositories. |
534-
| [**Accountable Record Contract**](#accountable-record-contract) | Define the language-neutral contract that Accountable Record systems consume. |
535-
| [**Accountable Record Systems**](#accountable-record-systems) | Implement durable record systems that preserve SE structural distinctions. |
536-
| [**Verification Implementations**](#accountable-record-verification-implementations) | Check record systems, packages, profiles, locks, bundles, and reports against selected contracts. |
537-
| [**Mapping Examples**](#mapping-examples) | Show bounded conformance examples without extending the neutral core. |
538-
| [**Source Materials**](#source-materials-govsrc) | Preserve traceable source artifacts for reference by mappings, profiles, and rules. |
539-
| [**Papers**](#papers) | Explain why the constraints are necessary and unavoidable. |
540-
541-
## Normative and Informative Specifications
542-
543-
These repositories define the admissible representational space
544-
for structurally explainable systems.
545-
They are normative only in the sense of defining structural constraints,
546-
not interpretations.
547-
548-
<details>
549-
<summary>See more</summary>
550-
551-
### Structural Explainability Core Specification
552-
553-
Defines neutrality and boundary constraints that apply to all downstream systems.
554-
555-
| Repository | Purpose | Status |
556-
| --------------------------------------------------------------- | -------------------------------------------------------------- | --------- |
557-
| [spec-se](https://github.com/structural-explainability/spec-se) | Neutrality and boundary constraints for all downstream systems | Normative |
558-
559-
### Accountable Entity and Evolution Specifications
560-
561-
Accountable Entities defines the entity-kind layer used by downstream
562-
information systems:
563-
Actor, Locus, Instrument, Event, Scope, and Observation.
564-
It references canonical identity-regime profiles defined in
565-
`se-theory-identity-regimes`; it does not define those profiles.
566-
567-
Evolution Protocol defines graph evolution over accountable entities.
568-
Together, these specifications define reusable structural vocabularies for
569-
systems that need accountable-entity and evolution layers.
570-
571-
| Repository | Purpose | Status |
572-
| --------------------------------------------------------------- | ----------------------------------------------------------------------- | --------- |
573-
| [spec-ae](https://github.com/structural-explainability/spec-ae) | Accountable entity kinds; references canonical identity-regime profiles | Normative |
574-
| [spec-ep](https://github.com/structural-explainability/spec-ep) | Graph evolution over accountable entities | Normative |
575-
576-
### Interface Specification (CEE)
577-
578-
The Contextual Evidence and Explanation (CEE) layer defines
579-
a structural interface to the neutral substrate.
580-
It does not alter identity, structure, or recorded change.
581-
582-
| Repository | Purpose | Status |
583-
| ----------------------------------------------------------------- | ------------------------------------------------------------- | --------- |
584-
| [spec-cee](https://github.com/structural-explainability/spec-cee) | Contextual evidence, explanation, attestation, and provenance | Normative |
585-
586-
### Boundary Specifications (GB / IB)
587-
588-
These repositories define additional structural boundaries
589-
that operate relative to the neutral substrate.
590-
They do not alter identity, structure, or recorded change.
591-
They prevent interpretation, governance status, or external authority claims
592-
from leaking into the neutral substrate.
593-
594-
| Repository | Purpose | Status |
595-
| --------------------------------------------------------------- | -------------------------------------------------------- | --------- |
596-
| [spec-gb](https://github.com/structural-explainability/spec-gb) | Governance boundary for structural artifacts and actions | Normative |
597-
| [spec-ib](https://github.com/structural-explainability/spec-ib) | Interpretation boundary for external frameworks | Normative |
598-
599-
### Informative Specification Materials
600-
601-
| Repository | Purpose | Status |
602-
| --------------------------------------------------------------------------------- | --------------------------------------------------- | ----------- |
603-
| [spec-se-appendix](https://github.com/structural-explainability/spec-se-appendix) | Identifier rules, examples, and cross-spec patterns | Informative |
604-
605-
</details>
606-
607-
## Reference Implementations and Formal Anchors
608-
609-
These repositories provide optional reference implementations and formal anchors
610-
for building information systems on the Structural Explainability theory layer.
611-
612-
They are not required by every downstream system.
613-
Existing information systems may adopt SE by preserving the required structural
614-
distinctions in their own architectures, schemas, records, and validation processes.
615-
616-
These repositories exist for systems that need a ready-made foundation,
617-
a formally anchored implementation vocabulary, or a shared implementation path.
618-
They instantiate, constrain, or enforce the corresponding specifications without
619-
replacing the active `se-theory-*` derivation repositories.
620-
621-
<details>
622-
<summary>See more</summary>
623-
624-
### Optional Foundation Implementations
625-
626-
These repositories provide reusable accountable-entity and evolution foundations
627-
for downstream systems that need them.
628-
They are reference implementation layers, not universal dependencies.
629-
630-
| Repository | Purpose | CI | Description |
631-
| --------------------------------------------------------------------------------------- | ----------------------------- | --------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
632-
| [AccountableEntities](https://github.com/structural-explainability/AccountableEntities) | Accountable entity kinds | ![CI](https://github.com/structural-explainability/AccountableEntities/actions/workflows/ci-lean.yml/badge.svg?branch=main) | Lean formalization of six AE entity kinds and their mapping to canonical identity-regime profiles |
633-
| [EvolutionProtocol](https://github.com/structural-explainability/EvolutionProtocol) | Graph evolution over entities | ![CI](https://github.com/structural-explainability/EvolutionProtocol/actions/workflows/ci-lean.yml/badge.svg?branch=main) | Formalization of EP graph evolution |
634-
635-
### Optional Interface Implementation (CEE)
636-
637-
This repository provides a reusable structural interface for contextual evidence,
638-
explanation, attestation, and provenance.
639-
Systems may implement equivalent boundary-respecting structures without depending
640-
on this repository directly.
641-
642-
| Repository | Purpose | CI | Description |
643-
| ------------------------------------------------------- | --------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- |
644-
| [CEE](https://github.com/structural-explainability/CEE) | Contextual evidence and explanation interface | ![CI](https://github.com/structural-explainability/CEE/actions/workflows/ci-lean.yml/badge.svg?branch=main) | Structural forms for contextual explanation, evidence, attestation, and provenance |
645-
646-
### Optional Boundary Implementations (GB / IB)
647-
648-
These repositories provide reusable governance and interpretation boundary
649-
implementations.
650-
They are intended for systems that need explicit boundary machinery rather than
651-
for systems that already enforce these constraints internally.
652-
653-
| Repository | Purpose | CI | Description |
654-
| --------------------------------------------------------------------------------------------- | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------- |
655-
| [GovernanceBoundary](https://github.com/structural-explainability/GovernanceBoundary) | Governance boundary | ![CI](https://github.com/structural-explainability/GovernanceBoundary/actions/workflows/ci-lean.yml/badge.svg?branch=main) | Structural boundary for governance artifacts and actions |
656-
| [InterpretationBoundary](https://github.com/structural-explainability/InterpretationBoundary) | Interpretation boundary | ![CI](https://github.com/structural-explainability/InterpretationBoundary/actions/workflows/ci-lean.yml/badge.svg?branch=main) | Conditions under which external frameworks may interpret substrate records |
657-
658-
### Archived / Superseded Theory Repositories
659-
660-
> ⚠️ The repositories below are archived. Active development has moved to
661-
> the `se-theory-*` series.
662-
663-
| Repository | Purpose | CI | Description |
664-
| ------------------------------------------------------------------------------------------------- | ------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
665-
| [StructuralExplainability](https://github.com/structural-explainability/StructuralExplainability) | Cross-cutting constraints | ![CI](https://github.com/structural-explainability/StructuralExplainability/actions/workflows/ci-lean.yml/badge.svg?branch=main) | Neutrality and conformance predicates |
666-
| [NeutralSubstrate](https://github.com/structural-explainability/NeutralSubstrate) | Neutrality theorem | ![CI](https://github.com/structural-explainability/NeutralSubstrate/actions/workflows/ci-lean.yml/badge.svg?branch=main) | Substrates stable under incompatible extensions must be pre-causal and pre-normative |
667-
| [IdentityRegimes](https://github.com/structural-explainability/IdentityRegimes) | Identity regimes | ![CI](https://github.com/structural-explainability/IdentityRegimes/actions/workflows/ci-lean.yml/badge.svg?branch=main) | Earlier formalization of six identity-and-persistence regime families as a necessary lower bound under neutrality assumptions |
668-
669-
</details>
670-
671521
## Papers
672522

673523
Structural Explainability consists of a small formal core (SE-100: Neutrality; SE-200: Identity Regimes)
674-
and a parallel stewardship track (SE-ST-Gx) addressing governance over time.
524+
and a parallel stewardship track addressing governance over time.
675525
The stewardship track examines how neutral systems are defined, audited, stressed, and
676526
repaired in real institutional contexts.
677527

678528
The two formal papers provide theoretical justification for foundational specifications.
679529
They are explanatory rather than normative (they describe what must be true for such systems to work,
680530
not what people should believe or do).
681531

682-
Stewardship papers build on the formal core but do not modify or extend it.
683-
684532
| Repository | Focus | Description |
685533
| ------------------------------------------------------------------------------------------------------- | ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------- |
686534
| [paper-100-neutral-substrate](https://github.com/structural-explainability/paper-100-neutral-substrate) | Neutrality theorem | Narrative exposition of the neutrality theorem and its formal proof, establishing design constraints for neutral representational substrates |
687535
| [paper-200-identity-regimes](https://github.com/structural-explainability/paper-200-identity-regimes) | Identity regimes | Narrative exposition of the identity-regimes result and its formal justification |
688536

689-
### General Descriptions
690-
691-
- [Neutrality](https://arxiv.org/abs/2601.14271): If you want to build an information system for domains
692-
where people legitimately disagree (like law or politics),
693-
the core of the system must be neutral;
694-
if you bake in causes, values, or conclusions,
695-
the system cannot represent disagreement accurately.
696-
697-
- [Identity Regimes](https://arxiv.org/abs/2601.16152): To represent identity
698-
and persistence under structural change, information must distinguish between
699-
regime-relative ways that entities persist, break, or become irrelevant under
700-
transformation. The current framework organizes this through six regime
701-
families refined into nine profile kinds.
702-
703-
## Design Commitments
704-
705-
Across all repositories:
706-
707-
- Identity and persistence are profile-relative.
708-
- Structure and change are recorded without interpretation.
709-
- Transformation does not by itself determine persistence.
710-
- Graph continuity does not by itself imply identity continuity.
711-
- Interpretation remains external, attributable, and contestable.
712-
- Governance records do not imply authority, legitimacy, obligation, or enforcement.
713-
- Disagreement is representable and not forced to resolve.
714-
- No domain semantics are embedded in the core.
715-
- Verification is optional; systems may be useful in their domain
716-
without being SE-verified, and may seek verification as a quality property.
717-
- Authority over repository surfaces is recorded, not conferred;
718-
crossing a declared authority boundary requires human review
719-
and supporting evidence, enforced externally.
720-
721-
## Intentionally Excluded
722-
723-
The following are intentionally excluded from this core organization:
724-
725-
- domain vocabularies (except clearly labeled examples and Accountable Record systems)
726-
- application schemas or data models (except in Accountable Record systems)
727-
- analytics, inference, optimization, recommendation, or decision systems
728-
- governance authority, legitimacy, obligation, or enforcement as substrate facts
729-
(repository authority surfaces are operational and non-substrate, and are
730-
not part of the neutral core)
731-
- interpretation, explanation, evidence, or attestation as substrate facts
732-
- visualization or presentation layers
733-
734-
Domain projects may claim conformance with these specifications, but are outside this core.
735-
736537
## How to Use This Organization
737538

738539
- **To understand the justification**, start with the papers.

0 commit comments

Comments
 (0)