AIFC-004: Feedback and Change Proposals

Status: Draft 0.1 Standard: AI-First Community Standard Short name: AIFC Related to:

• AIFC-000: Manifesto for AI-First Communities
• AIFC-001: Core Concepts
• AIFC-002: Community Model
• AIFC-003: Values and Purpose

Purpose of this document: Define how an AIFC community receives signals from work and its environment, converts them into change proposals, evaluates them, and reflects approved changes back into the Source of Truth, strategy, workflows, skills, or value interpretation.

1. Purpose of this document

This document describes the feedback mechanism of an AIFC community.

An AIFC community is not only a top-down system where values, purpose, and strategy flow downward toward work.

It is a living system in which experience, signals, risks, opportunities, and change proposals can flow back upward.

This document answers questions such as:

• What is a feedback loop?
• What is an observed signal?
• What is a change proposal?
• Who can propose a change?
• What role may AI play?
• How are change proposals classified?
• How is the decision level determined?
• How does the community avoid chaos from too many proposals?
• How are approved changes reflected in the Source of Truth?
• How can change proposals move between communities or to a higher level?

2. Core principle

The core principle of this document is:

Values and purpose flow downward.
Experience, signals, and change proposals flow upward.

An AIFC community must not become only a well-structured command system.

It must be able to learn from reality.

3. Feedback Loop

Definition

Feedback Loop is the mechanism by which work experience, environmental signals, risks, opportunities, and change proposals return to decisions, strategy, workflows, skills, value interpretation, or community purpose.

The feedback loop connects:

Work / Execution
down
Experience
down
Observed Signals
down
Change Proposals
down
Decision
down
Update of Source of Truth
down
Updated Work / Strategy / Skills / Governance

Why it matters

Without a feedback loop, the community only executes a plan.

With a feedback loop, the community learns.

Purpose and values give work direction. Reality may show that:

• strategy is not working,
• a workflow creates debt,
• AI helps less than expected,
• AI creates dependency,
• customers need something different,
• another community is negatively affected,
• values are interpreted too narrowly,
• a new opportunity emerges,
• the original purpose needs to be refined.

Minimum requirement

An AIFC community must have a mechanism for:

• capturing signals,
• creating a change proposal,
• assigning an evaluation owner,
• determining the decision level,
• making a decision,
• recording the decision,
• reflecting the approved change in the Source of Truth.

4. Observed Signal

Definition

Observed Signal is a meaningful input from reality that may lead to learning or system change.

An observed signal may be:

• a repeated problem,
• risk,
• opportunity,
• contradiction between values and practice,
• market change,
• customer feedback,
• incident,
• cost trend,
• AI dependency,
• security weakness,
• proposal from a community member,
• signal from another community,
• environmental or ecosystem signal,
• signal detected by an AI agent.

Why it matters

A community cannot respond to reality if it cannot capture signals.

Not every signal must lead to change. Every significant signal must be capturable, structured, and evaluated.

Minimum requirement

An AIFC community must allow an observed signal to be recorded with at least:

• what was observed,
• who or what recorded the signal,
• when it was recorded,
• which area it concerns,
• why it may matter,
• whether it requires a change proposal,
• who should evaluate it.

5. Change Proposal

Definition

Change Proposal is a structured proposal for change.

It may concern:

• workflow,
• process,
• skill,
• documentation,
• rule,
• strategy,
• priority,
• AI workflow,
• AI autonomy,
• AI capacity allocation,
• security boundary,
• value interpretation,
• Community Interface,
• governance,
• or purpose.

A change proposal is not a decision.

It is an input into decision-making.

Why it matters

Without structured change proposals, feedback turns into noise.

With well-structured proposals, the community can safely receive input from the bottom up, from AI agents, customers, or other communities.

Minimum requirement

A significant change proposal must include at least:

• title,
• proposer,
• source signal,
• description of the current state,
• proposed change,
• reason for the change,
• expected benefit,
• risks,
• affected values,
• affected communities,
• proposed decision level,
• proposal status,
• link to a Decision Record.

6. Who can propose change

An AIFC community should allow change proposals from multiple sources.

A proposal may come from:

• team member,
• process owner,
• customer,
• stakeholder,
• another community,
• AI agent,
• retrospective,
• incident review,
• data trend,
• environmental signal,
• representative of a higher or lower community level.

Human proposals

A person may propose change based on experience, intuition, observation, context knowledge, or values conflict.

AI-generated proposals

An AI agent may propose change based on:

• detection of a repeated problem,
• knowledge base analysis,
• contradiction between values and practice,
• AI retrospective,
• AI waste pattern,
• security risk,
• missing fallback,
• unmaintained documentation,
• customer trend,
• cross-community impact.

An AI-generated proposal must be clearly marked as a proposal from AI.

Minimum requirement

An AIFC community must distinguish:

proposal
recommendation
decision
approved change
implemented change

An AI proposal must not automatically skip into a decision.

7. Proposal classification

Change proposals must be classified so the community is not overwhelmed.

Recommended types:

opportunity
risk
values conflict
strategy change
workflow improvement
skill update
governance change
AI dependency
AI waste
security issue
community interface change
cross-community impact
purpose drift
maintenance need

Why it matters

Different proposals require different decision levels.

For example:

• a skill update may be approved by the skill owner,
• a change to a local workflow may be approved by the team,
• a change to the AI-NDA Boundary must be approved by the security or governance owner,
• a change in value interpretation must be approved by a higher community level,
• cross-community impact must pass through the interface between communities.

Minimum requirement

Every significant change proposal must have a type and proposed decision level.

8. Decision level

Definition

Decision Level determines who is authorized to evaluate and approve a change proposal.

Recommended levels:

local / individual
team
process owner
skill owner
security owner
AI governance owner
department
company leadership
community owner
cross-community governance
higher-level community

Why it matters

Without a decision level, change proposals either get lost or create chaos.

Low-risk changes must be decidable close to the work. High-risk changes must be escalated.

Minimum requirement

An AIFC community must have rules for determining the decision level of a proposal.

9. Change proposal lifecycle

Recommended proposal lifecycle:

observed
down
draft proposal
down
classified
down
triaged
down
under review
down
accepted / rejected / deferred / needs more information
down
decision record
down
implementation
down
verification
down
source of truth update

Statuses

Recommended statuses:

draft
submitted
triaged
under_review
accepted
rejected
deferred
implemented
verified
archived

Why it matters

A change proposal must have a path through the system.

Without a lifecycle, the result is either chaos or frustration that the community does not work with feedback.

Minimum requirement

An AIFC community must have at least these proposal statuses:

• submitted,
• under review,
• accepted,
• rejected,
• deferred.

10. Decision Record

Every significant accepted or rejected change proposal must have a Decision Record.

The Decision Record should contain:

• what was decided,
• why,
• who decided,
• when,
• based on which signal,
• which values were affected,
• which alternatives were considered,
• what impact is expected,
• how the impact will be verified,
• when the decision should be reviewed.

Why it matters

Without Decision Records, the community loses the memory of its own learning.

A Decision Record is the bridge between feedback and the Source of Truth.

Minimum requirement

Significant change proposals must be linked to Decision Records.

11. Feedback and Source of Truth

An approved change must be reflected in the Source of Truth.

Otherwise, feedback remains only a conversation.

Depending on proposal type, it may update:

• purpose,
• values interpretation,
• strategy,
• workflow,
• skill,
• AI skill,
• human skill,
• AI capacity plan,
• AI operating mode,
• security rule,
• Community Interface,
• risk register,
• backlog,
• documentation,
• Decision Record.

Why it matters

Know-how that does not return to the Source of Truth is lost.

An AI output that remains in chat is not owned community know-how.

Minimum requirement

Every accepted change proposal must have a target artefact in the Source of Truth or a reason why it is not reflected there.

12. Feedback and Human Cockpit Layer

The Human Cockpit Layer must make feedback visible.

A community member should see:

• which signals have been recorded,
• which change proposals are waiting,
• what is under evaluation,
• what was accepted,
• what was rejected,
• why the decision was made,
• how the decision affected work,
• which proposals were created by AI,
• which proposals require human approval.

Why it matters

If feedback exists only in the Source of Truth but is not human-accessible, the community loses the ability to actively participate in its own learning.

The Human Cockpit Layer is human access to system feedback.

Minimum requirement

An AIFC community must have a human-accessible way to work with change proposals.

13. AI role in feedback

AI may play several roles in the feedback loop.

13.1 Signal detector

AI may detect:

• repeated problems,
• missing metadata,
• outdated information,
• quality decline,
• AI waste,
• AI dependency,
• security risks,
• values conflicts,
• purpose drift,
• cross-community impacts.

13.2 Proposal writer

AI may help formulate a change proposal.

It may structure:

• current state,
• observed signal,
• proposed change,
• expected benefit,
• risks,
• affected values,
• affected communities,
• recommended decision level.

13.3 Impact analyst

AI may analyze the possible impact of a proposal.

It may compare:

• alternatives,
• risks,
• costs,
• values conflicts,
• impact on other communities,
• impact on AI capacity,
• impact on Human Capability Reserve.

13.4 Decision support

AI may prepare decision support material.

It must not own the decision when the change has significant impact.

Minimum requirement

AI roles in the feedback loop must be clearly marked.

An AI-generated proposal must be distinguishable from a human-approved decision.

14. Feedback from AI retrospective

AI retrospective is one of the main sources of change proposals.

It may generate proposals such as:

• reduce AI intensity,
• change AI operating mode,
• add fallback,
• create a non-AI workflow,
• update a skill,
• adjust the AI-NDA Boundary,
• reduce AI waste,
• strengthen Human Capability Reserve,
• change AI capacity allocation,
• limit AI for a certain type of work.

AI retrospective is not only an evaluation of the past.

It is a source of proposals for system improvement.

15. Feedback from maintenance

Maintenance work is an important source of feedback.

Maintenance often reveals:

• what is degrading,
• where debt emerges,
• what nobody owns,
• what is outdated,
• what is repeatedly repaired,
• where a validator is missing,
• where AI performs routine work that the system should handle.

Everything the community does not care for tends to degrade or create debt.

Maintenance feedback helps the community protect its ability to keep moving toward purpose.

16. Cross-community feedback

A change proposal may cross the boundary of one community.

Examples:

• a team finds that a company rule creates unnecessary debt,
• support finds that product strategy does not match customer needs,
• an AI agent finds that one unit’s process harms another unit,
• a municipality finds that a state decision has negative local impact,
• ecosystem data shows that human activity harms a living system.

Cross-community feedback must pass through the Community Interface.

Minimum requirement

The Community Interface must allow the community to:

• receive change proposals from other communities,
• escalate impacts of its own decisions,
• describe affected values,
• determine the responsible decision level,
• record the decision in the Source of Truth.

17. Feedback in nested communities

AIFC is a recursive model.

A change proposal may flow upward:

team member
-> team
-> department
-> company
-> owner / board
-> industry
-> state
-> world
-> Earth-level governance

This does not mean that every local proposal should reach the highest level.

It means that the standard must allow a path for proposals that have higher-level impact.

Example

An AI agent in a team may detect that a certain type of automation reduces human work capability.

First, a local change proposal is created.

If it proves to be a systemic problem, the proposal may be escalated:

team AI retrospective
-> department governance
-> company AI policy
-> AIFC standard update candidate

18. Feedback and values

Feedback may reveal tension between declared values and actual behavior.

For example:

• the community declares resilience, but removes non-AI fallbacks,
• it declares security, but allows AI to work with restricted data without an AI-NDA Boundary,
• it declares human development, but removes junior tasks,
• it declares transparency, but AI decisions are not auditable,
• it declares care, but maintenance is permanently postponed.

Such feedback must be treated as a values conflict or purpose drift signal.

Minimum requirement

Change proposals that affect values must be evaluated at the appropriate decision level.

19. Feedback and purpose drift

The feedback loop is the main mechanism for detecting purpose drift.

Purpose drift may be detected when:

• work no longer relates to purpose,
• metrics push the community away from values,
• AI optimizes local performance but harms the whole,
• a customer perceives the service differently than the community intended,
• maintenance debt blocks movement toward the desired state,
• agentic workflow creates unexpected behavior.

Detected purpose drift must be processed as an observed signal or change proposal.

20. Feedback overload

The feedback loop must be managed.

If every signal generates an urgent change proposal, the community becomes overwhelmed.

AIFC therefore requires triage.

Triage evaluates:

• severity,
• urgency,
• impact on values,
• impact on other communities,
• risk,
• repeatability,
• required decision level,
• whether it is a one-time issue or systemic pattern.

Minimum requirement

An AIFC community must have a mechanism for distinguishing:

• noise,
• useful feedback,
• urgent risk,
• strategic signal,
• values conflict,
• system change candidate.

21. Suggested metadata structure

Example metadata for a change proposal:

change_proposal:
  id:
  title:
  status: draft | submitted | triaged | under_review | accepted | rejected | deferred | implemented | verified | archived
  proposer:
    type: human | ai_agent | team | external_community | observed_signal
    name:
  created_at:
  source:
  proposal_type:
    - opportunity
    - risk
    - values_conflict
    - strategy_change
    - workflow_improvement
    - skill_update
    - governance_change
    - ai_dependency
    - ai_waste
    - security_issue
    - cross_community_impact
    - purpose_drift
    - maintenance_need
  affected_area:
  affected_values:
  affected_communities:
  current_state:
  observed_signal:
  proposed_change:
  expected_benefit:
  risks:
  decision_level:
  decision_owner:
  decision_record:
  source_of_truth_targets:
  verification_plan:

This structure is illustrative, not the final schema.

The final schema should be defined in the agent-actionable layer of the standard.

22. Anti-patterns

AIFC rejects the following anti-patterns.

22.1 Top-down without feedback

Purpose and strategy flow downward, but community members have no way to surface reality.

22.2 Feedback without decision

The community collects many inputs but cannot evaluate them, decide on them, and reflect them back into the system.

22.3 AI proposal as decision

AI proposes a change and it is automatically implemented without responsible governance.

22.4 Feedback trapped in conversation

Important signals remain in chat, meeting, or email and do not return to the Source of Truth.

22.5 No Decision Record

The community accepts a change but later does not know why it was accepted.

22.6 Over-escalation

Every small proposal is escalated too high and slows the system.

22.7 Under-escalation

A significant proposal affecting values, security, or other communities stays at the local level.

22.8 Feedback as criticism only

Feedback is treated only as criticism, not as a system learning mechanism.

22.9 AI signal ignored because it came from AI

AI detects a relevant risk or opportunity, but the community rejects it without evaluation only because AI formulated it.

22.10 AI signal accepted because it came from AI

AI detects a signal and the community accepts it without evaluation only because it sounds persuasive.

23. Minimal requirements

For feedback and change proposals, an AIFC community must at least:

1. Have a mechanism for recording observed signals.
2. Have a mechanism for creating a change proposal.
3. Allow change proposals from community members.
4. Allow change proposals from authorized AI agents.
5. Distinguish proposal, recommendation, decision, and approved change.
6. Classify significant change proposals.
7. Determine the decision level of the proposal.
8. Have a minimal change proposal lifecycle.
9. Record accepted and rejected significant proposals in Decision Records.
10. Reflect approved changes in the Source of Truth.
11. Make change proposals and their status visible in the Human Cockpit Layer.
12. Clearly mark AI-generated proposals.
13. Route cross-community proposals through the Community Interface.
14. Escalate values conflicts and purpose drift signals to the appropriate level.
15. Have a triage mechanism against feedback overload.

24. Summary

An AIFC community is not a pyramid.

It is a living feedback system.

Top-down:
values -> purpose -> strategy -> work

Bottom-up:
experience -> signals -> change proposals -> decisions -> system updates

Feedback allows the community to learn from reality.

A change proposal converts a signal into a structured proposal.

A Decision Record converts a decision into memory.

The Source of Truth converts learning into durable capability.

AI may help detect signals, formulate proposals, and analyze impacts.

The community remains the owner of decisions.

The AIFC feedback loop turns experience into governed change.