Good tools give people more room for one another and their work. They help us cooperate, record and learn, while people retain judgement and responsibility.
How we workv 2.2October 2026Developed through practiceCC BY-SA 4.0v 2.2
In this page
Anyone working with others on a place or project knows the problem: agreements sit in a chat, documents in different folders and experience mainly in people’s memories. This makes cooperation and reflection unnecessarily difficult.
Technology can bring this information together. It helps retrieve agreements, connect data and recognise patterns. A group can then discuss what the work reveals and choose a next step.
is an open framework for regenerative practice, with tools for working and learning together. It helps communities and cooperatives organise decisions, involve people and carry experience forward. Judgement, care and responsibility remain with people.
Good tools make room for attention, cooperation and learning.
Syntrociety provides the federation context; SYFERS brings a shared framework and practical tools. Each tool answers a different question. Access and available functions depend on the tool and its configuration.
The public site
Syntrociety.org explains the ideas, approaches and development of the federation. Here you can find the , Practice, essays and ways to contribute, among other things.
Syntrociety.org has four public languages: Dutch, English, Portuguese and French. The SYFERS framework and its instruments are presented in seven languages on syfers.eu.
The site provides context and connects readers with the right starting point. Use the contact route for current availability or specific cooperation; a description here is not automatically an available service.
The SYFERS suite
SYFERS includes six instruments. The five below start with shared work: relationships, practice, self-reflection, documents and funding. RRL adds a personal starting point: investigating land and a housing plan in Portugal. These are different uses, not compulsory steps through the suite.
people · relationships, consent and follow-up
People helps federation teams keep relationships, communication choices and follow-up together. Individuals can manage their preferences and personal data. People also supports accounts and the register; a shared account does not grant access to every tool.
chart · practice and its context
Chart records activities, proposals, decisions and experiences. A group can revisit what happened, how an agreement was reached and what followed. This gives new people a place to pick up the work.
compass · reflect on your own development
Compass helps a group reflect against sixteen SYFERS conditions and its own starting point. Shared definitions make strengths and tensions discussable. The group interprets its answers; self-reflection is not certification or a ranking of Labs.
makes documents into a searchable organisation archive. Processing and translation help make information useful; questions can be explored with references to source documents. Those references support checking, without guaranteeing a correct or complete answer.
ledger · funding and accountability
Ledger helps assess funding opportunities, work on applications together and prepare reports with traceable figures. Sources, decisions and contributions stay together. Reporting uses aggregate snapshots; sensitive participant records remain with the Lab.
Available sources and reporting adapters determine what can be prepared. People check the application or report; Ledger does not award funding, guarantee acceptance or replace financial accounting.
How the parts can strengthen one another
The diagram shows complementary roles, not an automatic pipeline. Choose the tool that fits the question. Reusing information requires a working connection and appropriate access and agreements for that use.
peoplepeople.syfers.eu
relationships, consent and follow-up
People starts with relationships and communication choices. Shared identity supports access; each tool retains its own permissions.
↓ bring information and sources together
lenslens.syfers.eu
searchable archive and sources
↓ record the practice and its context
chartchart.syfers.eu
practice, decisions and context
different questions, relevant tools
reflect on your own development
compasscompass.syfers.eu
reflection against your own starting point
funding questions and aggregate figures
ledgerledger.syfers.eu
funding, applications and reporting
↓ review before sharing
These are illustrative roles, not guaranteed data transfers. RRL adds a personal land and housing question alongside this shared work. Access, data use and publication require their own checks.
RRL is the sixth instrument, with a direct personal use: comparing places in Portugal and bringing housing, water, energy and land restoration into one supported plan. It keeps sources and open questions visible. It grants no building permission and does not require someone to lead a Lab.
Record agreements. Revisit experience. Learn together.
Creating documents
Digital tools help turn information into an understandable document. This could be a translation, summary, proposal or report. Automatic generation shortens part of the work; sources and substance need checking.
Where AI is used in writing or development, people remain responsible for what they retain and publish. The explanation below makes that role clear.
Technology supports three parts of the work: writing, building and reflecting. AI can be used as a tool in this process. The output needs assessment by people who understand the context and consequences.
Writing
A person brings the question, sources and purpose. A tool can suggest wording, alternatives or a summary. The person checks the substance, chooses what is useful and takes responsibility for the text.
This works best when the question and source material are clear. Convincing wording is not itself evidence that a statement is correct.
Building
Technology can help develop code, translations, structure and design. The maker describes what is needed, assesses the proposal and checks the result before it is used.
Software also needs targeted checks on functionality, security and accessibility. Learning comes from feeding errors and user experience back into the design.
Reflecting
The third role is to help revisit recorded experiences. Which patterns recur? Where does practice differ from an agreement? The Lens describes the perspective through which Syntrociety explores these questions at /lens. Patterns translates parts of that perspective into criteria for analysis.
A group chooses its question and relevant data. Technology can connect that information and highlight a pattern or missing data. The criteria used belong in the explanation of the analysis, allowing the group to discuss the perspective itself too.
A signal is a starting point for investigation and conversation. Context determines what it means.
A fictional example of a question that could help reflection:
Many financial decisions were prepared by the same people. Is that a deliberate division of tasks, or do we want to enable more people to carry this responsibility?
The group explores the question, adds information and decides whether an adjustment is needed.
Recorded experience can then become a source of learning. The tool helps people look; people know their situation and live with the consequences of their choices.
We use four principles in further development. They describe how we want to shape responsible use. For each tool, they must be translated into demonstrable agreements and arrangements.
Safeguard 01
Protect people and keep sources traceable
Replace names where they are unnecessary and limit access to identifying information. Consider context too: a role, date or small group may still make someone identifiable.
Pseudonymisation can reduce risks. Information that can be linked back to someone using additional data remains personal data. Processing and publication therefore require, among other things, an appropriate legal basis, security and agreements on access and retention.
Safeguard 02
Make personal and shared use clear
A personal reflection needs different access from a shared evaluation. Record in advance who can see information, what it is used for and who decides on sharing.
A participant must be able to understand what the tool does with information about them. Its design and agreements must support this; a general promise on this page is not enough.
Safeguard 03
Discuss patterns with attention to context
A shared reflection begins with an understandable question: what do we see, and what do we need to understand it?
A pattern can have different causes. Responsibility often rests with the same people may reflect experience, a deliberate agreement or a lack of room for others. The group investigates which explanation fits before changing anything.
Safeguard 04
Show the analytical perspective
An analysis depends on the question, data and criteria used. Within SYFERS, some of these are described by Patterns. The public Lens documentation gives the broader perspective. The criteria and instructions actually used must be recorded with an analysis; publication of a standalone prompt is not confirmed on this page.
Transparency means those involved can understand what was investigated, which sources were used and what the outcome does and does not support. This makes it possible to improve the analysis.
Carefully designed tools support an honest conversation.
What happens after a reflection requires people who take responsibility.
They add missing context, hear different experiences and assess which conclusion fits. Sometimes this leads to a new agreement. Sometimes what is happening needs better investigation first.
Relational work also remains with people: supporting someone, discussing a conflict, restoring trust or carrying a difficult choice together. A record can help people remember, but does not make attention and presence unnecessary.
We use technology where it helps the work. Time for one another is itself part of the practice.
Three questions help when choosing and developing tools.
Can we understand and check how it works? Documentation, sources and targeted checks make a tool open to discussion and improvement. Users must be able to understand how an outcome was reached and when human assessment is needed.
Can we make a different choice later? Portable data, clear export options and open standards help limit dependency. For commercial services, we weigh practical usefulness, costs and the ability to take information with us.
Does use fit the agreements with people? Access, processing, analysis and publication must fit the purpose and agreements. We must be able to explain and assess these arrangements before people rely on them.
Independent Labs retain their own needs and context. A shared framework helps discuss choices; the services used and their conditions must be clear to participants.
Digital tools use energy, materials and infrastructure. This applies to hosting, data storage and AI. The trade-off therefore belongs in the design too.
We want to connect use with a clear purpose: which work becomes simpler, which information becomes more useful and how much use is needed for that?
External providers host the digital infrastructure. Local solar energy at a Lab does not automatically make that hosting sustainable or climate-neutral. A claim about the total footprint requires its own data.
Design choices we weigh:
Less unnecessary processing and storage.
A tool suited to the size of the task.
Reusing data where this can be done carefully.
Assessing hosting, costs and portability together.
User experience matters too: a complicated tool can require more recording than it gives back. The aim is a useful balance between effort and value for people and their work.
We keep revisiting these choices based on what we learn and the information that becomes available about the infrastructure.
The tools develop alongside questions from practice.
Method, framework and tools form a learning cycle. The method gives the working rhythm. The framework provides shared terms. The tools make agreements and experience findable. Reflection leads to adjustments that can be investigated in turn.
The audience is wider than Lab residents. People and organisations who cooperate, support projects, conduct research or carry public duties can support different parts of the work. Their questions help make the tools more useful.
We want to make knowledge transferable. This requires clear documentation and explicit agreements on access, export, licences and publication. A public description is not the same as public source code or access to internal data.
The model is open to improvement. Practical experience, research and scrutiny must show where the tools help and what needs improving. We invite people and organisations to contribute. The Charter remains the federation’s shared foundation.
Publication must reflect what is actually available. The Lens can be read on this site. Additional analysis criteria and instructions need their own version and publication link. Their publication is not yet confirmed here: link to follow after verification.