Solutions · Projects
Knowledge intelligence for complex projects
What a project does not yet know is also part of its knowledge.
On one page
Systems that build an active memory of questions, evidence, decisions, dependencies, risks and work so that teams and agents can carry long projects forward and keep visible whatever remains open.
- 01A project is also a system of knowledge and decision. Planning explains what is expected to be done.
- 02A shared representation. SuperSocrates and SuperQuestions are two different systems working on the same living graph of the project.
- 03Continuity between people and agents. Projects increasingly bring in agents to research, program, document, analyse, review and execute.
Complex projects produce far more than tasks and deliverables.
They produce questions, hypotheses, decisions, alternatives, tests, commitments, dependencies, exceptions, risks and changes of criterion. Part of that knowledge ends up in documents; another part in conversations, repositories, tickets, meetings and people.
Over time, the team can know the state of the tasks and lose the reasoning that explains the project:
- why one architecture was chosen;
- which alternative was discarded;
- what evidence existed at the time;
- which assumption remains unchecked;
- which decision depends on another;
- which change reopens a question;
- which part an agent can execute;
- who holds the responsibility;
- what result would allow a front to be considered closed.
We build systems to represent and relate that knowledge.
The solution complements planning and execution tools with a layer of questions, evidence and decisions. People and agents can retrieve the project’s situation, continue interrupted work and understand what has changed without rebuilding the whole history from fragments.
A project is also a system of knowledge and decision
Planning explains what is expected to be done. The project’s knowledge explains why, with what evidence, under what conditions and what remains open.
The two layers are related.
A task may depend on a decision that has not yet been taken. A decision may depend on a test. A test may reveal that the original question was badly framed. A result may force an architecture, a requirement or a hypothesis to be reopened.
Representing these relationships makes it possible to distinguish:
- activity from progress;
- decision from provisional preference;
- evidence from argument;
- dependency from temporal coincidence;
- open question from oversight;
- change of criterion from contradiction;
- completed task from result achieved.
A shared representation
SuperSocrates and SuperQuestions are two different systems working on the same living graph of the project. SuperQuestions is the product that represents and manages that graph — questions, evidence, decisions, dependencies and work; SuperSocrates is the system that interrogates it: it looks for gaps, proposes the next useful question and points out the collisions, that is, the information that does not match between sources, the decisions that contradict each other and the assumptions nobody ever wrote down.
The system can show:
And also:
This representation makes it possible to navigate from a task towards the decision that gave rise to it, from a decision towards its evidence and from a new piece of evidence towards the parts of the project it might modify.
Continuity between people and agents
Projects increasingly bring in agents to research, program, document, analyse, review and execute.
The main difficulty appears in preserving continuity:
- what objective each agent is pursuing;
- what context it needs;
- what work has already been done;
- which decision is still in force;
- what result it must deliver;
- what it may modify;
- what a person needs to review;
- how the result is incorporated into the project;
- what happens if another agent disagrees;
- who decides the next action.
A shared representation lets agents work on defined objects instead of merely exchanging messages.
The agent can read a question, retrieve evidence, produce a proposal and record the result, sources, uncertainty, suggested changes, artefacts created, new questions and completion criterion. Another agent or a person can review that object without rebuilding the whole preceding conversation.
The role of project management
Management retains purpose, priorities, commitments, allocation of authority, decisions with consequences, management of trade-offs, communication and the relationship with the project’s environment. The system gives it a more shared and examinable situation.
It can help to answer:
- which questions block the most work?;
- which decisions rest on weak evidence?;
- which dependencies are growing?;
- which assumptions have turned into facts without validation?;
- which fronts produce activity and little learning?;
- which agents or teams are waiting for context?;
- which change should reopen a decision?;
- which knowledge depends on a single person?;
- which result still lacks an acceptance criterion?;
- which part of the plan rests on an undemonstrated capability?
Project intelligence prepares questions and relationships. Authority over objectives and commitments stays with the people who direct and answer for the project.
Listening to the project from different positions
A project can be described differently from management, business, engineering, operations, security, users and maintenance. Each perspective makes one part visible.
The system can preserve vocabulary, concerns, criteria, responsibilities, evidence, disagreements, decisions and consequences.
The enquiry helps to discover which term means something different to two teams, which condition is taken for granted and which exception changes the design.
This practice connects project intelligence with the Socratic culture of 3.14: asking in order to understand the situation better and to keep visible what is not yet known.
Projects that cross several repositories and systems
A project may use one or several repositories, documentation, issues, pull requests, workflows, collaboration rooms, models and agents, execution environments, data systems, hardware and organisational decisions.
The solution can relate these objects through identifiers and events. For example:
- a commit implements a decision;
- a test provides evidence;
- an issue uncovers an exception;
- a review modifies a hypothesis;
- a workflow completes an experiment;
- an incident reopens a question;
- a document formalises a policy;
- a person approves a change;
- an agent proposes an alternative.
The integration preserves the place where each team works and adds continuity between tools.
Configuring teams of people and agents
In projects with agents, the configuration can define repositories, rooms, people, connected systems, tools, orchestrator, models, roles, budgets, review criteria, environments and execution policies.
The roles may include coordination and analysis, research, programming and execution, documentation, evaluation, adversarial review and second opinion.
The configuration is part of the project’s memory. It makes it possible to understand which capabilities were available when a result was produced.
What can change for a project
Less reconstruction
New people or agents can understand why a decision was taken and what remains open.
Visible questions
The project can manage uncertainty explicitly and relate it to work, risks and decisions.
Reviewable decisions
The alternatives, the evidence and the conditions stay available when the context changes.
Better continuity
Work can be resumed after a wait, a change of team or an agent interruption.
More comprehensible dependencies
Informational, technical and authority relationships appear alongside the tasks.
Less duplicated activity
Previous research and analysis are retrieved with their context and their state of validity.
Better integrated agents
Agents receive concrete responsibilities and objects, and their results are incorporated into the shared memory.
Learning from the project
Experiments, errors, decisions and reviews produce reusable knowledge.
Applications
Software development
Architecture, decisions, repositories, issues, tests, agents and deployments, all related.
Engineering and robotics
Requirements, geometry, physical capabilities, simulation, testing, safety, hardware and field results.
Research
Questions, hypotheses, sources, evidence, experiments and conclusions with provenance.
Complex documentation
Knowledge distributed across versions, requirements, rules, decisions and owners.
Transformation of enterprise systems
Current logic, migration decisions, dependencies, exceptions, integration and testing.
Editorial production
Evidence, commissions, decisions, review, formats, audiences and publication.
Multi-agent programmes
Coordination of specialised agents, tools, memory, review and continuity.
How it is built
The architecture can combine:
- a typed model of questions, evidence and decisions;
- graphs;
- PostgreSQL;
- hybrid search and pgvector;
- events from GitHub and other systems;
- MCP and FastMCP;
- durable workflows;
- agents;
- permission policies;
- project memory;
- exploration interfaces;
- Ask 3.14 or conversational search;
- activity and status dashboards.
The central representation stays independent of any particular model. Agents read and write through contracts and permissions.
Maturity state
Prototype under evaluation.
The current capability allows reconstructed projects and limited paths to be represented, questions, evidence and decisions to be navigated, and agents to be coordinated over typed objects.
The next maturity threshold consists of accompanying an active project through a complete cycle and measuring usefulness for management, continuity between participants, the cost of maintaining the representation and the quality of the work resumed.
Conditions of use
The representation adds value when it is integrated with the existing tools and recording a decision or a question costs less than reconstructing it afterwards.
The design must capture automatically whatever the work already produces, and ask for intervention only when there is a semantic or organisational decision.
Every project needs to agree what is worth persisting, what authority each object holds and what information should expire.
Related systems
SuperSocrates
The system that asks: gaps, next questions and collisions between sources, decisions and assumptions.
SuperQuestions
The product that represents and manages questions, evidence, decisions, dependencies and work.
3.14’s project architecture
Repositories, rooms, people, agents, tools and systems configured per project.
RAG and project memory
Hybrid retrieval of documentation, dialogues, code, decisions and activity.
SuperPythagoras
Building software as a team: roles, contracts, handovers and SecondOpinion on every change with consequences.
Agents and orchestration
Coordination of research, programming, execution, review and second opinion.
DocuLogic
Reconstruction of logic and operational knowledge in modernisation projects.
Closing
A complex project advances better when it can remember what it knows, explain why it decides and keep visible what it still needs to discover.
What the system represents
- 01QuestionsWhat remains to be understood, why it matters, what it blocks and what evidence would allow progress.
- 02HypothesesExplanations, designs or predictions the team wants to put to the test, with their assumptions and counter-examples.
- 03EvidenceDocuments, data, results, traces, experiments, code and observations with provenance, version and scope.
- 04DecisionsWhat was agreed, who answers for it, what alternatives existed and under what conditions it should be reviewed.
- 05DependenciesWhat must happen, be known or be decided before another part can move forward.
- 06WorkWhat result is expected, what state it is in, who takes part and which knowledge object it modifies.
- 07Risks and uncertaintiesWhat could change the course, what consequence it would have and what signal would allow it to be detected.
- 08AgentsWhich agents may research, analyse, program, execute or review, with function, tools, permissions and budget.
- 09MemoryWhat must be preserved in order to continue and what context may expire under the project's policy.
The system from the inside
Maturity · Prototype- How it is organised
- The project is represented as a graph of questions, evidence, decisions, dependencies and work, rather than as a list of tasks. Agents read from and write to that representation with bounded permissions. A decision preserves its alternatives and the conditions under which it was taken, so that it can be re-read later.
- What can be examined
- We can show a prototype with a synthetic project: the graph, the complete history of a decision and an open question with its associated evidence. Also the data schema and the permissions of each type of agent.
- How it is checked
- We evaluate reconstruction — whether a person understands why a decision was taken and what information existed — continuity, quality of the relationships, coverage, cost of recording, usefulness for the project management, agent behaviour and memory.
Conditions and limits
The current capability allows work with reconstructed projects and limited paths. Its next maturity threshold is to accompany an active project through a complete cycle and measure usefulness, continuity and maintenance cost. The representation adds value when recording a decision costs less than reconstructing it afterwards.