Not another directory. Not another dashboard. A system that learns.
A directory stores what people already know. A dashboard displays whatever the last query returned. An intelligence system is something else: a structure that holds experience, grades it honestly, connects it, proposes explanations, mobilises responses, and — the part that decides everything else — remembers what happened so that the next question starts from where the last one ended.
- Engines
- 6
- Evidence levels
- 5
- Trust principles
- 12
Status
This is the proposed architecture of the SolutionSynq intelligence layer — a design to be built, tested, and revised. None of the engines described here are operational, and no finding, dataset, or capability on this page should be read as existing today.
It is published in this form deliberately: the design can be criticised, and criticised designs improve faster than defended ones.
Six engines, arranged as a cycle
Each engine has one responsibility and one boundary. The cycle exists because the sixth engine — Learning — exists to feed the first: an outcome that is measured but never routed back into listening is a filed document, not a learning.
Conceptual architecture
Six engines, arranged as a cycle because the sixth feeds the first. Select any engine to read its role. This is the proposed architecture of the SolutionSynq intelligence layer — a design to be built and tested, not a description of a system already in service.
What each one consumes, does, and produces
Expand any engine to read its inputs, its functions, and its outputs. The boundaries between engines are deliberate: separating collection from grading, and grading from reasoning, is what stops a first-hand account from being reported as a finding.
01Listening EngineUnderstands what is happening across stakeholder experiences.
The entry point of the system. It exists to notice what the formal structures miss — the recurring friction, the small adaptations people make without mentioning, and the signals that appear before they are counted anywhere.
Inputs
- Consent-based submissions
- Structured interviews and roundtables
- Existing research and industry data
- Community and association reporting
Functions
- Operate multiple accessible channels, including assisted and multilingual routes
- Track and report representativeness of the corpus
- Identify recurring signals early, without asserting prevalence
- Maintain provenance for every item collected
Outputs
- First-hand accounts with context
- Early signal clusters, marked as provisional
- Gaps: whose experience is still not represented
02Evidence EngineDistinguishes reports, observations, validated patterns, causal explanations, and tested interventions.
The discipline layer. Its function is to make it impossible to confuse a report with a finding, and to keep every claim attached to the evidence, limitations, and counterevidence that support it.
Inputs
- Captured signals
- Corroborating material
- Counterevidence
- Existing findings
Functions
- Assign and record an explicit evidence level to every claim
- Test independence of corroboration, not just its volume
- Search actively for disconfirming evidence
- Track what would change each conclusion
Outputs
- Graded claims with stated limitations
- Documented counterevidence
- A record of unresolved disputes
03Graph EngineConnects stakeholders, problems, causes, resources, opportunities, and outcomes.
The structural layer. It holds the relationships that no single participant can see — and, critically, holds the reasoning for each relationship so that the structure can be argued with rather than merely believed.
Inputs
- Graded signals
- Stakeholder records
- Capability and resource records
- Recorded interventions
Functions
- Maintain typed relationships between problems, causes, parties, and resources
- Carry the reason for every asserted connection
- Surface near-duplicate problems described in different vocabularies
- Expose gaps: needs without capabilities, capabilities without needs
Outputs
- A navigable relationship structure
- Reusable capability and problem descriptions
- Explicit gaps and orphaned records
04Intelligence EngineIdentifies recurring patterns, possible root causes, risks, and opportunities.
The analytical layer. It reasons over the graph to propose explanations — while being explicit that its outputs are hypotheses until they have been corroborated or tested.
Inputs
- Graph structure
- Graded evidence
- Comparable cases
- Contextual data
Functions
- Identify recurring patterns across independent instances
- Generate and rank competing causal hypotheses
- Detect structural risks in workflows and dependencies
- Distinguish a novel opportunity from a familiar constraint
Outputs
- Ranked hypotheses with reasoning
- Pattern and risk briefings
- Opportunity hypotheses, clearly marked as untested
05Action EngineHelps identify responsible stakeholders, relevant capabilities, and potential next steps.
The coordination layer. It turns an understanding into something a person can actually do — and it is careful about the difference between what is technically possible and what someone is willing and able to take responsibility for.
Inputs
- Prioritised hypotheses
- Capability records
- Stakeholder availability and consent
Functions
- Match a defined need to plausible responsible parties
- Draft interventions with explicit scope and exclusions
- Check equity and unintended-consequence risks before activation
- Track implementation against the stated baseline
Outputs
- Action briefs with a named owner
- Draft interventions and success measures
- An activation record with consent captured
06Learning EngineRecords what changed, what worked, what failed, and what remains uncertain.
The memory layer, and the reason the system improves rather than merely accumulating. It treats failures as first-class results and it refuses to generalise a lesson beyond the context in which it was learned.
Inputs
- Measurement results
- Participant feedback
- Abandoned interventions
Functions
- Record attempt, rationale, baseline, outcome, and limitations together
- Keep failed interventions retrievable and attributed
- Assess transferability before a lesson is generalised
- Feed reusable findings back into listening and structuring
Outputs
- Verified learning records
- Transferability assessments
- An updated evidence base feeding the next cycle
Seven things every engine rests on
Engines are the visible part of the system. These are the parts that decide whether its output can be trusted, and they are not optional features — they are the precondition for the engines existing at all.
Data provenance
Every item carries where it came from, when, and under what conditions. Nothing enters the system without a traceable origin.
Consent & permissions
Collection is consent-based, purpose-bound, and revocable. Access rights are scoped to what the contributor agreed to.
Evidence standards
A single published standard governs what may be claimed at each level, applied identically to every contributor and every finding.
Context & metadata
Industry, region, language, role, scale, and timeframe travel with the signal, because context changes what a signal means.
Privacy safeguards
Data minimisation, aggregation thresholds, re-identification protection, and retention limits applied before analysis rather than after.
Human review
Sensitive, disputed, or consequential conclusions require a named human who reviewed the reasoning and accepts responsibility for it.
Feedback & learning
Contributors can see how their input was used, correct it, withdraw it, and contest the conclusions drawn from it.
Five rungs, and what each one is not allowed to say
Every claim the system makes carries a level. The level governs what may be said about it — not just how strongly it is phrased, but which conclusions it is permitted to support at all. Select a rung to read its requirements and its limits.
Rung 01 — REPORTED
Reported signal
A first-hand account has been recorded. It is credible as an account of what one person experienced, and nothing more.
What this level requires
- Provenance: source, date, and context
- Consent to hold the account
- Original wording preserved alongside any classification
This permits
Saying that a person reported an experience.
This does not permit
Claiming the problem is common, that it affects a population, or that the stated cause is correct.
Labels used throughout the interface
HYPOTHESIZED marks a causal claim the system has proposed but has not yet corroborated. INFERRED marks one the evidence supports. They sit on the same rung on purpose — a causal claim should never look stronger than it is.
The standard above is applied to this site's own published material. Every source it relies on is published with its date, a link, and the limits of what it establishes, alongside the counterevidence search and the gaps that remain.
What a problem has to look like before it enters the system
A record is not a document about a problem. It is a fixed structure that forces the things usually left out — provenance, counterevidence, competing explanations, baselines, exclusions, and what would change the conclusion — to be written down rather than assumed.
Group Identity
Enough to find the record again, and to tell at a glance what kind of thing it is.
record_idstringRequiredStable identifier. Assigned once, never reused, never reassigned when the record changes.
Illustrative value
PR-2026-0148
titlestringRequiredA plain-language description of the problem, in the words of the people who experience it.
Illustrative value
Crew wait weeks for payment after a production wraps.
summarytextRequiredOne paragraph. What the problem is, who experiences it, and why it appears to matter.
Illustrative value
Daily-wage crew on short-form productions report being invoiced 30–60 days after wrap, with no tracking of when a payment was due.
problem_typeenumRequiredWhich structural category the record sits in. A record may relate to more than one category, but it has one primary type.
Illustrative value
repeated-failures
statusenumRequiredWhere the record currently sits in the investigation cycle.
Illustrative value
hypothesised
Twelve commitments the system is bound by
These are not aspirations. Each one is a rule that constrains what the system is permitted to do, and each one exists because the temptation to break it is strong and the failure would be quiet.
01
Consent-based collection
Nothing is collected without an informed, specific, and revocable agreement to do so.
02
Confidential reporting
A route exists for sensitive accounts, and the protection offered by it is described accurately rather than claimed generously.
03
Clear purpose & access limits
Contributors are told what their information will be used for, who will see it, and who will not.
04
Data minimisation
Only what is needed for the stated purpose is collected. Detail that serves no analytical purpose is never requested.
05
Retention limits
Information is held only as long as it remains useful and consented, and is then deleted rather than archived indefinitely.
06
Correction & withdrawal
Contributors can correct, withdraw, or restrict their contributions at any point, and the system records the effect of doing so.
07
Dispute & appeal
A contributor who believes a conclusion drawn from their account is wrong can contest it, and the contest is recorded.
08
Appropriate human review
Consequential conclusions are reviewed by a named person with the authority to reject the system's own output.
09
Re-identification protection
Aggregation thresholds, generalisation, and suppression rules are applied so that a described group cannot be traced back to a person.
10
Fair handling of allegations
Unproven allegations are carried as allegations, attributed as claims, never published as findings, and never commercially exploited.
11
Explicit uncertainty
Confidence is stated where it is high and where it is low. The interface is designed to make weak claims look weak.
12
Representative treatment
Regional, linguistic, and stakeholder composition of the record is tracked and reported, not left implicit.
A limit on this list
We will not promise anonymity we cannot deliver.
A confidentiality route is only worth offering if the infrastructure and the operating process behind it can genuinely deliver it. Until that is in place, this site does not claim anonymous submission, and the form on this site says so plainly rather than implying protection it cannot offer.
Where a protection genuinely exists — consent that can be withdrawn, corrections that can be made, contributions that can be contested — it is described precisely, including its limits.