SWJ Note

Valuation Analysis - NIKE

2026-07-05T00:00:00+00:00

import yfinance as yf
import pandas as pd
import datetime

# Show full numbers instead of scientific notation
pd.options.display.float_format = '{:,.0f}'.format

ticker = yf.Ticker("NKE")
# - income statement
pd.set_option('display.max_rows', None)
balance_sheet_df = ticker.quarterly_balance_sheet
balance_sheet_df

	2026-02-28	2025-11-30	2025-08-31	2025-05-31	2025-02-28	2024-11-30
Ordinary Shares Number	1,480,000,000	1,479,887,752	1,476,903,492	1,476,000,000	1,476,887,752	NaN
Share Issued	1,480,000,000	1,479,887,752	1,476,903,492	1,476,000,000	1,476,887,752	NaN
Net Debt	1,369,000,000	1,041,000,000	976,000,000	502,000,000	359,000,000	NaN
Total Debt	11,178,000,000	11,282,000,000	11,061,000,000	11,018,000,000	11,911,000,000	NaN
Tangible Book Value	13,591,000,000	13,586,000,000	12,969,000,000	12,714,000,000	13,509,000,000	NaN
Invested Capital	22,119,000,000	22,100,000,000	21,468,000,000	21,179,000,000	22,967,000,000	NaN
Working Capital	12,346,000,000	12,375,000,000	12,987,000,000	12,796,000,000	13,386,000,000	NaN
Net Tangible Assets	13,591,000,000	13,586,000,000	12,969,000,000	12,714,000,000	13,509,000,000	NaN
Capital Lease Obligations	3,149,000,000	3,267,000,000	3,061,000,000	3,052,000,000	2,951,000,000	NaN
Common Stock Equity	14,090,000,000	14,085,000,000	13,468,000,000	13,213,000,000	14,007,000,000	NaN
Total Capitalization	21,120,000,000	21,101,000,000	21,464,000,000	21,174,000,000	21,963,000,000	NaN
Total Equity Gross Minority Interest	14,090,000,000	14,085,000,000	13,468,000,000	13,213,000,000	14,007,000,000	NaN
Stockholders Equity	14,090,000,000	14,085,000,000	13,468,000,000	13,213,000,000	14,007,000,000	NaN
Gains Losses Not Affecting Retained Earnings	-207,000,000	-104,000,000	-308,000,000	-258,000,000	263,000,000	NaN
Other Equity Adjustments	-207,000,000	-104,000,000	-308,000,000	-258,000,000	263,000,000	NaN
Retained Earnings	-610,000,000	-519,000,000	-700,000,000	-727,000,000	-175,000,000	NaN
Additional Paid In Capital	14,904,000,000	14,705,000,000	14,473,000,000	14,195,000,000	13,916,000,000	NaN
Capital Stock	3,000,000	3,000,000	3,000,000	3,000,000	3,000,000	NaN
Common Stock	3,000,000	3,000,000	3,000,000	3,000,000	3,000,000	NaN
Total Liabilities Net Minority Interest	22,974,000,000	23,702,000,000	23,866,000,000	23,366,000,000	23,786,000,000	NaN
Total Non Current Liabilities Net Minority Interest	12,136,000,000	12,062,000,000	12,955,000,000	12,800,000,000	12,563,000,000	NaN
Other Non Current Liabilities	2,450,000,000	2,292,000,000	2,404,000,000	2,289,000,000	2,130,000,000	NaN
Preferred Securities Outside Stock Equity	0	0	0	0	0	NaN
Long Term Debt And Capital Lease Obligation	9,686,000,000	9,770,000,000	10,551,000,000	10,511,000,000	10,433,000,000	NaN
Long Term Capital Lease Obligation	2,656,000,000	2,754,000,000	2,555,000,000	2,550,000,000	2,477,000,000	NaN
Long Term Debt	7,030,000,000	7,016,000,000	7,996,000,000	7,961,000,000	7,956,000,000	NaN
Current Liabilities	10,838,000,000	11,640,000,000	10,911,000,000	10,566,000,000	11,223,000,000	NaN
Current Debt And Capital Lease Obligation	1,492,000,000	1,512,000,000	510,000,000	507,000,000	1,478,000,000	NaN
Current Capital Lease Obligation	493,000,000	513,000,000	506,000,000	502,000,000	474,000,000	NaN
Current Debt	999,000,000	999,000,000	4,000,000	5,000,000	1,004,000,000	NaN
Other Current Borrowings	999,000,000	999,000,000	NaN	NaN	1,000,000,000	1,000,000,000
Current Notes Payable	0	0	4,000,000	5,000,000	4,000,000	NaN
Pensionand Other Post Retirement Benefit Plans Current	1,544,000,000	1,236,000,000	1,244,000,000	1,726,000,000	1,708,000,000	NaN
Current Provisions	1,658,000,000	1,748,000,000	1,788,000,000	1,834,000,000	1,682,000,000	NaN
Payables And Accrued Expenses	6,144,000,000	7,144,000,000	7,369,000,000	6,499,000,000	6,355,000,000	NaN
Current Accrued Expenses	2,365,000,000	2,320,000,000	2,292,000,000	1,753,000,000	1,917,000,000	NaN
Payables	3,779,000,000	4,824,000,000	5,077,000,000	4,746,000,000	4,438,000,000	NaN
Dividends Payable	616,000,000	615,000,000	599,000,000	598,000,000	598,000,000	NaN
Total Tax Payable	275,000,000	492,000,000	706,000,000	669,000,000	734,000,000	NaN
Income Tax Payable	275,000,000	492,000,000	706,000,000	669,000,000	734,000,000	NaN
Accounts Payable	2,888,000,000	3,717,000,000	3,772,000,000	3,479,000,000	3,106,000,000	NaN
Total Assets	37,064,000,000	37,787,000,000	37,334,000,000	36,579,000,000	37,793,000,000	NaN
Total Non Current Assets	13,880,000,000	13,772,000,000	13,436,000,000	13,217,000,000	13,184,000,000	NaN
Other Non Current Assets	5,729,000,000	5,536,000,000	5,349,000,000	5,178,000,000	5,355,000,000	NaN
Goodwill And Other Intangible Assets	499,000,000	499,000,000	499,000,000	499,000,000	498,000,000	NaN
Other Intangible Assets	259,000,000	259,000,000	259,000,000	259,000,000	259,000,000	NaN
Goodwill	240,000,000	240,000,000	240,000,000	240,000,000	239,000,000	NaN
Net PPE	7,652,000,000	7,737,000,000	7,588,000,000	7,540,000,000	7,331,000,000	NaN
Accumulated Depreciation	NaN	NaN	NaN	-6,104,000,000	NaN	NaN
Gross PPE	7,652,000,000	7,737,000,000	7,588,000,000	13,644,000,000	7,331,000,000	NaN
Leases	NaN	NaN	NaN	2,037,000,000	NaN	NaN
Construction In Progress	NaN	NaN	NaN	404,000,000	NaN	NaN
Other Properties	7,652,000,000	7,737,000,000	7,588,000,000	2,712,000,000	7,331,000,000	NaN
Machinery Furniture Equipment	NaN	NaN	NaN	4,647,000,000	NaN	NaN
Buildings And Improvements	NaN	NaN	NaN	3,510,000,000	NaN	NaN
Land And Improvements	NaN	NaN	NaN	334,000,000	NaN	NaN
Properties	NaN	NaN	NaN	0	NaN	NaN
Current Assets	23,184,000,000	24,015,000,000	23,898,000,000	23,362,000,000	24,609,000,000	NaN
Other Current Assets	2,271,000,000	2,206,000,000	2,247,000,000	2,005,000,000	2,186,000,000	NaN
Inventory	7,487,000,000	7,726,000,000	8,114,000,000	7,489,000,000	7,539,000,000	NaN
Finished Goods	7,487,000,000	7,726,000,000	8,114,000,000	7,489,000,000	7,539,000,000	NaN
Receivables	5,369,000,000	5,738,000,000	4,962,000,000	4,717,000,000	4,491,000,000	NaN
Accounts Receivable	5,369,000,000	5,738,000,000	4,962,000,000	4,717,000,000	4,491,000,000	NaN
Allowance For Doubtful Accounts Receivable	NaN	NaN	NaN	-27,000,000	NaN	NaN
Gross Accounts Receivable	NaN	NaN	NaN	4,744,000,000	NaN	NaN
Cash Cash Equivalents And Short Term Investments	8,057,000,000	8,345,000,000	8,575,000,000	9,151,000,000	10,393,000,000	NaN
Other Short Term Investments	1,397,000,000	1,371,000,000	1,551,000,000	1,687,000,000	1,792,000,000	NaN
Cash And Cash Equivalents	6,660,000,000	6,974,000,000	7,024,000,000	7,464,000,000	8,601,000,000	NaN
Cash Equivalents	4,967,000,000	5,216,000,000	5,615,000,000	6,243,000,000	7,263,000,000	NaN
Cash Financial	1,693,000,000	1,758,000,000	1,409,000,000	1,221,000,000	1,338,000,000	NaN

cash_flow_df = ticker.cashflow
cash_flow_df

	2025-05-31	2024-05-31	2023-05-31	2022-05-31
Free Cash Flow	3,268,000,000	6,617,000,000	4,872,000,000	4,430,000,000
Repurchase Of Capital Stock	-2,985,000,000	-4,250,000,000	-5,480,000,000	-4,014,000,000
Repayment Of Debt	-1,000,000,000	0	-500,000,000	0
Issuance Of Debt	NaN	NaN	NaN	0
Capital Expenditure	-430,000,000	-812,000,000	-969,000,000	-758,000,000
Interest Paid Supplemental Data	389,000,000	381,000,000	347,000,000	290,000,000
Income Tax Paid Supplemental Data	1,226,000,000	1,299,000,000	1,517,000,000	1,231,000,000
End Cash Position	7,464,000,000	9,860,000,000	7,441,000,000	8,574,000,000
Beginning Cash Position	9,860,000,000	7,441,000,000	8,574,000,000	9,889,000,000
Effect Of Exchange Rate Changes	1,000,000	-16,000,000	-91,000,000	-143,000,000
Changes In Cash	-2,397,000,000	2,435,000,000	-1,042,000,000	-1,172,000,000
Financing Cash Flow	-5,820,000,000	-5,888,000,000	-7,447,000,000	-4,836,000,000
Cash Flow From Continuing Financing Activities	-5,820,000,000	-5,888,000,000	-7,447,000,000	-4,836,000,000
Net Other Financing Charges	-85,000,000	-136,000,000	-102,000,000	-151,000,000
Proceeds From Stock Option Exercised	551,000,000	667,000,000	651,000,000	1,151,000,000
Cash Dividends Paid	-2,300,000,000	-2,169,000,000	-2,012,000,000	-1,837,000,000
Common Stock Dividend Paid	-2,300,000,000	-2,169,000,000	-2,012,000,000	-1,837,000,000
Net Common Stock Issuance	-2,985,000,000	-4,250,000,000	-5,480,000,000	-4,014,000,000
Common Stock Payments	-2,985,000,000	-4,250,000,000	-5,480,000,000	-4,014,000,000
Net Issuance Payments Of Debt	-1,001,000,000	0	-504,000,000	15,000,000
Net Short Term Debt Issuance	-1,000,000	0	-4,000,000	15,000,000
Net Long Term Debt Issuance	-1,000,000,000	0	-500,000,000	0
Long Term Debt Payments	-1,000,000,000	0	-500,000,000	0
Long Term Debt Issuance	NaN	NaN	NaN	0
Investing Cash Flow	-275,000,000	894,000,000	564,000,000	-1,524,000,000
Cash Flow From Continuing Investing Activities	-275,000,000	894,000,000	564,000,000	-1,524,000,000
Net Other Investing Changes	8,000,000	-15,000,000	52,000,000	-19,000,000
Net Investment Purchase And Sale	147,000,000	1,721,000,000	1,481,000,000	-747,000,000
Sale Of Investment	3,381,000,000	6,488,000,000	7,540,000,000	12,166,000,000
Purchase Of Investment	-3,234,000,000	-4,767,000,000	-6,059,000,000	-12,913,000,000
Net PPE Purchase And Sale	-430,000,000	-812,000,000	-969,000,000	-758,000,000
Purchase Of PPE	-430,000,000	-812,000,000	-969,000,000	-758,000,000
Operating Cash Flow	3,698,000,000	7,429,000,000	5,841,000,000	5,188,000,000
Cash Flow From Continuing Operating Activities	3,698,000,000	7,429,000,000	5,841,000,000	5,188,000,000
Change In Working Capital	-787,000,000	716,000,000	-513,000,000	-1,660,000,000
Change In Payables And Accrued Expense	-426,000,000	397,000,000	-225,000,000	1,365,000,000
Change In Payable	-426,000,000	397,000,000	-225,000,000	1,365,000,000
Change In Account Payable	-426,000,000	397,000,000	-225,000,000	1,365,000,000
Change In Prepaid Assets	-224,000,000	-260,000,000	-644,000,000	-845,000,000
Change In Inventory	120,000,000	908,000,000	-133,000,000	-1,676,000,000
Change In Receivables	-257,000,000	-329,000,000	489,000,000	-504,000,000
Changes In Account Receivables	-257,000,000	-329,000,000	489,000,000	-504,000,000
Stock Based Compensation	709,000,000	804,000,000	755,000,000	638,000,000
Deferred Tax	-288,000,000	-497,000,000	-117,000,000	-650,000,000
Deferred Income Tax	-288,000,000	-497,000,000	-117,000,000	-650,000,000
Depreciation Amortization Depletion	808,000,000	844,000,000	859,000,000	840,000,000
Depreciation And Amortization	808,000,000	844,000,000	859,000,000	840,000,000
Amortization Cash Flow	33,000,000	48,000,000	156,000,000	123,000,000
Amortization Of Intangibles	33,000,000	48,000,000	156,000,000	123,000,000
Depreciation	775,000,000	796,000,000	703,000,000	717,000,000
Operating Gains Losses	37,000,000	-138,000,000	-213,000,000	-26,000,000
Net Foreign Currency Exchange Gain Loss	37,000,000	-138,000,000	-213,000,000	-26,000,000
Net Income From Continuing Operations	3,219,000,000	5,700,000,000	5,070,000,000	6,046,000,000

income_statement_df = ticker.income_stmt.dropna(axis=1, thresh=10)
income_statement_df

	2025-05-31	2024-05-31	2023-05-31	2022-05-31
Tax Effect Of Unusual Items	0	0	0	0
Tax Rate For Calcs	0	0	0	0
Normalized EBITDA	4,510,000,000	7,155,000,000	6,774,000,000	7,515,000,000
Net Income From Continuing Operation Net Minority Interest	3,219,000,000	5,700,000,000	5,070,000,000	6,046,000,000
Reconciled Depreciation	808,000,000	844,000,000	859,000,000	840,000,000
Reconciled Cost Of Revenue	26,519,000,000	28,475,000,000	28,925,000,000	25,231,000,000
EBITDA	4,510,000,000	7,155,000,000	6,774,000,000	7,515,000,000
EBIT	3,702,000,000	6,311,000,000	5,915,000,000	6,675,000,000
Net Interest Income	107,000,000	161,000,000	6,000,000	-205,000,000
Normalized Income	3,219,000,000	5,700,000,000	5,070,000,000	6,046,000,000
Net Income From Continuing And Discontinued Operation	3,219,000,000	5,700,000,000	5,070,000,000	6,046,000,000
Total Expenses	42,607,000,000	45,051,000,000	45,302,000,000	40,035,000,000
Diluted Average Shares	1,487,600,000	1,529,700,000	1,569,800,000	NaN
Basic Average Shares	1,484,900,000	1,517,600,000	1,551,600,000	NaN
Diluted EPS	2	4	3	NaN
Basic EPS	2	4	3	NaN
Diluted NI Availto Com Stockholders	3,219,000,000	5,700,000,000	5,070,000,000	6,046,000,000
Net Income Common Stockholders	3,219,000,000	5,700,000,000	5,070,000,000	6,046,000,000
Net Income	3,219,000,000	5,700,000,000	5,070,000,000	6,046,000,000
Net Income Including Noncontrolling Interests	3,219,000,000	5,700,000,000	5,070,000,000	6,046,000,000
Net Income Continuous Operations	3,219,000,000	5,700,000,000	5,070,000,000	6,046,000,000
Tax Provision	666,000,000	1,000,000,000	1,131,000,000	605,000,000
Pretax Income	3,885,000,000	6,700,000,000	6,201,000,000	6,651,000,000
Other Income Expense	76,000,000	228,000,000	280,000,000	181,000,000
Other Non Operating Income Expenses	76,000,000	228,000,000	280,000,000	181,000,000
Net Non Operating Interest Income Expense	107,000,000	161,000,000	6,000,000	-205,000,000
Total Other Finance Cost	-107,000,000	-161,000,000	-6,000,000	205,000,000
Operating Income	3,702,000,000	6,311,000,000	5,915,000,000	6,675,000,000
Operating Expense	16,088,000,000	16,576,000,000	16,377,000,000	14,804,000,000
Other Operating Expenses	NaN	NaN	12,317,000,000	10,954,000,000
Selling General And Administration	16,088,000,000	16,576,000,000	16,377,000,000	14,804,000,000
Selling And Marketing Expense	4,689,000,000	4,285,000,000	4,060,000,000	3,850,000,000
General And Administrative Expense	11,399,000,000	12,291,000,000	12,317,000,000	10,954,000,000
Other Gand A	11,399,000,000	12,291,000,000	12,317,000,000	10,954,000,000
Gross Profit	19,790,000,000	22,887,000,000	22,292,000,000	21,479,000,000
Cost Of Revenue	26,519,000,000	28,475,000,000	28,925,000,000	25,231,000,000
Total Revenue	46,309,000,000	51,362,000,000	51,217,000,000	46,710,000,000
Operating Revenue	46,309,000,000	51,362,000,000	51,217,000,000	46,710,000,000

annual_income = ticker.income_stmt.dropna(axis=1, thresh=10)
annual_income

	2025-05-31	2024-05-31	2023-05-31	2022-05-31
Tax Effect Of Unusual Items	0	0	0	0
Tax Rate For Calcs	0	0	0	0
Normalized EBITDA	4,510,000,000	7,155,000,000	6,774,000,000	7,515,000,000
Net Income From Continuing Operation Net Minority Interest	3,219,000,000	5,700,000,000	5,070,000,000	6,046,000,000
Reconciled Depreciation	808,000,000	844,000,000	859,000,000	840,000,000
Reconciled Cost Of Revenue	26,519,000,000	28,475,000,000	28,925,000,000	25,231,000,000
EBITDA	4,510,000,000	7,155,000,000	6,774,000,000	7,515,000,000
EBIT	3,702,000,000	6,311,000,000	5,915,000,000	6,675,000,000
Net Interest Income	107,000,000	161,000,000	6,000,000	-205,000,000
Normalized Income	3,219,000,000	5,700,000,000	5,070,000,000	6,046,000,000
Net Income From Continuing And Discontinued Operation	3,219,000,000	5,700,000,000	5,070,000,000	6,046,000,000
Total Expenses	42,607,000,000	45,051,000,000	45,302,000,000	40,035,000,000
Diluted Average Shares	1,487,600,000	1,529,700,000	1,569,800,000	NaN
Basic Average Shares	1,484,900,000	1,517,600,000	1,551,600,000	NaN
Diluted EPS	2	4	3	NaN
Basic EPS	2	4	3	NaN
Diluted NI Availto Com Stockholders	3,219,000,000	5,700,000,000	5,070,000,000	6,046,000,000
Net Income Common Stockholders	3,219,000,000	5,700,000,000	5,070,000,000	6,046,000,000
Net Income	3,219,000,000	5,700,000,000	5,070,000,000	6,046,000,000
Net Income Including Noncontrolling Interests	3,219,000,000	5,700,000,000	5,070,000,000	6,046,000,000
Net Income Continuous Operations	3,219,000,000	5,700,000,000	5,070,000,000	6,046,000,000
Tax Provision	666,000,000	1,000,000,000	1,131,000,000	605,000,000
Pretax Income	3,885,000,000	6,700,000,000	6,201,000,000	6,651,000,000
Other Income Expense	76,000,000	228,000,000	280,000,000	181,000,000
Other Non Operating Income Expenses	76,000,000	228,000,000	280,000,000	181,000,000
Net Non Operating Interest Income Expense	107,000,000	161,000,000	6,000,000	-205,000,000
Total Other Finance Cost	-107,000,000	-161,000,000	-6,000,000	205,000,000
Operating Income	3,702,000,000	6,311,000,000	5,915,000,000	6,675,000,000
Operating Expense	16,088,000,000	16,576,000,000	16,377,000,000	14,804,000,000
Other Operating Expenses	NaN	NaN	12,317,000,000	10,954,000,000
Selling General And Administration	16,088,000,000	16,576,000,000	16,377,000,000	14,804,000,000
Selling And Marketing Expense	4,689,000,000	4,285,000,000	4,060,000,000	3,850,000,000
General And Administrative Expense	11,399,000,000	12,291,000,000	12,317,000,000	10,954,000,000
Other Gand A	11,399,000,000	12,291,000,000	12,317,000,000	10,954,000,000
Gross Profit	19,790,000,000	22,887,000,000	22,292,000,000	21,479,000,000
Cost Of Revenue	26,519,000,000	28,475,000,000	28,925,000,000	25,231,000,000
Total Revenue	46,309,000,000	51,362,000,000	51,217,000,000	46,710,000,000
Operating Revenue	46,309,000,000	51,362,000,000	51,217,000,000	46,710,000,000

annual_cash_flow = ticker.cashflow
annual_cash_flow

	2025-05-31	2024-05-31	2023-05-31	2022-05-31
Free Cash Flow	3,268,000,000	6,617,000,000	4,872,000,000	4,430,000,000
Repurchase Of Capital Stock	-2,985,000,000	-4,250,000,000	-5,480,000,000	-4,014,000,000
Repayment Of Debt	-1,000,000,000	0	-500,000,000	0
Issuance Of Debt	NaN	NaN	NaN	0
Capital Expenditure	-430,000,000	-812,000,000	-969,000,000	-758,000,000
Interest Paid Supplemental Data	389,000,000	381,000,000	347,000,000	290,000,000
Income Tax Paid Supplemental Data	1,226,000,000	1,299,000,000	1,517,000,000	1,231,000,000
End Cash Position	7,464,000,000	9,860,000,000	7,441,000,000	8,574,000,000
Beginning Cash Position	9,860,000,000	7,441,000,000	8,574,000,000	9,889,000,000
Effect Of Exchange Rate Changes	1,000,000	-16,000,000	-91,000,000	-143,000,000
Changes In Cash	-2,397,000,000	2,435,000,000	-1,042,000,000	-1,172,000,000
Financing Cash Flow	-5,820,000,000	-5,888,000,000	-7,447,000,000	-4,836,000,000
Cash Flow From Continuing Financing Activities	-5,820,000,000	-5,888,000,000	-7,447,000,000	-4,836,000,000
Net Other Financing Charges	-85,000,000	-136,000,000	-102,000,000	-151,000,000
Proceeds From Stock Option Exercised	551,000,000	667,000,000	651,000,000	1,151,000,000
Cash Dividends Paid	-2,300,000,000	-2,169,000,000	-2,012,000,000	-1,837,000,000
Common Stock Dividend Paid	-2,300,000,000	-2,169,000,000	-2,012,000,000	-1,837,000,000
Net Common Stock Issuance	-2,985,000,000	-4,250,000,000	-5,480,000,000	-4,014,000,000
Common Stock Payments	-2,985,000,000	-4,250,000,000	-5,480,000,000	-4,014,000,000
Net Issuance Payments Of Debt	-1,001,000,000	0	-504,000,000	15,000,000
Net Short Term Debt Issuance	-1,000,000	0	-4,000,000	15,000,000
Net Long Term Debt Issuance	-1,000,000,000	0	-500,000,000	0
Long Term Debt Payments	-1,000,000,000	0	-500,000,000	0
Long Term Debt Issuance	NaN	NaN	NaN	0
Investing Cash Flow	-275,000,000	894,000,000	564,000,000	-1,524,000,000
Cash Flow From Continuing Investing Activities	-275,000,000	894,000,000	564,000,000	-1,524,000,000
Net Other Investing Changes	8,000,000	-15,000,000	52,000,000	-19,000,000
Net Investment Purchase And Sale	147,000,000	1,721,000,000	1,481,000,000	-747,000,000
Sale Of Investment	3,381,000,000	6,488,000,000	7,540,000,000	12,166,000,000
Purchase Of Investment	-3,234,000,000	-4,767,000,000	-6,059,000,000	-12,913,000,000
Net PPE Purchase And Sale	-430,000,000	-812,000,000	-969,000,000	-758,000,000
Purchase Of PPE	-430,000,000	-812,000,000	-969,000,000	-758,000,000
Operating Cash Flow	3,698,000,000	7,429,000,000	5,841,000,000	5,188,000,000
Cash Flow From Continuing Operating Activities	3,698,000,000	7,429,000,000	5,841,000,000	5,188,000,000
Change In Working Capital	-787,000,000	716,000,000	-513,000,000	-1,660,000,000
Change In Payables And Accrued Expense	-426,000,000	397,000,000	-225,000,000	1,365,000,000
Change In Payable	-426,000,000	397,000,000	-225,000,000	1,365,000,000
Change In Account Payable	-426,000,000	397,000,000	-225,000,000	1,365,000,000
Change In Prepaid Assets	-224,000,000	-260,000,000	-644,000,000	-845,000,000
Change In Inventory	120,000,000	908,000,000	-133,000,000	-1,676,000,000
Change In Receivables	-257,000,000	-329,000,000	489,000,000	-504,000,000
Changes In Account Receivables	-257,000,000	-329,000,000	489,000,000	-504,000,000
Stock Based Compensation	709,000,000	804,000,000	755,000,000	638,000,000
Deferred Tax	-288,000,000	-497,000,000	-117,000,000	-650,000,000
Deferred Income Tax	-288,000,000	-497,000,000	-117,000,000	-650,000,000
Depreciation Amortization Depletion	808,000,000	844,000,000	859,000,000	840,000,000
Depreciation And Amortization	808,000,000	844,000,000	859,000,000	840,000,000
Amortization Cash Flow	33,000,000	48,000,000	156,000,000	123,000,000
Amortization Of Intangibles	33,000,000	48,000,000	156,000,000	123,000,000
Depreciation	775,000,000	796,000,000	703,000,000	717,000,000
Operating Gains Losses	37,000,000	-138,000,000	-213,000,000	-26,000,000
Net Foreign Currency Exchange Gain Loss	37,000,000	-138,000,000	-213,000,000	-26,000,000
Net Income From Continuing Operations	3,219,000,000	5,700,000,000	5,070,000,000	6,046,000,000

annual_balance_sheet = ticker.balance_sheet
annual_balance_sheet = annual_balance_sheet.fillna(0)
annual_balance_sheet

	2025-05-31	2024-05-31	2023-05-31	2022-05-31
Ordinary Shares Number	1,476,000,000	1,503,000,000	1,532,000,000	1,571,000,000
Share Issued	1,476,000,000	1,503,000,000	1,532,000,000	1,571,000,000
Net Debt	502,000,000	0	1,492,000,000	856,000,000
Total Debt	11,018,000,000	11,952,000,000	12,144,000,000	12,627,000,000
Tangible Book Value	12,714,000,000	13,931,000,000	13,449,000,000	14,711,000,000
...	...	...	...	...
Cash Cash Equivalents And Short Term Investments	9,151,000,000	11,582,000,000	10,675,000,000	12,997,000,000
Other Short Term Investments	1,687,000,000	1,722,000,000	3,234,000,000	4,423,000,000
Cash And Cash Equivalents	7,464,000,000	9,860,000,000	7,441,000,000	8,574,000,000
Cash Equivalents	6,243,000,000	8,638,000,000	5,674,000,000	7,735,000,000
Cash Financial	1,221,000,000	1,222,000,000	1,767,000,000	839,000,000

75 rows × 4 columns

# FCFF Calculation using Cash Flow Statement and Income Statement Inputs
free_cash_flow_firm = (cash_flow_df.loc['Free Cash Flow'].astype('int64')) \
                    + (income_statement_df.loc['Net Non Operating Interest Income Expense'].astype('int64') \
                        * (1 - income_statement_df.loc['Tax Provision'].astype('int64') \
                           / income_statement_df.loc['Pretax Income'].astype('int64'))).astype('int64')

# Change Series to a Pandas Dataframe
free_cash_flow_firm_df = free_cash_flow_firm.to_frame().transpose()
print(free_cash_flow_firm_df)
print(cash_flow_df.loc['Free Cash Flow'][0])
print(income_statement_df.loc['Net Non Operating Interest Income Expense'][0])
print(income_statement_df.loc['Tax Provision'][0])
print(income_statement_df.loc['Pretax Income'][0])
print((1 - income_statement_df.loc['Tax Provision'][0] \
                           / income_statement_df.loc['Pretax Income'][0]))
print(income_statement_df.loc['Net Non Operating Interest Income Expense'][0] *(1 - income_statement_df.loc['Tax Provision'][0] \
                           / income_statement_df.loc['Pretax Income'][0]))

   2025-05-31  2024-05-31  2023-05-31  2022-05-31
0  3356657142  6753970149  4876905660  4243647572
3268000000.0
107000000.0
666000000.0
3885000000.0
0.8285714285714285
88657142.85714285

# CAGR of FCFF
latest_free_cash_flow_firm = float(free_cash_flow_firm_df.iloc[0,0])
earliest_free_cash_flow_firm = float(free_cash_flow_firm_df.iloc[0,len(free_cash_flow_firm_df.columns)-1])
free_cash_flow_firm_CAGR = ((latest_free_cash_flow_firm/earliest_free_cash_flow_firm)\
                            **(float(1/(len(free_cash_flow_firm_df.columns)))))-1


print(latest_free_cash_flow_firm)
print(earliest_free_cash_flow_firm)
print(free_cash_flow_firm_CAGR)

3356657142.0
4243647572.0
-0.0569343672541337

# Perpetual (terminal) growth rate.
# The historical FCFF CAGR can be negative, which implies the firm shrinks
# forever - not a valid going-concern assumption. Use a conservative long-run
# rate (~ long-run GDP / inflation) instead.
long_term_growth = 0.025
long_term_growth

0.025

# Forecasted FCFF
forecast_free_cash_flow_firm_df = pd.DataFrame(columns=['Year ' + str(i) for i in range(1,6)])
free_cash_flow_firm_forecast_lst = []
for i in range(1,6):
    if i != 5:
        free_cash_flow_firm_forecast = latest_free_cash_flow_firm*(1+free_cash_flow_firm_CAGR)**i
    else:
        free_cash_flow_firm_forecast = latest_free_cash_flow_firm*(1+free_cash_flow_firm_CAGR)\
                                        **(i-1)*(1+long_term_growth)
    free_cash_flow_firm_forecast_lst.append(int(free_cash_flow_firm_forecast))
forecast_free_cash_flow_firm_df.loc[0] = free_cash_flow_firm_forecast_lst
forecast_free_cash_flow_firm_df

	Year 1	Year 2	Year 3	Year 4	Year 5
0	3165547991	2985319519	2815352241	2655061943	2721438491

# Risk-free Rate
timespan = 100
current_date = datetime.date.today()
formatted_date = current_date.strftime('%Y-%m-%d')
past_date = current_date-datetime.timedelta(days=timespan)
formatted_past_date = past_date.strftime('%Y-%m-%d')
tk = yf.Ticker('^TNX')
risk_free_rate_df = tk.history(period='3mo')
risk_free_rate = (risk_free_rate_df.iloc[len(risk_free_rate_df)-1,3])/100
risk_free_rate

c:\Users\Admin\anaconda3\lib\site-packages\yfinance\scrapers\history.py:396: FutureWarning: The default dtype for empty Series will be 'object' instead of 'float64' in a future version. Specify a dtype explicitly to silence this warning.
  self._capital_gains = pd.Series()

0.04484999656677246

import requests
from bs4 import BeautifulSoup

def finviz_fundament(symbol):
    # Finviz blocks non-browser requests and splits fundamentals across
    # multiple snapshot-table2 tables, so use a browser UA and aggregate them.
    url = f"https://finviz.com/quote.ashx?t={symbol}"
    headers = {"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
                             "AppleWebKit/537.36 (KHTML, like Gecko) "
                             "Chrome/126.0 Safari/537.36"}
    resp = requests.get(url, headers=headers, timeout=15)
    resp.raise_for_status()
    soup = BeautifulSoup(resp.text, "lxml")
    cells = []
    for table in soup.find_all("table", class_="snapshot-table2"):
        cells += [td.text for td in table.find_all("td")]
    return {cells[i]: cells[i + 1] for i in range(0, len(cells) - 1, 2)}

tk = finviz_fundament('NKE')
tk

{'Index': 'DJIA, S&P 500',
 'Market Cap': '65.29B',
 'Enterprise Value': '67.30B',
 'Income': '3.11B',
 'Sales': '46.40B',
 'Book/sh': '9.52',
 'Cash/sh': '6.10',
 'Dividend Est.': '1.66 (3.76%)',
 'Dividend TTM': '1.63 (3.70%)',
 'Dividend Ex-Date': 'Jun 01, 2026',
 'Dividend Gr. 3/5Y': '7.28% 8.78%',
 'Payout': '77.67%',
 'Employees': '77800',
 'IPO': 'Dec 02, 1980',
 'P/E': '21.01',
 'Forward P/E': '19.97',
 'PEG': '4.16',
 'P/S': '1.41',
 'P/B': '4.63',
 'P/C': '7.23',
 'P/FCF': '62.30',
 'EV/EBITDA': '18.45',
 'EV/Sales': '1.45',
 'Quick Ratio': '1.36',
 'Current Ratio': '1.96',
 'Debt/Eq': '0.74',
 'LT Debt/Eq': '0.58',
 'Option/Short': 'Yes / Yes',
 'EPS (ttm)': '2.10',
 'EPS next Y': '25.94%',
 'EPS next Q': '0.44',
 'EPS this Y': '-16.54%',
 'EPS next 5Y': '4.80%',
 'EPS past 3/5Y': '-13.39% -10.02%',
 'Sales past 3/5Y': '-3.22% 0.84%',
 'EPS Y/Y TTM': '-2.96%',
 'Sales Y/Y TTM': '-0.01%',
 'EPS Q/Q': '404.83%',
 'Sales Q/Q': '-1.33%',
 'Earnings': 'Jun 30 AMC',
 'EPS/Sales Surpr.': '479.24% 1.13%',
 'Insider Own': '21.06%',
 'Insider Trans': '0.01%',
 'Inst Own': '66.28%',
 'Inst Trans': '-1.43%',
 'ROA': '8.29%',
 'ROE': '22.14%',
 'ROIC': '13.27%',
 'Gross Margin': '44.06%',
 'Oper. Margin': '8.56%',
 'Profit Margin': '6.70%',
 'SMA20': '1.63%',
 'SMA50': '0.57%',
 'SMA200': '-23.08%',
 'Trades': '\n\n',
 'Shs Outstand': '1.48B',
 'Shs Float': '1.17B',
 'Short Float': '4.88%',
 'Short Ratio': '2.28',
 'Short Interest': '57.04M',
 '52W High': '80.17 -45.00%',
 '52W Low': '40.00 10.23%',
 'Volatility': '3.79% 3.25%',
 'ATR (14)': '1.49',
 'RSI (14)': '52.93',
 'Beta': '1.11',
 'Rel Volume': '1.25',
 'Avg Volume': '25.00M',
 'Volume': '31,232,182',
 'Perf Week': '7.80%',
 'Perf Month': '0.82%',
 'Perf Quarter': '-1.21%',
 'Perf Half Y': '-27.95%',
 'Perf YTD': '-30.80%',
 'Perf Year': '-42.28%',
 'Perf 3Y': '-60.05%',
 'Perf 5Y': '-72.40%',
 'Perf 10Y': '-20.72%',
 'Recom': '2.49',
 'Target Price': '50.32',
 'Prev Close': '43.06',
 'Price': '44.09',
 'Change': '2.39%'}

beta = float(tk['Beta']) # float is for decimal and int is for integer
beta

1.11

market_risk_premium = (0.10-risk_free_rate)
market_risk_premium

0.05515000343322755

# Required Cost of Equity

coe = risk_free_rate + (beta*market_risk_premium)

coe

0.10606650037765504

interest_expense = income_statement_df.loc['Net Non Operating Interest Income Expense']
interest_expense_df = interest_expense.to_frame().transpose()
interest_expense_str = interest_expense_df.values[0][0]
interest_expense_int = int(interest_expense_str)


# Total Debt
total_debt = balance_sheet_df.loc['Total Debt']
total_debt_df = total_debt.to_frame().transpose()
total_debt_str = total_debt_df.values[0][0]
total_debt_int = int(total_debt_str)

# Required Cost of Debt
cod = interest_expense_int / total_debt_int


print(interest_expense_str)
print(total_debt_df)

print(interest_expense_int)
print(total_debt_int)
print(cod)

107000000.0
               2026-02-28     2025-11-30     2025-08-31     2025-05-31  \
Total Debt 11,178,000,000 11,282,000,000 11,061,000,000 11,018,000,000   

               2025-02-28  2024-11-30  
Total Debt 11,911,000,000         NaN  
107000000
11178000000
0.009572374306673823

# Effective Tax Rate
effective_tax_rate = income_statement_df.loc['Tax Provision'].astype('int64') \
                           / income_statement_df.loc['Pretax Income'].astype('int64')

print(income_statement_df.loc['Tax Provision'].astype('int64'))
print(income_statement_df.loc['Pretax Income'].astype('int64'))
print(len(effective_tax_rate))
print(sum(effective_tax_rate))
avg_effective_tax_rate = sum(effective_tax_rate) / len(effective_tax_rate)
avg_effective_tax_rate

2025-05-31     666000000
2024-05-31    1000000000
2023-05-31    1131000000
2022-05-31     605000000
Name: Tax Provision, dtype: int64
2025-05-31    3885000000
2024-05-31    6700000000
2023-05-31    6201000000
2022-05-31    6651000000
Name: Pretax Income, dtype: int64
4
0.5940360047261646





0.14850900118154114

market_cap_str = tk['Market Cap']

market_cap_lst = market_cap_str.split('.')
if market_cap_str[len(market_cap_str)-1] == 'T':
    market_cap_length = len(market_cap_lst[1])-1
    market_cap_lst[1] = market_cap_lst[1].replace('T',(12-market_cap_length)*'0')
    market_cap_int = int(''.join(market_cap_lst))
if market_cap_str[len(market_cap_str)-1] == 'B':
    market_cap_length = len(market_cap_lst[1])-1
    market_cap_lst[1] = market_cap_lst[1].replace('B',(9-market_cap_length)*'0')
    market_cap_int = int(''.join(market_cap_lst))

market_cap_int

65290000000

last_cf = cash_flow_df.loc['End Cash Position']
last_cf_df = last_cf.to_frame().transpose()
last_cf_str = last_cf_df.values[0][0]
last_cf_int = int(last_cf_str)

last_equity = balance_sheet_df.loc['Total Equity Gross Minority Interest']
last_equity_df = last_equity.to_frame().transpose()
last_equity_str = last_equity_df.values[0][0]
last_equity_int = int(last_equity_str)


enterprise_value = market_cap_int + total_debt_int - last_cf_int

print(last_cf_int)
print(last_equity_int)
print(enterprise_value)

7464000000
14090000000
69004000000

WACC = ((last_equity_int/(last_equity_int + total_debt_int)) * coe) \
        + ((total_debt_int/(last_equity_int + total_debt_int)) * cod * (1-avg_effective_tax_rate))

WACC

0.0627507728033376

# Equity Value Calculation
discounted_FCFF_lst = []
for year in range(0,5):
    discounted_FCFF = forecast_free_cash_flow_firm_df.iloc[0,year]/(1+WACC)**(year+1)
    discounted_FCFF_lst.append(int(discounted_FCFF))
terminal_value = (forecast_free_cash_flow_firm_df.iloc[0,4]*(1+long_term_growth))/(WACC-long_term_growth)
PV_terminal_value = int(terminal_value/(1+WACC)**5)
firm_value = sum(discounted_FCFF_lst)+PV_terminal_value
equity_value = (firm_value - total_debt_int + last_cf_int)

print(discounted_FCFF_lst)
print(terminal_value)
print(forecast_free_cash_flow_firm_df.iloc[0,4])
print(firm_value)
print(equity_value)

[2978636263, 2643187438, 2345516274, 2081368319, 2007434463]
73891850315.40277
2721438491
66561525614
62847525614

# Total Shares Outstanding
shares_outstanding_str = tk['Shs Outstand']

shares_outstanding_lst = shares_outstanding_str.split('.')
if shares_outstanding_str[len(shares_outstanding_str)-1] == 'T':
    shares_outstanding_length = len(shares_outstanding_lst[1])-1
    shares_outstanding_lst[1] = shares_outstanding_lst[1].replace('T',(12-shares_outstanding_length)*'0')
    shares_outstanding_int = int(''.join(shares_outstanding_lst))
if shares_outstanding_str[len(shares_outstanding_str)-1] == 'B':
    shares_outstanding_length = len(shares_outstanding_lst[1])-1
    shares_outstanding_lst[1] = shares_outstanding_lst[1].replace('B',(9-shares_outstanding_length)*'0')
    shares_outstanding_int = int(''.join(shares_outstanding_lst))
if shares_outstanding_str[len(shares_outstanding_str)-1] == 'M':
    shares_outstanding_length = len(shares_outstanding_lst[1])-1
    shares_outstanding_lst[1] = shares_outstanding_lst[1].replace('M',(6-shares_outstanding_length)*'0')
    shares_outstanding_int = int(''.join(shares_outstanding_lst))

shares_outstanding_int

1480000000

# Two-stage FCFF Valuation Model Stock Price Estimate
stock_price = equity_value / shares_outstanding_int
stock_price = '${:,.2f}'.format(stock_price)
print("Model Stock Price = %s"%(stock_price))

# Actual Stock Price
actual_stock_price = market_cap_int / shares_outstanding_int
actual_stock_price = '${:,.2f}'.format(actual_stock_price)
print("Actual Stock Price = %s"%(actual_stock_price))

Model Stock Price = $42.46
Actual Stock Price = $44.11

   Reportable Operating Segments - Schedule of Operating Segment Information (Details) - USD ($)  $ in Thousands 12 Months Ended                            
   Reportable Operating Segments - Schedule of Operating Segment Information (Details) - USD ($)  $ in Thousands   Mar. 31, 2026 Mar. 31, 2025 Mar. 31, 2024
                                                                   Segment Reporting Information [Line Items]             NaN           NaN           NaN
                                                                                                    Net sales     $ 5,472,296   $ 4,985,612   $ 4,287,763
                                                                                          Less: Cost of sales         2314570       2099949       1902275
                                                                                                 Gross profit     $ 3,157,726   $ 2,885,663   $ 2,385,488
                                                                                         Segment gross margin          57.70%        57.90%        55.60%
                                                                                                        Less:             NaN           NaN           NaN
                                                                                    Payroll and related costs       $ 307,073     $ 265,328     $ 226,926
                                                               Advertising, marketing, and promotion expenses          495838        432198        348852
                                                                                           Rent and occupancy          130571        102615         92661
                                                                         Depreciation and other related costs           20184         19445         22718
                                                                                         Other segment items          231384        180121        146736
                                                                                       Segment SG&A expenses         1185050        999707        837893
                                                                              Segment income from operations     $ 1,972,676   $ 1,885,956   $ 1,547,595
                                                                                    Segment operating margin          36.00%        37.80%        36.10%
                                                                             Impairment of intangible assets             $ 0           $ 0       $ 8,164
                                                                                   UGG | Reportable segments             NaN           NaN           NaN
                                                                  Segment Reporting Information [Line Items]             NaN           NaN           NaN
             

Peer Comparison — NKE vs DECK (Hoka) vs ONON (On) vs ADDYY (Adidas)

Below we reuse the same two-stage FCFF DCF and layer in price-performance metrics and a qualitative read. Note: DECK reports in USD; ONON reports in CHF and ADDYY in EUR, while market data (price, market cap, shares) comes from Finviz in USD — so their model prices mix reporting currency with USD market data and should be read as rough, not precise.

import numpy as np

peers = ['NKE', 'DECK', 'ONON', 'ADDYY']

def _num(s):
    # Parse Finviz shorthand like '65.29B', '1.48B', '29.92M', '44.09'
    if s is None:
        return np.nan
    s = str(s).strip().replace(',', '')
    mult = {'T': 1e12, 'B': 1e9, 'M': 1e6, 'K': 1e3}
    if s and s[-1] in mult:
        try:
            return float(s[:-1]) * mult[s[-1]]
        except ValueError:
            return np.nan
    try:
        return float(s)
    except ValueError:
        return np.nan

def fcff_valuation(symbol, long_term_growth=0.025, market_return=0.10):
    tkr = yf.Ticker(symbol)
    cf  = tkr.cashflow
    inc = tkr.income_stmt.dropna(axis=1, thresh=10)
    bs  = tkr.quarterly_balance_sheet

    # Market data: Finviz first, fall back to yfinance (e.g. OTC ADRs like ADDYY)
    try:
        fv = finviz_fundament(symbol)
        beta = _num(fv.get('Beta')); shares = _num(fv.get('Shs Outstand'))
        mcap = _num(fv.get('Market Cap')); price = _num(fv.get('Price'))
    except Exception:
        info = tkr.info
        beta = info.get('beta'); shares = info.get('sharesOutstanding')
        mcap = info.get('marketCap')
        price = info.get('currentPrice', info.get('regularMarketPrice'))
    beta   = np.nan if beta   is None else float(beta)
    shares = np.nan if shares is None else float(shares)
    mcap   = np.nan if mcap   is None else float(mcap)
    price  = np.nan if price  is None else float(price)

    # Effective tax rate (clip to a sane range, fall back to 21%)
    if 'Tax Provision' in inc.index and 'Pretax Income' in inc.index:
        eff = inc.loc['Tax Provision'].dropna() / inc.loc['Pretax Income'].dropna()
        eff = eff[(eff > 0) & (eff < 0.35)]
        eff_tax = float(eff.mean()) if len(eff) else 0.21
    else:
        eff_tax = 0.21

    # FCFF = Free Cash Flow + after-tax non-operating interest
    fcf = cf.loc['Free Cash Flow'].dropna().astype(float)
    if 'Net Non Operating Interest Income Expense' in inc.index:
        nnoi = inc.loc['Net Non Operating Interest Income Expense'].dropna().astype(float)
        fcff = (fcf + nnoi * (1 - eff_tax)).dropna()
    else:
        fcff = fcf
    fcff = fcff.sort_index(ascending=False)          # newest first
    latest, earliest, n = float(fcff.iloc[0]), float(fcff.iloc[-1]), len(fcff)
    cagr = (latest / earliest) ** (1 / n) - 1 if (latest > 0 and earliest > 0) else 0.0

    # 5-year forecast (fade final year to terminal growth)
    fc = [latest * (1 + cagr) ** i if i != 5 else latest * (1 + cagr) ** (i - 1) * (1 + long_term_growth)
          for i in range(1, 6)]

    # Cost of equity (CAPM), floored at the risk-free rate
    beta = 1.0 if np.isnan(beta) else beta
    coe = max(risk_free_rate + beta * (market_return - risk_free_rate), risk_free_rate)

    # Cost of debt + WACC
    total_debt = int(bs.loc['Total Debt'].dropna().iloc[0]) if 'Total Debt' in bs.index else 0
    equity_bv  = int(bs.loc['Total Equity Gross Minority Interest'].dropna().iloc[0])
    int_exp    = int(inc.loc['Net Non Operating Interest Income Expense'].dropna().iloc[0]) if 'Net Non Operating Interest Income Expense' in inc.index else 0
    cod  = (int_exp / total_debt) if total_debt else 0.0
    wacc = ((equity_bv / (equity_bv + total_debt)) * coe
            + (total_debt / (equity_bv + total_debt)) * cod * (1 - eff_tax)) if (equity_bv + total_debt) else coe

    # Terminal value (keep WACC > g)
    g = long_term_growth if wacc > long_term_growth else wacc - 0.01
    disc = [fc[y] / (1 + wacc) ** (y + 1) for y in range(5)]
    tv    = (fc[4] * (1 + g)) / (wacc - g)
    firm_value = sum(disc) + tv / (1 + wacc) ** 5

    cash = int(cf.loc['End Cash Position'].dropna().iloc[0]) if 'End Cash Position' in cf.index else 0
    equity_value = firm_value - total_debt + cash

    model_price  = equity_value / shares if not np.isnan(shares) and shares else np.nan
    actual_price = price
    if np.isnan(actual_price) and not np.isnan(shares) and shares:
        actual_price = mcap / shares
    upside = (model_price / actual_price - 1) * 100 if (model_price and actual_price) else np.nan

    return {'Ticker': symbol, 'Beta': round(beta, 2), 'WACC': round(wacc, 4),
            'FCFF CAGR': round(cagr, 4), 'Firm Value ($B)': round(firm_value / 1e9, 2),
            'Equity Value ($B)': round(equity_value / 1e9, 2),
            'Model Price': round(model_price, 2), 'Actual Price': round(actual_price, 2),
            'Upside %': round(upside, 1)}

def performance_metrics(symbol, start='2022-01-01', end=None):
    px = yf.Ticker(symbol).history(start=start, end=end, interval='1d')['Close'].dropna()
    if len(px) < 2:
        return {'Ticker': symbol}
    daily = px.pct_change().dropna()
    years = (px.index[-1] - px.index[0]).days / 365.25
    return {'Ticker': symbol,
            'CAGR %': round(((px.iloc[-1] / px.iloc[0]) ** (1 / years) - 1) * 100, 1),
            'Cumulative %': round((px.iloc[-1] / px.iloc[0] - 1) * 100, 1),
            'Volatility %': round(daily.std() * np.sqrt(252) * 100, 1),
            'Expected Yearly %': round(daily.mean() * 252 * 100, 1),
            'Expected Monthly %': round(daily.mean() * 21 * 100, 1)}

dcf_df  = pd.DataFrame([fcff_valuation(t) for t in peers]).set_index('Ticker')
perf_df = pd.DataFrame([performance_metrics(t) for t in peers]).set_index('Ticker')

_dcf_fmt = {'Beta': '{:.2f}'.format, 'WACC': '{:.2%}'.format, 'FCFF CAGR': '{:.2%}'.format,
            'Firm Value ($B)': '{:.1f}'.format, 'Equity Value ($B)': '{:.1f}'.format,
            'Model Price': '${:.2f}'.format, 'Actual Price': '${:.2f}'.format,
            'Upside %': '{:+.1f}%'.format}
print("=== Two-stage FCFF DCF (model vs actual) ===")
print(dcf_df.to_string(formatters=_dcf_fmt))
print("\n=== Price performance (since 2022-01-01) ===")
print(perf_df.to_string(formatters={c: '{:+.1f}%'.format for c in perf_df.columns}))

c:\Users\Admin\anaconda3\lib\site-packages\yfinance\scrapers\history.py:396: FutureWarning: The default dtype for empty Series will be 'object' instead of 'float64' in a future version. Specify a dtype explicitly to silence this warning.
  self._capital_gains = pd.Series()
c:\Users\Admin\anaconda3\lib\site-packages\yfinance\scrapers\history.py:396: FutureWarning: The default dtype for empty Series will be 'object' instead of 'float64' in a future version. Specify a dtype explicitly to silence this warning.
  self._capital_gains = pd.Series()
c:\Users\Admin\anaconda3\lib\site-packages\yfinance\scrapers\history.py:396: FutureWarning: The default dtype for empty Series will be 'object' instead of 'float64' in a future version. Specify a dtype explicitly to silence this warning.
  self._capital_gains = pd.Series()
c:\Users\Admin\anaconda3\lib\site-packages\yfinance\scrapers\history.py:396: FutureWarning: The default dtype for empty Series will be 'object' instead of 'float64' in a future version. Specify a dtype explicitly to silence this warning.
  self._capital_gains = pd.Series()


=== Two-stage FCFF DCF (model vs actual) ===
       Beta   WACC FCFF CAGR Firm Value ($B) Equity Value ($B) Model Price Actual Price Upside %
Ticker                                                                                          
NKE    1.11  6.28%    -5.74%            66.5              62.8      $42.41       $44.09    -3.8%
DECK   1.16 11.11%    25.21%            28.2              29.7     $212.42      $104.69  +102.9%
ONON   2.12 12.44%     0.00%             2.7               3.1      $10.52       $36.83   -71.4%
ADDYY  1.21  4.84%     0.00%             6.4               2.1       $5.87      $105.15   -94.4%

=== Price performance (since 2022-01-01) ===
       CAGR % Cumulative % Volatility % Expected Yearly % Expected Monthly %
Ticker                                                                      
NKE    -24.3%       -71.3%       +36.6%            -21.1%              -1.8%
DECK   +12.7%       +70.7%       +44.9%            +22.1%              +1.8%
ONON    -1.1%        -4.8%       +54.6%            +13.7%              +1.1%
ADDYY   -6.1%       -24.5%       +38.7%             +1.1%              +0.1%

import matplotlib.pyplot as plt
from math import pi

fig, axes = plt.subplots(1, 3, figsize=(20, 6))

# 1) Normalized price (rebased to 100 at start)
prices = yf.download(peers, start='2022-01-01', progress=False)['Close'].dropna(how='all')
norm = prices / prices.bfill().iloc[0] * 100
norm.plot(ax=axes[0])
axes[0].set_title('Rebased Price (start = 100)'); axes[0].set_ylabel('Index'); axes[0].grid(alpha=.3)

# 2) Model vs Actual price
x = np.arange(len(dcf_df)); w = 0.35
axes[1].bar(x - w/2, dcf_df['Actual Price'], w, label='Actual', color='#888')
axes[1].bar(x + w/2, dcf_df['Model Price'],  w, label='Model (DCF)', color='#112e51')
axes[1].set_xticks(x); axes[1].set_xticklabels(dcf_df.index)
axes[1].set_title('DCF Model vs Actual Price'); axes[1].legend(); axes[1].grid(alpha=.3, axis='y')

# 3) Radar of normalized performance (higher = better; volatility inverted)
radar = perf_df.copy()
radar['Volatility %'] = -radar['Volatility %']              # lower vol scores higher
radar_n = (radar - radar.min()) / (radar.max() - radar.min())
labels = list(radar_n.columns)
angles = np.linspace(0, 2*pi, len(labels), endpoint=False).tolist(); angles += angles[:1]
axr = plt.subplot(1, 3, 3, polar=True)
for t in radar_n.index:
    vals = radar_n.loc[t].tolist(); vals += vals[:1]
    axr.plot(angles, vals, 'o-', linewidth=1.5, label=t); axr.fill(angles, vals, alpha=0.08)
axr.set_thetagrids(np.degrees(angles[:-1]), labels, fontsize=8)
axr.set_title('Normalized Performance (outer = better)'); axr.legend(loc='upper right', bbox_to_anchor=(1.3, 1.1))

plt.tight_layout(); plt.show()

c:\Users\Admin\anaconda3\lib\site-packages\yfinance\scrapers\history.py:396: FutureWarning: The default dtype for empty Series will be 'object' instead of 'float64' in a future version. Specify a dtype explicitly to silence this warning.
  self._capital_gains = pd.Series()
c:\Users\Admin\anaconda3\lib\site-packages\yfinance\scrapers\history.py:396: FutureWarning: The default dtype for empty Series will be 'object' instead of 'float64' in a future version. Specify a dtype explicitly to silence this warning.
  self._capital_gains = pd.Series()
c:\Users\Admin\anaconda3\lib\site-packages\yfinance\scrapers\history.py:396: FutureWarning: The default dtype for empty Series will be 'object' instead of 'float64' in a future version. Specify a dtype explicitly to silence this warning.
  self._capital_gains = pd.Series()
c:\Users\Admin\anaconda3\lib\site-packages\yfinance\scrapers\history.py:396: FutureWarning: The default dtype for empty Series will be 'object' instead of 'float64' in a future version. Specify a dtype explicitly to silence this warning.
  self._capital_gains = pd.Series()
C:\Users\Admin\AppData\Local\Temp\ipykernel_16632\2091169150.py:25: MatplotlibDeprecationWarning: Auto-removal of overlapping axes is deprecated since 3.6 and will be removed two minor releases later; explicitly call ax.remove() as needed.
  axr = plt.subplot(1, 3, 3, polar=True)

Qualitative Comparison

	NKE (Nike)	DECK (Hoka/UGG)	ONON (On)	ADDYY (Adidas)
Stage	Mature global leader	High-growth mid-cap	Fast-growth small-cap	Turnaround #2 player
Moat	Wide — brand, scale, DTC	Narrowing — brand momentum	Narrow — premium niche	Wide but dented (post-Yeezy)
FCFF trend	Declining (~ -6%/yr)	Strong, compounding	Low/erratic base	Recovering off a weak base
Growth driver	DTC + margin recovery	Hoka running franchise	Premium running + apparel	Terrace/lifestyle (Samba, Gazelle)
Key risk	Wholesale reset, China	Single-brand concentration	Valuation, scale, competition	Execution, FX, brand heat fading
Reporting ccy	USD	USD	CHF	EUR

How the numbers tie together

NKE — model $42 vs actual ~$44 (≈fair). Weak recent price (-71% since 2022) reflects the declining-FCFF story the DCF also captures. Lowest-risk profile (lowest volatility).
DECK — model $212 vs actual ~$105 (+103% “upside”). Driven by a very high FCFF CAGR (~25%) extrapolated forward; treat as optimistic — a 25% growth rate compounding 5 years is aggressive, and the model is highly sensitive to it. Best actual performer (+71%).
ONON — model $11 vs actual ~$37 (-71%). Misleading: On reports in CHF while price/shares are USD ADS, and its FCFF base is small/volatile (CAGR floored to 0). The DCF understates it — the market is pricing high future growth the model doesn’t.
ADDYY — model $6 vs actual ~$105 (-94%). Not usable as-is: EUR financials mixed with a USD ADR price, plus an ADR-to-ordinary share ratio the model ignores. Read the qualitative turnaround story here, not the DCF number.

Takeaway: the DCF is only apples-to-apples for the USD reporters (NKE, DECK). NKE screens fairly valued and defensive; DECK screens cheap but on aggressive growth assumptions. ONON and ADDYY need a currency-consistent model (convert statements to USD and apply the correct ADR share ratio) before their model prices mean anything.

# Revenue comparison (converted to USD $B for apples-to-apples)
report_ccy = {'NKE': 'USD', 'DECK': 'USD', 'ONON': 'CHF', 'ADDYY': 'EUR'}
fx = {'USD': 1.0,
      'EUR': float(yf.Ticker('EURUSD=X').history(period='5d')['Close'].iloc[-1]),
      'CHF': float(yf.Ticker('CHFUSD=X').history(period='5d')['Close'].iloc[-1])}

rev = {}
for t in peers:
    s = yf.Ticker(t).income_stmt.loc['Total Revenue'].dropna().astype(float)
    s.index = s.index.year                      # index by fiscal-year-end year
    rev[t] = s * fx[report_ccy[t]] / 1e9        # -> USD billions
rev_df = pd.DataFrame(rev).sort_index()

# Fiscal-year-ends differ, so compute growth/CAGR on each ticker's own series
latest_yoy = {}
summary = {}
for t in peers:
    s = rev_df[t].dropna()
    yoy = (s.iloc[-1] / s.iloc[-2] - 1) * 100
    cagr = ((s.iloc[-1] / s.iloc[0]) ** (1 / (len(s) - 1)) - 1) * 100
    latest_yoy[t] = yoy
    summary[t] = {'Latest Rev ($B)': f'{s.iloc[-1]:,.1f}',
                  'Latest YoY %': f'{yoy:+.1f}%',
                  'CAGR %': f'{cagr:+.1f}%',
                  'Years': f'{s.index[0]}-{s.index[-1]}'}
summary_df = pd.DataFrame(summary).T

print("=== Total Revenue (USD $B, by fiscal-year-end year) ===")
print(rev_df.to_string(float_format=lambda v: f'{v:,.1f}'))
print("\n=== Revenue growth summary (each on its own fiscal calendar) ===")
print(summary_df.to_string())

import matplotlib.pyplot as plt
fig, axes = plt.subplots(1, 3, figsize=(20, 5))

rev_df.plot(marker='o', ax=axes[0])
axes[0].set_title('Total Revenue (USD $B)'); axes[0].set_ylabel('$B'); axes[0].grid(alpha=.3)

rebased = rev_df.apply(lambda c: c / c.dropna().iloc[0] * 100)
rebased.plot(marker='o', ax=axes[1])
axes[1].set_title('Revenue Rebased to 100 (first year each)'); axes[1].grid(alpha=.3)

lg = pd.Series(latest_yoy)
lg.plot(kind='bar', ax=axes[2], color=['#c0392b' if v < 0 else '#27ae60' for v in lg])
axes[2].axhline(0, color='k', lw=.8)
axes[2].set_title('Latest Fiscal-Year Revenue Growth'); axes[2].set_ylabel('% YoY'); axes[2].grid(alpha=.3, axis='y')

plt.tight_layout(); plt.show()

c:\Users\Admin\anaconda3\lib\site-packages\yfinance\scrapers\history.py:396: FutureWarning: The default dtype for empty Series will be 'object' instead of 'float64' in a future version. Specify a dtype explicitly to silence this warning.
  self._capital_gains = pd.Series()
c:\Users\Admin\anaconda3\lib\site-packages\yfinance\scrapers\history.py:396: FutureWarning: The default dtype for empty Series will be 'object' instead of 'float64' in a future version. Specify a dtype explicitly to silence this warning.
  self._capital_gains = pd.Series()


=== Total Revenue (USD $B, by fiscal-year-end year) ===
      NKE  DECK  ONON  ADDYY
2022 46.7   NaN   1.5   25.8
2023 51.2   3.6   2.2   24.5
2024 51.4   4.3   2.9   27.1
2025 46.3   5.0   3.8   28.4
2026  NaN   5.5   NaN    NaN

=== Revenue growth summary (each on its own fiscal calendar) ===
      Latest Rev ($B) Latest YoY %  CAGR %      Years
NKE              46.3        -9.8%   -0.3%  2022-2025
DECK              5.5        +9.8%  +14.7%  2023-2026
ONON              3.8       +30.0%  +35.1%  2022-2025
ADDYY            28.4        +4.8%   +3.3%  2022-2025

Revenue basis — how they differ, and why NKE is losing

Scale & trajectory (USD, latest fiscal year)

Co.	Revenue	Latest YoY	CAGR (window)	Read
NKE	~$46B	−9.8%	−0.3%	Giant, but shrinking — only one going backwards
ADDYY	~$28B	+4.8%	+3.3%	#2 incumbent, recovering (Samba/Gazelle terrace wave)
DECK	~$5.5B	+9.8%	+14.7%	Mid-cap compounder, Hoka is the growth engine
ONON	~$3.8B	+30.0%	+35.1%	Small-cap hyper-growth, premium running

The scale chart shows NKE ~8–12x bigger than the challengers, but the rebased chart tells the real story: NKE is the only line rolling over while ONON nearly triples and DECK keeps climbing. NKE isn’t losing on size — it’s losing on direction and momentum.

Why NKE is losing

DTC over-pivot. Nike cut wholesale accounts (Foot Locker, DSW, Amazon, boutiques) to push direct/app sales. It gave up shelf space and doorway visibility — which On, Hoka, New Balance and Adidas rushed to fill. The margin/relationship damage outlasted the strategy, and Nike is now rebuilding those wholesale ties.
Innovation gap. Growth leaned on retro franchises (Air Force 1, Dunk, Jordan retros) instead of new performance platforms. Flooding the market with Dunks/AF1s diluted scarcity and “brand heat,” while On (CloudTec) and Hoka (max-cushion) owned the fresh running narrative.
Lost the running category. ONON +30% and Hoka/DECK +10–15% are taking premium run share directly. Running is the tip of the spear for credibility, and Nike ceded ground right when the category boomed.
Lifestyle share to Adidas. Adidas’s Samba/Gazelle/terrace revival (+4.8%, recovering off a post-Yeezy trough) recaptured the fashion-sneaker zeitgeist Nike used to own.
China + macro softness. Weak China demand and heavy promotional activity (clearing excess Dunk/AF1 inventory) pressured both revenue and gross margin simultaneously.
Reset underway. Elliott Hill (veteran insider) returned as CEO to un-wind the DTC excess, rebuild wholesale, refresh product, and clean inventory — a multi-quarter turnaround, which is exactly why FY25 revenue (−9.8%) is the trough the market is watching.

Bottom line: the challengers are winning innovation and channel, not just price. Nike’s problem is self-inflicted (strategy + product cadence) more than competitive pricing — which is why a credible product/wholesale reset could stabilize it, but the revenue trend confirms it is currently the loser of the group.

Caveat: revenue converted to USD at current spot FX (EURUSD/CHFUSD); fiscal-year-ends differ (NKE May, DECK Mar, ONON/ADDYY Dec), so year alignment is approximate.

# === SEC filing evidence: put NUMBERS behind the qualitative story ===
# Pulls segment/disaggregation tables straight from 10-K financial-report R-files on EDGAR.
import requests, io, re
from bs4 import BeautifulSoup

SEC_HEADERS = {"User-Agent": "finance-research research@example.com"}

def _cik(tk):
    j = requests.get("https://www.sec.gov/files/company_tickers.json", headers=SEC_HEADERS, timeout=20).json()
    return next(str(r['cik_str']).zfill(10) for r in j.values() if r['ticker'].upper() == tk.upper())

def _latest(cik, forms=('10-K', '20-F')):
    rec = requests.get(f"https://data.sec.gov/submissions/CIK{cik}.json", headers=SEC_HEADERS, timeout=20).json()['filings']['recent']
    i = next(k for k, f in enumerate(rec['form']) if f in forms)
    return rec['accessionNumber'][i].replace('-', ''), rec['reportDate'][i]

def _clean(v):
    if pd.isna(v):
        return None
    s = str(v).replace('$', '').replace(',', '').replace('%', '').replace('(', '-').replace(')', '').strip()
    try:
        return float(s)
    except ValueError:
        return None

def _extract(df, metric='Revenues'):
    out, last = {}, None
    for _, r in df.iterrows():
        lab = str(r.iloc[0]).strip()
        if lab.lower().startswith(metric.lower()):
            vals = [_clean(r.iloc[c]) for c in range(1, min(4, df.shape[1]))]
            if any(v is not None for v in vals) and last:
                out[last] = vals
        elif lab and lab.lower() != 'nan' and '[line items]' not in lab.lower() \
                and 'disaggregation' not in lab.lower() and 'reporting information' not in lab.lower():
            last = re.sub(r'^Operating Segments \| ', '', lab)
    return out

def sec_table(tk, shortname_kw, metric='Revenues', forms=('10-K', '20-F')):
    cik = _cik(tk); acc, rdate = _latest(cik, forms)
    base = f"https://www.sec.gov/Archives/edgar/data/{int(cik)}/{acc}"
    fs = BeautifulSoup(requests.get(f"{base}/FilingSummary.xml", headers=SEC_HEADERS, timeout=20).text, 'lxml-xml')
    fn = next(r.find('HtmlFileName').text for r in fs.find_all('Report')
              if r.find('HtmlFileName') and shortname_kw in r.find('ShortName').text.lower())
    df = pd.read_html(io.StringIO(requests.get(f"{base}/{fn}", headers=SEC_HEADERS, timeout=20).text))[0]
    return _extract(df, metric), rdate

# ---- NIKE: geography, channel, product (from FY2025 10-K, $M, FY25/FY24/FY23) ----
nke_geo, nke_date = sec_table('NKE', 'information by operating segments', 'Revenues', forms=('10-K',))
nke_dis, _        = sec_table('NKE', 'disaggregation of revenue', 'Revenues', forms=('10-K',))
yrs = ['FY25', 'FY24', 'FY23']

geo_keys = {'North America': 'NIKE Brand | NORTH AMERICA', 'EMEA': 'NIKE Brand | EUROPE, MIDDLE EAST & AFRICA',
            'Greater China': 'NIKE Brand | GREATER CHINA', 'APLA': 'NIKE Brand | ASIA PACIFIC & LATIN AMERICA'}
geo_df = pd.DataFrame({k: nke_geo[v] for k, v in geo_keys.items()}, index=yrs).T
chan_df = pd.DataFrame({'Wholesale': nke_dis['Sales to Wholesale Customers'],
                        'DTC (Nike Direct)': nke_dis['Sales through Direct to Consumer']}, index=yrs).T
prod_df = pd.DataFrame({'Footwear': nke_dis['Footwear'], 'Apparel': nke_dis['Apparel'],
                        'Equipment': nke_dis['Equipment']}, index=yrs).T
for d in (geo_df, chan_df, prod_df):
    d['YoY %'] = (d['FY25'] / d['FY24'] - 1) * 100

# ---- Competitor brand growth: HOKA (from DECK 10-K) ----
deck_seg, deck_date = sec_table('DECK', 'operating segment information', 'Net sales', forms=('10-K',))
hoka = next(v for k, v in deck_seg.items() if 'HOKA' in k.upper())          # FY26/FY25/FY24 in $K
hoka_yoy = (hoka[0] / hoka[1] - 1) * 100

_f = lambda v: f'{v:,.0f}'
_p = lambda v: f'{v:+.1f}%'
print(f"NIKE 10-K reportDate {nke_date}  |  DECK 10-K reportDate {deck_date}\n")
print("=== NIKE revenue by geography ($M) — China + macro softness ===")
print(geo_df.to_string(formatters={'FY25': _f, 'FY24': _f, 'FY23': _f, 'YoY %': _p}))
print("\n=== NIKE revenue by channel ($M) — the DTC over-pivot backfiring ===")
print(chan_df.to_string(formatters={'FY25': _f, 'FY24': _f, 'FY23': _f, 'YoY %': _p}))
print("\n=== NIKE revenue by product ($M) — footwear (innovation engine) leads the drop ===")
print(prod_df.to_string(formatters={'FY25': _f, 'FY24': _f, 'FY23': _f, 'YoY %': _p}))
print(f"\n=== Lost running/share: growth of the challengers vs NIKE footwear ===")
print(f"  NIKE Footwear    {(prod_df.loc['Footwear','YoY %']):+.1f}%")
print(f"  HOKA (DECK)      {hoka_yoy:+.1f}%   (net sales {_f(hoka[1]/1000)}M -> {_f(hoka[0]/1000)}M)")
print(f"  On (ONON total)  {latest_yoy['ONON']:+.1f}%")
print(f"  Adidas (total)   {latest_yoy['ADDYY']:+.1f}%")

# ---- Charts ----
import matplotlib.pyplot as plt
fig, ax = plt.subplots(1, 3, figsize=(20, 5))

geo_df['YoY %'].plot(kind='bar', ax=ax[0], color=['#c0392b' if v < 0 else '#27ae60' for v in geo_df['YoY %']])
ax[0].axhline(0, color='k', lw=.8); ax[0].set_title('NIKE Revenue YoY by Geography (FY25 vs FY24)')
ax[0].set_ylabel('% YoY'); ax[0].grid(alpha=.3, axis='y')

chan_df['YoY %'].plot(kind='bar', ax=ax[1], color=['#c0392b' if v < 0 else '#27ae60' for v in chan_df['YoY %']])
ax[1].axhline(0, color='k', lw=.8); ax[1].set_title('NIKE Revenue YoY by Channel — DTC fell hardest')
ax[1].set_ylabel('% YoY'); ax[1].grid(alpha=.3, axis='y')

comp = pd.Series({'NIKE\nFootwear': prod_df.loc['Footwear', 'YoY %'], 'HOKA': hoka_yoy,
                  'On': latest_yoy['ONON'], 'Adidas': latest_yoy['ADDYY']})
comp.plot(kind='bar', ax=ax[2], color=['#c0392b' if v < 0 else '#27ae60' for v in comp])
ax[2].axhline(0, color='k', lw=.8); ax[2].set_title('Nike is losing the growth: footwear vs challengers')
ax[2].set_ylabel('% YoY (latest FY)'); ax[2].grid(alpha=.3, axis='y')

plt.tight_layout(); plt.show()

NIKE 10-K reportDate 2025-05-31  |  DECK 10-K reportDate 2026-03-31

=== NIKE revenue by geography ($M) — China + macro softness ===
                FY25   FY24   FY23  YoY %
North America 19,572 21,396 21,608  -8.5%
EMEA          12,257 13,607 13,418  -9.9%
Greater China  6,586  7,545  7,248 -12.7%
APLA           6,251  6,729  6,431  -7.1%

=== NIKE revenue by channel ($M) — the DTC over-pivot backfiring ===
                    FY25   FY24   FY23  YoY %
Wholesale         26,758 28,856 28,696  -7.3%
DTC (Nike Direct) 19,477 22,351 22,282 -12.9%

=== NIKE revenue by product ($M) — footwear (innovation engine) leads the drop ===
            FY25   FY24   FY23  YoY %
Footwear  30,967 35,227 35,290 -12.1%
Apparel   13,045 13,868 13,933  -5.9%
Equipment  2,223  2,112  1,755  +5.3%

=== Lost running/share: growth of the challengers vs NIKE footwear ===
  NIKE Footwear    -12.1%
  HOKA (DECK)      +15.9%   (net sales 2,233M -> 2,587M)
  On (ONON total)  +30.0%
  Adidas (total)   +4.8%

SEC-filing evidence — the numbers behind each theme

All figures below are pulled directly from the companies’ latest 10-K financial-report tables on SEC EDGAR (NIKE FY2025 10-K, fiscal year end May 31, 2025; DECK FY2026 10-K).

Qualitative theme	Hard number (from 10-K)	Verdict
China + macro softness	Greater China revenue $7,545M → $6,586M (−12.7%) — the worst-declining region (NA −8.5%, EMEA −9.9%, APLA −7.1%)	Confirmed — China is the epicenter
DTC over-pivot backfiring	Nike Direct −12.9% vs Wholesale −7.3% — the channel Nike bet on fell nearly 2x harder than the one it walked away from	Confirmed — the DTC pivot is the bigger drag
Innovation gap / franchise fatigue	Footwear −12.1% (vs Apparel −5.9%, Equipment +5.3%) — the core sneaker engine is the single largest source of decline	Confirmed — the problem is footwear, i.e. product
Lost the running category / share	NIKE Footwear −12.1% while HOKA +15.9% ($2,233M → $2,587M), On +30.0%, Adidas +4.8%	Confirmed — challengers are growing double digits as Nike shrinks

Read the three charts together:

Geography — every region is red, but Greater China is the deepest hole (−12.7%), validating the “China + macro” narrative.
Channel — DTC (Nike Direct) fell harder than Wholesale, the numeric fingerprint of the failed direct-to-consumer over-pivot; rebuilding wholesale is exactly the reset underway.
Footwear vs challengers — Nike’s footwear is down ~12% in the same year Hoka (+16%), On (+30%) and Adidas (+5%) grew. That gap is the lost running/lifestyle share — quantified.

One-line takeaway: Nike’s decline is concentrated in footwear, DTC, and China — a product-and-strategy problem, not a pricing one — and the exact categories where On, Hoka and Adidas are simultaneously posting double-digit growth.

Note: fiscal-year-ends differ (NIKE May, DECK Mar, On/Adidas Dec) and Nike segment figures are NIKE Brand only in reported USD; competitor totals are whole-company.

Conclusion — what Nike must do to stop losing

The data points to a clear diagnosis: the decline is concentrated in footwear (−12.1%), Nike Direct (−12.9%) and Greater China (−12.7%) — a product, channel and China problem, not a pricing one — happening in the exact categories where On (+30%), Hoka (+16%) and Adidas (+5%) are growing. The fix has to attack those same three fronts.

1. Win back product & innovation (fixes footwear −12.1%)

Re-establish a performance-running franchise. On and Hoka took share with a clear technology story (CloudTec, max-cushion). Nike needs a flagship cushioning/running platform marketed as hard as Vaporfly was — not another retro drop.
Cut the retro oversupply. Deliberately ration Air Force 1 / Dunk to rebuild scarcity and pricing power; stop letting franchise volume mask the innovation gap.
Rebalance the pipeline toward newness (higher % of revenue from products <2 years old) with faster design-to-shelf cycles.

2. Rebuild wholesale without abandoning DTC (fixes Nike Direct −12.9%)

Re-enter lost doors (Foot Locker, Amazon, DSW, specialty run) to reclaim shelf space and reach — the vacuum challengers filled.
Reposition DTC as premium/full-price, not the whole engine — use it for launches, membership and data, not volume clearance.
Clean inventory to stop margin-destroying promotions that trained shoppers to wait for discounts.

3. Reset Greater China (fixes China −12.7%)

Localize product and marketing (China-specific design, local athletes/creators) rather than exporting the US line.
Rebuild credibility with local competitors (Anta, Li-Ning) taking share; lean on running and basketball where Nike still has authority.

4. Protect the moat & the P&L

Defend lifestyle against Adidas’s terrace wave (Samba/Gazelle) with Nike’s own low-profile silhouettes and culture partnerships.
Reinvest the demand-creation budget into product storytelling (it already rose to ~$4.7B) and measure by full-price sell-through, not shipments.
Restore gross margin through disciplined supply, fewer markdowns, and mix shift back to footwear innovation.

The scorecard to watch (from the same 10-K tables)

Signal that the turnaround is working	Target direction
Footwear revenue YoY	−12% → flat → positive
Nike Direct vs Wholesale	Both stabilize; wholesale re-growing
Greater China revenue	Stops declining faster than the group
Gross margin	Recovers as promotions fade
% revenue from new (<2yr) product	Rising

Bottom line: Nike doesn’t need to out-price On, Hoka or Adidas — it needs to out-innovate in footwear, rebuild the wholesale shelf it walked away from, and re-localize China. The FY25 trough (−9.8% total revenue) is the reset point; success is measured by footwear returning to growth and Nike Direct stabilizing alongside a rebuilt wholesale base — exactly the plan Elliott Hill’s leadership has signaled.

Internal Financial Analysis

2026-07-05T00:00:00+00:00

Internal Financial Analysis — SaaS Cloud (FY2025)

Company: SaaS Cloud, a mid-size SaaS business (simulated internal data).

Questions we answer:

Are we on budget? (Budget vs Actual variance analysis)
Which departments are overspending?
How is revenue trending by product and region?
What is our monthly operating margin?
Are we hiring to plan?

Skills: SQL joins/aggregation, variance %, KPI calculation, trend analysis, executive-style charts + written commentary.

import sqlite3
import pandas as pd
import matplotlib.pyplot as plt

conn = sqlite3.connect('company.db')

def q(sql):
    return pd.read_sql_query(sql, conn)

pd.options.display.float_format = '{:,.0f}'.format

1. Budget vs Actual — full-year variance by department

The core FP&A table. Variance = Actual − Budget; a positive variance on expense means overspend (unfavorable). Analysts flag anything over ±5%.

variance = q('''
    SELECT department,
           SUM(budget)  AS budget,
           SUM(actual)  AS actual,
           SUM(actual) - SUM(budget)              AS variance,
           ROUND((SUM(actual) * 1.0 / SUM(budget) - 1) * 100, 1) AS variance_pct
    FROM budget_vs_actual
    GROUP BY department
    ORDER BY variance_pct DESC
''')

variance['flag'] = variance['variance_pct'].apply(
    lambda v: 'OVER budget' if v > 5 else ('UNDER budget' if v < -5 else 'on track'))
variance

	department	budget	actual	variance	variance_pct	flag
0	Marketing	3,600,000	3,909,729	309,729	9	OVER budget
1	Customer Success	2,400,000	2,599,255	199,255	8	OVER budget
2	Sales	6,000,000	6,423,328	423,328	7	OVER budget
3	G&A	1,800,000	1,919,718	119,718	7	OVER budget
4	R&D	7,200,000	7,475,804	275,804	4	on track

colors = ['#c0392b' if v > 0 else '#27ae60' for v in variance['variance']]
ax = variance.plot(kind='barh', x='department', y='variance', legend=False, color=colors)
ax.axvline(0, color='k', lw=.8)
ax.set_title('FY2025 Budget Variance by Department ($)  —  red = overspend')
ax.set_xlabel('Actual − Budget ($)')
plt.tight_layout(); plt.show()

2. Monthly spend trend — where variance builds up

Leadership always asks “when did we go off track?” — so we plot budget vs actual by month across the whole company.

monthly = q('''
    SELECT month,
           SUM(budget) AS budget,
           SUM(actual) AS actual
    FROM budget_vs_actual
    GROUP BY month
    ORDER BY month
''')

ax = monthly.plot(x='month', marker='o', figsize=(12, 4))
ax.set_title('Company-wide Opex: Budget vs Actual by Month')
ax.set_ylabel('$'); ax.set_xlabel(''); ax.grid(alpha=.3)
plt.xticks(rotation=45, ha='right'); plt.tight_layout(); plt.show()

3. Revenue trend by product & region

A GROUP BY + pivot to see which product lines and regions are driving growth.

rev_month = q('''
    SELECT month, product, SUM(revenue) AS revenue
    FROM revenue
    GROUP BY month, product
    ORDER BY month
''')
rev_pivot = rev_month.pivot(index='month', columns='product', values='revenue')

ax = rev_pivot.plot(marker='o', figsize=(12, 4))
ax.set_title('Monthly Revenue by Product'); ax.set_ylabel('$'); ax.set_xlabel('')
ax.grid(alpha=.3); plt.xticks(rotation=45, ha='right'); plt.tight_layout(); plt.show()

# Region mix for the full year
region = q('''
    SELECT region, SUM(revenue) AS revenue
    FROM revenue GROUP BY region ORDER BY revenue DESC
''')
region

	region	revenue
0	North America	12,520,948
1	EMEA	6,829,608
2	APAC	3,414,804

4. Operating margin — the headline KPI

Join revenue and opex by month to compute operating margin = (Revenue − Opex) / Revenue. This is the number the CFO cares about most.

margin = q('''
    WITH r AS (SELECT month, SUM(revenue) AS revenue FROM revenue GROUP BY month),
         c AS (SELECT month, SUM(actual)  AS opex    FROM budget_vs_actual GROUP BY month)
    SELECT r.month,
           r.revenue,
           c.opex,
           r.revenue - c.opex                               AS operating_profit,
           ROUND((r.revenue - c.opex) * 100.0 / r.revenue, 1) AS margin_pct
    FROM r JOIN c ON r.month = c.month
    ORDER BY r.month
''')

fig, ax1 = plt.subplots(figsize=(12, 4))
ax1.bar(margin['month'], margin['operating_profit'],
        color=['#c0392b' if v < 0 else '#27ae60' for v in margin['operating_profit']])
ax1.axhline(0, color='k', lw=.8); ax1.set_ylabel('Operating profit ($)')
ax2 = ax1.twinx()
ax2.plot(margin['month'], margin['margin_pct'], 'o-', color='#112e51', label='Margin %')
ax2.set_ylabel('Operating margin (%)')
ax1.set_title('Operating Profit & Margin by Month')
plt.xticks(rotation=45, ha='right'); plt.tight_layout(); plt.show()
margin

	month	revenue	opex	operating_profit	margin_pct
0	2025-01	1,582,327	1,855,023	-272,696	-17
1	2025-02	1,641,351	1,976,937	-335,586	-20
2	2025-03	1,689,569	2,059,368	-369,799	-22
3	2025-04	1,722,337	2,046,249	-323,912	-19
4	2025-05	1,749,800	1,994,545	-244,745	-14
5	2025-06	1,808,046	1,929,833	-121,787	-7
6	2025-07	1,915,116	1,835,669	79,447	4
7	2025-08	1,981,283	1,762,782	218,501	11
8	2025-09	2,049,395	1,736,185	313,210	15
9	2025-10	2,172,971	1,692,343	480,628	22
10	2025-11	2,168,542	1,692,281	476,261	22
11	2025-12	2,284,623	1,746,619	538,004	24

5. Hiring: plan vs actual headcount

Headcount drives most of a SaaS company’s cost, so FP&A tracks hiring against plan.

hc = q('''
    SELECT department,
           MAX(planned_headcount) AS planned_eoy,
           MAX(actual_headcount)  AS actual_eoy,
           MAX(actual_headcount) - MAX(planned_headcount) AS gap
    FROM headcount
    GROUP BY department
    ORDER BY gap
''')
hc

	department	planned_eoy	actual_eoy	gap
0	Sales	54	45	-9
1	Marketing	27	21	-6
2	Customer Success	33	29	-4
3	G&A	21	17	-4
4	R&D	65	61	-4

6. Executive summary (the deliverable)

This written narrative — not the code — is what lands on the CFO’s desk. Fill it in from your run’s numbers.

Spend / budget

Company opex finished the year ~2% over budget; the biggest overspend was concentrated in the departments flagged OVER budget in section 1.
Spend ran hottest in the seasonal Q4 push — see the month-by-month gap in section 2.

Revenue & margin

Revenue grew steadily each month (MRR compounding), led by Core Platform, with North America the largest region (~55%).
Operating margin improved through the year as revenue growth outpaced opex — the key positive signal for leadership.

Headcount

Most departments are hiring close to plan; any negative gap in section 5 indicates roles behind plan (a risk to the growth forecast).

Recommended actions

Review the over-budget department(s) for run-rate correction next quarter.
Double down on the fastest-growing product/region in the FY2026 plan.
Close the headcount gap where hiring lags, since it underpins the revenue forecast.

What this project shows an employer

Business fluency — variance analysis, operating margin, headcount planning (real FP&A deliverables).
SQL — joins, CTEs, aggregation across multiple internal tables.
Communication — turned raw ERP-style extracts into an executive summary with clear actions.

conn.close()

Microsoft Fabric (DP-600)

2026-06-01T00:00:00+00:00

Microsoft Fabric (DP-600)

1. What Microsoft Fabric Actually Is

After passing PL-300, the natural next step was Microsoft Fabric and the DP-600: Fabric Analytics Engineer Associate certification. So before the exam details, let me explain what Fabric really is.

Microsoft Fabric is an all-in-one analytics platform that bundles data engineering, data warehousing, data science, real-time analytics, and Power BI into a single SaaS product. Instead of stitching together separate services, Fabric gives you one environment where every tool reads and writes to the same shared storage.

The core idea that makes this work is OneLake:

        ┌─────────────────── OneLake (one copy of data) ───────────────────┐
        │                                                                  │
   Data Engineering   Data Warehouse   Data Science   Real-Time   Power BI
   (Spark/Notebooks)     (SQL)          (ML models)   Analytics   (Reports)

OneLake is a single, unified data lake for the whole organization — think “OneDrive for data.” Every workload stores its data here in open Delta/Parquet format.
Because there’s one copy, a table created by a data engineer can be queried by SQL, modeled in Power BI, and used for ML — without copying it around.

Where PL-300 is about analyzing data, DP-600 is about engineering the analytics solution that feeds those reports.

2. The Lakehouse vs. the Warehouse

What they are: Fabric gives you two main ways to store and serve analytical data, and a big part of DP-600 is knowing when to use which.

Lakehouse — combines a data lake (files, unstructured data) with table-like structure on top. You work with it using Spark notebooks (Python/PySpark) and SQL. Best when you have raw, large, or semi-structured data and want flexibility.
Warehouse — a traditional relational data warehouse with full T-SQL support, including writes. Best when your team is SQL-first and you want classic warehouse semantics.

Lakehouse  → files + tables, Spark + SQL, schema-on-read,  data-engineer friendly
Warehouse  → tables only,    T-SQL,        schema-on-write, SQL-developer friendly

The concept to understand: Both store data in OneLake as Delta tables, so they’re interoperable. The choice is about the team and the workload, not about locking your data into one format. The exam tests whether you can recommend the right one for a given scenario.

3. Loading Data — The Medallion Architecture

What it is: A common pattern Fabric promotes for organizing data into quality layers, named after medals.

Bronze  →  Silver  →  Gold
(raw)      (cleaned)   (business-ready)

Bronze — raw data ingested exactly as it arrives, untouched.
Silver — cleaned, deduplicated, validated, and conformed.
Gold — aggregated, business-level tables ready for reporting.

Why it matters: Separating layers means you never lose the raw source, each transformation step is auditable, and reports always read from clean Gold tables. Data pipelines and Dataflows Gen2 are the tools you use to move data between these layers.

The concept to understand: Fabric isn’t just storage — it’s about building a governed flow from messy source to trusted analytics, with each layer adding quality.

4. Querying and Modeling

What it is: Once data lands in a Lakehouse or Warehouse, you query it with SQL and build a semantic model on top.

The key feature — Direct Lake: This is the headline capability DP-600 cares about. Traditionally Power BI either imports data (fast but a copy) or uses DirectQuery (live but slow). Direct Lake is a third mode: Power BI reads the Delta files in OneLake directly, getting import-level speed with no data copy and near real-time freshness.

Import       → copy data into the model        (fast, but stale + duplicated)
DirectQuery  → query the source on every visual (fresh, but slow)
Direct Lake  → read OneLake Delta files directly (fast AND fresh, no copy)

The concept to understand: A semantic model in Fabric still uses the same DAX and star-schema skills from PL-300 — Fabric just changes where the data lives and how fast it connects. Your modeling knowledge carries straight over.

5. Securing and Governing

What it is: Because Fabric centralizes all data in OneLake, governing access is critical, and DP-600 tests it heavily.

Workspace roles — Admin, Member, Contributor, Viewer control who can do what in a workspace.
Row-Level Security (RLS) and Object-Level Security (OLS) — restrict which rows or which tables/columns a user can see.
Sensitivity labels — tag data (e.g., “Confidential”) and have the classification follow the data wherever it flows.

The concept to understand: One shared copy of data is powerful but risky — governance is what makes it safe to centralize. The exam expects you to apply the least-privilege role and the right security layer for each scenario.

6. How DP-600 Compares to PL-300

To put it simply:

PL-300 (Data Analyst) — consume and analyze. Power Query, modeling, DAX, building reports.
DP-600 (Analytics Engineer) — build the platform. Lakehouse/Warehouse design, Spark and T-SQL, pipelines, Direct Lake, and governance across OneLake.

Source → [ DP-600 territory: ingest, clean, model, secure ] → [ PL-300 territory: analyze, visualize ]

DP-600 sits one layer earlier in the pipeline. If PL-300 taught me to make sense of data, DP-600 taught me to engineer the system that delivers clean, fast, governed data in the first place.

7. Final Thoughts

Microsoft Fabric is best understood as one platform on one copy of data (OneLake), with specialized tools — Lakehouse, Warehouse, pipelines, and Power BI — all working over that shared foundation. DP-600 tests whether you can choose the right tool, organize data with the medallion architecture, connect it efficiently with Direct Lake, and govern it safely.

My advice for anyone moving from PL-300 to DP-600: your DAX and modeling skills transfer directly, so focus your study on the engineering side — Lakehouse vs. Warehouse trade-offs, pipelines, and the OneLake/Direct Lake model. Once you see Fabric as a single lake with many doors into it, the whole platform clicks.

Power BI (PL-300)

2026-05-31T00:00:00+00:00

Power BI (PL-300)

1. What Power BI Actually Is

Before talking about the exam, it helps to explain what Power BI really is. Power BI is Microsoft’s business intelligence platform — a set of tools that takes raw data from many sources, turns it into a clean data model, and lets you build interactive reports and dashboards on top of it.

The key idea is that Power BI is not one tool but a pipeline of stages:

Data Sources → Power Query (clean) → Data Model (relate) → DAX (calculate) → Visuals (report) → Service (share)

Power BI Desktop is where you connect to data, shape it, build the model, and design reports.
Power BI Service is the cloud side where you publish, schedule refreshes, set security, and share with others.

I recently passed the PL-300: Microsoft Power BI Data Analyst certification. Below I’ll explain the main concepts the exam tests, in roughly the order data flows through Power BI — because understanding that flow is what the exam is really checking.

2. Preparing Data with Power Query

What it is: Power Query is the data preparation layer. Whenever you import data, it passes through Power Query first, where you clean and reshape it before it ever reaches your model.

Why it matters: Real data is messy — wrong types, blank rows, columns that need splitting or merging. Power Query records every cleaning step you take as a sequence, so when new data arrives, the same steps re-run automatically. You fix the data once, and it stays fixed on every refresh.

The concept to understand: Each action becomes a step in an ordered list. This is “ETL” (Extract, Transform, Load) — you extract from the source, transform it into a usable shape, and load it into the model. The exam expects you to know that cleaning belongs here, upstream, not patched later with formulas.

Raw column "2024-01-05 / N/A / 5,000"
→ Split by delimiter
→ Change type to Date / Text / Number
→ Replace "N/A" with null
= Clean, typed columns ready for modeling

3. Modeling Data (Star Schema & Relationships)

What it is: A data model is a set of tables connected by relationships. The recommended design is a star schema.

Why it matters: Imagine one giant flat table with everything in it — it’s slow and hard to reason about. A star schema splits data into two kinds of tables:

Fact tables hold the events you measure: sales, transactions, clicks. These are long and numeric.
Dimension tables hold the descriptive context: customers, products, dates. These are the things you filter and group by.

        [Date]      [Product]
            \          /
             \        /
            [Sales]  ← fact table (the numbers)
             /        \
            /          \
       [Customer]   [Region]   ← dimension tables (the context)

The concept to understand: Relationships let a filter on a dimension (say, “Product = Laptop”) automatically flow into the fact table and filter the numbers. Getting this structure right is the single most important skill in Power BI — it makes everything downstream simpler and faster.

4. Calculating with DAX

What it is: DAX (Data Analysis Expressions) is the formula language used to create measures — calculations like totals, averages, and year-over-year growth.

Why it matters: Visuals can only show numbers that exist. DAX is how you create those numbers dynamically, so they recalculate as the user filters and slices the report.

The concept to understand — filter context: This is the idea most people struggle with, so let me explain it plainly. Every cell in a Power BI visual has a “filter context” — the set of filters that apply to that specific cell. A measure is evaluated separately in each cell, under that cell’s filters.

For example, Total Sales = SUM(Sales[Amount]) shows the grand total in a card, but inside a table broken down by month, the same measure shows each month’s total — because each row’s filter context limits it to that month.

CALCULATE is the function that lets you change the filter context on purpose:

Total Sales = SUM(Sales[Amount])

-- Take Total Sales, but shift the date filter back one year
Sales LY =
CALCULATE(
    [Total Sales],
    SAMEPERIODLASTYEAR('Date'[Date])
)

Here CALCULATE overrides the current dates and replaces them with the same period last year. Once you understand that measures react to filter context and CALCULATE rewrites it, most advanced DAX stops being mysterious.

5. Visualizing and Analyzing

What it is: This is the report-building stage — choosing visuals (bar, line, card, matrix), arranging them on a page, and wiring up interactivity.

Why it matters: A report’s job is to answer questions quickly. The exam tests whether you can match the right visual to the question:

Trends over time → line chart
Comparing categories → bar/column chart
Part-to-whole → stacked or pie/donut (used sparingly)
A single key number → card or KPI

The concept to understand: Visuals on a page are linked. Clicking a bar in one chart cross-filters the others, so the whole page responds together. That interactivity — letting a user explore by clicking rather than asking for a new report — is the real value of Power BI over a static spreadsheet.

6. Managing and Securing (Power BI Service)

What it is: Once a report is built, you publish it to the Power BI Service to share and govern it.

Why it matters: Reports need to stay current and show the right data to the right people. Key concepts the exam covers:

Workspaces — shared containers where teams collaborate on reports and datasets.
Scheduled refresh — the Service re-runs your Power Query steps on a timer so data stays current automatically.
Row-Level Security (RLS) — define roles with DAX filters so each user only sees their slice of the data. A regional manager sees only their region, even though everyone opens the same report.

-- RLS rule on the Region table
[Region] = USERPRINCIPALNAME()  -- each user sees only their matching rows

The concept to understand: Building the report is only half the job. Governing it — keeping it refreshed, secured, and shared correctly — is what makes it trustworthy in a real organization.

7. Final Thoughts

The thing PL-300 really tests is whether you understand Power BI as a connected pipeline: clean in Power Query, structure in the model, calculate in DAX, present in visuals, and govern in the Service. Each stage builds on the one before it.

If you’re learning Power BI, my advice is to study it in that order rather than jumping straight to charts. Get Power Query and the star schema right first, then learn how filter context drives DAX — once those click, the visuals and sharing are the easy part. That mental model is exactly what the exam, and real reporting work, rewards.

Agentic AI

2026-02-21T00:00:00+00:00

Agentic AI

1. What Is Agentic AI?

Agentic AI refers to AI systems that can act autonomously. They don’t just answer questions. They plan, make decisions, use tools, and execute multi-step tasks on their own. Think of it as the difference between a chatbot that responds to prompts and an AI that actually does things for you.

A regular LLM takes an input and gives an output. An agentic system takes a goal, breaks it down into steps, decides which tools to use, handles errors along the way, and keeps going until the job is done.

Traditional AI:  Input → Output
Agentic AI:      Goal → Plan → Act → Observe → Adjust → Act → ... → Done

2. Why It Matters Now

We’ve had LLMs for a few years, but agentic AI is what makes them actually useful in the real world. A few things came together:

Tool use. Models can now call APIs, run code, search the web, read files, and interact with databases.
Planning & reasoning. Models got better at breaking complex tasks into logical steps.
Memory. Short-term (conversation context) and long-term (stored knowledge) let agents maintain state across interactions.
Cost & speed. Inference got cheap enough to let agents loop and retry without breaking the bank.

This is the shift from AI as a tool you use to AI as a worker you delegate to.

3. How Agentic Systems Work

Most agentic AI follows a loop:

GOAL      → What needs to be done
PLAN      → Break it into sub-tasks
ACT       → Execute a step (call a tool, write code, query an API)
OBSERVE   → Check the result
REFLECT   → Did it work? What's next?
REPEAT    → Loop until the goal is met

The key components:

Component	Role
LLM (Brain)	Reasoning, planning, decision-making
Tools	APIs, code execution, web search, file I/O, databases
Memory	Context window + external storage for long-term recall
Orchestrator	Controls the loop: when to act, when to stop, when to ask for help

4. Single Agent vs. Multi-Agent

Single agent. One LLM handles everything. Good for straightforward tasks.

Multi-agent. Multiple specialized agents collaborate, each handling a different part of the problem. For example:

Researcher agent. Gathers data from APIs and the web
Analyst agent. Processes and interprets the data
Writer agent. Drafts a report or summary
Reviewer agent. Checks for errors and quality

Multi-agent systems are more complex to build but handle harder problems better because each agent can be tuned for its specific role.

User Goal
   ↓
Orchestrator Agent
   ├── Researcher Agent → tools: web search, API calls
   ├── Analyst Agent    → tools: code execution, data analysis
   ├── Writer Agent     → tools: text generation, formatting
   └── Reviewer Agent   → tools: validation, fact-checking
   ↓
Final Output

5. Real-World Use Cases

Agentic AI is already showing up everywhere:

Coding assistants. Not just autocomplete, but agents that read your codebase, plan changes across multiple files, run tests, and fix errors autonomously (like what GitHub Copilot is becoming).
Data analysis. Give an agent a dataset and a question. It writes SQL, runs queries, builds charts, and explains the results.
Customer support. Agents that look up order info, process refunds, escalate to humans when needed, all without a script.
Research. Agents that search papers, summarize findings, identify gaps, and draft literature reviews.
DevOps. Agents that monitor systems, diagnose incidents, and apply fixes or roll back deployments.
Personal assistants. Schedule meetings, draft emails, book flights, manage to-do lists, all by chaining tools together.

6. Frameworks & Tools

The ecosystem is moving fast. Some of the frameworks I’ve been looking at:

Framework	What It Does
LangChain / LangGraph	Build agent workflows with tool use, memory, and branching logic
CrewAI	Multi-agent orchestration with role-based agents
AutoGen (Microsoft)	Multi-agent conversations and collaboration
OpenAI Assistants API	Built-in tool use, code interpreter, file search
Claude Tool Use	Native function calling and multi-step reasoning
Semantic Kernel	Microsoft’s SDK for building AI agents with plugins

The common pattern across all of them: give the LLM access to tools, let it decide when and how to use them, and wrap it in a loop with error handling.

7. Challenges & Risks

Agentic AI isn’t all upside. A few things to watch out for:

Hallucination loops. An agent makes a wrong assumption, acts on it, and compounds the error across multiple steps. By the time you catch it, the damage is done.
Cost blowup. Every loop iteration costs tokens. A poorly designed agent can burn through API credits fast by retrying or going in circles.
Safety & control. An autonomous agent with access to production databases, APIs, or external systems can do real harm if it misunderstands the goal. Guardrails are essential.
Debugging is hard. When an agent takes 15 steps to reach an answer, tracing why it did what it did is way harder than debugging a single prompt-response.
Over-autonomy. Sometimes you don’t want the AI to just go ahead and do things. Human-in-the-loop checkpoints are important for high-stakes decisions.

8. Opportunity & Threat — Two Sides of the Same Coin

This is the part I keep going back and forth on. Agentic AI is clearly a massive opportunity, but the threat side is just as real, and honestly, they’re inseparable.

The opportunity:

Leverage. A single person can now do what used to take a team. An engineer with the right agents can ship features, run data pipelines, monitor systems, and handle ops, all without hiring five more people. Small teams punch way above their weight.
Speed. Tasks that took hours (research, analysis, code review, report generation) can happen in minutes. The feedback loop between idea and execution shrinks dramatically.
Accessibility. People who aren’t developers can build things. Natural language becomes the new interface. A marketing person can query a database, a founder can prototype an app, a student can build something real.
New business models. Agents-as-a-service, autonomous workflows, AI-native products that couldn’t exist before. The design space just got way bigger.

The threat:

Job displacement is real. Let’s not sugarcoat it. If an agent can do 80% of a junior analyst’s job, companies will hire fewer junior analysts. The same applies to support reps, QA testers, content writers, and entry-level developers. The roles won’t disappear overnight, but the headcount will shrink.
Skill erosion. When agents handle the tedious work, people stop learning how to do it themselves. That’s fine until the agent breaks and nobody knows how to fix the underlying problem. We risk raising a generation of operators who can prompt but can’t build.
Concentration of power. The people and companies that build and control agents gain an outsized advantage. If agents become the primary way work gets done, whoever owns the agent layer owns the value chain.
Security surface. Every tool an agent can access is a tool it can misuse. An agent with database write access, API keys, and the ability to send emails is a security incident waiting to happen if the guardrails fail.
Race to the bottom. When everyone has access to the same AI agents, the work they produce converges. Differentiation shifts from execution to taste, strategy, and the quality of your data, which not everyone has.

The honest take? I think the people who treat agentic AI as a tool to amplify their own judgment will do well. The ones who blindly delegate everything to it without understanding what’s happening underneath will get burned. The technology is neutral. It’s leverage, and leverage amplifies both skill and incompetence.

9. Where I Think This Is Going

A few predictions:

Agents will become the default interface. Instead of clicking through UIs, you’ll tell an agent what you want and it’ll handle the rest. The app becomes the agent.
Specialization over generalization. The best agents won’t be “do everything” systems. They’ll be narrow, domain-specific agents that are really good at one thing (finance, code, operations, etc.).
Agent-to-agent communication. Agents will start talking to other agents, forming workflows that span organizations and systems. MCP (Model Context Protocol) and similar standards are early steps toward this.
Trust and verification. As agents do more, we’ll need better ways to audit what they did, why, and whether it was correct. Explainability will matter more than ever.
The “human in the loop” becomes the differentiator. The most valuable skill won’t be prompting an agent. It’ll be knowing when to override it. Domain expertise, judgment, and taste become more important, not less.

The way I see it, we’re at the point where AI stops being something you talk to and starts being something that works for you. That’s a big shift, and it’s happening faster than most people realize. Whether that’s exciting or terrifying probably depends on which side of the leverage you’re on.

ONWRD - A fitness mobile app

2026-01-21T00:00:00+00:00

[Info] ONWRD Website: https://www.goonwrd.com

You can go in apple app store through this website😊

1. What is ONWRD?

ONWRD is a fitness mobile app I’ve been building as a side project. It helps athletes and everyday gym-goers track their physical condition, monitor training trends, and get actionable insights — all without the bloat that comes with most fitness apps.

The name “ONWRD” comes from “onward” — keep moving forward, one rep at a time.

Size: 250px

2. Why I Built It

I tried a bunch of fitness apps and they were either too complicated, too expensive, or trying to be everything at once. I just wanted something clean that lets me log how I’m feeling, see how I’m trending, and stay on top of my condition. So I decided to build my own.

It also gave me a good excuse to learn mobile development and work on something outside of finance and data for a change.

3. Core Features & Plans

Everyone gets a solid baseline — no paywall for the essentials.

Daily Condition Insights — Algorithmic analysis of your physical condition each day.
Dashboard Trends — Track how your condition changes over time with clean visuals.
AI Condition Interpretation — Refined, personalized breakdowns of what your condition data actually means.
AI Activity Insights — Smart summaries of your training activity, challenge progress, and leaderboard standings.
Enhanced Pro Dashboard — More metrics, more detail, better views.
Challenges & Leaderboards — Compete with friends or your team to stay motivated.

📊 Superset Dashboards

On top of the mobile app, I’m building Apache Superset dashboards for both personal and group use — giving coaches and teams a powerful way to visualize condition and performance data at scale.

Size: 250px

4. Tech Stack

Keeping it lean and practical.

Layer	Tech
Frontend	Flutter/Superset
Backend	Python
Database	PostgreSQL
Hosting	Apple
Server	AWS/GCP/Supabase/Firebase

Flutter handles the mobile frontend –> one codebase for both iOS and Android, which saves a ton of time. For the dashboards, I’m using Apache Superset to give users (and coaches) rich, interactive data visualizations for both personal and group views.

The backend is Python –> it powers the REST API, the AI-driven condition and activity insights, and all the data processing behind the scenes. PostgreSQL is the main database, and on the infrastructure side I’m using a mix of AWS, GCP, Supabase, and Firebase depending on the service - auth, storage, push notifications, hosting, etc.

5. What I Learned

Building a full-stack mobile app from scratch taught me a lot. A few things that stood out:

Flutter is fast to build with, but has its quirks — Hot reload is a game-changer for UI work, but managing state across screens and handling platform-specific behavior (iOS vs Android) took real effort to get right.
Superset is powerful but needs tuning — Out of the box it does a lot, but customizing dashboards for both personal and group use cases meant digging into configs, permissions, and embedding options.
Python ties everything together — From the API layer to AI processing to data pipelines, Python made it easy to move fast. The ecosystem around ML and data analysis was a huge advantage for building the condition insights.
Multi-cloud is flexible but complex — Mixing AWS, GCP, Supabase, and Firebase gave me the best tool for each job, but keeping auth, data, and deployments in sync across providers was the hardest infra challenge.
Ship early, iterate often — I spent too long polishing the first version. Should’ve gotten real user feedback sooner.

6. What’s Next

A few things on the roadmap:

Android launch — Currently iOS-only, Android is next.
Advanced analytics — Deeper breakdowns of long-term performance patterns.
Coach tools — Dedicated features for coaches managing multiple athletes.

If you’re interested in trying it out or have feedback, feel free to reach out!

SQL RLS Rule

2026-01-10T00:00:00+00:00

PostgreSQL Row-Level Security (RLS)

1. What is RLS?

Row-Level Security is a PostgreSQL feature that lets you control which rows a user can see or modify in a table — at the database level. Instead of filtering data in your app code, the database itself enforces the rules.

This is especially useful when:

Multiple users share the same table (multi-tenant apps)
You want to guarantee data isolation regardless of how the data is queried
You’re building on top of platforms like Supabase that rely heavily on RLS
You’re using Apache Superset to serve dashboards to different users or teams and need each person to only see their own data

2. How It Works

RLS boils down to three steps:

Enable RLS on a table
Create policies that define who can see/do what
PostgreSQL automatically applies those policies to every query

Without a policy, no rows are returned once RLS is enabled — it’s deny-by-default.

-- Step 1: Enable RLS on the table
ALTER TABLE workouts ENABLE ROW LEVEL SECURITY;

-- Step 2: Create a policy
CREATE POLICY user_isolation ON workouts
    FOR ALL
    USING (user_id = current_setting('app.current_user_id')::uuid);

Now every SELECT, UPDATE, or DELETE on workouts only returns rows where user_id matches the current session’s user.

3. Policy Types

PostgreSQL supports different policy types depending on the operation:

Policy Clause	Controls	When It’s Checked
`USING`	Which rows are visible	`SELECT`, `UPDATE`, `DELETE`
`WITH CHECK`	Which rows can be written	`INSERT`, `UPDATE`

You can also scope policies to specific commands:

-- Read-only: users can only SELECT their own rows
CREATE POLICY select_own ON workouts
    FOR SELECT
    USING (user_id = current_setting('app.current_user_id')::uuid);

-- Insert: users can only insert rows for themselves
CREATE POLICY insert_own ON workouts
    FOR INSERT
    WITH CHECK (user_id = current_setting('app.current_user_id')::uuid);

-- Update: users can only update their own rows
CREATE POLICY update_own ON workouts
    FOR UPDATE
    USING (user_id = current_setting('app.current_user_id')::uuid)
    WITH CHECK (user_id = current_setting('app.current_user_id')::uuid);

-- Delete: users can only delete their own rows
CREATE POLICY delete_own ON workouts
    FOR DELETE
    USING (user_id = current_setting('app.current_user_id')::uuid);

4. Real-World Example: Multi-Tenant App

Say you have a fitness app where each user should only see their own data. Here’s a full setup:

-- Create the table
CREATE TABLE conditions (
    id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
    user_id UUID NOT NULL,
    condition_date DATE NOT NULL,
    score INTEGER,
    notes TEXT,
    created_at TIMESTAMPTZ DEFAULT now()
);

-- Enable RLS
ALTER TABLE conditions ENABLE ROW LEVEL SECURITY;

-- Users can only access their own rows
CREATE POLICY user_access ON conditions
    FOR ALL
    USING (user_id = auth.uid())
    WITH CHECK (user_id = auth.uid());

auth.uid() is a Supabase helper that returns the authenticated user’s ID from the JWT. If you’re not on Supabase, use current_setting('app.current_user_id')::uuid or a similar session variable.

5. Admin / Service Role Bypass

Sometimes you need a backend service or admin to access all rows. You can do this with BYPASSRLS or by creating permissive policies for specific roles:

-- Option 1: Grant a role the ability to bypass RLS entirely
ALTER ROLE service_role BYPASSRLS;

-- Option 2: Create a separate policy for admins
CREATE POLICY admin_full_access ON conditions
    FOR ALL
    TO admin_role
    USING (true)
    WITH CHECK (true);

The table owner also bypasses RLS by default. To force policies on the owner too:

ALTER TABLE conditions FORCE ROW LEVEL SECURITY;

6. RLS with Supabase

If you’re using Supabase, RLS is the primary security layer. A few patterns I use:

Authenticated users see only their data:

CREATE POLICY "Users read own data" ON conditions
    FOR SELECT
    TO authenticated
    USING (user_id = auth.uid());

Allow inserts only for the authenticated user:

CREATE POLICY "Users insert own data" ON conditions
    FOR INSERT
    TO authenticated
    WITH CHECK (user_id = auth.uid());

Public read access (e.g. leaderboards):

CREATE POLICY "Public leaderboard" ON leaderboard
    FOR SELECT
    TO anon, authenticated
    USING (true);

Group/team access:

CREATE POLICY "Team members access" ON team_data
    FOR SELECT
    USING (
        team_id IN (
            SELECT team_id FROM team_members
            WHERE member_id = auth.uid()
        )
    );

7. RLS in Apache Superset

This is how I actually use RLS day-to-day. I run Apache Superset dashboards for ONWRD — personal dashboards for individual users and group dashboards for teams/coaches. The problem is everyone hits the same tables, so I need each user to only see their own data on the charts.

Superset has a built-in Row Level Security feature that works separately from PostgreSQL’s RLS. You configure it through the Superset UI:

Settings → Row Level Security → + Add

Field	What to set
Name	e.g. `User isolation - conditions`
Filter Type	Regular
Tables	Select the tables this rule applies to
Roles	Which Superset roles are affected (e.g. `Gamma`, `Public`)
Clause	SQL WHERE clause, e.g. `user_id = ''`

Superset injects this clause as a WHERE filter on every query that touches those tables — so the charts automatically show only the relevant data.

Example: Personal dashboard

Each user logs into Superset and should only see their own condition scores:

Clause: user_id = ''

Or if you store a user ID mapping:

Clause: user_id = (SELECT id FROM users WHERE email = '')

Example: Group/team dashboard

Coaches should see data for all athletes in their team:

Clause: team_id IN (SELECT team_id FROM team_members WHERE coach_email = '')

Superset RLS vs PostgreSQL RLS — which to use?

	Superset RLS	PostgreSQL RLS
Where it runs	Superset app layer	Database level
Scope	Only Superset queries	All queries (app, API, direct SQL)
Config	UI-based, per role	SQL policies, per table
Best for	Dashboard-level filtering	Full data isolation across all access paths

I use both — Superset RLS for the dashboard layer (quick to set up, role-based), and PostgreSQL RLS on the Supabase side for the mobile app and API. Belt and suspenders.

Tip: If your Superset service account connects to PostgreSQL with a role that has BYPASSRLS, Superset RLS is your only line of defense on the dashboard side. Make sure it’s set up correctly.

8. Testing RLS Policies

Always test your policies. You can simulate a user session like this:

-- Set the session user
SET app.current_user_id = 'some-uuid-here';

-- This should only return rows for that user
SELECT * FROM conditions;

-- Try accessing someone else's data (should return nothing)
SET app.current_user_id = 'different-uuid';
SELECT * FROM conditions;

In Supabase, you can test by calling the API with different JWT tokens and verifying the response only contains the expected rows.

9. Performance Considerations

Index the columns used in policies — If your policy checks user_id, make sure it’s indexed. Otherwise every query does a full table scan.
```
CREATE INDEX idx_conditions_user_id ON conditions(user_id);
```
Keep policies simple — Subqueries in USING clauses (like the team access example) can get expensive. Consider materializing group memberships if queries are slow.
Use EXPLAIN ANALYZE — Check that the RLS filter is pushed down into the query plan efficiently.
Avoid too many policies — Multiple permissive policies on the same table are OR’d together, which can get complex. Restrictive policies are AND’d.

10. Common Pitfalls

Forgetting to create a policy — RLS enabled + no policies = nobody can see anything. This catches people off guard.
Table owner bypass — The table owner skips RLS by default. Use FORCE ROW LEVEL SECURITY if you want policies to apply to everyone.
Joins leaking data — If table A has RLS but table B doesn’t, a join can expose filtered rows through B. Enable RLS on all tables that hold sensitive data.
Migrations breaking policies — Dropping and recreating a table removes its policies. Always re-apply RLS in your migration scripts.

11. Summary

Concept	Key Point
Enable RLS	`ALTER TABLE ... ENABLE ROW LEVEL SECURITY`
Default behavior	Deny all — no rows returned without a policy
`USING`	Controls which rows are visible (reads)
`WITH CHECK`	Controls which rows can be written (inserts/updates)
Admin bypass	`BYPASSRLS` role or permissive admin policy
Force on owner	`FORCE ROW LEVEL SECURITY`
Superset RLS	UI-based row filtering per role — great for dashboards
Best practice	Use both Superset RLS + PostgreSQL RLS for full coverage
Performance	Index policy columns, keep policies simple

RLS is one of those features that, once you start using it, you wonder how you ever built multi-user apps without it. It moves the security boundary into the database where it belongs.

Deep dive into analysis

2025-12-30T00:00:00+00:00

📊 Stock Analysis Workflow

System: ML Analysis Pipeline · AI Valuation Engine · Schwab GEX Module · Agentic AI

System Architecture Overview
Step 1 — Ticker Selection
Step 2 — Fundamental Analysis
Step 3 — DCF Valuation (AI)
Step 4 — Machine Learning Forecast
Step 5 — Backtesting (MA Strategy)
Step 6 — Sentiment Analysis
Step 7 — Quantitative Risk Analysis
Step 8 — Macroeconomic Analysis
Step 9 — GEX (Gamma Exposure)
Step 10 — Weighted Score & Signal
Step 11 — AI Final Summary
Step 12 — Agentic AI (Alternative Pipeline)
Output — Email Report
Configuration Reference

1. System Architecture Overview

┌─────────────────────────────────────────────────────────────────────┐
│                     fetch_ML_v2.py / ML_report_v2.py                │
│                                                                       │
│  [Ticker Selection]                                                   │
│       │                                                               │
│       ▼                                                               │
│  ┌─────────────┐  ┌───────────┐  ┌──────────┐  ┌────────────────┐   │
│  │ Fundamental │  │    DCF    │  │    ML    │  │  Backtesting   │   │
│  │  Analysis   │  │  (AI LLM) │  │ Forecast │  │  (MA Strategy) │   │
│  └──────┬──────┘  └─────┬─────┘  └────┬─────┘  └───────┬────────┘   │
│         │               │             │                 │             │
│  ┌──────▼──────┐  ┌──────▼──────┐  ┌──▼──────────┐  ┌──▼──────────┐ │
│  │  Sentiment  │  │    Quant    │  │    Macro    │  │    GEX      │ │
│  │  (FinBERT)  │  │ (QuantStats)│  │   (FRED)   │  │  (Schwab)   │ │
│  └──────┬──────┘  └─────┬───────┘  └────┬────────┘  └─────┬───────┘ │
│         │               │               │                  │          │
│         └───────────────┴───────────────┴──────────────────┘          │
│                                    │                                   │
│                          [Weighted Score]                             │
│                                    │                                   │
│                          [AI Summary Report]                          │
│                                    │                                   │
│                    [Email + Database Insert]                          │
└─────────────────────────────────────────────────────────────────────┘

2. Step 1 — Ticker Selection

Source: Stock Screener Utility — Sector & momentum-ranked stock picker

How It Works

The screener finds the single highest-momentum, highest-liquidity stock each day using Finviz.

1. Sector finder
   └─ Overview → all sectors sorted by daily % change
   └─ Pick the TOP sector (best-performing sector today)

2. Ticker finder
   └─ Custom screener with filters:
       • Index:        Any
       • Country:      USA
       • Performance:  Today Up
       • Gap:          Up  (opening gap up)
   └─ Order by: % Change (descending)
   └─ Take top 25 results
   └─ Calculate Trade Value = Price × Volume
   └─ Sort by Trade Value (descending)
   └─ Return #1 ticker  ← highest momentum + highest liquidity

Screener Columns Pulled

Column	Description
Ticker	Symbol
Price	Current price
Change	Daily % change
Volume	Share volume
P/E	Price/Earnings
EPS this Y	EPS growth this year
EPS next Y	EPS growth next year
Sales Q/Q	Revenue growth QoQ
P/FCF	Price/Free Cash Flow
P/B	Price/Book
ROI	Return on Investment
ROE	Return on Equity

3. Step 2 — Fundamental Analysis

Source: Fundamental Data Fetcher — Multi-source stock fundamentals aggregator (Finviz + yfinance)

Data Sources

Source	Data
Finviz (`finvizfinance`)	P/E, P/B, P/S, ROA, ROE, gross margin, operating margin, EPS growth, short float, insider own%
yfinance	Company info, valuation, earnings, balance sheet, analyst targets, insider transactions, earnings dates

Key Metrics Collected

Valuation

Market Cap, Enterprise Value
Trailing P/E, Forward P/E, PEG Ratio
Price/Book, Price/Sales, EV/EBITDA, EV/Revenue

Profitability

EPS (trailing & forward)
Revenue & Revenue Growth
Gross Margins, Operating Margins, Profit Margins
ROE (Return on Equity), ROA (Return on Assets)

Balance Sheet Health

Total Cash, Total Debt, Debt/Equity Ratio
Current Ratio
Free Cash Flow, Operating Cash Flow

Price & Targets

Current Price
Analyst Target (Low / Mean / Median / High)
52-Week High/Low
50-Day / 200-Day Moving Averages
Dividend Yield, Payout Ratio

Qualitative

Recent analyst recommendations (last 5)
Insider transactions (last 5)
Upcoming earnings dates

4. Step 3 — DCF Valuation (AI)

Source: AI-Powered DCF Valuation Engine — 7-step discounted cash flow analysis

Inputs (from yfinance)

ticker_yf.cashflow        # Cash flow statement
ticker_yf.balance_sheet   # Balance sheet
ticker_yf.income_stmt     # Income statement (P&L)
company_info              # Key stats dict

AI DCF Methodology

The AI model is instructed to follow this exact 7-step process:

Step 1 ─ Forecast 5 years of Free Cash Flow (FCF)
          • Based on historical FCF trend
          • Max 20% annual growth unless justified
          • No negative forecasted FCF

Step 2 ─ Terminal Value (Gordon Growth Model)
          TV = Final Year FCF × (1 + g) / (WACC - g)

Step 3 ─ WACC Calculation
          • Cost of Equity = CAPM: rf + β × (rm - rf)
          • Cost of Debt = avg interest rate × (1 - tax rate)
          • Capital structure = Debt / (Debt + Equity)
          • WACC = wE × rE + wD × rD

Step 4 ─ Discount all FCFs + Terminal Value to PV
          PV = FCF_t / (1 + WACC)^t

Step 5 ─ Subtract Net Debt
          Equity Value = Σ PV(FCF) + PV(TV) - Net Debt
          Net Debt = Total Debt - Cash

Step 6 ─ Intrinsic Share Price
          Price = Equity Value / Shares Outstanding

Step 7 ─ Output: Intrinsic value (USD total) + per-share price

Output

Intrinsic Share Price: $XXX.XX Comparison to current market price → overvalued / fair / undervalued

5. Step 4 — Machine Learning Forecast

Source: ML Forecasting Engine — Bidirectional LSTM + XGBoost ensemble price predictor

Data Preparation

Price history: 3 years from yfinance
Lookback window: 60 trading days
Forecast horizon: 20 trading days
Train/Test split: 80% / 20%

Feature Engineering

# Price features
returns          = Close.pct_change()
log_returns      = log(Close / Close.shift(1))

# Moving averages (ratios — normalized)
sma_5/10/20/50   = Close.rolling(window).mean()
sma_ratio        = Close / sma

# Volatility
volatility_20    = returns.rolling(20).std()

# RSI (14-period)
rsi = 100 - (100 / (1 + avg_gain / avg_loss))

# MACD
macd             = EMA(12) - EMA(26)
macd_signal      = EMA(macd, 9)

# Bollinger Bands
bb_mid           = SMA(20)
bb_upper         = SMA(20) + 2 × std(20)
bb_lower         = SMA(20) - 2 × std(20)
bb_position      = (Close - bb_lower) / (bb_upper - bb_lower)

Model Architecture

LSTM (Primary)

Input: (60 days × 1 feature — scaled Close price)
  ↓
Bidirectional LSTM (128 units) → BatchNorm → Dropout(0.3)
  ↓
LSTM (64 units) → BatchNorm → Dropout(0.3)
  ↓
LSTM (32 units) → BatchNorm → Dropout(0.2)
  ↓
Dense(16, ReLU) → Dense(1)

Optimizer:  Adam (lr=0.001)
Loss:       Huber (robust to outliers)
Callbacks:  EarlyStopping (patience=5), restore_best_weights=True
Epochs:     10 max

XGBoost (Ensemble Pair)

XGBRegressor(
    n_estimators=100,
    max_depth=6,
    learning_rate=0.1,
    subsample=0.8,
    colsample_bytree=0.8
)

Ensemble

Final Prediction = (LSTM prediction + XGBoost prediction) / 2

Forecast Output

RMSE              : Root Mean Squared Error
MAE               : Mean Absolute Error
MAPE              : Mean Absolute Percentage Error
Model Accuracy    : max(0, 100 - MAPE) %
Forecast Trend    : "Up" or "Down"
Expected Return   : (last_forecast - first_forecast) / first_forecast
forecast_df       : DataFrame of 20-day price forecast

6. Step 5 — Backtesting (MA Strategy)

Source: MA Strategy Backtester — Vectorized moving average signal simulator

Strategy Logic

For each MA window in [5, 7, 9, 12, 15, 20, 50]:
  ┌──────────────────────────────────────┐
  │ Entry Signal                         │
  │   |Price - MA| / MA < 1%            │
  │   (price touching the moving average)│
  └──────────────────────────────────────┘
            │
            ▼
  ┌──────────────────────────────────────┐
  │ Exit Signal                          │
  │   Take Profit:  PnL ≥ +5%           │
  │   Stop Loss:    PnL ≤ -5%           │
  └──────────────────────────────────────┘

Data: yfinance from 2022-01-01 to yesterday
Starting capital: $10,000
Benchmark: Buy-and-Hold return over same period

Output Per MA Window

Metric	Description
`total_trades`	Number of trades executed
`win_rate`	% of profitable trades
`return_pct`	Total strategy return %
`final_capital`	End capital from $10,000
`avg_holding_days`	Average days held per trade

Selection Criteria

Best MA Window = highest return_pct across all windows Feeds into: best_sma stored in database, best_holding days

7. Step 6 — Sentiment Analysis

Source: Sentiment Analysis Pipeline — FinBERT NLP engine for news & Reddit crowd signals

Sentiment Models

Model	Role
FinBERT (`ProsusAI/finbert`)	Primary — fine-tuned on financial text
VADER + custom finance lexicon	Fallback if FinBERT unavailable

Custom Finance Lexicon (VADER additions)

'bullish': +3.7   'bearish': -3.7
'buy': +4.0       'sell': -4.0
'upgrade': +3.0   'downgrade': -3.0
'beat': +2.5      'miss': -2.5
'moon': +4.0      'crash': -3.5
'rally': +2.5     'squeeze': +2.0

News Analysis

Sources:

Finviz — recent news headlines for the ticker
Yahoo Finance — yf.Ticker(ticker).news

Process:

Fetch headlines → Deduplicate → FinBERT scoring →
Average compound score → Return {score, pos%, neg%, neu%, headline_count}

Reddit Analysis

Subreddits: wallstreetbets, stocks, investing, stockmarket

Filters:

Upvote ratio ≥ 0.70
Upvotes ≥ 20
Checks post title + body + top comments

Process:

Parallel fetch (4 workers) across subreddits →
Match ticker symbol or company name →
FinBERT scoring on matching posts/comments →
Average compound score → Return {score, mention_count}

8. Step 7 — Quantitative Risk Analysis

Source: Quantitative Risk Analyzer — QuantStats performance metrics + Risk/Return vs S&P 500 charting

QuantStats Metrics (from `2022-01-01`)

Metric	Meaning
Sharpe Ratio	Risk-adjusted return (rf = 4% annual)
Sortino Ratio	Downside-adjusted return
Calmar Ratio	CAGR / Max Drawdown
Max Drawdown	Worst peak-to-trough loss
Volatility	Annualized standard deviation of returns
Win Rate	% of positive daily returns
Profit Factor	Gross profit / Gross loss
CAGR	Compound Annual Growth Rate
Value at Risk (VaR)	95% worst-case daily loss
Expected Return	Mean daily return

Risk vs Return Chart

MarketVsticker.generate_vsticker() produces a scatter plot:

X-axis: Risk (daily return std dev)
Y-axis: Average return × 10
Plots ticker vs S&P 500
Red dashed line = S&P 500 slope (Sharpe reference line)

Tickers above the S&P line offer better risk-adjusted returns

9. Step 8 — Macroeconomic Analysis

Source: Macroeconomic Analysis Engine — FRED API data tracker with VIX and BofA Bear/Bull indicator scoring

Data Sources

Source	Series	Description
FRED API	`GDP`	Gross Domestic Product
	`FEDFUNDS`	Federal Funds Rate
	`CPIAUCSL`	CPI — inflation
	`PPIACO`	Producer Price Index
	`DGS10`	10-Year Treasury Yield
	`DGS2`	2-Year Treasury Yield
	`UNRATE`	Unemployment Rate
	`USSLIND`	Leading Economic Index
	`HOUST`	Housing Starts
	`PERMIT`	Building Permits
	`UMCSENT`	Consumer Confidence
Yahoo Finance	`^VIX`	Volatility Index
	`SPY`, `QQQ`, `IWM`	Market breadth

VIX Classification

VIX Level	Classification
< 15	Low (complacent)
15–20	Normal
20–25	Elevated
25–30	High
> 30	Extreme (fear)

Yield Curve Analysis

Spread = 10Y Treasury Yield - 2Y Treasury Yield

Spread < 0  →  ⚠️ INVERTED (Recession warning)
Spread > 0  →  ✅ Normal

Market Breadth (SPY / QQQ / IWM)

For each index: 1D, 1W, 1M, 3M, YTD returns + trend classification:

strong uptrend / uptrend / sideways / downtrend / strong downtrend

BofA Bear Indicators (10 signals — Market Peak Warnings)

#	Signal	Threshold
1	Consumer Confidence	> 110 (prior 60mo)
2	Net % expecting stocks higher	> 20% (prior 6mo)
3	Sell-side indicator	“Sell” signal
4	S&P 500 LT growth 5yr Z-score	> 1
5	M&A deals 10yr Z-score	> 1
6	(Trailing PE + YoY CPI) Z-score	> 1
7	Low PE underperforms High PE	by 2.5ppt (6mo)
8	Inverted yield curve	Spread < 0
9	Credit stress indicator	< 0.25
10	Tightening credit (SLOOS)	Triggered

BofA Bull Indicators (10 signals — Market Bottom Signals)

#	Signal	Threshold
1	Fed cutting rates	Prior 12mo
2	Unemployment rising	vs 12mo low
3	More bears than bulls	AAII survey
4	ERP increase	> 75bps vs 12mo low
5	2Y yield decline	> 50bps vs 6mo high
6	Sell-side indicator	“Buy” signal
7	Yield curve steepening	vs 6mo low
8	5% bear market rally	Prior 3mo
9	Rule of 20 triggered	—
10	PMI improves	vs 12mo YoY low

Macro Sentiment Classification

Bear signals - Bull signals > 2  →  BEARISH
Bull signals - Bear signals > 2  →  BULLISH
Otherwise                        →  NEUTRAL

Macro Score Adjustment

if macro_sentiment == 'bearish' or bear_count >= 5:
    macro_adjustment = -0.05   # Reduce buy conviction
elif macro_sentiment == 'bullish' or bull_count >= 5:
    macro_adjustment = +0.02   # Slightly increase conviction

if VIX > 30:
    macro_adjustment -= 0.03   # Additional caution in fear spike

10. Step 9 — GEX (Gamma Exposure)

Source: Schwab GEX Calculator — Dealer gamma exposure derived from live Schwab option chain feed
API: Charles Schwab Live Market Data — Real-time option chain endpoint (/marketdata/v1/chains)

What Is GEX?

GEX measures how much gamma market makers (dealers) hold, which predicts near-term market behavior:

GEX Formula:
  Call GEX =  Gamma × Open Interest × 100 × Spot Price  (positive)
  Put  GEX = -Gamma × Open Interest × 100 × Spot Price  (negative)

Total GEX = Σ(Call GEX) + Σ(Put GEX) across all strikes

Market Condition Interpretation

Condition	Meaning	Market Behavior
Positive GEX (Total > 0)	Dealers are long gamma	Mean-reverting, lower volatility, price pinned to large strikes
Negative GEX (Total < 0)	Dealers are short gamma	Trending/accelerating, higher volatility, moves amplified

Key GEX Levels

GEX Flip Level  — Strike where cumulative GEX crosses zero
                  Acts as a market pivot / support-resistance

Support Level   — Highest |GEX| strike below current price
                  Large positive GEX below = dealers hedge by buying → support

Resistance Level — Highest |GEX| strike above current price
                   Large positive GEX above = dealers hedge by selling → resistance

0DTE GEX

Special calculation for same-day expiration options only (highest gamma impact near expiry). Useful for intraday trading levels.

GEX Report Output

═══════════════════════════════════
         GEX ANALYSIS: SPY
═══════════════════════════════════
📊 Current Price: $565.43
💰 Total GEX: +$2.14B

📈 Market Condition: POSITIVE_GAMMA
   Dealers long gamma → Market likely to mean-revert

🎯 Key Levels:
   • GEX Flip:    $558.00
   • Support:     $560.00
   • Resistance:  $570.00

📍 Top Positive GEX Strikes (Resistance):
   • $570.00: $420.5M
   • $575.00: $380.2M
   ...

Covered Call Screener (bonus)

Source: Covered Call Screener — High-IV option income opportunity finder using Schwab option chains

Screens for high-IV covered call opportunities:

Metric	Formula
Premium Yield	bid / spot price
Annualized Return	premium_yield × 365/DTE
Downside Protection	bid / spot price
Theta/Gamma Ratio	θ / Γ (higher = better risk/reward)

Filters: DTE 14–60, OTM 1%–15%, min OI 10, configurable IV floor

11. Step 10 — Weighted Score & Signal

Source: ML Analysis Orchestrator — Weighted signal aggregator that combines all module outputs with macro adjustment

Score Weights

                    ┌─────────────────────────────────────────────────┐
                    │           WEIGHTED SCORE CALCULATION            │
                    │                                                  │
   News Sentiment   │  score × 0.30  (FinBERT compound, range -1 to 1)│
   Reddit Sentiment │  score × 0.20  (FinBERT compound, range -1 to 1)│
   ML Forecast      │  return × 0.30 (expected 20-day return decimal) │
   Buy-and-Hold     │  return × 0.20 (historical BnH return decimal)  │
                    │  ─────────────────────────────────────────────── │
                    │  raw_score  = sum of above                       │
                    │  + macro_adjustment  (-0.08 to +0.02)            │
                    │  ─────────────────────────────────────────────── │
                    │  weighted_score = raw_score + macro_adjustment   │
                    └─────────────────────────────────────────────────┘

Signal Decision

if weighted_score > 0.5:
    signal = "Buy"
else:
    signal = "Hold"

Database Record (`tk_selected` table)

INSERT INTO tk_selected (date, ticker, score, news, reddit, lstm, holding_days, sma, result)
VALUES (today, ticker, weighted_score, news_score, reddit_score, forecast_trend, best_holding, best_ma, signal)

12. Step 11 — AI Final Summary

Source: AI Investment Report Generator — Multi-factor synthesis engine that produces a buy-side equity memo

Inputs Fed to AI Model

═══ FUNDAMENTALS ═══        (Finviz + yfinance table)
═══ TECHNICAL CHART ═══     (Matplotlib chart: price + MA + forecast + sentiment + backtest)
═══ ML ANALYSIS REPORT ═══  (Full text report from generate_report())
═══ QUANTITATIVE METRICS ══ (QuantStats summary)
═══ MACROECONOMIC ANALYSIS ═(FRED + VIX + BofA signals)
═══ GEX ANALYSIS ═══        (Schwab GEX report)
═══ DCF VALUATION ═══       (AI DCF output)

Output Structure

1. Executive Summary (1-2 paragraphs)
   └─ Valuation, market position, technicals, macro, sentiment

2. Macroeconomic Context
   └─ VIX level, yield curve status, market breadth (SPY/QQQ/IWM)
   └─ BofA Bear/Bull signals
   └─ Risk-on / Risk-off assessment

3. GEX Analysis
   └─ Positive vs Negative gamma interpretation
   └─ Key GEX support/resistance/flip levels
   └─ Position sizing guidance from GEX

4. Fundamental Strengths & Risks (bullet points)

5. Sentiment Assessment
   └─ News vs Reddit divergence analysis

6. Risk/Return Positioning
   └─ Volatility, drawdowns, win rate

7. Model Alignment
   └─ MA backtest vs LSTM forecast alignment

8. DCF Comparison
   └─ Intrinsic value vs current price

9. ─────────────────────────────────────────────────────
   🟡 Final Recommendation (as of YYYY-MM-DD)
   ▶ Position: BUY / HOLD / SELL
   ▶ Macro Alignment: FAVORABLE / NEUTRAL / UNFAVORABLE
   ▶ GEX Condition: POSITIVE GAMMA / NEGATIVE GAMMA

   Key Notes:
   - Macro Context: [VIX, yield curve, market trend]
   - GEX Levels: [Support $X, Resistance $Y, Flip $Z]
   - Tactical entry/exit ranges
   - Position sizing guidance
   - Position management (trailing stop, profit target)
   - 1-line Summary Statement
   ─────────────────────────────────────────────────────

13. Step 12 — Agentic AI (Alternative Pipeline)

Source: Agentic AI Orchestrator & Specialist Agents — LLM-first sequential analysis pipeline with four domain-expert personas

This is an LLM-first alternative to the quantitative pipeline, useful for deeper qualitative analysis.

Agent Execution Flow

User provides ticker(s)
        │
        ▼
┌─────────────────────────────────────────────────────────────────┐
│  Step 1: Macro Analyst (runs ONCE, shared across all tickers)   │
│          Skill: macroeconomic (FRED + VIX + market data)         │
│          Output: RISK-ON / RISK-OFF / TRANSITIONAL              │
└───────────────────────────────┬─────────────────────────────────┘
                                │
                                ▼
┌─────────────────────────────────────────────────────────────────┐
│  Step 2: Fundamental Analyst (per ticker)                        │
│          Skills: microeconomic + qualitative                     │
│          Data: yfinance financials, DCF, sector comps, news      │
│          Output: OVERVALUED / FAIR / UNDERVALUED + catalysts     │
└───────────────────────────────┬─────────────────────────────────┘
                                │
                                ▼
┌─────────────────────────────────────────────────────────────────┐
│  Step 3: Quant Analyst (per ticker)                              │
│          Skill: quantitative                                     │
│          Data: Price history, MA structure, RSI/MACD, Sharpe,   │
│                max drawdown, beta, LSTM forecasts, GEX           │
│          Output: Technical signal + risk metrics + entry/exit    │
└───────────────────────────────┬─────────────────────────────────┘
                                │
                                ▼
┌─────────────────────────────────────────────────────────────────┐
│  Step 4: Portfolio Strategist (synthesis)                        │
│          Receives: all 3 agent analyses                          │
│          Output: BUY/HOLD/SELL + conviction (1-10) +            │
│                  position size + risk parameters                 │
└─────────────────────────────────────────────────────────────────┘

Agent Prompting Philosophy

Each agent has a specific system prompt persona:

Agent	Persona
Macro Analyst	Senior macro strategist at a global macro hedge fund
Fundamental Analyst	Buy-side equity research analyst at a top-tier investment firm
Quant Analyst	Quantitative portfolio analyst at a systematic trading firm
Portfolio Strategist	Chief Investment Officer at a multi-strategy fund

Running the Agentic Pipeline

from agentic_ai.orchestrator import Orchestrator

orchestrator = Orchestrator()

# Single ticker
result = orchestrator.analyze_ticker("AAPL")

# Multiple tickers (macro cached and shared)
results = orchestrator.analyze_portfolio(["AAPL", "TSLA", "NVDA"])

14. Output — Email Report

Source: Email Report Dispatcher — HTML report builder and Gmail SMTP sender

The HTML email contains all sections assembled:

Subject: "Daily Stock Report: {TICKER}, {Company Name}"

HTML Email Sections:
┌──────────────────────────────────────────────────────────┐
│ 1. ML Analysis Text Report (pre-formatted text)           │
│ 2. Analysis Dashboard Chart (2×2 matplotlib grid):        │
│    ├─ [Top-Left]  Price history (6mo) + MA20/MA50         │
│    ├─ [Top-Right] LSTM 20-day price forecast               │
│    ├─ [Bot-Left]  Sentiment bar chart (News/Reddit/Score) │
│    └─ [Bot-Right] MA backtest returns vs win rates        │
│ 3. Risk vs Return Chart (vs S&P 500 scatter plot)         │
│ 4. Fundamental Data Table (Finviz HTML table)             │
│ 5. QuantStats Summary                                     │
│ 6. AI DCF Valuation Analysis                              │
│ 7. AI Final Summary (with GEX & Macro)                   │
│ 8. Macro Analysis Report                                  │
│ 9. GEX Report (Schwab option chain analysis)              │
│ 10. Covered Call Screener (optional)                      │
└──────────────────────────────────────────────────────────┘

15. Configuration Reference

Source: Analysis Configuration Dataclass — All tunable parameters for the ML pipeline

Quick Reference Summary

TICKER SELECTION  →  Finviz: top sector + highest Trade Value stock
FUNDAMENTAL       →  Finviz + yfinance: P/E, margins, targets, insider
DCF               →  AI model: 5yr FCF forecast → WACC → intrinsic price
ML FORECAST       →  LSTM + XGBoost: 60-day lookback → 20-day price forecast
BACKTEST          →  MA strategy (5–50): touch MA → 5% TP / -5% SL
SENTIMENT         →  FinBERT on Finviz news + Reddit (4 subreddits)
QUANT RISK        →  QuantStats: Sharpe, Sortino, VaR, CAGR + Risk/Return plot
MACRO             →  FRED: yields, CPI, unemployment + VIX + BofA signals
GEX               →  Schwab API: dealer gamma → support/resistance/flip levels
WEIGHTED SCORE    →  0.3(news) + 0.2(reddit) + 0.3(ML) + 0.2(BnH) ± macro adj
SIGNAL            →  Score > 0.5 → BUY, else HOLD
AI SUMMARY        →  All data → AI model → final recommendation with entry/exit

16. Conclusion

That’s the entire workflow from ticker selection all the way through to a final buy & hold decision with covered calls on top. Every step feeds into the next: the screener narrows the universe, fundamentals and DCF set a fair-value anchor, ML and backtesting add a forward-looking edge, sentiment captures the crowd’s mood, macro and GEX keep me aware of the bigger picture, and the weighted score ties it all together into a single actionable signal.

Is it perfect? No. Markets will always surprise you. But having a structured, repeatable process removes most of the emotion from the decision and lets the data do the heavy lifting. The agentic AI pipeline is a newer addition that gives me a second opinion, a qualitative lens on top of the quantitative one and I’ve found the two complement each other well.

Building this system has been one of the most rewarding projects I’ve worked on. If you made it this far, I hope it gave you some ideas for your own workflow. Happy investing.

AWS Data Engineering

2025-11-10T00:00:00+00:00

AWS Data Engineering

1. Overview

This post walks through how I set up a data engineering pipeline on AWS. The goal was to build a reliable, scalable system that ingests raw data, transforms it, and serves it up for analytics — all using managed AWS services so I’m not babysitting servers.

The pipeline follows a classic Extract → Transform → Load (ETL) pattern, with a few extras like orchestration, monitoring, and cost controls baked in.

2. Architecture

Here’s the high-level flow:

Data Sources → S3 (Raw) → Glue (Transform) → S3 (Processed) → Athena / Redshift → Dashboard
                                  ↑
                          Step Functions (Orchestration)
                                  ↑
                         EventBridge (Scheduling)

Component	AWS Service	Role
Storage	S3	Landing zone for raw and processed data
Catalog	Glue Data Catalog	Schema discovery and metadata management
ETL	Glue Jobs (PySpark)	Data cleaning, transformation, aggregation
Orchestration	Step Functions	Coordinate multi-step ETL workflows
Scheduling	EventBridge	Trigger pipelines on a schedule or event
Query	Athena	Serverless SQL queries on S3 data
Warehouse	Redshift (optional)	Heavy analytical workloads
Monitoring	CloudWatch	Logs, metrics, and alerts
IAM	IAM Roles & Policies	Least-privilege access across services

3. Data Ingestion

Raw data lands in S3 — could be CSVs, JSON, or Parquet files from APIs, databases, or streaming sources. I organize the bucket with a partitioned structure:

s3://my-data-lake/
  raw/
    source=api_a/
      year=2025/month=11/day=08/
        data.json
  processed/
    table_name/
      year=2025/month=11/
        part-00000.parquet

For real-time ingestion, Kinesis Data Firehose can stream data directly into S3 with automatic batching and compression.

4. Transformation with Glue

AWS Glue handles the heavy lifting. I write PySpark jobs that:

Clean — Drop nulls, fix data types, deduplicate.
Transform — Join datasets, calculate derived fields, aggregate.
Partition — Write output in Parquet format, partitioned by date for fast querying.

A typical Glue job looks something like this:

import sys
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from pyspark.context import SparkContext
from awsglue.context import GlueContext
from awsglue.job import Job

args = getResolvedOptions(sys.argv, ['JOB_NAME'])
sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session
job = Job(glueContext)
job.init(args['JOB_NAME'], args)

# Read from catalog
df = glueContext.create_dynamic_frame.from_catalog(
    database="my_database",
    table_name="raw_table"
)

# Transform
df_clean = df.toDF() \
    .dropDuplicates() \
    .filter("amount > 0") \
    .withColumn("processed_date", current_date())

# Write back to S3 as Parquet
df_clean.write \
    .mode("overwrite") \
    .partitionBy("year", "month") \
    .parquet("s3://my-data-lake/processed/clean_table/")

job.commit()

The Glue Data Catalog keeps track of all the schemas automatically — once a Crawler runs, Athena can query the data right away.

5. Orchestration with Step Functions

Step Functions tie the pipeline together. A typical workflow:

Trigger — EventBridge fires on a schedule (e.g. daily at 2 AM UTC).
Crawl raw data — Glue Crawler updates the catalog.
Run ETL job — Glue job transforms and writes processed data.
Crawl processed data — Update the catalog with new partitions.
Notify — SNS sends a success/failure alert.

Each step has built-in retry logic and error handling, so if a Glue job fails it retries before alerting.

6. Querying with Athena

Once data is in processed S3 buckets and cataloged, Athena lets me run SQL directly on it — no loading into a database, no infrastructure to manage.

SELECT
    user_id,
    COUNT(*) AS total_events,
    SUM(amount) AS total_amount
FROM processed_db.clean_table
WHERE year = '2025' AND month = '11'
GROUP BY user_id
ORDER BY total_amount DESC
LIMIT 100;

Athena charges per TB scanned, so partitioning and Parquet compression make a real difference in cost.

7. Cost & Performance Tips

A few things I picked up along the way:

Parquet over CSV — Columnar format = faster queries and way less data scanned.
Partition everything — Date-based partitions cut Athena costs dramatically.
Right-size Glue DPUs — Start with the minimum workers and scale up only if jobs are slow.
Use Glue bookmarks — Process only new data instead of re-processing the full dataset every run.
Set S3 lifecycle rules — Move old raw data to Glacier after 90 days.
Tag everything — Makes cost tracking and cleanup much easier.

8. What I Learned

Serverless doesn’t mean zero ops — You still need to monitor, tune, and debug. CloudWatch dashboards and alerts are essential.
Schema evolution is tricky — When source data changes shape, the Glue Catalog and downstream queries can break. Adding schema validation early saves headaches.
Start simple, then optimize — It’s tempting to over-engineer from day one. A basic S3 → Glue → Athena pipeline handles most use cases before you need Redshift or EMR.
IAM is the real boss — Getting permissions right across S3, Glue, Step Functions, and Athena took more time than the actual data work.

Algorithmic Trading

2025-08-29T00:00:00+00:00

Algorithmic Trading Bot

Contents
Introduction
Ticker Selection
Ticker Database
Discord
Performance
Conclusion

1. Introduction

Algorithmic trading bots are automated systems that execute trades based on predefined strategies and algorithms. These bots analyze market data, identify trading opportunities, and place orders without human intervention with the pre-setup. By leveraging speed, accuracy, and data-driven decision-making, algorithmic trading bots can help traders optimize their strategies and manage risk more effectively.

In this blog, I’ll explore the basics of algorithmic trading, discuss popular strategies, and provide insights into building your own trading bot using Python. Whether you’re a beginner or an experienced trader, understanding how algorithmic bots work can give you a competitive edge in today’s fast-paced financial markets.

2. Ticker Selection

Choosing the right tickers matters as much as the strategy itself.

I start by screening for the highest dollar trading value of the day Trading Value = Volume x price. From there, I run each candidate through a pre-configured pipeline: fundamentals, risk/return metrics, quantitative factors, DCF intrinsic value, and backtests. Based on this evidence, I decide whether to enable the bot to automatically buy and sell that ticker.

3. Ticker Database

When I select a ticker that I think it will go down(I prefer buy the dip), then I add it to the dataset with fields such as ticker symbol, target buy percentage, notes/description, moving averages, and a suggested holding period derived from backtests. The database will add earnings date, PL, Win rate, moving percentage in a day and RVOL per se.

4. Send commands through discord

One feature I love is that I can send a command through discord to my database, so I can update parameters without touching the database UI, I can simply send commands like Percentage of buy, Buy Limit, Sell Limit, etc, and the system applies the changes immediately.

5. Performance (3 months)

Here’s a three-month snapshot, early results were strong (peaking over 15% of return). After the market pullback I gave back some gains, but the portfolio still remains profit as it shows. The KPI dashboard are built with Apache Superset.

6. Conclusion

Algorithmic trading doesn’t mean “good” or “bad”, but you can definitely try this thing and see how it works. If you can’t monitor markets all day (I have a full time job), a well-tested, rule-based bot can help execute consistently on your plan without straing at the screen. As always start small, validate with backtests and paper trading, and iterate thoughtfully.

SWJ Note

Valuation Analysis - NIKE

Peer Comparison — NKE vs DECK (Hoka) vs ONON (On) vs ADDYY (Adidas)

Qualitative Comparison

Revenue basis — how they differ, and why NKE is losing

Scale & trajectory (USD, latest fiscal year)

Why NKE is losing

SEC-filing evidence — the numbers behind each theme

Conclusion — what Nike must do to stop losing

1. Win back product & innovation (fixes footwear −12.1%)

2. Rebuild wholesale without abandoning DTC (fixes Nike Direct −12.9%)

3. Reset Greater China (fixes China −12.7%)

4. Protect the moat & the P&L

The scorecard to watch (from the same 10-K tables)

Internal Financial Analysis

Internal Financial Analysis — SaaS Cloud (FY2025)

1. Budget vs Actual — full-year variance by department

2. Monthly spend trend — where variance builds up

3. Revenue trend by product & region

4. Operating margin — the headline KPI

5. Hiring: plan vs actual headcount

6. Executive summary (the deliverable)

What this project shows an employer

Microsoft Fabric (DP-600)

Microsoft Fabric (DP-600)

1. What Microsoft Fabric Actually Is

2. The Lakehouse vs. the Warehouse

3. Loading Data — The Medallion Architecture

4. Querying and Modeling

5. Securing and Governing

6. How DP-600 Compares to PL-300

7. Final Thoughts

Power BI (PL-300)

Power BI (PL-300)

1. What Power BI Actually Is

2. Preparing Data with Power Query

3. Modeling Data (Star Schema & Relationships)

4. Calculating with DAX

5. Visualizing and Analyzing

6. Managing and Securing (Power BI Service)

7. Final Thoughts

Agentic AI

Agentic AI

1. What Is Agentic AI?

2. Why It Matters Now

3. How Agentic Systems Work

4. Single Agent vs. Multi-Agent

5. Real-World Use Cases

6. Frameworks & Tools

7. Challenges & Risks

8. Opportunity & Threat — Two Sides of the Same Coin

9. Where I Think This Is Going

ONWRD - A fitness mobile app

1. What is ONWRD?

2. Why I Built It

3. Core Features & Plans

📊 Superset Dashboards

4. Tech Stack

5. What I Learned

6. What’s Next

SQL RLS Rule

PostgreSQL Row-Level Security (RLS)

1. What is RLS?

2. How It Works

3. Policy Types

4. Real-World Example: Multi-Tenant App

5. Admin / Service Role Bypass

6. RLS with Supabase

7. RLS in Apache Superset

8. Testing RLS Policies

9. Performance Considerations

10. Common Pitfalls

11. Summary

Deep dive into analysis

📊 Stock Analysis Workflow

Table of Contents

1. System Architecture Overview

2. Step 1 — Ticker Selection

How It Works

Screener Columns Pulled

QuantStats Metrics (from `2022-01-01`)

Database Record (`tk_selected` table)