Operational intelligence that earns a decision.

Multi-vertical V1

Coverage grows from the records teams already keep.

Connectors, templates, and delivery surfaces are capability-ledger commitments, not claims that every integration is already live.

• CSV / Excel: Committed V1 scope
• Tally XML: Committed V1 scope
• Zoho CRM: Committed V1 scope
• Salesforce: Committed V1 scope
• Slack: Committed V1 scope
• REST APIs / Webhooks: Committed V1 scope
• ERP exports / custom adapter: FDE-scoped V1

Two motions, one engine

Lens and FDE compound the same operational learning.

Both use one shared engine for ingestion, Nous, detection, delivery, feedback, and the Pattern Library.

Pattern Library

Five committed patterns focus attention on preventable loss.

• Dead Stock DetectionCommitted V1 scope
• Silent Buyer / Churn RiskCommitted V1 scope
• Margin LeakageCommitted V1 scope
• Payment Delay / Credit RiskCommitted V1 scope
• Feature Regression CorrelationCommitted V1 scope

Authority stays gated

Infrastructure can be in V1 without production authority.

• Engine-proposed candidate discovery: Data-gated V1May analyse authorized tenant data only in read-only, tenant-isolated execution. It cannot be enabled as a production pattern, initiate an independent production scan, influence production confidence, or produce deliverable findings before reviewed, authorized promotion.
• Supervised confidence/output: Data-gated V1May train, evaluate, and run in shadow mode, but cannot control production confidence before 500 labelled findings across at least three tenants, sufficient pilot history, documented evaluation and calibration, rollback proof, and named approval authority.
• Bandit/RL authority: Data-gated V1May collect outcomes, simulate, and shadow-rank, but cannot reorder, suppress, or control production findings before the documented resolved-outcome threshold, offline evaluation, rollback proof, and named approval authority pass.

V1 recommends actions and records feedback. It does not write back to client systems. It does not execute business decisions. It does not automatically retrain models.

Truthful scope

Capability ledger

Implemented now

Repository-verified and test-verified.

Active V1 implementation

Required V1 capability currently being built.

Committed V1 scope

Required for V1 and accepted into the dependency-ordered implementation program, but implementation has not yet started.

FDE-scoped V1

Required V1 capability delivered through reviewed, tenant-specific engineering.

Data-gated V1

Infrastructure included in V1, but production authority remains evaluation/shadow-only until explicit gates pass.

V1 integration coverage

CSV / Excel: Committed V1 scopeTally XML: Committed V1 scopeZoho CRM: Committed V1 scopeSalesforce: Committed V1 scopeSlack: Committed V1 scopeREST APIs / Webhooks: Committed V1 scopeERP exports / custom adapter: FDE-scoped V1

Sector templates

Distribution/Wholesale: Committed V1 scopeManufacturing: Committed V1 scopeSoftware/SaaS: Committed V1 scopeLogistics/3PL: Committed V1 scope

Pattern Library

Dead Stock Detection: Committed V1 scopeSilent Buyer / Churn Risk: Committed V1 scopeMargin Leakage: Committed V1 scopePayment Delay / Credit Risk: Committed V1 scopeFeature Regression Correlation: Committed V1 scopeFDE-authored custom patterns: FDE-scoped V1

V1 infrastructure

MLflow: Committed V1 scopeRiver: Committed V1 scope

Engine-proposed candidate discovery

Data-gated V1: May analyse authorized tenant data only in read-only, tenant-isolated execution. It cannot be enabled as a production pattern, initiate an independent production scan, influence production confidence, or produce deliverable findings before reviewed, authorized promotion.

Supervised confidence/output

Data-gated V1: May train, evaluate, and run in shadow mode, but cannot control production confidence before 500 labelled findings across at least three tenants, sufficient pilot history, documented evaluation and calibration, rollback proof, and named approval authority.

Bandit/RL authority

Data-gated V1: May collect outcomes, simulate, and shadow-rank, but cannot reorder, suppress, or control production findings before the documented resolved-outcome threshold, offline evaluation, rollback proof, and named approval authority pass.

Architecture

Architecture diagrams

PostgreSQL remains the operational system of record. Immutable raw records flow through tenant-specific Nous metadata. The Go backend owns ingestion, authorization, deterministic validation, action construction, delivery, and feedback. The scoring service returns per-method scores, composite score, warnings, provenance, and explanation fragments; it does not decide actionability or delivery.

Architecture figure

High-level Mulanous Lens architecture

Summary. Existing business data moves through immutable ingestion, PostgreSQL domain data, Nous metadata, four distinct detection stages, and role-specific delivery. Structured feedback returns through reviewed configuration to future detection without changing raw records.

Show architecture figure

Source systems

1. CSV / Excel
2. Tally XML
3. Zoho CRM
4. Salesforce
5. Slack API
6. REST / Open API

1. Immutable raw storeAppend-only raw records with ingestion provenance
2. PostgreSQL domain dataPostgreSQL system of record with tenant isolation and RLS
3. Nous metadataMetadata over PostgreSQL, not a database

Pass 1

Candidate generation

Pass 2A

Scoring runtime

Pass 2B / Evidence Ladder

Deterministic counter-interrogation

Pass 3

Impact and action filtering

• Operator delivery
• Manager delivery
• Executive delivery

1. Delivery
2. Feedback
3. Reviewed Pattern Library and configuration
4. Future detection

Architecture figure

Nous ontology layer

Summary. Nous metadata maps PostgreSQL domain data into tenant-aware object instances. It is metadata over PostgreSQL, not a separate database, and improved mapping rules replay immutable raw records.

Show architecture figure

1. Raw Ingestion StoreRaw records are immutable and replayable.Raw records
2. PostgreSQL Domain TablesBuyers, products, orders, payments, and inventory snapshots.PostgreSQL tables
3. Nous metadata

   Object types

   Named business entities.

   Properties

   Typed fields with semantic tags.

   Links

   Named joins between object types.

   Mapping rules

   Source-to-property transformations.

   Tenant-aware relationships

4. Object InstancesBuyer, Product, Order, Payment, Inventory
5. Pattern QueriesBuyer places Order; Order contains Product; Order triggers Payment; Product tracked in Inventory
6. Detection EngineQueries traverse tenant-aware object relationships.

Architecture figure

Detection Engine

Summary. The Pattern Library produces untrusted candidates. Pass 2A scores them, Pass 2B tries to disprove them using deterministic checks and the Evidence Ladder, and Pass 3 prepares verified actions for the correct role.

Show architecture figure

1. Pass 1Candidate generation from Nous-resolved patterns
2. Pass 2A
   • IsolationForest
   • ruptures
   • STL
   • Prophet
   Composite anomaly scoreMinimum anomaly score threshold
3. Pass 2B / Evidence Ladder

   Deterministic checks

   • Seasonality
   • Stockout vs demand
   • Data freshness
   • Sample size
   • Tenant context
   1. Own history
   2. Peer cohort
   3. Cross-client benchmark
   4. Insufficient evidence: watch, do not surface
4. Pass 3

   Specific action

   Concrete next step

   Owner

   Responsible role

   Impact

   Quantified value at stake

   Confidence

   Composite score + evidence rung

   Delivery surface

   Role-specific format

Verified findings

• Operator delivery
• Manager delivery
• Executive delivery

Suppressed findings

• Weak signal / below threshold
• Not actionable
• Needs more evidence
• Failed checks

FeedbackFeedback returns to reviewed patterns and Evidence Ladder baselines.

Architecture figure

Decision delivery modes

Summary. One verified Pass 3 finding is filtered by role, adapted to the role's decision context, then routed through the client's configured delivery channel.

Show architecture figure

Verified finding

• Entity
• Signal
• Evidence summary
• Confidence
• Recommended action
• Owner
• Estimated impact

1. Role filterMatches the finding owner to the user role.
2. Format adapterPreserves one finding while changing its role-specific format.
3. Channel routerRoutes the format through the client's configured channel.

Operator mode

One action, one owner, no charts.

Manager mode

Aggregated team and territory exceptions.

Executive mode

Evidence, quantified impact, confidence, and decision context.

• In-appCommitted V1 scopeRole-specific workflow
• EmailCommitted V1 scopeDaily and weekly email digests
• SlackCommitted V1 scopeOperator workflow
• PDFCommitted V1 scopeExecutive PDF report
• WhatsAppExcluded from V1Not a V1 delivery channel

Architecture figure

Feedback loop and Pattern Library

Summary. Delivered findings collect structured human feedback that informs reviewed Pattern Library and Evidence Ladder configuration for future detection.

Show architecture figure

Delivered finding

Finding, evidence, action, owner, and confidence.

User response

• Useful
• Wrong
• Already Known
• Not Actionable
• Fixed
• Ignored

Structured labelled signal

finding_id

Traceable finding

user_role

Responding role

response_label

Feedback label

reason_code

Structured reason

action_taken

Recorded action

timestamp

Recorded time

Pattern Library

• Dead Stock Detection
• Silent Buyer / Churn Risk
• Margin Leakage
• Payment Delay / Credit Risk
• Feature Regression Correlation

FDE custom patterns

Engine-proposed candidate patterns
Data-gated: candidate-only until reviewed promotion.

Evidence baselines

Seasonality, data freshness, sample size, and tenant context.

Reviewed adjustment to pattern weights and evidence thresholds.

Feedback changes explicit, auditable configuration; it does not silently retrain models.

Architecture figure

Lens deployment modes

Summary. Lens self-service and Forward Deployment use one Mulanous core. They differ in configuration depth and delivery scope, not architecture.

Show architecture figure

Mulanous Lens core

Shared data, Nous, detection, and feedback

Lens self-service

Productized onboarding and proven standard patterns.

Forward Deployment

Engineer-led mapping, calibration, and reviewed custom patterns.

Configuration depth, not distinct architecture

Onboarding

Lens: Self-serve

Forward Deployment: FDE engineer-led

Pass 2 scrutiny

Lens: Light: Rung 2-3 default

Forward Deployment: Heavy: all checks, Rung 1 where data allows

Pattern Library

Lens: Standard patterns

Forward Deployment: Standard and custom patterns per engagement

Delivery

Lens: Operator and Manager

Forward Deployment: All three, including Executive

First finding timeline

Lens: Days to weeks

Forward Deployment: 1-3 weeks: pilot week mapping and baseline

Price point

Lens: Monthly subscription

Forward Deployment: Engagement fee and retainer