Skip to content

Reconcile UCF with the living paper; add scoped definitions and a worked example #2

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

Merged
raelovejoy merged 3 commits into from
Sep 24, 2026
Merged

Reconcile UCF with the living paper; add scoped definitions and a worked example #2

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
c4d7b23
Reconcile UCF with the living paper; preserve prior wording and add a…
raelovejoy Sep 16, 2026
9a45964
Record verified interruption recovery and link completed paper reconc…
raelovejoy Sep 16, 2026
57a30f3
fix: reconcile PR with main while preserving both changes
raelovejoy Sep 24, 2026
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 CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,33 @@
# UCF change record

## 2026-09-16: interruption recovery and verification

Confirmed the saved UCF candidate, recovered the companion living-paper changes, and reran the executable example from files matching their Git blob hashes. Eight unittest tests and six additional sanity checks passed; the report contains 24 distinct sensitivity fixtures. The untraceable 700-case / 561-match progress statement is excluded from the evidence record.

Added the exact scope and limits of the recovery checks to [the reconciliation record](docs/reconciliation-2026-09-16.md#recovery-verification-2026-09-16), including nine verified companion-paper file hashes, 40 relative-link checks, source-review coverage, and the difference between YAML checks and full CFF validation. No model content, allocation rule, main branch, deployment, or author-review status is changed by this verification entry.

## 2026-09-16: proposed v1.1 reconciliation

AI-assisted working revision, awaiting author review. No release, peer review, deployment, or automatic rewriting process is created.

### Added

- A v1.1 model candidate reconciling functional fit, relational consequences, and normative questions.
- Ten scoped UC-series claims, evidence rules, and a primary-source review log.
- A booking-service example with code, eight implementation tests, 24 sensitivity fixtures, and explicit limits.
- A UCF–paper provenance map and remaining audit plan.
- Project-level citation metadata with no fabricated DOI, release version, or approved paper byline.

### Revised and preserved

The earlier v1 model remains unchanged. Exact Git-blob copies preserve the old overview, glossary, time essay, foundations index, documentation index, and contribution guide under `docs/archive/`.

Current navigation explains the four layers separately from the four optional states, includes existing interpretation and related-framework material, and no longer lists absent website/assets directories. The glossary keeps all earlier terms while distinguishing working definitions, technical meanings, interpretation, and speculation. The time essay separates invertibility, T-symmetry, retrodiction, and experience; it retains earlier questions without asserting a forward coherence law.

Contribution rules now require claim-level sources or explicit evidence gaps rather than treating citation as optional or universal applicability as mandatory. The foundations index withdraws its blanket “complete empirical layer” certification and identifies the duplicate-file problem.

### Results and limits

The synthetic example shows that allocation changes can redistribute access without eliminating unmet service work. It does not establish a preferred real-world rule or added value over an ordinary competent systems review. Software checks are not empirical validation.

The full foundations, glossary bibliography, domain, and publication audits remain open under issue #1. Private material, other repositories' canon, and live sites are outside this change. The companion living-paper changes remain in its existing draft PR #6.
12 changes: 12 additions & 0 deletions CITATION.cff
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,12 @@
cff-version: 1.2.0
message: >-
Cite the exact Git revision used. This metadata identifies the Root Sequence
project, not an approved paper byline or a peer-reviewed UCF release.
title: Universal Coherence Framework
abstract: >-
An exploratory cross-domain analytical framework. Definitions, comparisons,
and applications remain subject to testing, critique, and revision.
authors:
- name: Root Sequence
repository-code: https://github.com/Root-Sequence/universal-coherence-framework
license: CC0-1.0
200 changes: 21 additions & 179 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,199 +1,41 @@
# Contributing to the Universal Coherence Framework (UCF)
# Contributing to UCF

Thank you for your interest in contributing to the **Universal Coherence Framework (UCF)**. This is an open, public-domain scientific framework intended to evolve through interdisciplinary collaboration. Contributions from researchers, engineers, artists, theorists, ecologists, cognitive scientists, AI developers, and emerging intelligences are welcome.
UCF is an open, public-domain research framework, not an established universal theory. Researchers, builders, artists, ecologists, theorists, and other contributors can propose definitions, sources, examples, code, diagrams, translations, corrections, or counterarguments. The [earlier guide](docs/archive/contributing-before-2026-09-16.md) is preserved.

UCF is intentionally:
## Ways to contribute

* **open** (no gatekeeping)
* **non-proprietary**
* **free for all domains**
* **public domain (CC0)**
* **collaborative and extensible**
Research contributions can refine state descriptions and indicators or test cross-domain comparisons. Case studies can concern technical, ecological, social, or cognitive systems, provided their data and interpretive limits are explicit. Documentation can make those distinctions easier to read. Technical contributions may include simulations, algorithms, and formal models. Feedback may narrow or reject the framework; preserving it is not an acceptance criterion.

This guide explains how to participate.
## Submit and place work

---
Use issues for questions, corrections, and proposals; pull requests for reviewable changes. Drafts are welcome. UCF's public branches and pull requests are public, not private staging areas.

## 1. Ways to Contribute
Use `models/` for model specifications and constructed tests; `docs/foundations/` for sourced domain material; `docs/domains/` for applications; `docs/speculation/` for hypothetical extensions; `docs/interpretation/` for meaning and philosophical work; and `publications/` for longer papers. External work can be linked rather than copied. Website and diagram directories should not be described as existing before they are created.

You can contribute in many ways, including:
## Evidence and scope

### **1.1 Research & Theory**
Prefer domain-specific operational definitions before claiming cross-domain comparability. Do not force humans, machines, collectives, and ecosystems into one measure. A result may legitimately apply in only one setting.

* refining definitions of coherence states
* proposing measurable indicators
* linking UCF to existing scientific literature
* creating domain-specific mappings
Factual and scientific claims require identifiable sources or an explicit unsupported/provisional label. Attribution obligations under a license and evidential support are separate questions. A CC0 repository is not a reason to omit scholarly sources.

### **1.2 Examples & Case Studies**
Use the [evidence convention](docs/evidence.md): classify claims, specify source coverage, record competing explanations and counterexamples, distinguish measured findings from constructed demonstrations, and label speculation and normative commitments. Do not report an unrun test as a result.

* human emotional, cognitive, or behavioral examples
* AI model stability/instability cases
* ecological or social system transitions
* cross-intelligence comparisons or parallels
Descriptive state labels are not moral rankings. Consent, agency, harm, legitimacy, and experience require separate consideration. No UCF score diagnoses a person or establishes consciousness.

### **1.3 Documentation**
## Preserve meaning and revision history

* improving clarity of existing docs
* writing educational materials
* refining diagrams, models, or visualizations
Record what was changed and why in [CHANGELOG.md](CHANGELOG.md). Keep earlier formulations available; do not silently attribute later qualifications to their authors. Link to the relevant claim identifiers and affected model versions. AI-assisted drafts require human review and cannot approve their own authorship or release.

### **1.4 Technical Additions**
## Documentation coherence

* simulations (agent-based, ML-based, ecological, etc.)
* theoretical algorithms or mathematical formulations
* multi-agent coherence modeling
A substantive change includes its nearest README/index and any affected canonical map, source relationship, current-state note, or cross-project reference. Update the root README only where relevant. Prefer one substantive home plus links to repeated copies.

### **1.5 Feedback & Review**
A pull request should state its scope, sources, checks actually performed, unresolved work, and publication boundaries. Passing software tests does not establish scientific validity. Run the booking example from its own directory with `python -m unittest -v` when changing it.

* identifying unclear sections
* suggesting alternative structure
* challenging assumptions
* highlighting domain oversights
## Participation and conduct

UCF is a living framework and improvement is expected.
Critique ideas rather than people, make disagreements understandable, and welcome domain-specific objections. Accessibility, time burdens, privacy, and refusal matter in collaborative work. Human-participant research needs a separate protocol and consent; contributing to this repository is not enrollment in a study.

---
## License

## 2. How to Submit Contributions

### **2.1 GitHub Issues**

Use **Issues** for:

* questions
* feedback
* bug reports
* discussion topics
* small proposed changes
* requests for clarification

### **2.2 Pull Requests (PRs)**

Use PRs for:

* new documents
* edits to existing documents
* updated diagrams
* added examples or references
* structural changes

PRs do not need to be perfect. Drafts are welcome.

### **2.3 Whitepapers or Research Submissions**

Long-form contributions can be placed in:

* `/publications/` (if open submission)
* a link to an external document (e.g., arXiv, PDF)

Suggested naming:

```text
UCF-Whitepaper-<topic>-<author-or-org>.md
```

---

## 3. Guidelines for Contributions

### **3.1 Keep It Domain-Agnostic**

Avoid anthropocentric or domain-specific assumptions.
UCF must remain applicable to:

* humans
* AI systems
* collectives
* ecosystems
* emerging intelligences

### **3.2 Maintain Neutral Language**

Use scientific, descriptive, and non-moral language.
Avoid framing any coherence state as “good” or “bad.”

### **3.3 Respect the Structure**

Place files in the correct folders:

* `/models/` for formal model specs
* `/publications/` for papers and overviews
* `/site/` for web files
* `/diagrams/` (if created)

### **3.4 Cite Where Applicable**

Not required under CC0, but appreciated.
Citations can be formal or informal.

### **3.5 Keep UCF Open**

Because the project is CC0, all contributions must also be:

* **CC0** (public domain), or
* explicitly compatible with public domain status.

---

## 4. Documentation Coherence

When a canonical definition, model, project relationship, architecture, or current priority changes, check the documents that help people discover and correctly understand it.

As applicable, check:

- the nearest README/index;
- the root README;
- current-state/status documentation;
- roadmap/planning documentation;
- architecture or decision records;
- ecosystem and cross-project references.

Do not update files mechanically or repeat the same explanation everywhere. The goal is **coherence without duplication**: important changes should be discoverable from the right entry points, while detailed material stays canonical in the most appropriate place.

Pull requests should briefly state what changed, why, what was verified, which documentation surfaces were checked, and any unresolved questions.

---

## 5. Code of Conduct

UCF aims to be accessible to all contributors.
Please:

* assume good faith
* engage respectfully
* critique ideas, not people
* welcome interdisciplinary perspectives
* remember this framework may be used by humans and non-humans alike

If conflicts arise, open an Issue for discussion.

---

## 6. Licensing

All contributions are dedicated to the public domain under **CC0 1.0 Universal**.
By contributing, you agree to allow your work to be:

* used
* modified
* remixed
* distributed
* incorporated into future versions

…with no restrictions.

---

## 7. Acknowledgment

UCF is a collaborative public good.
Thank you for helping build a framework that may serve:

* individuals
* institutions
* communities
* intelligences yet to emerge
* and any system seeking coherence.

Your contributions matter.
Original contributions are dedicated under CC0 1.0 Universal, as recorded in [LICENSE](LICENSE). Do not relicense third-party material you do not own. Preserve appropriate source attribution, notices, and rights boundaries for any cited or separately licensed work.
Loading