Rules-based capital allocation

Your money,
moving together.

Alepes helps you define how new money should flow into your portfolio, then directs contributions toward the holdings that need them most.

Rules-based capital allocation, with every decision explained.

Preview only — live transfers and live brokerage execution are not currently available.

Live flowShadow Mode

Paycheck +$3,200

Payroll deposit detected

MSFT
+$172
GOOGL
+$133
V
+$101
NVDA
+$74

How it works

From cash flow to formation.

  1. 1
    Qualifying deposit detected
  2. 2
    Cash-flow rule evaluated
  3. 3
    Reserve preserved
  4. 4
    Deployable amount calculated
  5. 5
    Portfolio contribution allocated
  6. 6
    Shadow plan explained

Two policies, kept separate

Your cash-flow policy decides whether and how much to deploy from new money — triggers, reserves, and caps. Your investment policy decides where it goes: the target allocation and bands that define your formation. Keeping them separate is what makes every decision explainable.

Cash-flow rules

Your automation, in rules you author.

Example rule — authored by you

Active

WHEN

a qualifying deposit is detected

IF

checking remains above $5,000

THEN

invest 40% of the deployable amount

Formation

Stay in formation with new money.

Formation is how close your portfolio is to its target allocation. Holdings drift over time; Alepes uses each new contribution to move the school back toward formation — underweight first, without forced selling.

Formation check

drifted
SymbolTargetCurrentAction
VTI50%44%Buy
AAPL25%30%Hold
VXUS25%26%Hold

New contribution → directed primarily toward VTI, the most underweight holding.

Shadow Mode

See the decision before anything moves.

Shadow Mode evaluates your rules and shows exactly what would happen — a full plan, with nothing executed.

Simulation only — no money moved

Shadow trace

No money moved
Deposit detected$1,250
Reserve preserved$5,000
Rule matchedInvest 40%
Deployable$500
Formation checked—
Allocation calculated—
Shadow plan created—

Explainability

Every decision, traceable.

Decision audit

What happened?
A qualifying deposit of $1,250 was detected.
Which rule matched?
“Invest 40%” above the $5,000 reserve.
Why was this amount deployable?
$500 — 40% of the deposit, after the reserve.
Which holding was underweight?
VTI, at 44% vs. its 50% target.
Why did it receive this allocation?
It had the largest actionable gap.
What would happen next?
The plan is held for your review — nothing executes.

Future capability

Models produce opinions. Alepes decides what is allowed.

Designed for what comes next, Alepes may one day let models influence a Formation — at the level of a single holding, of the whole portfolio, or both. A model would never submit an order or move money. It produces investment intent, an input that Alepes resolves through your policy, constraints, and execution rules.

Designed for what comes nextNot available today

How a model would fit — one direction of flow

Model
Investment Intent
Alepes Policy
Resolved Formation
Allocation Engine
Shadow / Execute

The model is an input to Alepes policy — not the authority. Every step after intent is Alepes's own deterministic machinery, unchanged.

Holding models

A model assigned to one holding evaluates that asset and produces a signal or a constrained intent — a valuation read, a momentum view, a quality flag, a volatility measure, or a factor score. It never produces a broker order directly.

ValuationMomentumQualityVolatilityFactor score

Formation models

A Formation-wide model evaluates the portfolio as a whole and may propose target weights or portfolio-level adjustments. Alepes still validates the resulting Formation against your rules and safety constraints.

Minimum volatilityRisk parityBlack-LittermanFactor allocationVolatility targeting

A future Formation with models

Formation model
  portfolio-risk-v4

AAPL → valuation-quality-v2
MSFT → momentum-v1
VTI  → (no holding model)

When both levels exist, composition is explicit: holding models contribute asset-specific signals while a Formation-level model resolves those signals into a coherent portfolio view. There is no “most specific model wins.” Any override behavior is a policy you configure, not a default.

Model output is subordinate to Alepes policy

Example

Model: AAPL target = 40%

Constraint: max single holding = 20%

Result: Alepes caps the target at 20%

Example

Model: allocate $800

Capital plan: only $240 investable

Result: Alepes can allocate at most $240

  • Disabled securities remain disabled.
  • Reserve rules still apply.
  • Contribution limits still apply.
  • Execution policy remains independent.
  • Models cannot bypass pause or kill switches.

Models would start in Shadow Mode

A future model would first run in Shadow Mode, where Alepes compares the current Formation, your target Formation, and a model-resolved Formation — side by side, with nothing executed. This is a simulation to review, not a live allocation.

Current Formation

40 / 35 / 25

User target

50 / 30 / 20

Model-resolved target

44 / 38 / 18

A new flow of $500 would be allocated against the resolved target, and the difference would be explained — not silently adopted.

Simulation only — no live model-driven trading today

Every model evaluation, versioned and auditable

A future Alepes decision could record: which model was used, its version, the input snapshot, the resulting intent, the policy constraints applied, the final resolved Formation, the Shadow or execution decision, and an explanation of why the result changed. Alepes should be able to explain not only what a model suggested, but how Alepes transformed that suggestion into an allowed decision.

A future model ecosystem

Alepes owns the model system. External libraries may provide model implementations.

Models produce investment intent. Alepes resolves that intent into a Formation and applies its existing deterministic financial and safety policies.

Alepes-native deterministic models

Momentum, valuation, volatility targeting, contribution tilt, and factor scoring — simple, explainable, and policy-bounded.

Portfolio-model libraries

Proven portfolio-optimization libraries may one day provide Formation-wide models such as minimum volatility, maximum Sharpe, Black-Litterman, or hierarchical risk parity. This is an example of a type of integration, not something integrated today.

Alepes is designed to host multiple model types without making any one quantitative framework the financial brain of the product.

Models produce opinions. Alepes decides what is allowed.

Product preview

A look at Alepes.

Static mock views of the product. No live connections, no real accounts.

OverviewFormationRulesShadow ModeActivity

Formation check

drifted
SymbolTargetCurrentAction
VTI50%44%Buy
AAPL25%30%Hold
VXUS25%26%Hold

New contribution → directed primarily toward VTI, the most underweight holding.

Safety guardrails

Guardrails that take precedence over growth.

Zero unauthorized orders or transfers.

No order or transfer is submitted unless a separately authorized execution capability exists and the user has explicitly granted it. Current state: preview only.

Zero excess investment beyond user limits.

Reserves, caps, and monthly maximums are user-authored. Nothing deploys beyond what the user's rules permit.

Zero silent plan rewrites.

Every decision is traceable. Immutable evidence preserves original provenance — corrections append history rather than rewrite it.

Zero credential exposure.

Provider tokens and secrets never appear in logs or repository files. Credentials remain protected.

Zero false claim of execution or settlement.

Simulation parity means Shadow and future execution use the same deterministic plan — differing only at a separately controlled execution gate. Live transfers are not currently available.

Fail closed by default.

Missing, stale, contradictory, or unauthorized inputs never become permission to invest or move money.

Alepes provides automation infrastructure, not investment advice. All investment decisions remain yours. This preview is for informational purposes only and is not a recommendation to buy or sell any security.

Release roadmap

Capability gates, not date promises.

Stages below are sequenced by evidence and dependency. Version labels are proposals subject to the repository's actual release conventions. Stages may be split, deferred, or rejected following risk review. No stage implicitly authorizes implementation of the next.

P1 / v0.5

Real qualifying cash event → audited Shadow plan

Next product gate

Real posted deposit provenance, deterministic recomputation, persisted audit/outbox, zero external mutations, credentialed independent certification. PR #6 open; live deposit proof absent.

Required acceptance evidence

Real deposit event with redacted provenance yielding identical plan under independent recomputation

P2 / proposed v0.6

Trustworthy account-based Shadow beta & intent-only approvals

Proposed

Authenticated account ownership, permissioned connections, persistent rules, end-to-end explainability, revocable approval queue with no order path.

Required acceptance evidence

Authenticated user completes full authorized read-only journey; reproduced decisions from immutable inputs; revoked/expired consent fails closed

P3 / proposed v0.7

Controlled execution architecture & nonproduction certification

Proposed — not authorized

Separate operator approval, idempotent scoped capabilities, mock/sandbox replay, complete reconciliation state machine. Decision gate required before work.

Required acceptance evidence

Strong mock-provider conformance; provider sandbox/paper testing only if separately approved

P4 / proposed v0.8

Narrow opt-in real-money pilot

Proposed — not authorized

External provider rights, regulatory review, explicit human consent, independent executed-order/settlement evidence, hard limits, kill switch. Separate approval only.

Required acceptance evidence

Legal analysis, approved broker/bank contracts, user consents, certified reconciliation, verified external settlement

P5 / proposed v0.9

Security, support, scaling & beta readiness

Proposed

Penetration review, privacy/retention, recovery drills, incident handling, onboarding accessibility, user experience data.

Required acceptance evidence

Documented and exercised drills; comprehensive logging without secrets; encrypted backups and restore drills

P6 / v1.0 candidate

General availability of explicitly approved capabilities

Proposed

All relevant certification, regulatory, operational, adoption, and release gates accepted.

Required acceptance evidence

Explicit operational/regulatory sign-off; proven retention/value; measured cohort economics

Key evidence principles

  • • Distinguish tests, mock/sandbox integrations, read-only live observations, real-deposit Shadow certification, order submission, and confirmed settlement.
  • • Completing a GitHub milestone, research model, or internal task never grants authority for financial execution.
  • • Reconcile remote URLs, branches, and ancestry before publishing release claims. No automatic merge, reset, rebase, or force-push.
  • • Availability/latency targets set only after production baseline measurement; do not invent current service-level achievements.

Separate research program

M001–M004: Investment research, not product execution.

Research programs explore possible investment opportunities. They must remain distinct from the production financial core and cannot submit orders or override a user's chosen portfolio. A future investment-recommendation product would require a separate charter, regulatory analysis, and explicit authorization.

M001

MACD / SMA9 Momentum

Which momentum signals beat simple benchmarks after costs?

Required next evidence

Historical point-in-time replays, adverse regimes, held-out test, independent risk review

Unchanged rule

Preserve earlier negative/NO-GO capital-allocation findings until evidence changes

M002

Graph Diffusion

Are cross-security graph residuals useful beyond sector/linear baselines?

Required next evidence

Historical network construction, graph-stability & correlation-breakdown stress, leakage attacks

Unchanged rule

Synthetic performance is not live alpha

M003

Earnings Event

Can positions bought before public earnings create positive expected net value after release?

Required next evidence

Release-timestamp-correct data, historical bid/ask option chains, IV-crush, expiration, costs, held-out event studies

Unchanged rule

No uncovered shorts or fictitious option fills

M004

Graham–Buffett Value

Do financially sound businesses bought at a sufficient margin of safety outperform suitable long-term benchmarks?

Required next evidence

Point-in-time financial statements, honest owner-earnings/quality assumptions, value-trap & multi-year drawdown tests

Unchanged rule

Valuation scenarios are estimates, not promises

Research phases

R0 data-license/architecture approval → R1 synthetic deterministic mathematical proof → R2 independent invariants and adversary → R3 point-in-time empirical data → R4 untouched out-of-sample comparison after realistic costs → R5 human decision on further research or separately scoped product/regulatory proposal. Negative and inconclusive results are legitimate endings.

Important constraints

  • • Pre-announcement implied volatility can already incorporate expected moves; post-announcement volatility may decline; premium may be lost entirely.
  • • Do not treat Graham-style balance-sheet cheapness and Buffett-style quality as a single opaque score. Review financial distress, capital allocation, return on invested capital, owner earnings, required reinvestment, discount rates, and permanent loss scenarios.
  • • First and last 30 minutes of applicable exchange regular trading hours remain prohibited for real model executions.
  • • An "engineering GO" is not a real-money or profitable-investment GO.

Build your formation.

Define how new money should move before it ever does.