How Builder works
When one problem is shared by many.
Builder keeps the process simple for users and careful behind the scenes. It checks if a problem already exists, asks people to support existing problems, and gives the Witdrim review team a clear way to keep Builder reliable.
Creating a new problem is not always the best action. Sometimes the right action is supporting the one that already exists.
If similar problems multiply, Builder becomes noisy. Builder is built to make support and merging easier than duplication.
Workflow
The full flow, from writing to review.
To the user, Builder should feel easy. Behind the scenes, every shared problem is cleaned, checked for matches, reviewed, and then used for learning or later decisions.
The user writes a problem.
The input starts as plain language. The user can explain what is happening, who is affected, and why the issue matters.
Builder cleans the text.
The system can fix basic grammar, choose a category, and prepare a clear version for matching and translation.
Builder looks for similar problems.
The matching layer compares the new problem with active problems. It looks for meaning, not only identical words.
If the match is right, the user supports it.
The user confirms the existing problem instead of creating a duplicate. This keeps all support in one place.
If the match is wrong, the user explains why.
The user can say it is not the same problem. Builder then asks for more detail before creating a new record.
Witdrim reviews the record.
The Witdrim review team can validate, reject, merge, or remove records. This protects Builder from spam, duplicates, and vague submissions.
Validated problems become usable.
Builder uses real problems from the system. It should not use examples, fake counts, or invented people to look active.
Learning adds context.
A problem can collect books, articles, news, references, and other real material so users can understand it better.
Duplicate control
Similar problems should come together.
Builder only works if repeated problems do not split into many copies. The system should prefer support, better details, and review-team merging over new duplicate records.
Match the meaning
The check should compare the idea, affected people, category, and context, not just exact words.
Support first
When a strong match exists, the main action should be supporting the existing problem.
Ask for the difference
If the user rejects a match, Builder should ask what makes their problem different.
Merge when needed
The review team needs a clear path to merge records if two problems turn out to describe the same issue.
Similar problem found
The match moment must be clear.
When Builder finds a similar problem, the interface should pause the user. It should show the existing problem clearly and ask if that is what they mean.
Yes, I have this problem
Adds a real confirmation to the existing record.
No, this is different
Allows the user to continue only by explaining the difference.
Add more details
Improves the problem statement so Builder can match more accurately.
Witdrim review
Human review keeps Builder trustworthy.
Builder should not rely only on automation. Witdrim review gives the team a way to protect quality while the system improves.
Validate
Mark a problem as reliable enough for public use.
Reject
Remove vague, abusive, irrelevant, or invalid submissions from public areas.
Merge
Combine duplicate problems and preserve confirmations on the strongest record.
Delete
Soft-delete records that should remain auditable but hidden.
Trust rules
Public reading, authenticated action, real data.
Builder can be open to read, but actions that change the data must be tied to real Witdrim accounts.
Open to read
People should be able to understand Builder and read public problem context without logging in too early.
Login to act
Sharing a problem or confirming one requires Witdrim Auth.
Real users only
Support should come from accounts the system can verify.
No fake statistics
Every count, source, and status should come from Builder or a traceable provider.
A clean flow protects the problem map.
If the first layer is clean, every future workspace and solution starts with better context.