How we think

Ask to discover. Build to verify. Unlearn to keep understanding.

On one page

Socratic enquiry inspires us: clarify terms, make assumptions visible, listen to different perspectives and look for counter-examples. Then we build, evaluate and revise our judgement with what reality lets us observe.

01Listening before closing a representation. An organisation contains many legitimate perspectives.
02Clarifying terms changes the system. Many differences of architecture begin as differences of meaning.
03Making assumptions visible. Every proposal contains assumptions:

Thinking well begins by granting the problem the possibility of being different from our first description of it.

A request may arrive phrased as “we need an agent”, “we want to automate this process” or “the data is not right”. Each sentence contains experience, and also a hypothesis about the solution or about the cause.

Our first task is to listen for the reality it is trying to name:

what happens;
from which position it is observed;
what each term means;
which examples support the description;
which cases contradict it;
which part is a fact;
which part is an inference;
which decision has already been taken;
which question remains open.

This form of enquiry is inspired by Socratic methods. Asking serves to discover distinctions, assumptions and consequences that are not yet visible, not to lead the other person towards an answer already chosen.

Culture 3.14 makes visible how engineering asks, documents, builds and revises.

Listening before closing a representation

An organisation contains many legitimate perspectives.

Whoever operates a process knows its exceptions. Whoever maintains it knows the technical dependencies. Whoever decides knows objectives and commitments. Whoever receives the result knows consequences the process may not record.

Listening actively means:

paying attention to the language used;
asking for examples;
reconstructing the usual case;
studying the difficult case;
locating disagreements;
confirming what has been understood;
handing back a representation that people can correct.

The aim is to build a shared understanding precise enough to act on.

Listening continues in the interfaces, the tests, the corrections and the observation of use.

Clarifying terms changes the system

Many differences of architecture begin as differences of meaning.

“Completed” may mean that an API responded, that the ERP updated a status or that the customer received a result.

“Approval” may mean formal authority, technical judgement, confirmation of data or acceptance of risk.

“Memory” may refer to the current conversation, to the state of a case, to a project decision or to the organisation’s lasting knowledge.

Clarifying terms makes it possible to decide:

which entity should be represented;
which state exists;
which evidence is needed;
which participant answers for it;
which tool can act;
which criterion closes the path;
what must stay separate.

Semantics is also a product decision and an architecture decision.

Making assumptions visible

Every proposal contains assumptions:

that the information exists;
that it is current;
that two sources are talking about the same thing;
that a rule represents the intention;
that a person has the capacity to review;
that a recommendation can be put into practice;
that the physical environment holds a tolerance;
that a metric represents the result.

Making them visible turns them into questions, tests, constraints, decisions, risks and conditions of use.

An explicit assumption can be checked. A hidden assumption tends to reappear as an exception.

Looking for the case that forces better thinking

The usual case explains the path. The difficult case explains its limits.

We ask about:

incomplete data;
contradictory sources;
insufficient permissions;
urgent decisions;
partial failures;
late events;
absent people;
duplicated actions;
policy changes;
out-of-distribution situations;
physical tolerances;
ambiguous results.

The aim is to discover which responsibility appears when the system stops following the comfortable route.

Adverse cases help formulate the architecture better from the start.

Distinguishing observation, inference, decision and action

This separation runs through our work.

Observation: What a source, a measurement, a trace or a person makes it possible to record.
Inference: The interpretation that relates observations and proposes a meaning, a class, a cause or a state.
Decision: The choice between alternatives according to objectives, constraints, evidence and authority.
Action: The change executed on a system, a piece of content, a process or an environment.

Each transition needs different controls.

A trace can observe behaviour. A model can infer intent. A person can decide an exception. A tool can execute an action.

Keeping these categories apart holds authority where it belongs: an observation becomes a rule through an explicit decision, and an inference acquires value through its evidence.

Building in order to understand

Some questions only reveal their shape when we try to build.

A prototype forces decisions about:

what comes in;
which object the system represents;
which state it keeps;
which function each component fills;
what it must ask;
what it can execute;
which result it delivers;
how it is checked;
what happens when it fails.

We prefer a first path that is limited and complete to a broad collection of disconnected screens or features.

The complete path makes it possible to observe the distance between:

source and knowledge;
recommendation and decision;
command and result;
design and operation;
technical possibility and usefulness.

Learning with evidence

Learning acquires value when it changes something: a question, a schema, a rule, an interface, a model, a policy, a test, an allocation of responsibility or a decision about maturity.

We record:

what we expected;
what we built;
what we observed;
what explanation we propose;
which decision changes;
which limit remains.

That way learning can be built into the system, and can also be argued about.

Learning means understanding the problem better and turning that understanding into more useful decisions.

Unlearning is part of the craft

Unlearning is withdrawing a representation that no longer helps. It uses experience to retire an idea when it stops explaining the situation well.

It may mean:

abandoning an architecture that is too complex;
replacing an agent with a rule;
withdrawing a rule that turned an exception into a norm;
separating concepts we had merged;
changing a metric;
recognising that a source does not hold the authority attributed to it;
modifying a workflow;
discarding a hypothesis;
returning a decision to people;
accepting that a promising technique does not improve the result yet.

Unlearning requires keeping the reason for the change. The history makes it possible to avoid cycles and to understand which conditions might make an idea useful again.

Flexibility without memory produces oscillation. Memory without the capacity to revise produces rigidity.

Rigour proportional to the consequence

Rigour adapts to the responsibility.

A reversible suggestion can accept exploration and visible uncertainty.

An action that modifies an ERP, publishes sensitive information or moves a machine needs:

permissions;
validations;
tests;
states;
traces;
verification;
recovery;
human authority where appropriate.

We match the depth of evaluation, security and supervision to the cost of the error, its reversibility and the ability to observe the result.

Ambition with clear states

Technological ambition leads us to work with agents, semantics, optimisation, simulation and robotics. Humility gives reality the authority to change the design, and makes a precise ambition sustainable.

States make it possible to communicate what has been learned:

EXPLORATION
EXPERIMENT
PROTOTYPE
EVALUATION
OPERATIONAL CAPABILITY

Each state answers different questions.

An exploration shows that it is worth going on asking. An experiment observes a property. A prototype integrates capabilities. An evaluation tests conditions. An operational capability adds continuity, support and responsibility in a defined environment.

Naming the state makes it possible to be ambitious and precise at the same time.

Shared judgement, clear responsibility

Building together means that each decision uses the right knowledge, keeps a clear responsibility and can be reviewed by those who will live with its consequences.

Participation varies with the decision:

specialists define meaning and exceptions;
engineering answers for architecture and behaviour;
operations contribute cases and consequences;
management sets objectives and trade-offs;
security defines limits;
users show how the interface changes the work.

Collaboration widens the knowledge available and keeps visible who decides.

What we publish in Culture 3.14

We publish questions, readings, systems and experiments that make it possible to follow how our judgement evolves:

questions;
readings;
our own projects in practice;
methods tied to a capability;
experiments and revisions inside the Laboratory;
significant changes of judgement;
trajectory.

Publication is organised by function and by the relations between pieces. A reader can start at a question and arrive at a technology, a project or a revised decision.

Seven practices

01Listening before closing a representationWe gather perspectives, clarify terms and hand back an understanding the team can correct.
02Asking in order to discoverEnquiry makes visible the assumptions, the differences of meaning and the cases that force better thinking.
03Separating observation, inference, decision and actionEach transition holds a different responsibility and a different kind of evidence.
04Building in order to verifyA complete path reveals states, permissions, exceptions and results that abstract language still hides.
05Learning with evidenceTests, use and corrections change questions, models, rules and interfaces.
06Unlearning with memoryWe withdraw an idea when it stops explaining the work, and we keep the reason that made the change necessary.
07Crossing disciplinesInformation, language, software, organisation and physical systems connect around real questions.

Our judgement comes from asking, building and observing. Its value also depends on our willingness to revise it and to unlearn whatever reality has left behind.