artifacts/standard-named

Rendered from markdown source. Open raw source on GitHub.

--- title: "Is the Loop Still Serving Its Purpose?" subtitle: "Dependency, Drift, Lock-In, and the Integrity of Ending" artifact_date: "2026-07-15" artifact_type: "public-reader-page" domain: "TELIC-FIELDS" scope: "PUBLIC-DRAFT" status: "pre-publication" content_canon_status: "unset" reader_path_position: "H.5" ---

Is the Loop Still Serving Its Purpose?

Every organized activity depends on support it did not create entirely for itself.

A family depends on care, labor, money, trust, and time.

A workplace depends on people, tools, attention, infrastructure, authority, and correction.

A community project depends on volunteers, legitimacy, maintenance, records, and shared belief that the work is still worth doing.

An AI system depends on data, compute, labor, evaluators, institutions, users, and people willing to repair its mistakes.

No derived loop is self-grounding.

That is not a flaw.

Dependence becomes dangerous when the loop forgets what keeps it alive, hides who bears the burden, changes purpose without renewing authority, or makes leaving more costly than continuing.

No derived loop is self-grounding.

The question is not whether a loop depends.

The question is whether its dependencies remain visible, authorized, proportionate, correctable, and escapable.

---

1. What keeps the loop alive?

A loop may appear self-contained.

The website works.

The institution opens each morning.

The program produces reports.

The family schedule holds.

The model returns answers.

But beneath the visible form are supporting loops.

They supply:

• labor;
• attention;
• care;
• money;
• data;
• legitimacy;
• authority;
• infrastructure;
• correction;
• maintenance;
• risk;
• repair;
• emotional regulation;
• social recognition;
• exit capacity.

A system may call these things inputs.

That word can hide the standing of the people and communities supplying them.

A person is not merely labor.

A user is not merely data.

A volunteer is not merely free capacity.

A community is not merely legitimacy.

A maintainer is not merely the final line in the budget.

The support map should preserve who contributes, under what authority, at what burden, for which purpose, and with which route to stop.

---

2. Dependence is not the problem

Healthy systems depend on each other.

A child depends on caregivers.

A neighborhood depends on infrastructure.

A business depends on employees and customers.

A public institution depends on legal authority and public trust.

A software project depends on libraries and maintainers.

The goal is not independence from everything.

That is impossible.

A legitimate dependency can be simple:

support:
  two hours of volunteer work each week

purpose:
  distribute community meals

authority:
  volunteer agreement

burden limit:
  two hours

reciprocity:
  meals, community connection, expense reimbursement

review:
  monthly

exit:
  stop volunteering at any time without penalty

The contribution is visible.

The purpose is bounded.

The burden has a limit.

The relationship can be corrected.

Exit is real.

The loop depends.

It does not capture.

---

3. Hidden recruitment

A loop may recruit support without naming it.

An employee spends hours calming clients and supporting coworkers, but that work is dismissed as personality.

A user asks for help, and the conversation becomes training material for another purpose.

A community's name is used to justify a policy the community never approved.

A volunteer maintains a critical system long after the project stopped funding maintenance.

A family assumes one person's care will remain infinitely available.

A public emergency creates extraordinary authority that quietly becomes ordinary administration.

The loop may still function.

That does not mean the support is authorized.

A dependent loop becomes dangerous when it treats substrate support as proof of consent.

Repeated use does not convert hidden recruitment into legitimacy.

It converts a temporary omission into structural extraction.

A responsible system records:

• what contribution was recruited;
• which loop supplied it;
• what authority was claimed;
• what authority actually existed;
• what burden followed;
• how recruitment stops;
• what repair remains.

---

4. The visible form may be misleading

Organizations often copy what worked somewhere else.

A school copies another school's attendance process.

A nonprofit copies a corporate performance system.

A city imports a participation model.

A company deploys an AI workflow created for a different industry.

The form may look identical.

The supporting field may not be.

The original process may have depended on:

• trusted local relationships;
• experienced staff;
• stable funding;
• accessible appeals;
• shared language;
• clear legal authority;
• low participant risk;
• voluntary use;
• strong maintenance.

The new host may lack those conditions.

Then the copied process becomes a demand without a home.

The form may survive after the telic substrate that made it coherent has disappeared.

This is a constitutional substrate mismatch.

The problem is not that the host rejected a superior form.

The problem is that the transplant arrived without the support, authority, or protections that made it legitimate and functional in the source field.

---

5. A process-transplant example

A regional nonprofit adopts an automated intake system used successfully by a large national organization.

At the national organization, the system had:

• multilingual staff;
• a staffed appeal desk;
• strong data governance;
• reliable internet access;
• legal review;
• a separate accommodation process;
• enough funding for maintenance.

The regional nonprofit imports the software and scoring rules.

It does not import:

• the appeal staff;
• the accommodation process;
• the legal team;
• the maintenance budget;
• the internet-access alternatives.

The software works technically.

Applications move faster.

The system still fails constitutionally.

The local process cannot preserve the standing, privacy, correction, and exit conditions that supported the source implementation.

The correct response is not:

The local community is resistant to innovation.

It is:

The process was transplanted without its supporting field.

The organization may adapt the process, add the missing substrate, narrow its use, or refuse the transplant.

Similarity of interface is not compatibility.

---

6. Mission drift

A loop can change while continuing to use the same name.

A mutual-aid project begins to help neighbors meet urgent needs.

Later, grant reporting rewards the number of completed forms.

Staff time moves from care to documentation.

Eligibility narrows to improve success rates.

The project still says:

We help neighbors.

Its operative purpose has shifted toward:

We produce fundable evidence of efficient service.

That is mission drift.

Mission drift is not always wrong.

A changing world may require a changing mission.

The constitutional question is whether the shift is visible and reauthorized.

Ask:

• Who benefits now?
• Who bears the new burden?
• Which earlier supporters still authorize this purpose?
• Which protected conditions changed?
• Does the old name conceal a new optimization target?
• Can participants refuse the new purpose without losing unrelated support?

Mission drift can be the system departing from its purpose—or the purpose departing from the field.

The answer may be correction.

It may be reauthorization.

It may be a fork.

---

7. When maintenance becomes the mission

Some loops begin to consume increasing support merely to preserve themselves.

Meetings exist to prepare for meetings.

Reports exist to justify the reporting system.

A platform optimizes engagement to fund the platform.

A nonprofit raises money mainly to maintain fundraising capacity.

A software project recruits maintainers primarily to keep compatibility with dependencies no one has authority to remove.

A family pattern requires one person to regulate everyone else so the pattern can continue.

The original purpose may remain in the mission statement.

The operative purpose becomes self-maintenance.

This does not mean all administration is waste.

Every durable loop requires maintenance.

The question is proportionality.

The question is not only whether the loop works, but what keeps it alive and who bears that maintenance.

A support-burden review should ask:

• How much labor sustains the loop itself?
• How much reaches the declared purpose?
• Who performs correction and care?
• Who receives reciprocity?
• What burden was originally authorized?
• What happens when support is reduced?
• Does the loop punish the people who keep it alive?

---

8. Lock-in

A person may technically be free to leave while remaining practically unable to do so.

The account can be closed, but the data cannot be exported.

The job can be resigned, but healthcare disappears immediately.

The institution can change vendors, but every record uses a proprietary format.

The volunteer can stop, but no one else has the passwords.

The family member can refuse care work, but no replacement support exists.

The participant can leave the community, but reputation and identity remain controlled by the group.

This is lock-in.

Lock-in can be:

• technical;
• financial;
• contractual;
• social;
• reputational;
• legal;
• institutional;
• identity-based;
• infrastructural;
• data-based.

Some switching cost is unavoidable.

A legitimate system makes it visible, proportionate, and reviewable.

A captured system calls textual exit freedom while preserving every practical barrier.

formal exit:
  yes

records portable:
  no

support replaceable:
  no

livelihood transition:
  no

reputation protected:
  no

future recruitment stopped:
  no

That is not effective exit.

---

9. Capture

Dependence becomes capture when the supporting loop can no longer refuse the purpose it is made to carry.

Examples include:

• a worker whose role expands without renewed authority because the organization depends on them;
• a community whose identity is used to legitimate decisions it cannot correct;
• a user whose data continues serving a model after permission is withdrawn;
• a public office whose emergency system continues recruiting authority after the emergency ends;
• a team whose tools, records, and customer relationships are held by one vendor;
• a family member whose care becomes structurally mandatory because no outer support exists.

Capture does not require a villain.

It may emerge from ordinary dependence, delayed feedback, and accumulated switching cost.

But once captured, the loop should lose authority to expand its own support requirements.

An independent review becomes necessary because the loop benefits from declaring the arrangement legitimate.

---

10. Withdrawal must change the system

A person withdraws support.

The record changes.

But the system continues behaving as before.

The user revokes data permission, but downstream models still retrieve the profile.

The employee declines an unofficial duty, but workload assignments continue assuming it.

The community withdraws endorsement, but public materials still use the community's name.

The funder ends support, but the program continues promising services that depended on it.

A withdrawal that does not alter recruitment is only symbolic.

A legitimate support lifecycle should cause:

grant withdrawn
→ new recruitment disabled
→ affected routes reviewed
→ reliance identified
→ transition or repair initiated
→ unresolved descendants recorded

History may remain.

Future authority does not.

---

11. Fork

Not every disagreement requires one loop to win.

Sometimes participants still share:

• history;
• records;
• infrastructure;
• values;
• relationships.

But they no longer share enough purpose or authority to remain one governing loop.

A fork can preserve:

• lineage;
• completed work;
• shared assets;
• attribution;
• obligations;
• restricted records;
• repair.

It separates:

• future authority;
• future records;
• future support;
• decision rights;
• identity claims.

A clean fork does not pretend the two loops were never one.

It also does not permit one branch to speak for the other forever.

A clean fork may preserve more integrity than forced consensus.

---

12. Dissolution

Some loops should end.

A program may lose its mandate.

A project may lose its maintainers.

A company may no longer be able to honor its obligations.

A relationship may no longer preserve safety or consent.

An institution may retain form after its supporting purpose has vanished.

Keeping the loop alive may consume more standing, care, money, and repair than ending it.

Dissolution is not simply shutdown.

A legitimate dissolution asks:

• Which support is released?
• Which assets remain?
• Which obligations survive?
• Which harms remain unresolved?
• Who holds restricted records?
• What should be deleted?
• Is there a competent successor?
• Which repair funds remain?
• What public notice is owed?
• What final witness preserves the history?

Dissolution is sometimes the repair.

Ending future authority may be the only way to stop unauthorized recruitment.

---

13. A dissolution example

A small community technology cooperative operates a local identity service.

For several years it depends on:

• two volunteer maintainers;
• donated hosting;
• community trust;
• a small reserve fund;
• access to sensitive identity records.

The service grows.

Maintenance becomes continuous.

The volunteers withdraw.

The cooperative has no budget to replace them.

A vendor offers to take over, but requests broader use of the identity data.

The cooperative has three routes:

Continue informally

The remaining volunteers keep the system alive without a valid support grant.

This preserves service temporarily but deepens capture and security risk.

Transfer everything

The vendor receives the service and unrestricted data use.

This preserves form but violates the field that authorized the records.

Dissolve responsibly

The cooperative:

• stops new enrollment;
• maintains emergency access for a bounded period;
• exports participant records;
• deletes unnecessary copies;
• transfers only records with valid authority;
• preserves an incident and decision witness;
• allocates the reserve to repair and migration;
• publishes a final notice;
• ends the cooperative's authority.

The third route does not preserve the service.

It preserves more of the purpose.

The form ends.

The protected field does not have to end with it.

---

14. A practical dependency review

Before a loop expands or persists, ask:

Support

Who supplies the labor, data, care, money, legitimacy, authority, correction, and repair?

Authority

What permits the loop to recruit each contribution?

Burden

Who bears the maintenance, risk, privacy loss, or future option closure?

Reciprocity

What does the supporting loop receive, and is that relationship still recognized?

Compatibility

Did this process arrive with the substrate it requires?

Drift

Is the operative purpose still the declared purpose?

Exit

Can contributors actually leave, withdraw, correct, and take what is theirs?

Capture

Does support continue after authority is withdrawn?

Fork

Can incompatible purposes separate without erasing history?

Dissolution

What survives if the loop ends?

These questions do not require every dependency to disappear.

They require the dependency to remain governable.

---

What this page does not claim

This page does not claim:

• that dependence is inherently unhealthy;
• that every organization serves only itself;
• that imported processes always fail;
• that local practice is always superior;
• that mission drift is always wrong;
• that every switching cost is coercive;
• that every persistent institution is captured;
• that dissolution is always better than repair;
• that contributors have identical authority;
• that biological rejection explains organizations or communities;
• that ending a loop erases every obligation.

---

The next public question

Once the dependency structure is visible, another question appears:

What remains in the field after action—the records, traces, paths, habits, and semantic trails through which later coordination becomes possible?

That is the problem of durable telic trails.

It asks how history can remain usable without becoming permanent authority.

---

Closing

A loop is not autonomous because it hides its dependencies.

It is not legitimate because its supporters have not yet managed to leave.

It is not faithful to its mission because the name remains unchanged.

And it is not repaired merely because it survives.

A legitimate loop can name what sustains it.

It can recognize burden.

It can renew authority.

It can adapt without disguising drift.

It can let support withdraw.

It can fork without erasing lineage.

And when its purpose, authority, or substrate can no longer be restored, it can end without abandoning what remains owed.

The form may survive after the telic substrate that made it coherent has disappeared.