The Protocol Habitat - Revision Brief

Why this brief is included

The Architecture Paper explains what the Protocol Habitat is and what must remain true as it develops. This companion explains how that architecture can become a coherent public field on papers.spiralweb.earth, a reliable status memory, and a safe basis for later records and machine-readable work.

The brief is included because an architecture becomes trustworthy only when its public names, links, routes, records and status statements agree with it. A strong paper beside a contradictory public surface would not be a baseline. The implementation therefore needs its own visible discipline.

Readers do not need this brief in order to understand the Architecture Paper. It is offered for board members, collaborators, editors and technical stewards who need to see what will be established, what still requires a decision, how each step will be checked, and where the work must stop rather than guess.

The two documents have different time horizons:

• Document A - Architecture Paper: the durable reasoning and architecture.
• Document B - Revision Brief: the dated work needed to establish and maintain the first public baseline.

Document B is expected to be completed, revised and eventually superseded. Its temporary character is a strength: implementation detail can change without rewriting the architecture it serves.

1. Purpose

This brief provides the bounded work programme for establishing the Architecture Paper as the controlling public baseline of the Protocol Habitat.

It contains:

• the decisions that govern the implementation;
• the choices still requiring explicit approval;
• the public, editorial and technical deliverables;
• minimum record contracts;
• two illustrative record tasks;
• an ordered implementation sequence;
• acceptance tests and stop conditions.

It does not repeat the architectural argument. Where reasoning is required, the Architecture Paper is the controlling source.

2. Implementation objective

Establish one source-locked public Protocol Habitat in which:

1. foundations, protocols, applications and tools remain distinct;
2. publication, maturity, registry state and field activation remain separately visible;
3. only a locally authorised place-bound application may be active;
4. AnchorPoints hold relationship and continuity without acquiring field authority by definition;
5. the PG Ledger records and connects, while named humans govern;
6. the public trust claim remains bounded next-step supportability rather than certification;
7. open practice remains distinct from organisational review, verified relationship and material support;
8. the papers index, public orientation, registry, human-readable records and machine-readable records state the same status;
9. the public field offers a clear reading path through Architecture, Human Entry, Institutional Ground, Operational Tools and later approved records.

3. Scope

In scope

• recording the Planetary Guardians route conflict as a separate public-surface dependency;
• publication of the Architecture Paper as a candidate foundation;
• publication of this Revision Brief as its dated implementation companion;
• creation of the Protocol Habitat field on the papers index;
• presentation of Architecture, Human Entry, Institutional Ground and Operational Tools as one coherent public reading field;
• creation of a readable Protocol Habitat orientation;
• creation of a canonical registry skeleton;
• minimum records for protocols, AnchorPoints and applications;
• a decision on the publication form of the Grounding process candidate;
• glossary and methods language required for source-lock;
• two bounded illustrative records: Doukkala and Mexico City / Xochimilco;
• a shared machine schema limited to structural validation and required disclosure;
• cross-links to AnchorPoints, field pages and the human-scale entry guidance in SRIP: The Steward's Journey.

Out of scope for this revision

• activation of any field cycle;
• release or commitment of funding;
• validation of a protocol across places or cultures;
• comprehensive redesign of PG Ledger Formats 1-5;
• public representation of a local field without local review and consent;
• creation of a certification, credit, MRV product or automated authorisation system.

4. Related public-surface dependency

Verified 3 August 2026:

• the slash route serves the current bounded Planetary Guardians page;
• the same route without the trailing slash serves an outdated and contradictory status page.

The conflict belongs to the separate Spiralweb public-surface repository, not to the green-papers repository used for the first Protocol Habitat publication batch. It does not block publication of the Architecture Paper, this brief, or the Protocol Habitat field on papers. It does block completion of the wider cross-site integration.

Required later edit: redirect the no-slash route to the canonical slash route and verify every deployed surface that can serve either form before the wider integration is declared complete.

5. Locked decisions

The following decisions govern the implementation unless this brief is formally amended.

1. The Protocol Habitat is an architecture paper, not a meta-protocol.
2. Publication is not activation.
3. Only a place-bound application may be active.
4. AnchorPoints hold relation, continuity and access; they do not automatically hold protocol or field authority.
5. Foundations, protocols, applications and tools remain separate material homes.
6. Material type, maturity, visibility, application state, publication state and registry state remain separate axes.
7. The shared grammar is binding; observations and indicators remain differentiated by domain and place.
8. Applications may translate, limit, challenge, supplement or reject generic protocol claims.
9. Citizen science observes; 13 x 13 structures inquiry; AI assists; PG Ledger records and connects; the Dashboard supports judgement; named humans govern.
10. The public trust claim is bounded next-step supportability, not certification.
11. Admission to the public registry follows explicit review under the Architecture Paper, not category quotas or technical availability.
12. Repository history remains technical history; the public field contains only materials deliberately admitted under the current architecture.
13. Condition streams and financial streams remain technically distinct.
14. Evidence limitations are represented inside evidence_status, together with provenance, strength and uncertainty.
15. No schema validates ecological truth, consent, legitimacy or readiness. It validates record structure and required disclosure only.
16. Open public practice does not create an organisational case, review obligation or support entitlement.
17. Self-starting practice and learning contact do not become AnchorPoints by default; an AnchorPoint requires a verified relationship, continuity and locally grounded correction capacity.
18. The no-slash route correction is a separate Spiralweb task and must be complete before the wider cross-site integration is declared complete; it is not a prerequisite for the first papers-only baseline.

6. Open decisions requiring approval

O1 - Grounding publication form. Publish a separate operational process candidate, or retain it internally while publishing only the Architecture Paper. Required before the Grounding publication decision.

O2 - Canonical registry location. Place the registry on the papers site, on the Spiralweb site, or mirror its display while keeping one canonical source. Required before the registry build.

O3 - Schema v1 depth. Begin with envelope and status only, or include claim and evidence objects. Required before schema drafting.

O4 - Illustrative record visibility. Keep records internal until local review, or publish them with explicit non-authorising status. Required before the Doukkala and Mexico City records are released.

O5 - Canonical URL treatment. Redirect non-canonical public endpoints to the Protocol Habitat orientation, or return a deliberate 410 response where a redirect would preserve a misleading identity. Required before the wider cross-site integration.

Default if no alternative is approved: choose the narrower, less public and less authoritative option.

7. Required deliverables

Architecture Paper v0.4. Publish as the candidate architecture baseline under the approved title The Protocol Habitat. Completion requires public HTML and PDF with the candidate status intact and a link to the Protocol Habitat field.

Revision Brief v0.4. Publish as the dated implementation companion. Completion requires the public status block, a link back to the Architecture Paper and the non-authorisation boundary intact.

Planetary Guardians route. Canonicalise the route in the separate Spiralweb repository. This is not part of the first papers-only publication batch. Completion of the wider integration requires slash and no-slash requests to resolve to the same current page.

Protocol Habitat field on papers. Establish one public section integrating Architecture, Human Entry, Institutional Ground and Operational Tools, with a clear route to AnchorPoints and later approved records.

Protocol Habitat orientation. Create a readable entry point explaining the four material homes, the activation boundary, AnchorPoints, applications, tools and status axes. It must also distinguish open self-starting practice, learning contact, verified relationship and supported relation, following SRIP: The Steward's Journey.

Canonical registry skeleton. Create the status memory for current foundations, approved candidates, applications and tools without implying validation.

Grounding process. Decide its publication form and edit accordingly. Completion requires Decision O2 to be implemented and the status source-locked.

Minimum record contracts. Finalise the Protocol, AnchorPoint, Application and Registry contracts before schema work begins.

Doukkala illustrative record. Draft it from the named source materials. It must remain clearly preparatory, non-authorising and subject to local review.

Mexico City illustrative record. Draft it from the Mexico City Brief (August 2026) and the current relationship status. It must remain clearly inquiry/pre-application and subject to invitation and local review.

Shared schema v1. Create it only after the contracts are approved. It validates required structure and disclosure, not truth or readiness.

Glossary and methods language. Revise this last, so the terms match the registry, records and public orientation exactly.

Public cross-links. Connect the Architecture Paper, Revision Brief, Constitutional Ground, Rule of Life, Knowing From the Ground, SRIP, the PG Ledger formats, AnchorPoints and the two field examples without implying field activation.

8. Minimum record contracts

The record contracts below are design baselines. They do not activate protocols, fields or funding.

8.1 Protocol Candidate Record

protocol_id
title
version
material_type
structure
scope
living_function
purpose
claim_boundary
does_not_claim
maturity
visibility
application_status
publication_state
registry_state
canonical_source
lineage
grammar_binding
domain_observations
claim_register
evidence_requirements
local_adaptation_requirements
consent_and_data_requirements
risks
pause_review_stop_conditions
decision_authority_requirements
last_impulse
application_interface
ledger_interfaces
prohibited_uses
known_application_relations
review_status
next_bounded_test
licence
verified_on

Rules:

• no local baseline in a generic candidate;
• no field activation claim without a named application;
• no unqualified numerical target without source, scope and evidence limitations;
• no automated authorisation;
• known application relations do not constitute validation.

8.2 AnchorPoint Record

anchorpoint_id
public_name
place_or_relational_field
anchorpoint_function
relationship_holders
relationship_pathway
local_steward_or_authority
bridge_roles
relationship_status
continuity_basis
site_binding_status
local_authority_status
consent_scope
public_visibility
what_is_alive_now
what_is_not_active
next_decision
application_bindings
right_to_correct
right_to_withdraw
verified_on

Rules:

• a contact or location alone is not an AnchorPoint;
• self-starting practice and learning contact are not AnchorPoints by default;
• the record does not activate a protocol;
• bridge roles do not inherit site authority;
• public description requires the relevant consent scope.

8.3 Place-Bound Application Card

application_id
public_name
place
anchorpoint_bindings
local_problem_articulation
local_terms_and_languages
field_boundary
protocol_bindings
local_authority
affected_people_and_living_systems
consent_and_withdrawal
protected_absence
baseline_status
evidence_forms_and_standing
three_stream_reading
steward_load_and_rotation
funding_and_flow_status
what_starts_the_clock
what_releases_money
pause_and_stop_rights
human_accountability_holder
next_decision
review_date
correction_route
public_claim_boundary
verified_on

Rules:

• unknown remains visible;
• preparation does not start a clock or release money;
• the application must be able to record a correction to any generic protocol it uses;
• public claims cannot exceed local review and consent.

8.4 Registry Entry

record_id
title
material_type
current_version
canonical_version
maturity
visibility
application_status
publication_state
registry_state
supersedes
superseded_by
field_review_status
verified_on
canonical_url
repository_path
notes

Rules:

• the registry is the public status memory;
• the repository is the technical history;
• canonical does not mean validated;
• frozen describes version stability, not universal truth.

9. Illustrative record tasks

9.1 Doukkala

Purpose: test one bounded Grounding Cycle where site, steward relationship and concrete land-water questions already exist.

Source lineage:

• Rehamna / Badaoui - Compréhension pré-pilote et contexte de conception, working v0.6;
• Supplementary Note - Working with the Existing Pomegranate Structure, July 2026.

Required record condition:

relationship_status: established
site_binding_status: present
local_authority_status: present_but_not_fully_recorded
application_status: preparing
protocol_bindings: not_yet_fixed
field_cycle_status: not_activated
funding_status: no_release
validation_claim: none

Required first-cycle contents:

• one minimal application card;
• one or two evidence passports;
• one preliminary three-stream reading;
• no more than five questions requiring local response;
• one burden note;
• one correction note back to the Grounding process.

Non-activation boundary: the record starts no clock, releases no money and binds no steward to an area, planting design or timetable.

9.2 Mexico City / Xochimilco

Purpose: show an inquiry and bridge relation that is not yet a locally held application.

Source lineage:

• Mexico City Brief, August 2026;
• current public Mexico City and AnchorPoints descriptions, verified at drafting;
• any later locally reviewed source added only with consent.

Required record condition:

relationship_status: active_research_and_bridge_relation
site_binding_status: none
local_field_authority_status: not_yet_established
application_status: inquiry_or_pre_application
ledger_status: shadow_only_if_invited
funding_status: no_release
public_impact_claim: prohibited_before_local_review
validation_claim: none

The shadow-ledger test is retained only if it improves a real judgement, makes hidden work visible, reduces duplicate documentation or restores a missing feedback loop. If it only produces more documentation, it is changed or stopped.

10. Ordered implementation sequence

The order below is binding unless an earlier step reveals a stop condition.

Step 0 - Approve this brief

Resolve O1-O5 or record the approved defaults.

Output: approved Revision Brief with named approver and date.

Step 1 - Establish the Protocol Habitat field on papers

Create the public section that presents Architecture, Human Entry, Institutional Ground and Operational Tools as one coherent reading field. Update the papers index and sitemap, remove materials not admitted to the new public baseline, and preserve repository history without making it part of the public narrative.

Output: one clear public field with no contradictory current status claims.

Step 2 - Publish the Architecture Paper and Revision Brief

Publish candidate HTML and PDF for the Architecture Paper with its status block intact. Publish this brief as the dated implementation companion, clearly subordinate to the Architecture Paper and carrying the non-authorisation boundary.

Output: one durable candidate architecture paper and one public implementation companion with distinct functions.

Step 3 - Establish the orientation, registry skeleton and cross-links

Create the human-readable entry point and canonical status memory. Initial entries should include the Architecture Paper, Revision Brief, Constitutional Ground, Rule of Life, Knowing From the Ground, SRIP, Regenerative Reciprocity, the approved status of the Grounding source, the PG Ledger formats, and later approved applications or tools. Link outward to AnchorPoints and the relevant field pages.

Output: a small public habitat with a clear reading path and a source-locked status memory.

Step 4 - Finalise the minimum record contracts

Review the four contracts in Section 8. Resolve field names, enums, required/optional status and privacy boundaries. Test each contract against Doukkala and Mexico City without filling unknowns by inference.

Output: approved record contracts and two validation fixtures.

Step 5 - Draft the two illustrative records

Draft Doukkala and Mexico City from Section 9. Keep them internal until the visibility decision and relevant local review are complete.

Output: two clearly differentiated, non-authorising records.

Step 6 - Decide and prepare the Grounding publication form

Implement O1. If published as a protocol candidate, separate its operational process from architecture prose and give it a bounded claim, application interface, burden test and next test. If retained internally, state that accurately in the registry.

Output: one unambiguous Grounding status.

Step 7 - Define shared schema v1

Implement O3 after the record contracts are approved. The schema may validate identity, classification, status axes, required claim disclosure, consent fields, authority fields and relationships. It must not validate truth, readiness or legitimacy.

Output: schema, examples and structural validation report.

Step 8 - Revise glossary, methods and public cross-references

Source-lock AnchorPoint, protocol, application, field cycle, core, candidate, canonical, frozen, active and validated-for-defined-use. Remove any public wording that contradicts the registry.

Output: one terminology set across both sites.

Step 9 - Correct the separate Spiralweb route conflict

In the Spiralweb public-surface repository, redirect the no-slash Planetary Guardians route to the canonical slash route. Verify direct requests, internal links, redirects, Worker/Pages behaviour and the custom domain. This step is separate from the papers-only baseline publication.

Output: one route, one current body, one status source across the wider public surface.

Step 10 - Publish one source-locked integration

Publish the orientation, registry, approved records, schema and cross-reference changes as one guarded integration. Verify exact or semantic parity as appropriate, all internal links, sitemap, both route forms and clean repository state across the relevant repositories.

Output: one coherent public protocol habitat.

11. Acceptance criteria

Related public route - required for final cross-site completion

• slash and no-slash requests reach the same current page;
• no alternate current status body remains reachable;
• the first papers-only baseline is not represented as having completed this separate task.

Public field

• the Architecture Paper is visibly a candidate foundation;
• the Revision Brief is visibly a dated implementation companion and not a second architecture paper;
• Architecture, Human Entry, Institutional Ground and Operational Tools are presented as one coherent field;
• only materials explicitly admitted under the Architecture Paper appear as current registry entries;
• the public orientation keeps self-starting practice separate from organisational review, verified relationship and support.

Registry

• every entry has separate type, maturity, visibility, application, publication and registry states;
• every current claim includes a verification date;
• canonical is never used as a synonym for validated;
• no material is shown as active unless a named application establishes activation.

Applications and AnchorPoints

• Doukkala and Mexico City remain visibly different relation conditions;
• self-starting practice and learning contact are not represented as AnchorPoints;
• neither record starts a clock or releases money;
• bridge authority is not converted into site authority;
• public descriptions do not exceed local review and consent.

Schema

• evidence limitations are carried inside evidence status;
• structural validation cannot produce a readiness, funding or legitimacy decision;
• prohibited uses and human authority requirements remain machine-visible where included in the chosen schema depth.

Source-lock

• Architecture Paper, public orientation, glossary, registry and records use the same definitions;
• Constitutional Ground is classified as a foundation and not as a field procedure;
• the Grounding process has one unambiguous publication and registry state.

Repository and deployment

• only approved files are committed;
• unrelated and untracked files are preserved;
• local and remote repository states are verified;
• public HTML, PDF and machine-readable outputs are checked after deployment.

12. Stop conditions

Stop without commit or deployment if any of the following occurs:

1. the canonical repository or branch cannot be verified;
2. a later route correction is attempted without enough understanding for a narrow change;
3. an edit would expose protected location, personal or field information;
4. a local application statement lacks the relevant review or consent;
5. a record requires an unknown value to be fabricated;
6. a schema rule would automate a substantive ecological, governance or funding decision;
7. the public pages and registry cannot be made semantically consistent;
8. unrelated repository changes would be staged;
9. a generated PDF or human-readable page fails visual inspection;
10. a public URL treatment would silently preserve an outdated status claim;
11. a public entry pathway would convert open practice into automatic organisational intake or support expectation.

13. Completion definition

This revision is complete only when:

1. one canonical Planetary Guardians route exists;
2. the Architecture Paper is public as a candidate foundation;
3. the protocol habitat orientation and registry are live and source-locked;
4. the Protocol Habitat field is live on papers, integrating Architecture, Human Entry, Institutional Ground and Operational Tools;
5. the minimum record contracts are approved;
6. Doukkala and Mexico City records exist in their approved visibility state;
7. the Grounding process has one explicit status;
8. the shared schema validates structure without claiming truth or authority;
9. glossary and methods language match the registry;
10. all public surfaces have been verified and the tracked repository is clean.

14. Source register

Controlling source:

• The Protocol Habitat - Architecture Paper, candidate v0.4.

Primary architectural and constitutional sources:

• Constitutional Ground: Stewardship, support, and the pathway from red to green, March 2026;
• Spiralweb Protocol Architecture & The Grounding Protocol, v0.3-candidate;
• Rule of Life;
• Knowing From the Ground;
• The Correction Loop;
• SRIP: The Steward's Journey - human-scale entry, light records, pathway distinctions, the burden test, AnchorPoints, support without capture, pause and dignified incompletion;
• Penguin Dashboard: Legibility as Governance;
• Regenerative Reciprocity and its five PG Ledger formats;
• From Climate Intervention to Bioregional Stewardship.

Field and application sources:

• Rehamna / Badaoui - Compréhension pré-pilote et contexte de conception, working v0.6;
• Supplementary Note - Working with the Existing Pomegranate Structure, July 2026;
• Mexico City Brief, August 2026;
• current public AnchorPoints and field descriptions, verified when records are drafted.

Public-surface evidence:

• both Planetary Guardians route forms and their deployed responses, verified 3 August 2026; this evidence belongs to the separate cross-site dependency.

No edit, commit, push or deployment is authorised merely by the existence of this brief. Execution begins only after approval of Step 0.

Spiralweb Stewardship Association · Planetary Guardians · Protocol Habitat. Developed through AI-assisted dialogue; final authorship and responsibility remain human. Licensed CC BY 4.0.