Engineering · Coordination
Accord
Find agreement that can actually work.
01
In plain English
- What it is
- A decision tool that separates what people prefer from what a workable plan actually requires.
- How it works
- You would collect options, preferences and must-haves, such as who needs to attend. Accord would show which options work, then a named owner would choose one and record the reason.
- Why it matters
- To reach an explainable decision without mistaking the most popular option for a workable one.
02
The working model
A preferred date is useful only after the required conditions are satisfied.
The boundary that matters Mira owns the decision. The proposed system exposes feasibility and preserves the inputs she reviewed.
Two paths: Standard flow and Required reply missing · 5 stages each
03
How it fits together
A person acts, the system checks, a result follows — and one other path, for when the check does not pass. This describes proposed responsibilities and decisions, not deployed infrastructure.
Read the diagram source
%% Director-friendly architecture. Maturity and limits are recorded in accDescr.
flowchart TB
accTitle: How Project Accord works
accDescr: Participants provide requirements and preferences for the available options. Signal keeps requirements separate and identifies which options are workable only when required replies are known. The decision owner chooses among feasible options and records why. Missing replies or conflicting requirements leave the decision pending. The service does not decide autonomously. This is a proposed concept.
A(["Participants<br/>Share requirements and preferences"])
B("Decision workspace<br/>Keeps essential requirements separate")
C{"Required replies known<br/>and options workable?"}
D(["Decision owner<br/>Chooses a workable option"])
E("Decision recorded<br/>With the reason why")
X("Decision pending<br/>Clarify or revise requirements")
A --> B
B --> C
C -->|Workable options| D
D -->|Explicit choice| E
C -->|Missing or conflicting| X
classDef human fill:#faf7f2,stroke:#bf8c53,color:#24211c;
classDef work fill:#ffffff,stroke:#a3a5ad,color:#25262a;
classDef decision fill:#f3efff,stroke:#967bcb,color:#30244c;
classDef result fill:#f0f6ff,stroke:#7b9dca,color:#1d365b;
classDef exception fill:#fff5ec,stroke:#ce9b63,color:#64431e;
class A,D human;
class B work;
class C decision;
class E result;
class X exception;
04
The case study
A decision should satisfy its required conditions before it competes on preference.
The problem
The most popular launch date excludes a mandatory participant. A poll captures enthusiasm but misses the distinction between a preference and a condition that cannot be violated.
The insight
Model requirements, constraints, and preferences separately, then make feasibility visible before a decision is recorded.
The system
The proposed decision workspace records options and named constraints, evaluates which options remain feasible, and displays preferences within that set. An authorised decision owner records the outcome against a specific version of the inputs.
The rationale
A visible rationale helps participants understand why a workable option was selected even when another received more reactions.
Responsibilities
- Decision inputs
- Options, requirements, constraints, and preferences remain distinct.
- Feasibility view
- Explain which options satisfy the required conditions.
- Recorded decision
- Named owner, input revision, and explicit rationale.
The boundary
Accord supports a decision; it does not autonomously resolve conflicting requirements or replace the person accountable for the outcome.
The trade-off
Formal constraints improve clarity but can become an accidental veto mechanism. The decision owner needs visibility into who set each requirement and why.
When it fails
No option satisfies the constraints
Show the blocking requirements and ask for revised options or explicit changes to the constraints.
A required participant has not replied
Keep their constraint state unknown. Silence must not count as availability or approval.
A constraint changes after decision
Flag the recorded decision for reconsideration without silently rewriting its original rationale.
Evidence Design proposal · local demonstration uses synthetic data
05
On the design side
Separating preference from constraint is a guest-list problem before it is a decision-tool problem.
Guests
The list, the ask, the table and the care.