Disposable addresses and tokens can change. Operator behavior leaves patterns.
Rugburn is risk infrastructure for inspecting token structure, operator relationships, funding topology, holder concentration, liquidity movement, and historical outcomes before a person or autonomous system acts.
OwnershipSolo product direction, architecture, Go worker, frontend, data systems, risk doctrine, API/MCP, bot surfaces, and operations.
GO + TSProduction systemWorker through product interface
API · MCP · BOTSAccess surfacesHuman and agent workflows
01
Context / failure
The first model was too structural.
The initial product inherited a familiar scanner assumption: if enough contract, authority, liquidity, and holder checks look healthy, the resulting score should be dependable.
Calibration showed the limitation. Overall accuracy could look respectable while failed-token separation remained weak. A clean score was not the same thing as a reliable account of the actor behind the launch.
SYS-01A model can be accurate and still miss the event that matters.+
Class imbalance can make aggregate accuracy flattering. Rugburn treats calibration as a reason to narrow claims, inspect failure classes, and keep evidence visible rather than marketing a perfect predictor.
02
System thesis
The reframe: follow behavior, not costume.
On Solana, a launchpad, program account, fee payer, authority, and true operator can be different entities. The hard problem is attribution.
01Resolve the subject
Separate program infrastructure from the human-controlled identity the evidence actually supports.
02Preserve provenance
Keep provider facts, on-chain evidence, and inferred relationships distinguishable.
03Represent absence
A failed measurement must not silently become a zero, a clean result, or a confident label.
04Expose why
The interface should show the evidence class behind the assessment, not only a final score.
03
Architecture
A layered forensic system.
Current public architecture, simplified
01IntakeDashboard, API, MCP, bots
02EvidenceRPC, provider, and market facts
03AttributionCreator, funding, and operator context
04AssessmentEvidence, confidence, and explicit limits
05PersistencePostgres records and calibration data
06SurfacesReports, alerts, agents, and public records
This diagram deliberately omits proprietary scoring policy, calibration thresholds, and private operational controls.
Source-backed surface / ForgeScan evidence moves from intake to an inspectable assessment.
Production
01 / IntakeSubject resolved
Token, wallet, or deployer enters a shared evidence path.
02 / EvidenceKnown · degraded
Provider facts retain source and coverage state.
03 / AssessmentWhy remains visible
Risk and confidence are presented as separate concepts.
Decision provedForge proves that the product exposes the path from evidence collection to a bounded conclusion, including degraded coverage.
Source-backed surface / AtlasFunding topology is useful only after infrastructure is excluded.
Production direction
SubjectDeployer
The visible launch identity starts the investigation.
Evidence edgeFunding relation
A relationship carries provenance and confidence, not visual coincidence.
BoundaryShared rail excluded
Known exchange and provider infrastructure is contextualized.
Decision provedAtlas proves the attribution decision: relationship edges are qualified before they become operator evidence.
Source-backed surface / AuguryA claim remains attached to its eventual outcome.
Emerging public corpus
T-0Call recorded
The initial assessment is fixed before resolution.
IntegrityHash chained
A record cannot quietly forget an earlier claim.
ResolutionStanding · fulfilled · broken · void
Misses and unresolved states stay explicit.
Decision provedAugury proves the accountability decision: the product preserves the original call and the result instead of displaying only wins.
04
Key decisions
Attribution is where the system earns trust.
Launchpad ambiguity
Infrastructure can look like an operator.
Known programs and shared services must be excluded or contextualized before they contaminate deployer history.
Burner rotation
The visible wallet may be disposable.
Funding relationships and repeated behavior matter because the address that pressed the button may never appear again.
False clustering
Shared rails are not automatic coordination.
Exchange and provider infrastructure can connect unrelated users. Edges need evidence and confidence, not a visual coincidence.
Provider failure
Unknown must remain unknown.
Missing history, immature market data, or a timed-out provider should degrade the claim instead of laundering uncertainty into safety.
ATTR-02Wrong data is quieter than no data.+
A visible degraded state creates friction, but a fabricated zero creates false certainty. The system prefers a bounded non-answer over a clean lie.
05
Product doctrine
Evidence before confidence.
Evidence
Show the holder, liquidity, authority, market, deployer, and funding facts the assessment can defend.
Confidence
Keep the strength of the evidence separate from the severity of the risk.
Unassessed
Missing coverage is a distinct state. It is not safe, risky, or zero.
Boundaries
High-risk evidence can constrain the final presentation without exposing private scoring mechanics.
06
Design system
The interface uses contrast as an information budget.
Rugburn’s current design system separates recessed instrument panels from raised objects, quiet chrome from semantic status, and known values from degraded or unassessed data.
Risk color is reserved for risk. Unknown has its own semantics. A decorative accent cannot borrow the same visual language as a critical finding without weakening the whole forensic hierarchy.
DS-03Semantic status cannot become decoration.+
If a color means critical risk in a forensic interface, reusing it as casual brand chrome makes every future signal harder to read.
07
Augury / operating doctrine
Verifiability means preserving the misses.
The Augury direction records selected claims before outcomes resolve, then keeps the result attached. The point is not mystique. It is making it harder for a system to quietly delete a wrong prediction and remember only its wins.
The verification surface exists in the product direction; the public record is still an emerging corpus, so no accuracy claim is presented here.
08
Outcome
What shipped, and what changed.
Production Go worker and Next.js product surfaces.
Token, wallet, and deployer evidence exposed through dashboard, API, and read-only MCP.
Telegram and Discord scan access for community workflows.
Calibration, provenance, and explicit unknown states became product requirements, not internal implementation details.
The product thesis moved from “scan the token” toward “inspect the operator and the evidence around the action.”