Analysis of an open repository: what gates stand between a found match and a human, and what is the limitation of the matching logic itself.
First. Between a finding and a person stand four gates in a row: the community boundary, the reading ceiling, the return ceiling, and the rule "only what the agent opened becomes an opportunity." Each gate cuts silently, without recording a reason.
Second. The similarity threshold in the most prominent path is set to zero. The logic optimizes not to "return only good ones," but to "fill ten spots." A candidate with weak similarity will make it into the top ten if there aren't enough better ones, and a strong one outside the top ten will never make it.
Third. In the code, there is a service that searches for real people on the open web and synthetically inserts them into pairs. And there is a place where a constant hundred is recorded instead of an evaluation, and zero evidence. Therefore, the six percent who made it is not a consequence of limits, but a consequence of the finding arriving without a reason to look at it.
Their funnel loses findings not because the findings are bad, but because the system has no rule that distinguishes a good finding from a filled spot. All ceilings are before the person, and there is not a single one on the person themselves.
I took their open repository entirely, looked at all 343 TypeScript files, found three places where the detection and evaluation logic lives: the intent service, the protocol package, and the database adapters. Then I followed the path of one finding from intent creation to the card at the person's and wrote down every step where it could disappear.
Each statement below is tied to a specific file and line, so it can be verified in a minute, rather than taken at face value. Files and commands for re-verification are listed at the end.
Everything named as a rule or a number is taken from their code or their documentation. Where the breakdown by stages is not derived from open data, it is stated directly, and not substituted with a plausible number.
Below is the path of one finding. Red marks indicate places where it might disappear, and none of them inform either a human or an agent that the finding occurred.
| Gate | Rule | Where |
|---|---|---|
| community boundary | intent is searched only within communities to which it is assigned; no communities, search returns empty | intent.service.ts:488 |
| reading ceiling | the system reads a maximum of 90 candidates per search | intent.service.ts:57, 499 |
| similarity threshold | in query search, the threshold is zero, meaning it is not applied | intent.service.ts:500 |
| return ceiling | no more than 10 candidates are returned externally; a maximum of 30 can be requested | intent.service.ts:47, 50, 529 |
| duplicate collapsing | one intention in multiple communities yields one row, the best hit remains | intent.service.ts:506 |
| discovery ceiling | no more than 30 opportunities per call; one's own intention and self-match are skipped | intent.service.ts:60, 562, 563, 568 |
| pair validity | active intentions attributed to this network and different people are needed; otherwise, there will be no opportunity | negotiation.rules.ts:48 |
| right of discovery | only a candidate discovered by an agent becomes an opportunity | their opportunity section documentation |
| negotiation limit | 12 moves maximum, a move no longer than 4000 characters | negotiation.constants.ts:2 |
| exhaustion of moves | at the limit, the status remains "negotiations", there is no refusal, the question is pending | negotiation.rules.ts:79, 83 |
| expiration | only archiving of intent, check every 15 minutes; capabilities have no timeout | opportunity-expiration.cron.ts:26 |
Pay attention to the order. First, they cut by affiliation, then by quantity, then by who opened it. None of these places evaluate the quality of the match. Quality selection is completely absent in this chain.
The main finding of the analysis. There are three different similarity thresholds in the repository, and they are not consistent with each other.
The threshold is set by the calling code, and in the most prominent path, query search, it is set to zero. This is not a one-line oversight; it is a consequence of the design: the system rounds up to ten candidates instead of returning only those that passed evaluation.
A person whose best candidate scores thirty-one hundredths still receives ten cards. A person who has one strong candidate and nine weaker ones also receives ten. There is no difference between these two cases in the interface, because the logic does not distinguish between “there is a match” and “reached the limit.”
Second in importance. When an opportunity is created by a personal agent after the owner manually selected a counterparty, the pair is recorded as follows: the score is one hundred, the evidence list is empty, and in the reason field, it is written in their own text that there is no score at all.
Their own comment on this point: the agent's judgment is which counterparties it chose, so there is nothing to transfer to the pair. The logic is honest. But the result is this: on the card, a person sees confidence from one path as calculated by the model, and from another as a constant one hundred, and it is impossible to distinguish them by the card.
At the same time, their own documentation shows an example card with eighty-seven hundredths confidence. This means the number on the card is read by a person as a quality assessment, although in one of the paths, it is not an assessment at all.
An opportunity born from an agent's choice comes to a person without a single piece of evidence. An empty list of evidence is a direct quote from the code, not our interpretation. This is where the gap is, which our evidence envelope closes.
There is a separate service in the repository. It searches for real people on the open web through an external research interface, registers them as participants with intentions and avatars, and introduces them into pairs through a service account. Up to three such counterparties are allowed per intention.
Further, the system works with them as with ordinary participants: they go through negotiations and can be accepted by a person. After acceptance, a letter with the option to refuse is sent to the real person whose profile was found on the web.
This changes the reading of their funnel. Some of the found matches are not matches between living people, but rather substituted counterparties. This is not separately stipulated in the field report, and the extent of this proportion cannot be derived from open data.
Separately, it is worth noting the honesty of their code. Three confessions they left directly in the text:
First. The list of network intentions is truncated at fifty lines, and filtering happens afterward, so in the loaded network, a person might lose their own intentions. This place has a ticket number.
Second. The field "who proposed" is present, but always empty: the value is not filled anywhere.
Third. Capabilities have no timeout. Expiration is only possible through archiving the intention, so a negotiation that has hit its move limit hangs indefinitely.
Such comments are usually not written. They mean that the team knows its limitations and states them aloud. This makes their code readable, and them a suitable party for a conversation about the standard.
Below are their own field run numbers and what happens between stages according to the code. The breakdown of "exactly how many gate number two were cut off" cannot be derived from the open data, because their report only gives the results of the stage, not the reasons for the disappearance of each finding. This is noted directly, instead of a plausible figure.
| Stage | Number | What happens between stages according to the code |
|---|---|---|
| intentions | 541 | visible only within communities, not searched outside the community |
| pairs found | 9 688 | up to 90 candidates are read for search, up to 10 are output, similarity threshold is zero |
| negotiation sessions | 11 593 | launched only for candidates opened by the agent; limit 12 moves |
| different pairs of people | 4 126 | duplicate pairs are collapsed by counterparty key, the record with higher confidence remains |
| reached a person | 572 | there is no limit on the number of cards a person has at all |
| introductions made | 147 | each human decision is a separate action; a repeated decision is rejected |
A ratio worth keeping in mind: about six percent of what was found reached a person, and about a quarter of what reached them led to an acquaintance. The first is a consequence of the selection logic. The second is already human, and logic does not affect it.
The system perfectly decides whom to find, and does not decide at all to whom among those found it should show itself. All ceilings are on the search side, none on the evaluation side. Hence the six percent.
| The solution in their code | Our attitude | Why |
|---|---|---|
| list of reasons for refusal in negotiations | we take | nine explicit reasons instead of “it didn’t work out”; we have a move limit, but no such list |
| checking the suitability of a pair before opening | we take | both intentions are active and attributed to the network; we have an owner check, but no activity check |
| limit of 12 moves | we take | matches ours; for them, the question at the limit remains open, and this is more correct than a refusal |
| selection without a threshold with topping up to ten | we don't take | turns the finding into a filled spot and deprives a person of a quality attribute |
| constant instead of confidence | we don't take | the number on the card ceases to mean anything, and the person doesn't know about it |
| synthetic counterparties | we don't take | makes the funnel incomparable with the live market and blurs the very concept of consent |
| empty proofs from the couple | we don't take | it is precisely this gap that our proof envelope closes |
The analysis was done based on the code for a single date, main branch, commit from October nineteenth. The code changes, and any rule here should be re-checked if a decision relies on it.
The funnel numbers are taken from their public report; they do not have a single independent reproduction. The share of synthetic counterparties in these numbers cannot be derived from open data, and we do not estimate it.
We did not look at their operational service, only the open code and documentation. A difference between the code and the deployed system is possible, for example, in threshold settings.
Decomposition of losses by gates in percentages. Their report does not provide data for such a decomposition, and a plausible figure here would be worse than its absence.
The repository is open under the MIT license, so verification takes minutes. Below are the files containing all the rules from this analysis, and what to look for in each.
| File | What to look at |
|---|---|
| services/api/src/services/intent.service.ts | search and discovery ceilings, similarity threshold equal to zero, recording a pair with a score of one hundred and empty evidence |
| services/api/src/adapters/chat.database.adapter.ts | default threshold of thirty hundredths, comment about the list truncated at fifty lines and a ticket |
| services/api/src/adapters/database.adapter.ts | default threshold of seventy hundredths |
| packages/protocol/src/protocol/negotiation.rules.ts | list of rejection reasons, pair validity rule, behavior at the move limit |
| packages/protocol/src/protocol/negotiation.constants.ts | twelve moves, four thousand characters per move |
| services/ghost/src/ | searching for people on the web, adding them as participants, up to three per intent, rejection letter |
| services/api/src/crons/opportunity-expiration.cron.ts | expiration only upon intent archiving, check every fifteen minutes |
First and foremost: our position is not "we do the same thing better," but "we do what is missing in this chain." They do not have a single rule that distinguishes a good match from a filled space, and they do not have a single piece of evidence attached to a finding.
Second: two of their rules are worth adopting, and this is not borrowing, but a common industry denominator that they have articulated carefully. The list of rejection reasons and the pair validity check.
Third: our evidence envelope ceases to be an embellishment and becomes a direct answer to a specific line in their code where evidence is an empty list.
Add two found rules to the stand: the list of rejection reasons and the intent activity check. Both are small, both are testable, and after them, we will have a complete set of what their design does, plus what it doesn't.
ARLI membership: the notes from the workshop
One site of yours, measured, with the price for the work in the same document
ARLI, Inc., a Delaware corporation. Questions: hq@arliwork.com.