Technical documentation.

Architecture

MALiGN is built as a hard-multiplexed monorepo of eight cooperating subsystems. The web tier is an edge-rendered Next.js application; every long-running computation is executed by an isolated worker process communicating exclusively through durable database-backed job queues. No request ever blocks on inference — streams are cancel-token managed from browser to model and back.

apps/web         Next.js UI + API routes (guest sessions · SSE streams · artifact store)
services/worker  autonomous execution substrate: swarm graphs · recon suites
                 agent tool-loops · scheduled ledger & catalog jobs
packages/db      schema + durable queue w/ heartbeats & stale-requeue
                 usage metering · micro-dollar credit ledger
packages/shared  zod contract layer · presets · routing-tier utilities
                 crawler etiquette (robots parsing, UA rotation)
packages/gateway multi-engine MLN inference mesh · egress proxy control
                 streaming with mid-stream cancellation · offline mock mode
packages/agent   sandboxed tool-loop runtime (http / search / fs / js_run / finish)
apps/range       integrated practice range — live-fire training target on :3001
infra/           compose stack: postgres · redis · migrate · web · worker · TLS edge

The execution substrate

Missions are admitted through a zod-validated gateway (/api/missions) under per-account concurrency caps and daily token ceilings, then become durable jobs claimed by workers in FIFO order with heartbeat liveness — crashed work is automatically detected, requeued, and never lost. Each mission runs as a directed graph of agent roles (planners, researchers, synthesizers) that execute concurrently against isolated result channels and merge under contradiction checks.

Inference mesh (the MLN engine)

All reasoning flows through the MLN engine — MALiGN's proprietary adaptive routing layer. It abstracts an arbitrary pool of frontier engines behind three compute profiles (balanced · rapid · deep), selecting engines per-request based on task class, latency budget and payload shape. Client surfaces never see engine identities, providers or endpoints — only profiles. Requests traverse the platform's own egress fabric; nothing about upstream topology leaks to the browser tier.

Resilience chain

request → profile router → primary engine ─┬─ success → metered stream to client
                                           ├─ fallback #1 (fast-class engine)
                                           ├─ fallback #2 (second pass, backoff-gated)
                                           └─ circuit-break → graceful degradation

The scan pipeline

Three escalations, recorded per-run under scan.phase:

• passive — certificate-chain inspection, full DNS surface mapping, certificate-transparency subdomain enumeration, historical archive mining, robots/intent analysis, tech fingerprinting, security-header scoring.
• active-advisory — expanded path discovery across a curated wordlist, form-surface enumeration, reflected-XSS advisories, SQL error-signature detection, login-surface mapping plus credential-hygiene probing at disciplined request rates with etiquette enforcement.
• deep-exploit — the full offensive suite for authorized engagements:
  · extended directory burst + sensitive-asset exposure sweep
  · parameter mining → boolean-delta & error-based injection confirmation per parameter
  · reflected-XSS sink classification across rendering contexts
  · CRLF/header-injection probes · open-redirect heuristics
  · auth-bypass suffix logic against admin-classified surfaces
  · complete TLS chain-of-trust walk
  · CVE exposure matrix: evidence-based fingerprint matching against high-profile CVEs spanning Log4Shell-class RCEs, framework deserialization chains, traversal primitives and appliance attack surfaces — each scored with CVSS context
  · extended credential analysis: dozens of common weak pairs × account space

Every finding is evidence-linked: reports embed the verbatim probe, URL and response-shape that produced the signal. Fingerprint matches are published with confidence labels — the console treats unverified claims as unverified, which is what makes its output trustworthy enough to act on.

Engineering quality gates

The repository ships a nine-gate verification pipeline (nightcheck): typecheck → production build → production boot → boot smoke probes → end-to-end public-flow suite → deep API robustness matrix → security behavior matrix → load characterization → chaos drill (worker kill/requeue under live traffic). Supply-chain installs are lockfile-frozen with zero-known-vulnerability policy enforced via workspace overrides.

Credits & metering

wallet ................ micro-dollar balance per identity
pricing ............... per-engine rates resolved from the live catalog
grant ................. daily allowance applied by scheduler job platform-wide
chargeAfterUsage ...... debits metered tokens per request, mission-referenced
FREE_MODE ............. operator switch: open access mode

Deployment posture

Development runs on an embedded local store; production deploys as a containerized stack — persistent state volumes for Postgres/Redis/workspaces, automated migrations at boot, automated TLS at the edge, hardened session cookies behind HTTPS, health-checked services with restart policies. Deep-mode egress is designed to route through configurable proxy fabrics so the platform's origin IP never becomes the scanning fingerprint.

Roadmap (near-term)

→ in-house weighted engine nodes served from isolated enclaves
→ attestation artifacts for every scan run (verifiable evidence chain)
→ swarm marketplace: community-authored mission templates
→ multi-region worker pools with per-region etiquette budgets

Environment cheat-sheet (operator)

DATABASE_URL           embedded store (dev) | postgres cluster (prod)
*_API_KEY              engine credentials — server-side only, never shipped
DEFAULT_CHAT_MODEL     MLN balanced-route default
CHAT_MODEL_FAST/MAX    rapid & deep tier mappings
MOCK_GATEWAY           deterministic demo engine for offline demos
ATTACK_MODULES         advisory attack-module master switch
WORKER_MAX_CONCURRENT  execution substrate concurrency (default 4)
GRANT_DAILY_MICROS     daily free credit grant size
RESPECT_ROBOTS         etiquette enforcement for light audits
ALL_PROXY              optional egress fabric for scans+inference

Production domain layout: app.* → this console · docs.* → this page · range.* → live-fire practice target · chat.* → direct chat-room entry.