initial repo setup
This commit is contained in:
@@ -0,0 +1,279 @@
|
||||
# Autonomous Enterprise Portfolio
|
||||
## Initial architecture
|
||||
|
||||
**Document:** `ARCHITECTURE.md`
|
||||
**Status:** First draft — conceptual architecture; not an implementation specification
|
||||
**Established:** September 16, 2026
|
||||
**Owner / architecture authority:** Ken Schaefer
|
||||
**Companion documents:** [`VISION.md`](VISION.md) · [`PORTFOLIO.md`](PORTFOLIO.md) · [`PROJECT-PLAN.md`](PROJECT-PLAN.md)
|
||||
|
||||
> **Build once. Launch rapidly. Validate with a sale. Operate, replicate, or sell.**
|
||||
|
||||
## 1. Purpose and scope
|
||||
|
||||
This document describes the **business factory** that supports a portfolio of complementary, AI-enabled ventures. The factory provides reusable capabilities; each venture retains a clear identity, its own commercial hypothesis, and a practical path to independent operation, licensing, sale, or retirement.
|
||||
|
||||
The architecture must help us test whether AI and assets already under our control can compress time to launch, time to first sale, incremental capital, and required routine owner labor. It is **not** a prerequisite to building the first venture. We will implement only the boundaries and capabilities required by active experiments, then extract reusable parts from working solutions.
|
||||
|
||||
**In scope:** portfolio and venture boundaries; shared business services; responsibilities and authorization; information, evidence, and financial attribution; integration and deployment patterns; lifecycle, portability, and migration; first two proofs of concept.
|
||||
|
||||
**Out of scope for this draft:** finalized cloud or local topology, selected agent framework, product database schema, vendor subscriptions, legal-entity structure for future acquisitions, detailed staffing, and assumptions that unbuilt systems are already running. Those decisions belong in canvases, work orders, and architecture decision records (ADRs) when supported by actual requirements.
|
||||
|
||||
## 2. Architectural drivers and governing constraints
|
||||
|
||||
| Driver | Architectural consequence |
|
||||
|---|---|
|
||||
| First genuine arm's-length sale with collected revenue > $0 is the **only initial commercial pass/fail KPI** | Each venture has a payment/attribution path and evidence record; operational metrics remain diagnostics, not substitute success criteria. |
|
||||
| Launch quickly at low **incremental** cost | Reuse existing lab, business facilities, and IP; avoid platform-building ahead of a purchasable offer. |
|
||||
| Approximately 70% speculative effort, while preserving near-term acquisition | Prioritize Opportunity Intelligence and the Egypt media POC in parallel with existing-income follow-through. |
|
||||
| One factory, many experiments | Common services expose replaceable interfaces; each venture has logical and financial boundaries from inception. |
|
||||
| Owner remains involved by choice | Automate repetitive research and operations; reserve meaningful product, creative, relationship, investment, and consequential decisions for Ken. |
|
||||
| Commercial complementarity without forced coupling | Share audiences, production, or IP through explicit relationships; allow a venture to survive without another venture's channel or platform. |
|
||||
| Lab-first, cloud-ready when justified | Model commercial hosting costs during planning; isolate experimental workloads; design a reproducible migration path. |
|
||||
| Optional operate / replicate / license / sell / retire outcomes | Maintain an identifiable inventory of IP, data, code, customers, financial records, contracts, and third-party dependencies. |
|
||||
|
||||
**Design rule:** the cost of separation must not overwhelm the cost of experimentation. Logical boundaries are mandatory; duplicate legal entities, cloud accounts, or full technology stacks are not.
|
||||
|
||||
## 3. Context and business boundaries
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
K[Ken: owner and governance] --> PM[Portfolio management]
|
||||
PM --> FAC[Shared business factory]
|
||||
FAC --> OI[Opportunity Intelligence]
|
||||
FAC --> SD[Sales Development]
|
||||
FAC --> PROD[Research and production]
|
||||
FAC --> ADMIN[Finance and administration support]
|
||||
FAC --> ENG[Engineering, AI and deployment]
|
||||
OI --> V1[Employment and contract channel]
|
||||
OI --> V2[Fractional Insight ecosystem]
|
||||
SD --> V2
|
||||
PROD --> V3[Withered Sanctum ecosystem]
|
||||
ENG --> V4[Future independent ventures]
|
||||
ADMIN --> V2
|
||||
ADMIN --> V3
|
||||
ADMIN --> V4
|
||||
V2 -. opt-in commercial adjacency .-> V4
|
||||
V3 -. opt-in audience and IP adjacency .-> V4
|
||||
```
|
||||
|
||||
The diagram shows **responsibility and potential dependencies**, not deployed software, completed integrations, or a requirement that each box be an agent. Employment and contract acquisition is an income channel, not automatically a separately transferable business. Fractional Insight CIO, LLC is an existing commercial asset; the future legal structure of other ventures is undecided.
|
||||
|
||||
### 3.1 Portfolio management
|
||||
|
||||
Portfolio management owns the venture register, priority, authorized effort and incremental cash ceilings, experiment clocks, review dates, commercial evidence, and decisions to continue, redesign, operate, sell, or retire. Ken is the investment and exception authority. AI may prepare briefs and proposed decisions, but cannot silently authorize a new venture or commitment.
|
||||
|
||||
### 3.2 Business units and ecosystems
|
||||
|
||||
An **ecosystem** groups commercially adjacent ventures, but does not erase their boundaries.
|
||||
|
||||
- **Fractional Insight:** existing consulting and Gaussian relationship, new-client acquisition, narrow AI services, and potential software/products arising from demonstrated customer problems.
|
||||
- **Withered Sanctum:** Ancient Egypt media POC, Pyramid and related original publishing, and potential future games or interactive products.
|
||||
- **Additional ventures:** admitted through a short canvas, explicit priority and authorization; no permanent restriction to the two initial ecosystems.
|
||||
|
||||
A YouTube channel, media-production service, Pyramid publishing product, and prospective game may be different assets or ventures even when they share a brand. Define the commercial boundary in the canvas rather than assume one entity owns or transfers everything.
|
||||
|
||||
### 3.3 Shared factory
|
||||
|
||||
The factory provides reusable capabilities to ventures through explicit inputs, outputs, access rules, cost attribution, and documented dependencies. Shared services must not become indispensable black boxes that prevent a venture from operating or being sold independently.
|
||||
|
||||
## 4. Logical capability architecture
|
||||
|
||||
| Capability | Responsibility | Initial status / priority | Boundary |
|
||||
|---|---|---|---|
|
||||
| Portfolio governance and evidence | Canvas, venture register, approvals, gates, actual receipts and decisions | P0 minimal records | Portfolio-wide; Ken authorizes |
|
||||
| Opportunity Intelligence | Independently discover, deduplicate, qualify, and report employment, contract, and FI opportunities | **P0 first shared automation** | Internal research and brief; no autonomous applications or outreach |
|
||||
| Existing-income follow-through | Applications, proposals, Gaussian and FI follow-up | **P0 ongoing human activity** | Ken authorizes external actions |
|
||||
| Egypt media production | Research, source dossier, script, assets, rendering, metadata and performance observations | **P0 venture POC** | Ken approves publication and editorial claims |
|
||||
| Sales Development | Prospect research, tailored drafts, pipeline and follow-up preparation | P1 | No unsolicited sends without approved scope and permissions |
|
||||
| Product/AI-service fulfillment | Scope, intake, production, acceptance, delivery | P1, driven by paid offer | Venture-specific deliverable and customer obligations |
|
||||
| Finance and administration | Invoice preparation, cost/receipt tagging, obligations, receivables and reporting | Minimal records at P0; fuller service later | Authoritative accounting stays in approved systems; no autonomous money movement |
|
||||
| Engineering, AI and deployment | Reusable model access, automation execution, configuration and releases | Build only what active POCs need | Controlled environment and release permissions |
|
||||
| Asset and exit management | Rights/dependencies inventory, export and recovery procedures | Minimal inventory at birth; P2 hardening | No assumption that contracts/accounts/data can transfer |
|
||||
|
||||
A capability can be implemented by existing software, a deterministic workflow, an AI agent, a person, or a combination. **Organization chart ≠ agent inventory.** Choose the simplest reliable execution form when designing each bounded process.
|
||||
|
||||
## 5. Execution and autonomy model
|
||||
|
||||
### 5.1 Separate decision-making from execution
|
||||
|
||||
1. **Deterministic software/workflows:** use for repeatable rules, scheduling, deduplication where exact, accounting arithmetic, file conversion, rendering, and recording state.
|
||||
2. **AI-assisted steps:** use for interpretation-heavy research, qualification, drafting, script development, and proposals. Require source references and explicit uncertainty where material.
|
||||
3. **Human steps:** use for portfolio allocations, major product choices, consequential editorial decisions, customer commitments, and other actions requiring authorization.
|
||||
|
||||
A production pipeline can mix all three; no mandate to introduce a multi-agent framework or custom interface for the first POC.
|
||||
|
||||
### 5.2 Authority matrix — initial default
|
||||
|
||||
| Action | Default authority |
|
||||
|---|---|
|
||||
| Research permitted sources and create internal opportunity or topic briefs | May run unattended within approved access, scope, rate, and budget |
|
||||
| Draft scripts, outreach, applications, proposals, or invoices | May prepare; not equivalent to sending or committing |
|
||||
| Publish a video or product; submit an application; send customer-facing outreach | Ken approval before action unless a narrower explicit future delegation is recorded |
|
||||
| Accept contracts, make promises, spend money, issue refunds, change live production, or grant access | Explicit authorized human decision and appropriate system controls |
|
||||
| Stop a failed experiment | Ken investment decision; automation may flag deadline and prepare closure checklist |
|
||||
|
||||
Record authority expansions per workflow: permitted actions, environment, accounts, spending/rate limits, escalation rules, rollback where available, and audit evidence. The system must not report a proposed or drafted action as completed.
|
||||
|
||||
### 5.3 Bounded autonomy progression
|
||||
|
||||
`ASSISTED → DELEGATED → SUPERVISED → BOUNDED OPERATIONAL AUTONOMY`
|
||||
|
||||
Advance a specific workflow only after demonstrating adequate quality, repeatability, exception handling, access control, and observability. The aim is to remove **required routine labor**, not to exclude Ken from enjoyable or valuable work.
|
||||
|
||||
## 6. Minimum venture contract and information architecture
|
||||
|
||||
Every activated experiment receives a **venture ID** and a short canvas. The minimum logical record includes:
|
||||
|
||||
| Area | Minimum information |
|
||||
|---|---|
|
||||
| Identity | Venture ID, ecosystem, owner, offer/brand, stage and responsible decision-maker |
|
||||
| Market | Buyer, problem, current alternative, proposed value, acquisition channel and commercial adjacencies |
|
||||
| Validation | Authorized kickoff (D0), build and acquisition assumptions, maximum sale window, next review date, first-sale evidence rule |
|
||||
| Budget | Incremental cash ceiling, owner-time allocation, actual spending and labor; shared costs attributed transparently |
|
||||
| Commercial | Payment mechanism, transaction reference, payer evidence, collected amount and date, refunds, fees, earned vs. unearned/restricted receipts, obligations |
|
||||
| Assets | Repository/content location, domain/brand, original and third-party IP, licenses, data classification, customers, configuration and secrets ownership |
|
||||
| Deployment | Environment, dependencies, backup/recovery needs, production-cost estimate, migration economics and safety requirements |
|
||||
| Exit | Export, independent-operation dependencies, contract/account/data transfer constraints, customer closure duties and asset disposition |
|
||||
|
||||
**Systems of record:** do not duplicate authoritative payments or financial accounts inside an agent's memory. QuickBooks and payment-provider records are existing business assets; specific connector/API availability and accounting integration remain to be verified. The venture evidence log references authoritative transactions and preserves only the data needed for attribution and decisions, never payment credentials. Customer and candidate information is accessible only to workflows with a legitimate purpose.
|
||||
|
||||
**Suggested evidence flow:** `source / order → captured reference → verified state → venture attribution → portfolio review`. Maintain provenance for sources, generated assets, and claims where relevant. A channel's audience metrics, draft invoice, pledge, or unpaid booking must not be presented as a qualifying collected sale.
|
||||
|
||||
## 7. Integration and modularity rules
|
||||
|
||||
1. **Explicit interfaces.** Record each shared service's inputs, outputs, errors, permissions, and owner. Start with documented file or API contracts; introduce message brokers only if an actual use case requires them.
|
||||
2. **Venture-scoped configuration and data.** At minimum use separate identifiers, access boundaries, repositories/content areas or namespaces, secrets, and financial tags. Do not assume every venture needs a separate database or infrastructure account.
|
||||
3. **Replaceable dependencies.** A venture should be able to replace shared inference, workflow automation, checkout, or hosting using documented configuration/data export rather than rewriting its product from scratch. Absolute provider independence is not required for a seven-day POC; known lock-in must be recorded.
|
||||
4. **Provenance and rights.** Record sources, original work, generated/third-party assets, licenses, attribution/disclosure requirements, and rights retained by the parent or licensed to the venture.
|
||||
5. **No accidental cross-venture data sharing.** A shared AI or CRM capability does not grant one venture permission to use another venture's customer records, proprietary materials, or prospect data.
|
||||
6. **Extract after repetition.** On the first use, solve the concrete problem with a separable implementation. After a second justified use, consider promoting it to a shared service. This is a heuristic, not a mandatory numeric gate.
|
||||
7. **Shutdown must be possible.** Maintain enough dependency and obligation information to stop an experiment without breaking another venture or abandoning customers.
|
||||
|
||||
### 7.1 Asset ownership and possible sale
|
||||
|
||||
Keep a **venture asset register** distinguishing owned assets, shared/factory-owned assets, licensed assets, and third-party accounts or services. A potential buyer must be able to understand what is included and what must be replaced or newly contracted. A sale is never assumed to include the entire Pyramid IP, other channels, central AI platform, or FI customer base by default. Transferability remains subject to actual rights, consent, platform rules, and buyer interest.
|
||||
|
||||
## 8. Deployment architecture and cloud migration economics
|
||||
|
||||
### 8.1 Existing capacity and deployment posture
|
||||
|
||||
Available starting assets: home lab with static IP, firewall, reverse proxy and virtualization; public-facing Docker server; Forge / Gateway / Oracle AI triad; local-model capability and Project Thoth engineering work. These are **available assets, not evidence that a new portfolio application or agent is deployed**.
|
||||
|
||||
The intended initial posture is **lab-first** for suitable experiments. Keep experimental workloads isolated from personal information, existing revenue services, and one another. Use least-privilege accounts, managed secrets, appropriate backups, updates, restore tests commensurate with obligations, and constrained public exposure. Confirm actual capacity and environment boundaries during the relevant implementation work order.
|
||||
|
||||
A proposed logical placement—not a verified deployment—is:
|
||||
|
||||
- **Forge:** development and human-directed engineering work.
|
||||
- **Gateway / public Docker capacity:** appropriate application, automation, and serving workloads after security/capacity review.
|
||||
- **Oracle:** local AI inference, subject to existing resource and access constraints.
|
||||
|
||||
These assignments reflect the existing triad's broad roles; concrete hostnames, networks, ports, containers, and access paths are **TBD**, not defined here. A public service does not automatically belong on a specific machine.
|
||||
|
||||
### 8.2 Cloud affordability floor
|
||||
|
||||
Each software venture's canvas will price a **fit-for-purpose** Azure, DigitalOcean, or alternative production design during planning. Estimate compute, storage, network/egress, backups, managed dependencies, monitoring, support, and per-customer usage as applicable. Quote actual provider pricing when selecting the design; do not assume a generic cloud price.
|
||||
|
||||
For a simple subscription model:
|
||||
|
||||
`Contribution/customer = collected price/customer − variable cost/customer`
|
||||
|
||||
`Break-even active paying customers = ceiling(monthly fixed production costs ÷ contribution/customer)`
|
||||
|
||||
This calculation requires positive contribution/customer and adjustments for refunds, taxes as applicable, variable usage, payment fees, migration spending and cash reserve. A one-time migration must be fundable separately; for irregular revenue use a conservative dependable-contribution estimate rather than a single exceptional month.
|
||||
|
||||
**Migration decision = affordability AND operational justification.** Affordability sets the economic floor; capacity, availability expectations, security, privacy, recovery, or customer commitments supply the reason to move. If the lab cannot safely fulfill a product's current obligations, narrow/pause the offer or fund an appropriate environment earlier. Early Access is not an exemption from those obligations.
|
||||
|
||||
### 8.3 Portability package (incremental)
|
||||
|
||||
For a venture that approaches commercial operation or sale, assemble: reproducible build/deployment instructions; sanitized configuration example; dependency and license inventory; backup/restore and export procedure; domains/accounts inventory; operating runbook; and outstanding customer obligations. Do not build a complete migration platform for unvalidated experiments.
|
||||
|
||||
## 9. Lifecycle and experiment gates
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
P[Propose and authorize] --> B[Build usable offer]
|
||||
B --> L[Launch and acquire]
|
||||
L --> G{Collected first sale in window?}
|
||||
G -->|Yes| R[Review further investment]
|
||||
G -->|No; adequately resourced| F[Fail current hypothesis]
|
||||
G -->|Resources unavailable| D[Explicitly defer]
|
||||
R --> O[Operate / expand / license / offer for sale]
|
||||
F --> X[Retire / archive / explicit redesign]
|
||||
D --> P
|
||||
O --> A[Preserve reusable assets and evidence]
|
||||
X --> A
|
||||
```
|
||||
|
||||
The first sale is the **only initial commercial pass/fail KPI**. A pass permits an investment decision, not automatic scaling, profitability, or autonomy. The seven-day Egypt publication is an **operational** milestone and the $10,000 gross collected in the first 30 days is an ambitious **stretch outcome**, neither a replacement for the first-sale gate. Employment and Gaussian have their different first-paycheck and incremental-revenue rules as specified in `PORTFOLIO.md`.
|
||||
|
||||
Each experiment must have a recorded D0, adequately resourced validation window, intermediate reviews, incremental ceilings, and an exit/fulfillment procedure. Never silently extend an experiment, infer an unverified sale, or label a deferred effort a commercial failure.
|
||||
|
||||
## 10. Initial implementation slices and boundaries
|
||||
|
||||
### Slice A — Opportunity Intelligence (W1, P0)
|
||||
|
||||
**Purpose:** independently find, deduplicate, qualify, and organize employment, short-term contract, and FI client opportunities, so Ken spends attention on decisions and relationships rather than repetitive discovery.
|
||||
|
||||
**Minimum flow:** approved source → retrieve permitted listings/material → capture source link, date and provenance → deduplicate → compare with approved criteria and career/service source material → produce actionable brief and pipeline record → Ken reviews and selects action.
|
||||
|
||||
**Initial acceptance:** a repeatable discovery cycle produces current, actionable, deduplicated findings that Ken can verify and use. False positives, missed source access, owner time and actual downstream actions are diagnostics. Sending applications or outreach is **not** implied by research autonomy. Data sources, credentials, matching method, reporting destination, cadence, and actual stack remain **TBD for D0**.
|
||||
|
||||
### Slice B — Ancient Egypt media (W2, P0)
|
||||
|
||||
**Purpose:** prove rapid original video production using repeatable tooling and establish a potential audience for Withered Sanctum/Pyramid-related products.
|
||||
|
||||
**Minimum flow:** editorial topic → sourced research dossier and claim list → original script → licensed/original production assets and rights log → narration and repeatable render → factual/rights/quality review → Ken publication approval → publish and preserve URL/artifacts → collect performance and commercial attribution separately.
|
||||
|
||||
**Initial acceptance:** one original publicly published video with verifiable URL, source/rights evidence, reproducible production steps, actual incremental cost and owner hours within the authorized seven-day sprint target. This proves operational launch, **not** revenue. The first attributable qualifying paid transaction is the separate commercial gate. Channel/account access, topic, creative format, exact rendering and publishing tools, and adjacent product remain **TBD for the business canvas**.
|
||||
|
||||
### Slice C — Existing revenue and next opportunities (W3/W4, P0/P1)
|
||||
|
||||
Maintain live contract/job/client follow-through; prepare Sales Development by reusing the opportunity pipeline. Gaussian growth is measured against the already-paying baseline, not a first-ever sale. No additional shared CRM, autonomous sales agent, or invoice integration is assumed completed.
|
||||
|
||||
### Slice D — First narrow AI service or SaaS (W6/W7, P1)
|
||||
|
||||
Select an offer and buyer first. Provide a purchasable or pilot-ready product with a valid payment path, fulfillment terms, venture attribution, and cloud cost estimate if software. Do **not** wait for full autonomous operation, elaborate SaaS scaffolding, or a second media channel to make the first sale.
|
||||
|
||||
## 11. Observability, economics, and portfolio review
|
||||
|
||||
Every active experiment reports a compact weekly record:
|
||||
|
||||
- **Commercial gate:** qualifying paid sale (`YES / NO / NOT YET DUE`), verified payment reference, date, amount, product and venture attribution; separate refunds, fees, pledges/prepayments and outstanding fulfillment.
|
||||
- **Execution diagnostics:** authorization/build/launch dates, actual human hours, incremental spend, defects, deliverables, source or publication links, and remaining obligations.
|
||||
- **Decision state:** next gate/deadline, approved remaining cash/time, issues requiring Ken, and an explicit `CONTINUE / OPERATE / REDESIGN / DEFER / RETIRE` (or proposed sale/license) decision.
|
||||
|
||||
Operational dashboards, views, agent telemetry and sales analytics are **later implementation choices**. For the first sprint, a durable Markdown or appropriately controlled structured register with source references is sufficient. The financial source of truth must remain reconcilable with payment and accounting records.
|
||||
|
||||
## 12. Architecture decisions and open questions
|
||||
|
||||
The following are **not decided** by this draft. Record material choices as short ADRs with context, choice, tradeoffs, date, owner, and reversal path.
|
||||
|
||||
| Decision / question | Needed by | Current status |
|
||||
|---|---|---|
|
||||
| D0, actual weekly hours, incremental cash limits and owners | Sprint authorization | TBD |
|
||||
| Opportunity sources, access method, report destination, eligibility criteria and approved unattended scope | W1 D0 | TBD |
|
||||
| Egypt channel account/brand, first topic, source standard, rights inventory and production tools | W2 D0 | TBD |
|
||||
| Venture register/evidence store and authoritative transaction references | W0/D0 | Minimal format TBD |
|
||||
| Which services are shared versus venture-specific after actual second use | As reuse emerges | Defer design |
|
||||
| Workflow orchestrator, LLM/model selection, agent framework, and connectors | Per implementation work order | No portfolio-wide mandate |
|
||||
| Cloud provider, actual deployment topology, cost floor and migration reserve | Per software canvas | Estimate before selling; verify before migration |
|
||||
| SaaS buyer, product, customer-data classification and offer terms | W7 canvas | Unknown |
|
||||
| Intellectual property and legal ownership boundaries for media, Pyramid, and potential asset sales | Before commitments/transfer | Verify and document |
|
||||
| Customer-funded development suitability, obligations, refunds and accounting treatment | Per venture canvas | Evaluate; do not assume funding |
|
||||
|
||||
## 13. Document map and next actions
|
||||
|
||||
- [`VISION.md`](VISION.md): founding thesis and non-negotiable principles.
|
||||
- [`PORTFOLIO.md`](PORTFOLIO.md): uncertainty, allocation, priorities, windows, commercial gates and venture register policy.
|
||||
- [`PROJECT-PLAN.md`](PROJECT-PLAN.md): workstreams, first seven days and 90-day roadmap.
|
||||
- `PROJECT-CHARTER.md`: **proposed, not presumed created**; authority and investment limits.
|
||||
- `canvases/EGYPT-MEDIA.md` and `canvases/OPPORTUNITY-INTELLIGENCE.md`: **proposed** D0 business/process canvases.
|
||||
- `logs/EXPERIMENT-REGISTER.md`: **proposed** record of actual kickoffs, receipts, evidence and decisions.
|
||||
- ADRs, work orders, runbooks and per-venture repositories: create only when their first real use justifies them.
|
||||
|
||||
**Next architecture task:** approve the minimum venture/evidence record and the two P0 canvas boundaries. Then execute W1 and W2 in parallel while maintaining W3. Record actual technology choices from those builds and revise this draft rather than treating its conceptual boxes as deployed components.
|
||||
|
||||
---
|
||||
|
||||
**Architecture principle:** Shared where it creates leverage; separate where it preserves accountability, customer trust, and the freedom to operate, replicate, license, sell, or retire.
|
||||
@@ -0,0 +1,887 @@
|
||||
# Autonomous Enterprise Portfolio
|
||||
|
||||
## Enterprise Model
|
||||
|
||||
**Document:** `ENTERPRISE-MODEL.md`
|
||||
**Status:** Initial baseline
|
||||
**Established:** September 18, 2026
|
||||
**Owner:** Ken Schaefer
|
||||
**Applies to:** Autonomous Enterprise Portfolio
|
||||
**Related documents:** `VISION.md`, `PORTFOLIO.md`, `PROJECT-PLAN.md`, `PROJECT-CHARTER.md`, `ARCHITECTURE.md`
|
||||
|
||||
> **Build once. Launch rapidly. Validate with a sale. Operate, replicate, or sell.**
|
||||
|
||||
---
|
||||
|
||||
# 1. Purpose
|
||||
|
||||
The Autonomous Enterprise Portfolio is intended to create and operate a portfolio of businesses using reusable AI-enabled operational capabilities.
|
||||
|
||||
The portfolio therefore contains two fundamentally different kinds of assets:
|
||||
|
||||
1. **Products / Businesses**
|
||||
2. **Shared Services**
|
||||
|
||||
This distinction governs:
|
||||
|
||||
* project organization;
|
||||
* source repositories;
|
||||
* requirements and architecture;
|
||||
* ownership of work product;
|
||||
* commercial validation;
|
||||
* reuse;
|
||||
* automation;
|
||||
* deployment;
|
||||
* eventual licensing or sale.
|
||||
|
||||
The purpose of this document is to define that distinction and provide a durable enterprise structure for future projects.
|
||||
|
||||
The enterprise should identify the **business function first, automation second, and software third**.
|
||||
|
||||
Technology exists to support an operating business model. The existence of an agent, workflow, or application does not itself establish a business or justify a separate project.
|
||||
|
||||
---
|
||||
|
||||
# 2. Core Enterprise Model
|
||||
|
||||
The Autonomous Enterprise Portfolio consists of:
|
||||
|
||||
```text
|
||||
Autonomous Enterprise Portfolio
|
||||
│
|
||||
├── Products / Businesses
|
||||
│
|
||||
│ ├── Fractional Insight
|
||||
│ ├── Withered Sanctum
|
||||
│ ├── Pyramid
|
||||
│ └── Future businesses and products
|
||||
│
|
||||
└── Shared Services
|
||||
├── Sales & Marketing Operations
|
||||
├── Finance & Administration
|
||||
├── Research & Knowledge Services
|
||||
├── Production Services
|
||||
├── Technology Operations
|
||||
└── Future shared capabilities
|
||||
```
|
||||
|
||||
Products and businesses create external customer value and revenue.
|
||||
|
||||
Shared services exist to make those products and businesses more effective, efficient, autonomous, measurable, or scalable.
|
||||
|
||||
---
|
||||
|
||||
# 3. Products / Businesses
|
||||
|
||||
## 3.1 Definition
|
||||
|
||||
A **Product / Business** is an independently identifiable commercial activity intended to produce customer value and revenue.
|
||||
|
||||
A product or business may be:
|
||||
|
||||
* an operating company;
|
||||
* a consulting practice;
|
||||
* a media company;
|
||||
* a publication;
|
||||
* a software product;
|
||||
* a SaaS offering;
|
||||
* a game;
|
||||
* a digital product;
|
||||
* a service;
|
||||
* another independently marketable venture.
|
||||
|
||||
A product exists because customers may directly purchase, subscribe to, license, fund, or otherwise economically support it.
|
||||
|
||||
---
|
||||
|
||||
## 3.2 Characteristics
|
||||
|
||||
A Product / Business should have identifiable:
|
||||
|
||||
* customers or audience;
|
||||
* value proposition;
|
||||
* revenue mechanism;
|
||||
* brand or product identity;
|
||||
* commercial hypothesis;
|
||||
* assets and intellectual property;
|
||||
* source materials;
|
||||
* configuration;
|
||||
* financial attribution;
|
||||
* operating requirements;
|
||||
* commercial validation criteria;
|
||||
* lifecycle;
|
||||
* potential path to independent operation, licensing, or sale.
|
||||
|
||||
---
|
||||
|
||||
## 3.3 Commercial Validation
|
||||
|
||||
Products and businesses are subject to the portfolio's commercial validation principle.
|
||||
|
||||
The initial commercial KPI is:
|
||||
|
||||
> **One genuine, arm's-length sale with collected revenue greater than $0 within the approved validation window.**
|
||||
|
||||
Exceptions may exist for income channels such as employment, where the equivalent cash event is explicitly defined.
|
||||
|
||||
Publishing, audience growth, prototypes, expressions of interest, or completed development do not replace the first-sale requirement.
|
||||
|
||||
---
|
||||
|
||||
## 3.4 Source Project Rule
|
||||
|
||||
Each standalone Product / Business receives its own formal source project.
|
||||
|
||||
A product source project contains the **entire body of work required to operate, reproduce, maintain, develop, and potentially transfer the product**, not merely conventional software source code.
|
||||
|
||||
Examples may include:
|
||||
|
||||
* source code;
|
||||
* research;
|
||||
* requirements;
|
||||
* scripts;
|
||||
* manuscripts;
|
||||
* narration;
|
||||
* voice models or profiles;
|
||||
* images;
|
||||
* music;
|
||||
* audio;
|
||||
* video project source;
|
||||
* production templates;
|
||||
* product files;
|
||||
* design materials;
|
||||
* data;
|
||||
* configuration;
|
||||
* documentation;
|
||||
* operating procedures;
|
||||
* deployment assets;
|
||||
* test assets;
|
||||
* provenance records.
|
||||
|
||||
Large binary artifacts may reside in an appropriate external asset store when Git is not suitable, provided that the project clearly documents where they reside and how they relate to the product.
|
||||
|
||||
---
|
||||
|
||||
# 4. Shared Services
|
||||
|
||||
## 4.1 Definition
|
||||
|
||||
A **Shared Service** is a reusable internal business capability that supports one or more Products / Businesses.
|
||||
|
||||
A shared service does not need to produce revenue directly.
|
||||
|
||||
Its value comes from improving the businesses that consume it.
|
||||
|
||||
Examples include:
|
||||
|
||||
* finding opportunities;
|
||||
* qualifying sales leads;
|
||||
* preparing outreach;
|
||||
* managing pipeline information;
|
||||
* supporting accounting;
|
||||
* generating narration;
|
||||
* performing research;
|
||||
* deploying applications;
|
||||
* maintaining infrastructure;
|
||||
* preparing financial reporting.
|
||||
|
||||
---
|
||||
|
||||
## 4.2 Shared-Service Value
|
||||
|
||||
A shared service should be evaluated according to the value it creates for its consumers.
|
||||
|
||||
Relevant measures may include:
|
||||
|
||||
* owner time eliminated or reduced;
|
||||
* opportunities discovered;
|
||||
* errors avoided;
|
||||
* response time improved;
|
||||
* administrative work reduced;
|
||||
* production throughput increased;
|
||||
* operating cost reduced;
|
||||
* availability improved;
|
||||
* business continuity improved;
|
||||
* downstream revenue supported.
|
||||
|
||||
A shared service is not required to have its own first-sale KPI unless it later becomes a standalone commercial product.
|
||||
|
||||
---
|
||||
|
||||
## 4.3 Shared Service Does Not Mean "Agent"
|
||||
|
||||
A shared service may be implemented by:
|
||||
|
||||
* an AI agent;
|
||||
* conventional software;
|
||||
* a deterministic workflow;
|
||||
* an external application;
|
||||
* an integration;
|
||||
* a documented manual process;
|
||||
* a combination of these.
|
||||
|
||||
The implementation method is an architectural decision.
|
||||
|
||||
A business function should not be converted into an AI agent merely because automation is possible.
|
||||
|
||||
---
|
||||
|
||||
## 4.4 Shared Source Project
|
||||
|
||||
Shared business services should reside within a common formal source project rather than creating a separate repository for every automated business function.
|
||||
|
||||
Working name:
|
||||
|
||||
**AEP Shared Services**
|
||||
|
||||
Conceptual structure:
|
||||
|
||||
```text
|
||||
AEP-Shared-Services/
|
||||
│
|
||||
├── .project/
|
||||
│
|
||||
├── opportunity-intelligence/
|
||||
├── sales-development/
|
||||
├── marketing/
|
||||
├── finance/
|
||||
├── research/
|
||||
├── production/
|
||||
├── technology-operations/
|
||||
├── common/
|
||||
└── ...
|
||||
```
|
||||
|
||||
The shared project provides common ownership, standards, infrastructure, and reusable components while allowing individual services to retain clean technical boundaries.
|
||||
|
||||
A shared repository must not become a monolithic application.
|
||||
|
||||
Each service should maintain:
|
||||
|
||||
* clear responsibility;
|
||||
* documented interfaces;
|
||||
* independent tests;
|
||||
* configuration boundaries;
|
||||
* understandable dependencies;
|
||||
* separable implementation where practical.
|
||||
|
||||
---
|
||||
|
||||
# 5. Business Capability Structure
|
||||
|
||||
The initial shared-service domains are:
|
||||
|
||||
## 5.1 Sales & Marketing Operations
|
||||
|
||||
Potential capabilities include:
|
||||
|
||||
* Opportunity Intelligence;
|
||||
* lead discovery;
|
||||
* lead qualification;
|
||||
* sales research;
|
||||
* prospect research;
|
||||
* outreach preparation;
|
||||
* follow-up;
|
||||
* pipeline management;
|
||||
* marketing operations;
|
||||
* content-distribution support;
|
||||
* sales reporting.
|
||||
|
||||
### Current capability
|
||||
|
||||
**W1 — Opportunity Intelligence**
|
||||
|
||||
Classification:
|
||||
|
||||
**Shared Service**
|
||||
|
||||
Initial consumer:
|
||||
|
||||
**Fractional Insight and owner income-acquisition activity**
|
||||
|
||||
W1 is intended to locate and qualify employment, consulting, contract, procurement, and other relevant opportunities.
|
||||
|
||||
---
|
||||
|
||||
# 6. Finance & Administration
|
||||
|
||||
Potential capabilities include:
|
||||
|
||||
* accounting support;
|
||||
* transaction review;
|
||||
* invoice preparation;
|
||||
* receivables monitoring;
|
||||
* expense classification;
|
||||
* financial reporting;
|
||||
* cash-flow reporting;
|
||||
* administrative workflow;
|
||||
* tax-preparation support;
|
||||
* records management.
|
||||
|
||||
### Current activity
|
||||
|
||||
**W9 — QuickBooks Reconciliation & Business Accounting**
|
||||
|
||||
W9 currently consists primarily of operational accounting work.
|
||||
|
||||
QuickBooks reconciliation itself is not automatically a software product or agent project.
|
||||
|
||||
If reusable accounting automation is later developed, that capability belongs under:
|
||||
|
||||
**Shared Services → Finance & Administration**
|
||||
|
||||
The architecture may conclude that existing software plus human procedure is the appropriate implementation.
|
||||
|
||||
Automation is not a required outcome.
|
||||
|
||||
---
|
||||
|
||||
# 7. Research & Knowledge Services
|
||||
|
||||
Potential capabilities include:
|
||||
|
||||
* research assistance;
|
||||
* source retrieval;
|
||||
* source provenance;
|
||||
* knowledge-base retrieval;
|
||||
* document analysis;
|
||||
* summarization;
|
||||
* evidence management;
|
||||
* reusable business knowledge.
|
||||
|
||||
Project Thoth may provide capabilities in this area.
|
||||
|
||||
Thoth should be treated as an existing platform or dependency where appropriate, not as the automatic home for every new AI capability.
|
||||
|
||||
A service belongs in Project Thoth only when its core purpose is aligned with Thoth's knowledge, archival, reasoning, or information-management mission.
|
||||
|
||||
---
|
||||
|
||||
# 8. Production Services
|
||||
|
||||
Potential reusable capabilities include:
|
||||
|
||||
* text-to-speech;
|
||||
* voice generation;
|
||||
* audio processing;
|
||||
* image generation;
|
||||
* media transformation;
|
||||
* rendering;
|
||||
* publication packaging;
|
||||
* transcription;
|
||||
* caption generation;
|
||||
* production automation.
|
||||
|
||||
Reusable capabilities should generally be extracted into Shared Services only after demonstrated reuse.
|
||||
|
||||
The portfolio should avoid prematurely converting every production technique discovered inside a product into generalized infrastructure.
|
||||
|
||||
---
|
||||
|
||||
# 9. Technology Operations
|
||||
|
||||
Potential capabilities include:
|
||||
|
||||
* deployment;
|
||||
* CI/CD;
|
||||
* application hosting;
|
||||
* model hosting;
|
||||
* inference services;
|
||||
* backups;
|
||||
* monitoring;
|
||||
* secrets management;
|
||||
* networking;
|
||||
* infrastructure automation;
|
||||
* environment management.
|
||||
|
||||
Existing Forge, Gateway, Oracle, Gitea, and related infrastructure may support this service domain.
|
||||
|
||||
Technology operations should remain replaceable and documented so that individual products can eventually operate independently if required.
|
||||
|
||||
---
|
||||
|
||||
# 10. Current Product / Business Classification
|
||||
|
||||
## 10.1 Fractional Insight
|
||||
|
||||
**Classification:** Product / Business
|
||||
|
||||
Fractional Insight is an existing consulting and professional-services business.
|
||||
|
||||
It is currently a primary consumer of Shared Services.
|
||||
|
||||
Examples include:
|
||||
|
||||
* Opportunity Intelligence;
|
||||
* sales support;
|
||||
* marketing;
|
||||
* accounting;
|
||||
* financial reporting;
|
||||
* technology operations.
|
||||
|
||||
Fractional Insight's consulting work and customer relationships remain distinct from the shared operating capabilities used to support them.
|
||||
|
||||
---
|
||||
|
||||
## 10.2 Withered Sanctum Media / Ancient Egypt
|
||||
|
||||
**Classification:** Product / Business
|
||||
|
||||
W2 is not a shared service.
|
||||
|
||||
W2 is an effort to create a media business.
|
||||
|
||||
The Ancient Egypt media experiment includes:
|
||||
|
||||
* original historical media;
|
||||
* a publishing presence;
|
||||
* research and editorial assets;
|
||||
* narration;
|
||||
* production assets;
|
||||
* potential companion publications;
|
||||
* potential commercial products;
|
||||
* audience development;
|
||||
* revenue experiments.
|
||||
|
||||
It therefore requires its own formal source project.
|
||||
|
||||
---
|
||||
|
||||
## 10.3 Pyramid
|
||||
|
||||
**Classification:** Product / Intellectual Property ecosystem
|
||||
|
||||
Pyramid is an existing creative and commercial intellectual-property asset.
|
||||
|
||||
It may interact with Withered Sanctum media, publishing, games, and other future products.
|
||||
|
||||
Those relationships should be explicit rather than assumed.
|
||||
|
||||
---
|
||||
|
||||
# 11. Product Work May Produce Shared Services
|
||||
|
||||
A Product / Business may create reusable capabilities during implementation.
|
||||
|
||||
This does not automatically make those capabilities Shared Services.
|
||||
|
||||
The preferred process is:
|
||||
|
||||
```text
|
||||
Product need
|
||||
↓
|
||||
Product-specific implementation
|
||||
↓
|
||||
Demonstrated successful use
|
||||
↓
|
||||
Second legitimate reuse requirement
|
||||
↓
|
||||
Evaluate extraction into Shared Services
|
||||
```
|
||||
|
||||
This follows the portfolio principle:
|
||||
|
||||
> **Extract reusable services from demonstrated use rather than building generalized infrastructure in advance.**
|
||||
|
||||
---
|
||||
|
||||
# 12. Example — W2 Narration
|
||||
|
||||
The Ancient Egypt project may use Qwen3-TTS and the Pyramid Narrator voice.
|
||||
|
||||
These represent two different asset types.
|
||||
|
||||
### Pyramid Narrator
|
||||
|
||||
The specific voice identity, voice files, reference audio, creative description, and canonical narrator configuration are **Withered Sanctum product assets**.
|
||||
|
||||
They belong with the media product.
|
||||
|
||||
### Generic TTS capability
|
||||
|
||||
The generalized capability:
|
||||
|
||||
```text
|
||||
text
|
||||
↓
|
||||
selected voice profile
|
||||
↓
|
||||
local TTS generation
|
||||
↓
|
||||
audio output
|
||||
```
|
||||
|
||||
may eventually become a Shared Production Service if multiple products legitimately require it.
|
||||
|
||||
Until that reuse requirement exists, W2 should be free to implement narration locally within its own product project.
|
||||
|
||||
---
|
||||
|
||||
# 13. Formal Source Projects
|
||||
|
||||
The portfolio recognizes two primary repository patterns.
|
||||
|
||||
## 13.1 Shared Service Project
|
||||
|
||||
One formal project contains reusable internal operating services.
|
||||
|
||||
Example:
|
||||
|
||||
```text
|
||||
AEP-Shared-Services/
|
||||
```
|
||||
|
||||
Individual capabilities may have their own internal project-control folders where their complexity justifies it.
|
||||
|
||||
---
|
||||
|
||||
## 13.2 Product Project
|
||||
|
||||
Each independently identifiable Product / Business receives its own formal source project.
|
||||
|
||||
Examples:
|
||||
|
||||
```text
|
||||
Fractional-Insight/
|
||||
Withered-Sanctum-Media/
|
||||
Pyramid/
|
||||
Future-Product-X/
|
||||
```
|
||||
|
||||
Project names and repositories should reflect actual commercial and ownership boundaries rather than implementation technology.
|
||||
|
||||
---
|
||||
|
||||
# 14. Universal `.project/` Standard
|
||||
|
||||
Every formal AEP source project will contain:
|
||||
|
||||
```text
|
||||
.project/
|
||||
```
|
||||
|
||||
The `.project/` directory is the project's management and architectural control plane.
|
||||
|
||||
It serves the same purpose conceptually that `.thoth/` serves within Project Thoth, while providing a portfolio-wide convention independent of product or technology.
|
||||
|
||||
---
|
||||
|
||||
# 15. Purpose of `.project/`
|
||||
|
||||
The `.project/` directory answers:
|
||||
|
||||
* Why does this project exist?
|
||||
* What problem are we solving?
|
||||
* What does success mean?
|
||||
* What are we building?
|
||||
* How is it architected?
|
||||
* How long are we willing to build it?
|
||||
* What is its commercial or operational validation window?
|
||||
* What is currently being worked on?
|
||||
* What decisions have been made?
|
||||
* What work is authorized next?
|
||||
|
||||
A person opening an unfamiliar AEP project in VS Code should be able to begin with `.project/` and quickly understand the project's state.
|
||||
|
||||
---
|
||||
|
||||
# 16. Standard `.project/` Contents
|
||||
|
||||
The initial standard is:
|
||||
|
||||
```text
|
||||
.project/
|
||||
│
|
||||
├── REQUIREMENTS.md
|
||||
├── ARCHITECTURE.md
|
||||
├── PROJECT-PLAN.md
|
||||
├── STATUS.md
|
||||
│
|
||||
├── DECISIONS/
|
||||
│
|
||||
└── WORK-ORDERS/
|
||||
```
|
||||
|
||||
Additional project-management artifacts may be added only when useful.
|
||||
|
||||
The objective is rigorous project control without unnecessary process overhead.
|
||||
|
||||
---
|
||||
|
||||
# 17. Required Project Documents
|
||||
|
||||
Every substantive formal project requires:
|
||||
|
||||
## `REQUIREMENTS.md`
|
||||
|
||||
Defines:
|
||||
|
||||
* business problem;
|
||||
* users;
|
||||
* functional requirements;
|
||||
* non-functional requirements;
|
||||
* success criteria;
|
||||
* exclusions;
|
||||
* operational value;
|
||||
* commercial value where applicable.
|
||||
|
||||
---
|
||||
|
||||
## `ARCHITECTURE.md`
|
||||
|
||||
Defines:
|
||||
|
||||
* project boundary;
|
||||
* product/service classification;
|
||||
* components;
|
||||
* information flows;
|
||||
* interfaces;
|
||||
* dependencies;
|
||||
* deployment;
|
||||
* security;
|
||||
* human interface;
|
||||
* replaceability;
|
||||
* technology decisions.
|
||||
|
||||
---
|
||||
|
||||
## `PROJECT-PLAN.md`
|
||||
|
||||
Defines:
|
||||
|
||||
* development window;
|
||||
* validation window;
|
||||
* phases;
|
||||
* milestones;
|
||||
* work packages;
|
||||
* dependencies;
|
||||
* testing;
|
||||
* implementation order;
|
||||
* measurable progress;
|
||||
* stop/review conditions.
|
||||
|
||||
---
|
||||
|
||||
# 18. Value Gates
|
||||
|
||||
Every project's Requirements, Architecture, and Project Plan must prominently state its value gates.
|
||||
|
||||
There are two categories.
|
||||
|
||||
---
|
||||
|
||||
## 18.1 Development Value Gate
|
||||
|
||||
The project must define:
|
||||
|
||||
> **How long are we willing to spend making this capability or product usable?**
|
||||
|
||||
This is a central AEP experiment.
|
||||
|
||||
The enterprise is specifically testing whether AI can materially reduce the effort and elapsed time required to create businesses and business capabilities.
|
||||
|
||||
A technically successful project may still fail this experiment if its development cost or duration is excessive relative to its value.
|
||||
|
||||
The development window must therefore be explicit and time-boxed.
|
||||
|
||||
---
|
||||
|
||||
## 18.2 Commercial / Operational Value Gate
|
||||
|
||||
### Products / Businesses
|
||||
|
||||
Must define a commercial validation window.
|
||||
|
||||
The normal initial KPI is:
|
||||
|
||||
> One qualifying sale with collected revenue greater than $0.
|
||||
|
||||
---
|
||||
|
||||
### Shared Services
|
||||
|
||||
Must define an operational validation criterion.
|
||||
|
||||
This may include:
|
||||
|
||||
* repeatable execution;
|
||||
* human effort saved;
|
||||
* opportunities found;
|
||||
* business tasks completed;
|
||||
* errors reduced;
|
||||
* throughput increased;
|
||||
* downstream revenue enabled.
|
||||
|
||||
Shared Services are not required to invent artificial internal revenue.
|
||||
|
||||
---
|
||||
|
||||
# 19. SDLC Standard
|
||||
|
||||
Software implementation may begin only after the project has sufficient approved requirements, architecture, and project planning to bound the work.
|
||||
|
||||
For code-bearing projects, environment setup includes:
|
||||
|
||||
1. Create the appropriate repository in Gitea.
|
||||
2. Initialize or clone the project on Forge.
|
||||
3. Open the repository in VS Code.
|
||||
4. Establish `.project/`.
|
||||
5. Establish the approved source structure.
|
||||
6. Verify version control and remote connectivity.
|
||||
7. Begin implementation through approved work orders.
|
||||
|
||||
---
|
||||
|
||||
# 20. Development Roles
|
||||
|
||||
The standard development relationship is:
|
||||
|
||||
## ChatGPT — AppDev Manager / Technical Lead
|
||||
|
||||
Responsible for:
|
||||
|
||||
* requirements refinement;
|
||||
* architecture;
|
||||
* project planning;
|
||||
* work orders;
|
||||
* acceptance criteria;
|
||||
* review;
|
||||
* technical management.
|
||||
|
||||
ChatGPT does not directly act as the source-code implementation engineer in the established workflow.
|
||||
|
||||
---
|
||||
|
||||
## Ken — Senior Architect / Owner
|
||||
|
||||
Responsible for:
|
||||
|
||||
* architecture authority;
|
||||
* business decisions;
|
||||
* design approval;
|
||||
* implementation supervision;
|
||||
* operating VS Code;
|
||||
* reviewing Codex output;
|
||||
* supplying results and observations back to ChatGPT;
|
||||
* accepting or rejecting completed work.
|
||||
|
||||
---
|
||||
|
||||
## Codex — Implementation Engineer / Junior Programmer
|
||||
|
||||
Responsible for:
|
||||
|
||||
* implementing approved work orders;
|
||||
* writing and modifying source code;
|
||||
* creating tests;
|
||||
* running verification;
|
||||
* reporting implementation results.
|
||||
|
||||
Implementation does not redefine project requirements or architecture without review.
|
||||
|
||||
---
|
||||
|
||||
# 21. Source-Code Quality
|
||||
|
||||
Generated code must emphasize maintainability.
|
||||
|
||||
Required characteristics include:
|
||||
|
||||
* human-readable organization;
|
||||
* meaningful names;
|
||||
* generous whitespace;
|
||||
* explanatory comments where useful;
|
||||
* clear boundaries;
|
||||
* understandable modules;
|
||||
* documented configuration;
|
||||
* automated tests where appropriate;
|
||||
* predictable folder organization.
|
||||
|
||||
Test-driven development is preferred.
|
||||
|
||||
Working code is not considered successful solely because it executes or passes automated tests.
|
||||
|
||||
The human owner must be able to understand and maintain the system.
|
||||
|
||||
---
|
||||
|
||||
# 22. Human Interface Principle
|
||||
|
||||
Automated systems must remain usable by humans.
|
||||
|
||||
Every agent-based project must initially provide a human-operable interface.
|
||||
|
||||
This will normally be:
|
||||
|
||||
* a web application/dashboard; or
|
||||
* a visible workflow where a workflow engine is the natural execution environment.
|
||||
|
||||
Internal JSON files, run directories, databases, logs, or generated Markdown may serve as evidence and audit records but should not constitute the primary user experience.
|
||||
|
||||
---
|
||||
|
||||
# 23. Current Classification of Active Sprint 0 Work
|
||||
|
||||
| Workstream | Classification | Project relationship |
|
||||
| ------------------------------ | -------------------------------- | --------------------------------------------------------------- |
|
||||
| W1 — Opportunity Intelligence | **Shared Service** | Sales & Marketing Operations within AEP Shared Services |
|
||||
| W2 — Ancient Egypt Media | **Product / Business** | Withered Sanctum media product |
|
||||
| W9 — QuickBooks Reconciliation | **Business Operations Activity** | May produce future Finance & Administration shared capabilities |
|
||||
|
||||
These classifications supersede any previous implication that W1, W2, and W9 are equivalent kinds of projects.
|
||||
|
||||
---
|
||||
|
||||
# 24. Immediate Structural Decisions
|
||||
|
||||
## W1
|
||||
|
||||
The Opportunity Intelligence requirements effort should continue.
|
||||
|
||||
Its architecture should proceed on the assumption that:
|
||||
|
||||
* W1 is a Shared Service;
|
||||
* its initial consumer is Fractional Insight / owner income acquisition;
|
||||
* it belongs conceptually within AEP Shared Services;
|
||||
* the existing implementation spike is feasibility evidence and may be reused or refactored;
|
||||
* its final placement and internal boundaries must be formalized in `W1-ARCHITECTURE.md`.
|
||||
|
||||
---
|
||||
|
||||
## W2
|
||||
|
||||
The Ancient Egypt media effort must become a formal Product / Business project.
|
||||
|
||||
Its repository should contain the source materials and operating assets required to reproduce and continue the media business.
|
||||
|
||||
Its project documents should live under `.project/`.
|
||||
|
||||
---
|
||||
|
||||
## W9
|
||||
|
||||
QuickBooks reconciliation may continue as operational business work.
|
||||
|
||||
No accounting-agent or software effort should begin until a specific reusable business capability has been identified and justified.
|
||||
|
||||
If such automation is later created, it should reside within AEP Shared Services under Finance & Administration.
|
||||
|
||||
---
|
||||
|
||||
# 25. Enterprise Principle
|
||||
|
||||
The Autonomous Enterprise Portfolio is not a collection of unrelated agents.
|
||||
|
||||
It is a portfolio of **revenue-producing products and businesses supported by reusable shared business services**.
|
||||
|
||||
Shared Services exist to make Products more capable.
|
||||
|
||||
Products exist to create customer value and economic return.
|
||||
|
||||
Architecture, repositories, automation, and project controls must preserve that distinction.
|
||||
|
||||
---
|
||||
|
||||
**Enterprise rule:**
|
||||
|
||||
> **Define the business. Identify the shared capabilities it needs. Automate where automation creates measurable value. Build software only after the capability is bounded.**
|
||||
@@ -0,0 +1,509 @@
|
||||
# Autonomous Enterprise Portfolio
|
||||
## Initial portfolio and investment priorities
|
||||
|
||||
**Document:** `PORTFOLIO.md`
|
||||
**Status:** Initial planning baseline — estimates, not commitments or forecasts
|
||||
**Established:** September 16, 2026
|
||||
**Owner:** Ken Schaefer
|
||||
**Companion document:** [`VISION.md`](VISION.md)
|
||||
|
||||
> **Build once. Launch rapidly. Validate with a sale. Operate, replicate, or sell.**
|
||||
|
||||
## 1. Purpose and decision scope
|
||||
|
||||
This document translates the founding vision into an initial **register of income channels and experiments**, priorities, effort allocation, first-sale gates, and portfolio decision rules. It is not a detailed implementation plan, an approved spending authorization, or a forecast of earnings. `VISION.md` governs the principles; future business canvases and `PROJECT-PLAN.md` will define individual work and dependencies.
|
||||
|
||||
The initiating experiment asks whether AI, existing infrastructure, and reusable business capabilities can compress the time and incremental capital required to launch and commercialize businesses. The extraordinary revenue claims that inspired it are **unverified**. We will test our own outcomes rather than adopt those claims as assumptions.
|
||||
|
||||
**Portfolio mandate:** Preserve near-term revenue acquisition while committing approximately **70% of available effort to speculative opportunities**. Prefer experiments that reinforce one another, but do not confuse shared infrastructure with independent market demand.
|
||||
|
||||
## 2. Measurement and interpretation
|
||||
|
||||
### 2.1 Definitions
|
||||
|
||||
- **Uncertainty, 1–5:** A qualitative planning judgment about whether a channel will produce meaningful *additional* collected income in its window. `1` = lower uncertainty; `5` = very high uncertainty. It is **not** a numerical success probability, a measure of downside financial risk, or a comparison of personal worth.
|
||||
- **Build horizon:** Estimated time to make a real offer/product available. **Acquisition horizon:** Estimated time after a viable offer exists to obtain a buyer or payer. Neither is a promise. Where we lack evidence, horizons remain **TBD** rather than invented.
|
||||
- **Maximum validation window:** The decision deadline, measured from an explicit experiment start recorded in its business canvas. It includes build and customer acquisition unless that canvas deliberately defines a different clock. Calendar deadlines will be set when work is actually authorized and resourced.
|
||||
- **Qualifying first sale:** At least one genuine, arm's-length transaction with **more than $0 of collected revenue** attributable to the experimental offer within its window. Record gross cash receipts separately from refunds, expenses, tax, deferred revenue, and outstanding obligations. An unpaid order, a pledge, a waitlist, or a promotional exchange is not a collected sale. Crowdfunding, preorder, and subscription receipts require separate classification and recognition of obligations.
|
||||
- **Initial commercial result:** `PASS` if the qualifying sale occurs by the deadline; otherwise `FAIL — current hypothesis`, followed by a decision to retire, archive, or explicitly redesign. A pass earns **consideration**, not automatic scaling capital. A deferred or under-resourced experiment must be labeled `DEFERRED`, not silently recorded as a failed completed test.
|
||||
- **Priority:** `P0` = initiate now, `P1` = prepare next / alongside capacity, `P2` = retain as a later candidate. Priority does not imply funding or operational readiness.
|
||||
|
||||
**Only initial commercial pass/fail KPI: first qualifying sale.** Build time, acquisition time, audience metrics, production cost, customer satisfaction, human effort, and potential exit value are diagnostic measures and later-stage investment criteria, not substitutes for that gate. For an already paying channel, test *incremental* paid business rather than its first historical sale.
|
||||
|
||||
### 2.2 Planning uncertainty and horizon register
|
||||
|
||||
The ratings and ranges below are **working estimates from our discussion**, not researched market statistics. A `+` means the outcome may take longer or may never occur. The maximum window is a management decision, not a prediction.
|
||||
|
||||
| Channel / experiment | Uncertainty | Build horizon | Customer / payer acquisition horizon | Maximum initial window | Complexity | Priority | First commercial gate |
|
||||
|---|---:|---|---|---:|---|---|---|
|
||||
| Traditional employment | 3/5 | Applications and materials: TBD | TBD | **48 weeks** | Medium | P0 | First paycheck from a new position. |
|
||||
| Short-term contract | 3/5 | Offer / application readiness: TBD | TBD | **12 weeks** | Medium | P0 | First collected payment from a new contract. |
|
||||
| Gaussian expansion | 3/5 | Additional funded scope: TBD | TBD | **24 weeks** | Medium | P0 | First collected payment for **additional** work beyond the existing baseline. |
|
||||
| New Fractional Insight client | 4/5 | Targeted offer: TBD | TBD | **24 weeks** | Medium | P0 | First collected payment from a new client. |
|
||||
| AI service business | 4/5 | A narrow paid offer: target in weeks | TBD | **24 weeks** | High | P1 | First collected AI-service order for the test offer. |
|
||||
| Ancient Egypt media / publishing | 5/5 | **7-day video/production POC target** | TBD | **52 weeks** | High | P0 | First collected revenue **attributable to this ecosystem**; identify the specific mechanism. |
|
||||
| Narrow SaaS product | 5/5 | **4-week first-sale stretch target**, product TBD | TBD | **52 weeks** | Very high | P1 | First paying customer for a usable product. |
|
||||
| Standalone digital publication | 4/5 | Small release: TBD | TBD | **24 weeks** | Medium | P1 | First paid publication purchase. |
|
||||
|
||||
**Interpretation:** The four-week SaaS target is an ambition to put a usable offer in the market *and seek* a sale, not a prediction that a complete autonomous SaaS platform can be built in four weeks. The Egypt seven-day target tests operational launch, **not** whether the first sale or advertising eligibility will occur in seven days. A 52-week outer window does not authorize 52 weeks of uninterrupted spending: shorter checkpoints and investment ceilings will govern continuation.
|
||||
|
||||
**Gaussian baseline:** The existing relationship has already generated **more than $8,000 in 2026**. Its incremental-growth gate does not erase that established revenue. Routine existing paid work continues to be tracked as baseline cash flow, not miscounted as a new experiment's success.
|
||||
|
||||
**Employment exception:** Employment is an income channel, not a sellable venture. A 48-week failure ends or redesigns that search strategy; it does not prove that employment is impossible or require rejecting a subsequent suitable opportunity.
|
||||
|
||||
## 3. Effort allocation and rebalancing
|
||||
|
||||
The original proposed allocation was 20% jobs/contracts, 10% Gaussian/new clients, 40% YouTube, and 30% SaaS. It expresses the deliberate **70% speculative** posture but omits an explicit AI-service allocation and treats YouTube and SaaS as separate bets even where they may share an audience or product.
|
||||
|
||||
**Initial proposed allocation — subject to approval in `PROJECT-PLAN.md`:**
|
||||
|
||||
| Effort bucket | Share | Classification | Immediate use |
|
||||
|---|---:|---|---|
|
||||
| Employment and short-term contracts | **20%** | Near-term acquisition | Opportunity discovery, qualification, tailored applications and proposals. |
|
||||
| Existing Gaussian growth + new FI clients | **10%** | Existing-business development | Incremental scope, prospecting, sales conversations. |
|
||||
| AI service experiments | **15%** | Speculative | Test a narrowly bounded paid offer; automate fulfillment only where useful. |
|
||||
| Ancient Egypt media + adjacent publishing | **35%** | Speculative | Seven-day production POC and first-revenue test; prepare a small related product. |
|
||||
| Narrow SaaS discovery / paid-product experiment | **20%** | Speculative | Find a buyer/problem, validate an offer, test a minimal paid product. |
|
||||
| **Total** | **100%** | **70% speculative / 30% near-term** | |
|
||||
|
||||
This is an **effort allocation**, not a revenue allocation, a cash budget, or a promise to work a fixed number of hours. AI-generated work does not consume Ken's working hours in the same way, but setup, verification, and exception handling do. Record actual owner time separately from machine runtime. The P0 Opportunity Intelligence effort serves the employment/contract and FI acquisition buckets; it is **shared infrastructure**, not an additional sixth bucket that makes the percentages exceed 100%.
|
||||
|
||||
**Rebalancing rules:**
|
||||
|
||||
1. Protect an explicit minimum of effort for immediate cash-generating opportunities while short-term obligations remain unresolved. Rebalance based on **collected cash and evidence**, not simply elapsed time.
|
||||
2. Reallocate from experiments that miss a milestone, exceed their approved incremental budget, or fail their first-sale gate; do not continue merely because work has already been invested.
|
||||
3. A first sale permits a new investment decision, not an automatic increase in allocation.
|
||||
4. Do not count complementary products as independent diversification when they rely on the same audience, platform, customer, or distribution channel.
|
||||
5. If a funded client engagement or urgent cash need materially changes capacity, revise the allocation explicitly and record experiments as deferred where appropriate.
|
||||
|
||||
## 4. Initial ecosystems and adjacent products
|
||||
|
||||
### 4.1 Withered Sanctum — Ancient Egypt, Pyramid, and publishing
|
||||
|
||||
**Anchor experiment:** An original Ancient Egypt video and repeatable AI-supported media-production workflow. The channel can develop an audience for **Pyramid** tabletop products, adventures, sourcebooks, maps, game assets, memberships, and potentially a game adaptation. A small purchasable digital product may precede advertising income; advertising stays on the long-term revenue-mechanism list.
|
||||
|
||||
**Complementarity hypothesis:** Historical research and storytelling produce both media and source material for original products; product development creates material for videos. We will measure actual attributable transactions rather than presume viewers become purchasers. A large video-game project is a **future option**, not a dependency of the first media POC. Pyramid's prior publication/sales demonstrate historical execution, not current demand.
|
||||
|
||||
**Potential independent units:** Channel/media catalog; Pyramid tabletop IP and product catalog; digital publishing; future game. Design ownership, branding, rights, and accounts so that one unit can potentially be licensed or sold without automatically transferring all related IP.
|
||||
|
||||
### 4.2 Fractional Insight — consulting, AI services, and software
|
||||
|
||||
**Anchor cash-flow activities:** Existing Gaussian work, contract acquisition, and the next consulting client. **Anchor enabling capability:** Shared Opportunity Intelligence, followed by Sales Development and business-administration support.
|
||||
|
||||
**Adjacent experiments:** Published AI-service offers can become narrow automated-fulfillment products. Real client problems may suggest a paid template, workflow, tool, or SaaS. A technology media channel is a possible distribution mechanism **only when it serves a coherent buyer and offer**; it is not automatically a separate P0 initiative.
|
||||
|
||||
**Legal and commercial foundation:** Fractional Insight CIO, LLC has an EIN, business bank account, QuickBooks, and credit-card processing. Early ventures can use shared administrative services with identifiable venture-level revenue, expenses, assets, and obligations. Verify suitability for each new activity rather than assume all contracts, licenses, data, or accounts are transferable.
|
||||
|
||||
### 4.3 Opportunity pool beyond the two initial ecosystems
|
||||
|
||||
Keep a discoverable idea backlog for niche publications, information services, games, small software utilities, and other AI-native ventures. Ideas are **not active projects** until assigned an owner, short canvas, validation window, resource ceiling, and portfolio allocation. The factory should allow many cheap tests without inadvertently creating hundreds of unsupported operating obligations.
|
||||
|
||||
## 5. Prioritized initial efforts
|
||||
|
||||
| Priority | Effort | Intended outcome | Evidence / deliverable | Boundaries and dependencies |
|
||||
|---|---|---|---|---|
|
||||
| **P0** | Establish portfolio governance | Make experiments comparable and governable | `VISION.md`, this register, initial charter and 90-day project plan | Keep documentation lightweight; no prolonged planning gate. |
|
||||
| **P0** | Opportunity Intelligence | Independently find, qualify, and organize employment, contract, and FI opportunities | Working discovery pipeline with actionable findings for Ken to review | No unauthorized applications, outreach, commitments, or payments. |
|
||||
| **P0** | Ancient Egypt production POC | Test rapid launch and repeatable media operations | Publish **one original video within seven days of authorized kickoff**; record steps, costs, and owner effort | Editorial verification, rights, and platform compliance; a publication is not a sale. |
|
||||
| **P0** | Existing revenue follow-through | Preserve cash acquisition while experiments run | Active contract/job pipeline, Gaussian expansion conversations, new-client prospect activity | Existing Gaussian revenue is baseline; incremental growth requires new paid work. |
|
||||
| **P1** | Sales Development | Research qualified prospects and prepare tailored sales work | Prospect pipeline, outreach drafts and follow-up workflow | Approval and applicable contact/platform rules before sending. |
|
||||
| **P1** | First Egypt-adjacent product | Make a small, useful item purchasable | Scoped Pyramid-related product, checkout path, separate sales attribution | Avoid full game/video-game build as initial dependency. |
|
||||
| **P1** | Narrow AI-service offer | Test first paid, reliably fulfillable order | Offer, delivery criteria, first-sale tracking | Do not build an entire autonomous organization before selling. |
|
||||
| **P1** | SaaS opportunity discovery | Identify buyer, painful problem, and smallest paid solution | Short canvas, customer evidence, proposed paid pilot or minimal product | Four-week first-sale stretch; no speculative platform build without a buyer hypothesis. |
|
||||
| **P1** | Funding options | See whether customers can fund development earlier | Kickstarter / Patreon / preorder / paid-pilot suitability in relevant canvases | Count funding by type; account for fees, refund and delivery obligations. |
|
||||
| **P2** | Shared business factory hardening | Reuse successful components across ventures | Documented workflow, data and service boundaries | Extract shared services from actual use; avoid premature agent proliferation. |
|
||||
| **P2** | Venture transfer / exit readiness | Make validated units independently operable, licensable, or sellable | Asset register, financial attribution, portability and rights checklist | Do not assume platform accounts or customer data can be transferred. |
|
||||
| **P2** | Additional channels / game adaptation | Replicate only tested capabilities | Approved new canvas and explicit investment gate | Do not scale production merely because it is cheap. |
|
||||
|
||||
**Parallelism:** P0 Opportunity Intelligence and the Egypt POC may proceed together. No SaaS implementation is a prerequisite for either. Business architecture should capture reusable patterns as they appear, while providing basic separation and safety from day one.
|
||||
|
||||
## 6. Initial experiments and their short-form canvases
|
||||
|
||||
Each initiative gets a one-page canvas before spending or external commitments. The **minimum fields** are:
|
||||
|
||||
1. Venture ID, ecosystem, owner, stage, and decision date.
|
||||
2. Customer, problem, current alternative, and usable offer.
|
||||
3. First revenue mechanism and attribution rule; how a genuine first sale will be verified.
|
||||
4. Build horizon, customer-acquisition horizon, explicit kickoff, maximum window, and intermediate review dates.
|
||||
5. Incremental cash ceiling, owner-time allocation, and dependencies on shared assets.
|
||||
6. Existing distribution/access, acquisition hypothesis, and commercial adjacencies.
|
||||
7. Early Access / paid pilot / preorder / Kickstarter / Patreon suitability; fees, refund and delivery obligations.
|
||||
8. Lab deployment requirements, estimated commercial-cloud deployment, affordability floor, and earlier safety/contractual migration triggers.
|
||||
9. Independently identifiable IP, customer data, brand, code, revenue and expenses; possible operate / license / sell / retire path.
|
||||
10. First-sale result, supporting evidence, actual costs and labor, and next investment decision.
|
||||
|
||||
**Avoid fake precision:** If a cost, target audience, acquisition rate, or horizon is not known, mark it `TBD`, state the test that would resolve it, and do not invent a probability.
|
||||
|
||||
## 7. Funding, hosting, and modularity policies
|
||||
|
||||
### 7.1 Lab first, with a cloud affordability floor
|
||||
|
||||
Use the existing home lab, public Docker infrastructure, Forge / Gateway / Oracle AI triad, and reusable software to minimize **incremental** spending. Existing committed expenditures are part of the standing cost base; incremental electricity, storage, usage charges, maintenance load, and human support attributable to an experiment still matter.
|
||||
|
||||
Every software canvas must model a fit-for-purpose production architecture on Azure, DigitalOcean, or another suitable provider. Its **cloud affordability floor** is the level of dependable contribution required to cover that incremental hosting and associated operating cost. In a simplified subscription case:
|
||||
|
||||
`Break-even paying customers = ceiling(monthly fixed production costs / contribution per paying customer)`
|
||||
|
||||
where `contribution per paying customer = collected price minus per-customer variable costs`, and fixed production costs must include the actual required hosting and other fixed expenses. If contribution per customer is zero or negative, adding customers cannot cover fixed costs. Include any incremental migration and support costs and a prudent cash reserve in the actual decision; positive monthly contribution alone does not fund a one-time migration.
|
||||
|
||||
**Floor ≠ automatic migration trigger.** Move when commercial infrastructure is economically supportable **and** business, resource, security, data, or customer commitments justify it. If safe operation requires moving sooner, fund that move or narrow/pause the offer; revenue cannot override baseline security or truthful customer commitments.
|
||||
|
||||
### 7.2 Early Access and customer funding
|
||||
|
||||
Offer a functional, presently useful product with honestly stated limitations; do not rely on promised future work for current value. Model paid pilots, preorders, crowdfunding, memberships, and other funding sources where suitable. Early Access does **not** eliminate customer obligations, refunds, privacy responsibilities, or platform terms.
|
||||
|
||||
Record separately: pledged funds, collected cash, recognized/earned revenue, refundable or restricted receipts, fees, and remaining fulfillment obligations. This prevents a successful funding campaign from being mistaken for unrestricted profit.
|
||||
|
||||
### 7.3 Modular from inception
|
||||
|
||||
Every venture should have a distinct ID and identifiable product, customer, IP, data, code/configuration, financial attribution, and operational documentation. Prefer portable data, documented interfaces, containerized or otherwise reproducible deployments, and replaceable shared services. Separate legal entities or full cloud stacks are **not** required for every cheap test. Do not commingle assets in ways that prevent a clean shutdown or a potential sale. Transferability is contingent on licenses, contracts, platform policies, privacy rights, and buyer interest.
|
||||
|
||||
## 8. Portfolio review and investment decisions
|
||||
|
||||
**Cadence:** A brief weekly portfolio review and a formal review at each experiment's stated milestone or deadline. Record decisions in this document or a linked register; do not assume an action occurred merely because it was planned.
|
||||
|
||||
**Weekly questions:**
|
||||
|
||||
- Has any channel produced a **new qualifying collected sale**? Which offer and payment mechanism produced it?
|
||||
- What is each experiment's actual stage, next gate, deadline, remaining cash ceiling, and required owner time?
|
||||
- What relevant opportunities did Opportunity Intelligence discover, and which did Ken choose to act on?
|
||||
- What evidence supports or weakens the customer hypothesis? Are there shared-market or platform dependencies?
|
||||
- Which reusable components or IP emerged? What new obligations would continuation create?
|
||||
|
||||
**Decision vocabulary:** `PROPOSED` → `AUTHORIZED` → `BUILDING` → `LIVE / SEEKING SALE` → `FIRST SALE VALIDATED` → `OPERATE / SCALE / LICENSE / SELL`; alternative outcomes: `DEFERRED`, `REDESIGN`, `RETIRED`. A sale does not itself imply profit or permission to scale.
|
||||
|
||||
**Stretch test, recorded separately:** A venture launched in **seven days** and generating **$10,000 in collected gross receipts over its first 30 operating days** would exceed our stretch target. Neither milestone is assumed, and neither replaces the first-sale pass/fail rule or financial accounting.
|
||||
|
||||
## 9. Immediate decisions and open items
|
||||
|
||||
**Established:** The founding vision; willingness to devote roughly 70% of effort to speculative activities; the first-sale gate; complementary ecosystems; modularity; lab-first economics; Opportunity Intelligence and Ancient Egypt as simultaneous initial priorities.
|
||||
|
||||
**Still to decide during planning:**
|
||||
|
||||
- Actual weekly hours, initial incremental spending ceiling, and the cash threshold for rebalancing.
|
||||
- Explicit kickoff dates, intermediate checkpoints, and business-canvas owners for each active experiment.
|
||||
- Ancient Egypt topic/format, initial product offer, publication/distribution workflow, and attribution method.
|
||||
- Opportunity Intelligence data sources, qualification rubric, reporting cadence, and access controls.
|
||||
- SaaS buyer/problem hypothesis and whether it belongs in the Fractional Insight or Withered Sanctum ecosystem.
|
||||
- Actual Azure / DigitalOcean deployment estimates and product-specific migration economics.
|
||||
- Which shared services genuinely need agents versus conventional software or deterministic workflows.
|
||||
|
||||
**Next governing artifacts:** `PROJECT-CHARTER.md`, `PROJECT-PLAN.md`, and concise business canvases for the Ancient Egypt POC and Opportunity Intelligence capability. `ARCHITECTURE.md` should document only the initial shared-service boundaries, then grow from demonstrated needs.
|
||||
|
||||
---
|
||||
|
||||
**Portfolio rule:** Make the offer real, seek a sale, record the result, and decide deliberately. Protect reusable assets and the ability to stop, operate, replicate, license, or sell each venture independently.
|
||||
|
||||
|
||||
# APPENDIX
|
||||
|
||||
## A: Additional Ideas
|
||||
|
||||
## Daily Briefing Engine
|
||||
|
||||
**Status:** Product Candidate — Discovery
|
||||
**Category:** Information Synthesis / Autonomous Workflows
|
||||
**Priority:** Unassigned — Pending Portfolio Evaluation
|
||||
**Business Model:** SaaS, Self-Hosted Software, B2B Licensing
|
||||
**Working Name:** Daily Briefing Engine
|
||||
|
||||
### Vision
|
||||
|
||||
A configurable AI-powered briefing engine that autonomously gathers information from multiple sources, synthesizes it into a personalized report, and delivers a finished artifact on a defined schedule.
|
||||
|
||||
The product transforms fragmented information into a coherent, actionable briefing without requiring the user to initiate a conversation, open multiple applications, or manually assemble information.
|
||||
|
||||
The guiding principle is:
|
||||
|
||||
> Autonomous work should produce useful artifacts, not merely autonomous conversations.
|
||||
|
||||
### Product Concept
|
||||
|
||||
The Daily Briefing Engine operates as a scheduled information-processing workflow.
|
||||
|
||||
It collects information from authorized sources, identifies relevant developments, organizes them according to the user's priorities, and produces a personalized briefing.
|
||||
|
||||
The initial inspiration is a daily newspaper generated overnight and delivered before the user wakes up.
|
||||
|
||||
However, the underlying product is independent of any particular presentation format.
|
||||
|
||||
Potential output formats include:
|
||||
|
||||
- Printable newspapers and PDF reports.
|
||||
- Email briefings.
|
||||
- Web dashboards.
|
||||
- Audio briefings.
|
||||
- E-ink displays.
|
||||
- Structured reports for downstream systems.
|
||||
|
||||
The newspaper is one possible product experience. The reusable briefing engine is the core intellectual property.
|
||||
|
||||
### Potential Markets and Product Editions
|
||||
|
||||
#### 1. Personal Briefing — Consumer SaaS
|
||||
|
||||
A personalized daily newspaper combining information from the user's digital life.
|
||||
|
||||
Potential content includes:
|
||||
|
||||
- Calendar and daily schedule.
|
||||
- Weather.
|
||||
- Important email.
|
||||
- Personal tasks and reminders.
|
||||
- Package tracking.
|
||||
- Curated news.
|
||||
- Personalized entertainment.
|
||||
|
||||
**Potential revenue model:** Monthly or annual subscription.
|
||||
|
||||
**Key uncertainty:** Consumer willingness to pay for a service that consolidates information already available through existing applications.
|
||||
|
||||
#### 2. Executive Briefing — Business SaaS
|
||||
|
||||
A daily operational briefing for business owners, executives, and managers.
|
||||
|
||||
Potential content includes:
|
||||
|
||||
- Business performance indicators.
|
||||
- Revenue and sales activity.
|
||||
- Customer commitments.
|
||||
- Outstanding decisions.
|
||||
- Project status.
|
||||
- Infrastructure and service alerts.
|
||||
- Upcoming meetings and deadlines.
|
||||
- Significant industry developments.
|
||||
|
||||
The objective is to reduce the time required to assemble operational information and identify matters requiring human attention.
|
||||
|
||||
**Potential revenue model:** Per-user, per-organization, or tiered subscription.
|
||||
|
||||
**Key uncertainty:** Whether the briefing provides sufficient measurable value to justify its subscription cost and integration requirements.
|
||||
|
||||
#### 3. Private Briefing — Self-Hosted Edition
|
||||
|
||||
A packaged application deployed within the customer's own infrastructure.
|
||||
|
||||
Potential characteristics include:
|
||||
|
||||
- Docker Compose deployment.
|
||||
- Local LLM support through Ollama or compatible inference services.
|
||||
- Optional frontier-model integration.
|
||||
- Customer-controlled data storage.
|
||||
- Configurable information sources.
|
||||
- Local document generation.
|
||||
- Configurable delivery mechanisms.
|
||||
|
||||
This edition aligns with Fractional Insight's Private & Sovereign AI service offering.
|
||||
|
||||
**Potential revenue model:** Software license, implementation services, maintenance, and support.
|
||||
|
||||
**Key uncertainty:** The cost of supporting diverse customer environments relative to licensing and service revenue.
|
||||
|
||||
#### 4. White-Label Briefing — B2B Licensing
|
||||
|
||||
A configurable briefing platform that consultants, agencies, and service providers can deploy under their own brands.
|
||||
|
||||
Potential applications include:
|
||||
|
||||
- Daily client intelligence reports.
|
||||
- Industry monitoring.
|
||||
- Portfolio management briefings.
|
||||
- Customer account summaries.
|
||||
- Operational status reports.
|
||||
|
||||
**Potential revenue model:** Licensing, usage-based pricing, or managed-service agreements.
|
||||
|
||||
**Key uncertainty:** Whether prospective partners prefer a packaged platform over custom reporting and automation solutions.
|
||||
|
||||
### Preliminary Architecture
|
||||
|
||||
The product should be designed as a modular application with replaceable components.
|
||||
|
||||
The initial architecture would comprise five functional stages.
|
||||
|
||||
#### 1. Information Acquisition
|
||||
|
||||
Collect information from authorized external and internal sources.
|
||||
|
||||
Potential integrations include email, calendars, RSS feeds, business applications, files, and structured APIs.
|
||||
|
||||
Each integration should be independently replaceable.
|
||||
|
||||
#### 2. Information Processing
|
||||
|
||||
Normalize collected information into a consistent internal representation.
|
||||
|
||||
Identify relevant changes, remove duplicates, and apply user-defined relevance criteria.
|
||||
|
||||
Preserve references to original sources where practical.
|
||||
|
||||
#### 3. Intelligence and Synthesis
|
||||
|
||||
Use an LLM to summarize, organize, and contextualize information.
|
||||
|
||||
The intelligence layer should support interchangeable inference providers.
|
||||
|
||||
Local and frontier models should use a common application interface wherever practical.
|
||||
|
||||
The system should distinguish source-derived facts from generated interpretation and avoid presenting unsupported claims as verified information.
|
||||
|
||||
#### 4. Presentation
|
||||
|
||||
Transform structured briefing content into a selected presentation format.
|
||||
|
||||
Presentation templates should be independent of the intelligence layer.
|
||||
|
||||
The initial implementation should favor HTML templates with PDF generation.
|
||||
|
||||
#### 5. Scheduling and Delivery
|
||||
|
||||
Execute the briefing workflow automatically according to a configurable schedule.
|
||||
|
||||
Provide delivery through supported channels.
|
||||
|
||||
Record execution status, errors, and delivery outcomes.
|
||||
|
||||
A failed information source should not necessarily prevent the remainder of the briefing from being produced.
|
||||
|
||||
### Architectural Principles
|
||||
|
||||
The product should follow the Autonomous Enterprise Portfolio's established engineering philosophy.
|
||||
|
||||
**Modularity:** Each functional component should be independently replaceable.
|
||||
|
||||
**Engine independence:** No mandatory dependency on a particular LLM provider.
|
||||
|
||||
**Local-AI-First:** Support local inference where technically and economically feasible.
|
||||
|
||||
**Standards first:** Prefer established protocols, formats, and frameworks over proprietary abstractions.
|
||||
|
||||
**Minimal infrastructure:** Avoid introducing distributed systems or complex orchestration before they are required.
|
||||
|
||||
**Data stewardship:** Access only authorized sources, minimize retained sensitive information, and provide appropriate controls over storage and deletion.
|
||||
|
||||
**Human agency:** Provide information and identify decisions requiring attention without assuming authority to make consequential decisions on the user's behalf.
|
||||
|
||||
**Artifact orientation:** The primary output is a completed briefing, not an interactive chat session.
|
||||
|
||||
### Minimum Viable Product
|
||||
|
||||
The first MVP should demonstrate the complete information-to-artifact workflow without attempting to support every proposed market.
|
||||
|
||||
#### Proposed MVP Scope
|
||||
|
||||
- Single-user application.
|
||||
- Two or three information sources.
|
||||
- Configurable briefing preferences.
|
||||
- Scheduled execution.
|
||||
- One interchangeable LLM interface.
|
||||
- Structured briefing generation.
|
||||
- One HTML-based newspaper template.
|
||||
- PDF output.
|
||||
- Local download or email delivery.
|
||||
- Basic execution logging and error handling.
|
||||
|
||||
The MVP should use a deterministic workflow with narrowly defined LLM operations rather than requiring a general-purpose autonomous agent framework.
|
||||
|
||||
#### Explicit MVP Exclusions
|
||||
|
||||
- Multi-tenant SaaS infrastructure.
|
||||
- Native mobile applications.
|
||||
- Complex visual template editors.
|
||||
- Audio generation.
|
||||
- Autonomous business actions.
|
||||
- Extensive integration catalogs.
|
||||
- Enterprise identity management.
|
||||
- White-label administration.
|
||||
|
||||
These capabilities should be considered only after product validation.
|
||||
|
||||
### Commercial Validation
|
||||
|
||||
Development should begin with a small experiment designed to establish whether the product solves a problem customers will pay to address.
|
||||
|
||||
#### Proposed Experiment
|
||||
|
||||
1. Build a minimal working briefing using existing automation and document-generation tools.
|
||||
2. Demonstrate it to a small number of prospective users.
|
||||
3. Identify which information sources and briefing sections they actually value.
|
||||
4. Test willingness to pay through a paid pilot or equivalent purchase commitment.
|
||||
5. Measure the operational cost of producing and delivering each briefing.
|
||||
|
||||
The experiment should evaluate both customer demand and delivery economics.
|
||||
|
||||
### Preliminary Unit Economics
|
||||
|
||||
The planning phase should establish a simple per-customer break-even model.
|
||||
|
||||
Potential costs include:
|
||||
|
||||
- LLM inference.
|
||||
- External API usage.
|
||||
- Hosting and storage.
|
||||
- Document generation.
|
||||
- Delivery services.
|
||||
- Customer support.
|
||||
- Payment processing.
|
||||
|
||||
The basic contribution calculation is:
|
||||
|
||||
Monthly Contribution per Customer =
|
||||
Monthly Revenue per Customer - Monthly Variable Cost per Customer
|
||||
|
||||
The initial break-even calculation is:
|
||||
|
||||
Break-Even Customers =
|
||||
Monthly Fixed Operating Costs / Monthly Contribution per Customer
|
||||
|
||||
The calculation should be performed separately for SaaS and self-hosted editions because their cost structures differ.
|
||||
|
||||
Development cost recovery should be modeled separately from operating break-even.
|
||||
|
||||
No pricing, margin, or break-even assumptions have yet been validated.
|
||||
|
||||
### Portfolio Strategy
|
||||
|
||||
The Daily Briefing Engine should be treated as a reusable product platform rather than four independent applications.
|
||||
|
||||
The consumer, executive, self-hosted, and white-label offerings should share a common core wherever feasible.
|
||||
|
||||
Product-specific differences should primarily reside in:
|
||||
|
||||
- Information-source configuration.
|
||||
- Briefing templates.
|
||||
- Deployment configuration.
|
||||
- Access controls.
|
||||
- Delivery options.
|
||||
- Commercial packaging.
|
||||
|
||||
This approach supports rapid experimentation across multiple markets while minimizing duplicated development.
|
||||
|
||||
If an individual edition becomes commercially viable, it should be possible to operate, expand, license, or sell that business without requiring ownership of unrelated portfolio products.
|
||||
|
||||
Shared intellectual property, licensing arrangements, and product boundaries must be established before pursuing independent business sales.
|
||||
|
||||
### Relationship to Project Thoth
|
||||
|
||||
Project Thoth may eventually provide reusable capabilities for information acquisition, provenance, synthesis, and model-independent inference.
|
||||
|
||||
However, the Daily Briefing Engine must not depend on the completion of Project Thoth.
|
||||
|
||||
The initial implementation should use existing tools and established standards.
|
||||
|
||||
Integration with Thoth should occur only when a demonstrated capability provides a practical advantage.
|
||||
|
||||
### Proposed Next Action
|
||||
|
||||
**Create a one-page opportunity brief and validate the concept before committing to full product development.**
|
||||
|
||||
The immediate objective is to establish:
|
||||
|
||||
1. A clearly defined initial customer.
|
||||
2. A specific briefing use case.
|
||||
3. A minimal demonstration.
|
||||
4. Evidence of willingness to pay.
|
||||
5. A preliminary operating-cost model.
|
||||
|
||||
The candidate should remain in Discovery until these questions have been addressed.
|
||||
|
||||
**Portfolio decision:** No development commitment or priority assignment has been made.
|
||||
@@ -0,0 +1,129 @@
|
||||
# Autonomous Enterprise Portfolio
|
||||
## Project charter — initial draft
|
||||
|
||||
**Document:** `PROJECT-CHARTER.md`
|
||||
**Status:** Draft for owner approval; not an authorization to spend, deploy, publish, solicit, or commence a sprint
|
||||
**Prepared:** September 16, 2026
|
||||
**Sponsor, owner, and final investment authority:** Ken Schaefer
|
||||
**Related documents:** [`VISION.md`](VISION.md) · [`PORTFOLIO.md`](PORTFOLIO.md) · [`PROJECT-PLAN.md`](PROJECT-PLAN.md) · [`ARCHITECTURE.md`](Projects/Autonomous%20Enterprise%20Portfolio/ARCHITECTURE.md)
|
||||
|
||||
> **Build once. Launch rapidly. Validate with a sale. Operate, replicate, or sell.**
|
||||
|
||||
## 1. Mandate
|
||||
|
||||
Establish an **Autonomous Enterprise Portfolio (AEP)**: a repeatable, modular way to discover, launch, commercially test, operate, license, sell, or responsibly retire complementary AI-enabled businesses using shared capabilities and assets already under our control. Test, rather than assume, claims that AI can compress the time, incremental cash, and owner labor needed to bring businesses to market. The viral claims that prompted the initiative—including a reported $1.2 million business built in roughly 30 minutes—are **unverified** and are not planning forecasts.
|
||||
|
||||
The initial work combines **revenue acquisition for existing channels** with **speculative venture experiments**. The first two P0 initiatives are Opportunity Intelligence and the Ancient Egypt media proof of concept. The latter targets a first original published video within seven days of an **explicitly authorized and resourced kickoff**; the stretch commercial challenge is $10,000 of collected gross receipts during its first 30 operating days. Neither milestone constitutes a forecast or a promise.
|
||||
|
||||
## 2. Charter outcomes and limits
|
||||
|
||||
AEP is intended to:
|
||||
|
||||
1. Maintain a transparent, prioritized register of revenue channels and venture experiments.
|
||||
2. Build a shared Opportunity Intelligence capability to independently discover and qualify employment, contract, and Fractional Insight opportunities for Ken to review and act upon.
|
||||
3. Test a repeatable AI-assisted media production and commercialization process through an Ancient Egypt channel and a potentially adjacent Pyramid-related product.
|
||||
4. Use observed customer problems to identify narrow AI-service, software, publishing, and other commercial experiments.
|
||||
5. Reuse common capabilities while preserving each venture's identifiable assets, finances, customer obligations, and potential path to separation or sale.
|
||||
6. Reduce *required routine operational labor* without eliminating Ken's voluntary involvement in products, relationships, creativity, and strategy.
|
||||
|
||||
**Not authorized by this charter:** any expenditure; subscriptions; access to private accounts or systems; outbound job applications, sales messages, or customer commitments; production deployments; public publication; customer-data processing; or an assumption that the full business factory must be built before the first sale. Each requires the appropriate later approval and prerequisites.
|
||||
|
||||
## 3. Decision authority and delegation
|
||||
|
||||
| Decision or action | Default authority / rule |
|
||||
|---|---|
|
||||
| Portfolio direction, priorities, venture starts, extensions, and terminations | Ken decides and records the decision. |
|
||||
| Experiment time and incremental cash ceilings | Ken explicitly authorizes the venture canvas and kickoff; unapproved ceilings are `TBD`, not zero or unlimited. |
|
||||
| Research, internal drafting, analysis, classification, and prototype preparation | AI/workflows may perform bounded tasks within approved tools, source access, data permissions, and budgets. |
|
||||
| External outreach, job applications, public content, customer-facing promises, pricing commitments | Ken approves before execution unless a specific narrowly scoped delegation is separately documented. |
|
||||
| Payments, purchases, transfers, refunds, signing contracts, production changes, privileged access | Require explicit authorization and applicable safeguards; do not infer authority from a goal or a prior approval of a draft. |
|
||||
| Editorial accuracy, rights, and consequential exceptions | Escalate for review under the venture's documented rules. |
|
||||
| Financial records and sales evidence | Use verifiable transactions and attributable venture-level records; AI may prepare summaries but does not invent receipts or declare a sale. |
|
||||
|
||||
A named *agent* does not itself confer authority. Implement tasks with agents, deterministic workflows, conventional software, or human effort according to actual requirements. No autonomous system may expand its own permissions or spending authority.
|
||||
|
||||
## 4. Portfolio investment policy
|
||||
|
||||
**Effort allocation:** The planning ambition is approximately **70% speculative effort** and **30% near-term revenue acquisition**, as described in `PORTFOLIO.md`. This is an allocation target, not an automatic weekly schedule or an instruction to neglect current obligations. Actual hours, cash ceilings, and deviations must be recorded at kickoff and reviewed as conditions change.
|
||||
|
||||
**Investment discipline:** Launch cheap, genuinely purchasable offers before building extensive organizational machinery. Use already-owned lab, business, and IP assets to minimize *incremental* capital needs. Record incremental usage, fees, maintenance demands, and owner effort where attributable; existing committed costs need not be re-purchased for each experiment.
|
||||
|
||||
**Complementarity:** Prefer shared audiences, IP, technology, distribution, and operating services when commercially sensible. Do not presume one business's audience will purchase another's products. Each venture must have its own customer and revenue hypothesis.
|
||||
|
||||
**Funding:** Evaluate paid pilots, Early Access, preorders, memberships, Kickstarter, Patreon, and comparable mechanisms in the relevant canvas. Distinguish pledges, collected cash, earned revenue, refunds, fees, and unfulfilled commitments. Customer funding is not unrestricted profit.
|
||||
|
||||
## 5. The first-sale rule and validation clock
|
||||
|
||||
**The sole initial commercial pass/fail KPI for a new venture is its first qualifying sale:** a genuine, arm's-length transaction attributable to the experimental offer with **more than $0 in collected revenue** within its approved maximum validation window. A pledge, unpaid booking, waitlist entry, free exchange, or merely published product does not qualify. Keep recognized earnings, cash receipts, fees, refunds, and remaining delivery obligations distinct. A refunded or invalid transaction must be flagged and the result reconsidered, not quietly counted as durable proof of demand.
|
||||
|
||||
For already paying channels, validate **incremental** income rather than counting a historical first sale. Gaussian's established revenue is baseline; its expansion test requires additional paid work. Employment uses the first paycheck as its cash milestone, while a contract uses first collected payment.
|
||||
|
||||
**Clock rule:** A venture's clock begins only on its recorded, authorized, adequately resourced start (`D0` or a separately recorded venture kickoff). Build and customer-acquisition time are recorded separately when feasible; the maximum validation window includes both unless the approved canvas expressly says otherwise. Missed dates do not silently reset the clock.
|
||||
|
||||
**At the deadline:**
|
||||
|
||||
- `PASS`: verified qualifying sale; the venture becomes *eligible for a new investment decision*, not automatically entitled to scale.
|
||||
- `FAIL — CURRENT HYPOTHESIS`: adequately resourced test, no qualifying sale; stop the current hypothesis and decide whether to retire, archive, or explicitly redesign it with a new test.
|
||||
- `DEFERRED`: planned resources were not provided or an external prerequisite prevented a valid test; record the reason, resources actually spent, and a new authorization before restarting. Do not call an unrun experiment a successful or failed market test.
|
||||
|
||||
The windows and uncertainty ratings in `PORTFOLIO.md` are initial estimates and ceilings, not predicted revenue dates. Diagnostic evidence—conversion, audience response, unit costs, fulfillment quality, owner labor, and retention—informs the *next* decision but cannot substitute for a first sale.
|
||||
|
||||
## 6. Stages and investment gates
|
||||
|
||||
| Stage | Required evidence and decision |
|
||||
|---|---|
|
||||
| Idea / backlog | Identifiable hypothesis and potential ecosystem; **no active-project status by default**. |
|
||||
| Authorized experiment | One-page canvas with offer, buyer, first-sale mechanism, kickoff, window, resource ceiling, rights, obligations, and exit path; owner approval logged. |
|
||||
| Launch / Early Access | Presently useful offer, truthful limitations, authorized sales path, protection of customer interests, and relevant platform compliance. |
|
||||
| First sale | Collected and attributable transaction verified; `PASS` or `FAIL — CURRENT HYPOTHESIS` recorded at the gate. |
|
||||
| Operate / reinvest | Separate review of repeatability, contribution after costs, support load, customer obligations, and the case for further spend. |
|
||||
| Scale / migrate / license / sell | Specific further authorization; financial capacity, rights, transferability, and operational readiness assessed. |
|
||||
| Retire / archive | Stop acquisition and spending, meet or resolve outstanding obligations, preserve reusable assets and records, and document lessons. |
|
||||
|
||||
Avoid treating the possibility of hundreds of low-cost experiments as permission to accumulate hundreds of unsupported live businesses. Any active venture carries real customer, maintenance, records, and security responsibilities.
|
||||
|
||||
## 7. Shared-services and modularity policy
|
||||
|
||||
Use one **shared business factory** for reusable opportunity research, sales support, AI production, administration, financial reporting, and technical infrastructure; build only the functions demanded by current experiments. Ventures must be logically separable from inception, with identifiable brand, domain/account dependencies, IP and licenses, code/workflows, customer and financial records, and documented operating procedures. Do not create a separate legal entity or duplicate technical stack for every experiment without a demonstrated need.
|
||||
|
||||
A venture must be capable, in principle, of continuing with replacement shared services. Possible outcomes include **operate, replicate, license, sell, or retire**; a sale is never assumed to be available, and platform accounts, customer data, licenses, and contracts may have restrictions on transfer.
|
||||
|
||||
## 8. Hosting, security, and economic migration
|
||||
|
||||
Default to existing lab and AI assets for appropriate experiments: the home lab, public-facing Docker infrastructure, and Forge/Gateway/Oracle triad. Isolate experimental workloads from existing revenue-critical services and personal data; grant minimum necessary access, maintain recovery paths, and review rights and security before public exposure.
|
||||
|
||||
Every software venture canvas estimates a **fit-for-purpose commercial deployment** (Azure, DigitalOcean, or another provider) and a cloud affordability floor based on dependable contribution: collected customer revenue less attributable variable costs must cover appropriate incremental cloud and other fixed production expenses. Account separately for one-time migration costs and a cash reserve. A positive margin is not, on its own, an automatic migration instruction.
|
||||
|
||||
Move when *both* economically supportable and justified by capacity, service requirements, security, customer commitments, or resilience needs. If adequate protection or honest service commitments require commercial hosting earlier than revenue supports, narrow, defer, or fund the offering rather than expose customers to inappropriate conditions. An Early Access label does not waive legal, platform, privacy, or refund obligations.
|
||||
|
||||
## 9. Governance cadence and records
|
||||
|
||||
**Weekly portfolio review:** Ken reviews actual collected sales, spending against approved ceilings, first-sale deadlines, pipeline evidence, owner effort, customer obligations, production failures, and decisions to continue, adjust, migrate, or stop. The review may be brief; the record must be explicit.
|
||||
|
||||
**Minimum records:**
|
||||
|
||||
- `PORTFOLIO.md`: current investment register, priority, uncertainty, windows, allocation, and decisions.
|
||||
- A canvas per authorized venture: owner, customer/offer, revenue path, D0, cash/time ceilings, funding model, commercial-hosting floor, risks/obligations, and separation path.
|
||||
- Experiment log: status, dated evidence of launch and sales, payments/refunds, manual interventions, decision and rationale.
|
||||
- Architecture decisions and operating runbooks only as requirements and repeatable workflows emerge.
|
||||
|
||||
A drafted artifact, proposed workflow, or elapsed calendar date is **not evidence of completed execution**. Link or record objective proof for published videos, live offers, paid receipts, and functioning automation where practical.
|
||||
|
||||
## 10. Initial authorizations required before execution
|
||||
|
||||
This charter proposes **no pre-approved cash amount or automatic access**. Ken must record the following before the relevant work begins:
|
||||
|
||||
| Authorization item | Initial state |
|
||||
|---|---|
|
||||
| First sprint start (`D0`) and available weekly hours | `TBD` |
|
||||
| Portfolio and per-experiment incremental cash ceilings | `TBD` |
|
||||
| Opportunity Intelligence sources, evaluation criteria, account access, permitted actions | `TBD` |
|
||||
| Egypt channel identity, ownership/account, first topic, editorial/rights requirements, publication approval | `TBD` |
|
||||
| First Egypt-adjacent paid offer, attribution, and any crowdfunding/preorder commitments | `TBD` |
|
||||
| SaaS buyer/problem hypothesis and paid-test scope | `TBD`; not a prerequisite for the first sprint |
|
||||
|
||||
Approval of this charter establishes governance **only**. Approval of an individual canvas and its resources initiates that experiment. Implementation remains governed by `PROJECT-PLAN.md` and the evolving `ARCHITECTURE.md`.
|
||||
|
||||
---
|
||||
|
||||
**Charter commitment:** Pursue ambitious, cheap, fast experiments; make a genuine first sale the initial commercial test; preserve the owner's decision rights and customers' interests; reuse capabilities; and retain the option to operate, replicate, license, sell, or responsibly retire each venture.
|
||||
@@ -0,0 +1,136 @@
|
||||
# Autonomous Enterprise Portfolio
|
||||
## Initial project plan — 90 days
|
||||
|
||||
**Document:** `PROJECT-PLAN.md`
|
||||
**Status:** Proposed execution baseline; not an authorization to spend, publish, contact prospects, or deploy production services
|
||||
**Prepared:** September 16, 2026
|
||||
**Owner / investment authority:** Ken Schaefer
|
||||
**Governing documents:** [`VISION.md`](VISION.md) and [`PORTFOLIO.md`](PORTFOLIO.md)
|
||||
**Planning convention:** `D0` is the date Ken explicitly authorizes and resources the first execution sprint. Days and weeks below are relative to D0; no task is considered completed solely because it appears here.
|
||||
|
||||
> **Build once. Launch rapidly. Validate with a sale. Operate, replicate, or sell.**
|
||||
|
||||
## 1. Objective and boundaries
|
||||
|
||||
Establish the first working iteration of a **modular AI-enabled business factory** while pursuing immediate income. Run two P0 experiments in parallel: (1) an Opportunity Intelligence capability that independently discovers and qualifies actionable employment, contract, and Fractional Insight opportunities for Ken to review; and (2) an original Ancient Egypt media-production proof of concept with **one published video within seven days of D0**, followed by a bounded first-revenue test. Maintain ordinary outreach and existing-client follow-through throughout.
|
||||
|
||||
The project tests whether AI and already-owned assets can compress time-to-launch, time-to-first-sale, incremental cash investment, and required routine owner labor. Viral claims about extraordinary business revenue are **unverified inspiration, not forecasts**. The stretch challenge is **launch in seven days and collect $10,000 in gross receipts in the first 30 operating days**, measured separately from the initial first-sale gate.
|
||||
|
||||
**Not in scope for the first sprint:** a complete autonomous organization, full Pyramid game or video-game production, a speculative SaaS platform without a buyer/problem hypothesis, hundreds of channels, or duplicating finance/marketing infrastructure for each venture.
|
||||
|
||||
## 2. Decision rights and ways of working
|
||||
|
||||
- **Ken:** authorizes experiments and budgets; chooses opportunities and products; approves external outreach, applications, publication, customer commitments, and consequential production changes; conducts creative/editorial and investment reviews.
|
||||
- **AI/workflows:** research, qualify, draft, assemble, report, and execute bounded preauthorized internal tasks. Do not assume a task was performed without a result or verifiable artifact.
|
||||
- **Weekly portfolio review:** examine collected sales, evidence, deadlines, remaining spending authorization, owner effort, customer obligations, and next investment decisions. Record decisions in the portfolio register.
|
||||
- **First-sale rule:** one genuine arm's-length sale with **collected revenue > $0** within the authorized validation window is the *only initial commercial pass/fail KPI* for a new venture. It earns a further-investment decision, not automatic scaling. Track other measures as diagnostics. For Gaussian, test incremental paid work beyond the established baseline; for employment use first paycheck.
|
||||
- **Failure/deferment:** if adequately resourced and no qualifying sale occurs by the deadline, stop the current commercial hypothesis and decide `RETIRE`, `ARCHIVE`, or explicitly `REDESIGN`. If an authorized effort cannot receive its planned resources, record `DEFERRED` and revise its clock openly.
|
||||
- **Customer obligations:** paid pilots, Early Access, preorders, and crowdfunding must deliver candidly described present value or commitments. Record receipts, recognized revenue, refunds, platform fees, and remaining fulfillment separately; a pledge is not a collected sale.
|
||||
|
||||
## 3. Workstreams and order of execution
|
||||
|
||||
| ID | Priority | Workstream | Owner / role | Immediate output | Gate / dependency |
|
||||
|---|---|---|---|---|---|
|
||||
| W0 | P0 | Portfolio governance | Ken, AI drafting support | Approved lightweight charter, experiment register, two canvases, sprint authorization | D0 and effort/cash ceilings recorded; no prolonged planning gate |
|
||||
| W1 | P0 | Opportunity Intelligence | Ken sponsors, automation executes | Repeatable qualified opportunity brief and tracked pipeline | Source access, criteria and allowed actions agreed; review findings before action |
|
||||
| W2 | P0 | Ancient Egypt media POC | Ken editorial owner, AI production support | Original published video, reproducible workflow, production log | Channel access, rights/accuracy review, publication approval; D0+7 target |
|
||||
| W3 | P0 | Existing-income follow-through | Ken with W1 support | Contract/job applications or proposals, Gaussian expansion and FI prospect activity | Keep active throughout; no unauthorized external contact |
|
||||
| W4 | P1 | Sales Development | Ken sponsors | Researched prospect list, outreach drafts, follow-up process | Reuse W1 pipeline; approve sends and respect contact/platform rules |
|
||||
| W5 | P1 | Egypt-adjacent product and funding | Ken creative/product owner | Small useful Pyramid-related offer and purchase/attribution path; funding-options decision | Do not make full RPG or video game prerequisite |
|
||||
| W6 | P1 | AI service first-sale test | Ken offer owner | Narrow purchasable offer with acceptance criteria and fulfillment record | Sale before elaborate autonomy; use FI infrastructure where appropriate |
|
||||
| W7 | P1 | SaaS discovery and paid pilot | Ken product owner | Buyer/problem canvas, validated offer, smallest usable product if warranted | Four-week first-sale stretch; no platform build without buyer hypothesis |
|
||||
| W8 | P2 | Shared factory and exit readiness | Ken architecture owner | Extracted reusable components, deployment/asset/finance boundaries | Extract from tested workflows, rather than building everything upfront |
|
||||
|
||||
**Parallelism:** W0 is intentionally short. W1, W2 and W3 start together once authorized; W4–W7 can be prepared in bounded blocks without derailing them. W8 supplies minimal isolation from day one but broad hardening waits for demonstrated reuse.
|
||||
|
||||
## 4. First seven days — detailed sprint
|
||||
|
||||
The following are **targets**, not claims of completed work. A day can be rescheduled only with an explicit plan update; publication requires actual editorial approval.
|
||||
|
||||
| When | Opportunity Intelligence / revenue acquisition | Egypt POC / publishing | Governance / evidence |
|
||||
|---|---|---|---|
|
||||
| **D0 — authorize** | Define target roles/contracts/FI prospects, geographic and remote criteria, trusted sources, qualification rubric, report destination and action permissions. Continue any live revenue follow-up. | Choose audience, first subject, documentary format, minimum episode length **TBD**, channel identity, source/rights standard and publish account. | Approve two short canvases, actual available weekly hours, first-sprint incremental cash ceiling and D0. Create venture IDs and baseline log. |
|
||||
| **D1** | Build minimal source-to-pipeline ingestion and deduplication; establish manual fallback. | Build source dossier and claim/evidence list for the first episode. | Confirm access, dependencies, and no unapproved spending. |
|
||||
| **D2** | Implement basic suitability scoring with citations to each opportunity; generate first internal brief. | Draft and edit original script; flag unsupported claims and reconstruction. | Review first pipeline examples and research quality. |
|
||||
| **D3** | Test source freshness, duplicate handling, false positives and actionable links; revise criteria. | Produce or license imagery, narration and audio; record rights, attribution and synthetic-content disclosures where required. | Record incremental expenses, human time, machine runtime and defects. |
|
||||
| **D4** | Deliver a usable qualified brief; Ken selects opportunities and authorizes next actions. | Assemble first cut using a reproducible render/edit workflow; prepare captions, thumbnail and description. | Check whether W1 actually saves search effort and W2 has a complete draft. |
|
||||
| **D5** | Convert selected leads into tailored resume/proposal/outreach drafts for review; maintain pipeline states. | Verify factual claims, asset rights, narration, accessibility and platform requirements; correct defects. | Go/no-go quality review; explicitly record blockers. |
|
||||
| **D6–D7** | Run second independent discovery cycle; present prioritized findings, next actions and unresolved access gaps. | Publish **one original video** after Ken's approval; save source dossier, files, production steps and public URL. Begin second-cycle feasibility assessment. | Sprint review: actual launch date, owner hours, incremental cost, autonomy gaps, sales status and week-2 decision. |
|
||||
|
||||
**Seven-day acceptance:** (a) one actually published original video with verifiable URL and rights/source records; (b) one repeatable Opportunity Intelligence discovery cycle with actionable, current, deduplicated findings for Ken; (c) recorded actual costs/time and explicit next investment decisions. If any item fails, report it as incomplete rather than inferring success from a draft or prototype. **Publishing a video is an operational milestone, not a commercial sale.**
|
||||
|
||||
## 5. Ninety-day roadmap and gates
|
||||
|
||||
| Phase | Timing from D0 | Main activities | Evidence and investment decision |
|
||||
|---|---|---|---|
|
||||
| **Launch** | **Week 1** | Complete W0 foundation; execute W1/W2 sprint; maintain W3. | Accept or revise the actual video and opportunity pipeline; log first-sale status separately. |
|
||||
| **Repeat and offer** | **Weeks 2–4** | Repeat Egypt production, test topics/audience response, put a small adjacent product up for purchase if ready; improve W1 and start W4; test W6 offer; research W7 buyer/problem and potential paid pilot. | Week-4 review: first sales, collected cash, working product paths, acquisition evidence, production cost, human burden. **Four-week SaaS first-sale stretch**, only for an authorized specific experiment. |
|
||||
| **Commercial learning** | **Weeks 5–8** | Pursue paid transactions through the channel/product, AI services and FI opportunities; evaluate Patreon, Kickstarter, preorders or paid pilots where suitable; improve only workflows with demonstrated use. | Week-8 review: attribute each receipt correctly; compare offers, acquisition paths, customer requests and remaining investment ceilings. Pause weak hypotheses or redesign explicitly. |
|
||||
| **Portfolio decision** | **Weeks 9–12** | Continue or retire bounded experiments; document shared components; evaluate whether any live software product meets commercial-cloud affordability and operational triggers; prepare viable ventures for standalone reporting. | Week-12 review: decide `CONTINUE / OPERATE / REDESIGN / RETIRE` for each active experiment, subject to its own maximum sale window. No assumption of profitability or autonomy. |
|
||||
| **Rebaseline** | **Days 85–90** | Consolidate lessons, financial attribution, reusable IP, and the next 90-day candidates. | Approve a fresh portfolio allocation and plan; carry forward only explicitly funded and authorized experiments. |
|
||||
|
||||
**Longer commercial windows continue outside this 90-day plan:** employment 48 weeks; new contract 12; Gaussian growth 24; new FI client 24; AI service 24; Ancient Egypt media/publishing 52; narrow SaaS 52; standalone digital publication 24. Each clock starts at its own recorded authorization/kickoff and remains subject to interim review and spending ceilings. See `PORTFOLIO.md` for the governing register.
|
||||
|
||||
## 6. Initial effort budget (proposed; actual hours TBD)
|
||||
|
||||
Maintain the portfolio's proposed **70% speculative / 30% near-term** allocation. These are percentages of *Ken's available working time*, not machine runtime, cash, or predicted revenue.
|
||||
|
||||
| Allocation bucket | Share | Includes |
|
||||
|---|---:|---|
|
||||
| Employment and short-term contracts | 20% | W1-qualified applications and contract pursuits; share of W1 build/time |
|
||||
| Gaussian expansion and new FI clients | 10% | W3 and client-facing W4; share of W1 relevant to FI |
|
||||
| AI-service experiments | 15% | W6 and its sales/fulfillment test |
|
||||
| Egypt media and adjacent publishing | 35% | W2 and W5 |
|
||||
| Narrow SaaS discovery / product | 20% | W7 |
|
||||
| **Total** | **100%** | **70% speculative** |
|
||||
|
||||
W0/W8 work must be charged to the benefiting buckets or separately identified when reviewing actual time; do not quietly create extra unallocated labor. If immediate paid work changes capacity, Ken explicitly rebalances and marks displaced experiments `DEFERRED` where appropriate. The first week's P0 sprint may require a documented temporary variance from these portfolio-level percentages.
|
||||
|
||||
**Cash:** Initial incremental spending ceiling **TBD — Ken authorization required**. Use existing lab, Docker, Forge/Gateway/Oracle, FI business/payment capabilities and existing IP first. Do not interpret an existing asset as permission for unbounded compute, public exposure, or external spending.
|
||||
|
||||
## 7. Minimum reusable business canvas and records
|
||||
|
||||
Before launching or taking money for a venture, create a concise canvas containing: venture ID and owner; ecosystem and product; buyer/problem/offer; first revenue mechanism and payment path; separate build and acquisition assumptions; D0 and maximum window; incremental cash/time ceilings; first-sale verification; adjacent products and funding options; Early Access limitations and fulfillment/refund commitments; cloud-hosting model and affordability floor when applicable; source/rights/data requirements; modular assets; and next decision date.
|
||||
|
||||
Maintain a **venture evidence log** with these distinct fields:
|
||||
|
||||
- **Commercial:** order ID, payer/transaction evidence, payment date, collected amount, currency, refunds, fees, earned versus unearned/restricted receipts, and product attribution. Do not store sensitive payment credentials in the log.
|
||||
- **Operational diagnostics:** dates authorized/built/launched, source and publication URLs, actual human hours, incremental cost, defects, support and outstanding commitments, production repeatability and acquisition activity.
|
||||
- **Investment:** approved ceiling, remaining ceiling, gate result, date, decision-maker, decision, and rationale.
|
||||
|
||||
The first qualifying sale is the only *initial* commercial pass/fail KPI. The other records allow honest interpretation and later-stage investment decisions; they are not competing first-sale thresholds.
|
||||
|
||||
## 8. Architecture and deployment guardrails
|
||||
|
||||
- **Logical separation at birth:** distinct venture ID, identifiable brand/offer, repository or content store, configuration, IP/assets, customer data and financial tags. Do not require separate LLCs, cloud accounts or full stacks for cheap tests.
|
||||
- **Shared services:** opportunity intelligence, research, AI inference, workflow orchestration, production, finance support and reporting should be reused where sensible through documented interfaces. Select agents versus deterministic workflows during process design, not from organizational labels alone.
|
||||
- **Human authorization:** no autonomous external applications, marketing messages, customer promises, financial transactions, production deployments or publication without the permissions appropriate to that action. Internal opportunity research may run independently within its authorized sources and access scope.
|
||||
- **Lab-first, safely:** isolate experiments from important data and existing revenue services; use least privilege, backups appropriate to the data, clear secrets handling and truthful product terms. Early Access does not waive privacy, refunds, or security obligations.
|
||||
- **Cloud economics:** for each software product, estimate a fit-for-purpose Azure, DigitalOcean or other commercial deployment **during planning**. Calculate contribution required to cover monthly fixed production costs and per-customer variable costs, plus one-time migration cost and cash reserve. This is an **affordability floor, not an automatic migration trigger**. Move when affordable *and* justified by capacity, customer obligations, reliability or security. If safe operation requires earlier migration, fund it or narrow/pause the offer.
|
||||
- **Transferability:** document dependencies and rights so a venture can potentially be operated independently, licensed, sold or retired. Verify actual transfer rights for accounts, software licenses, contracts and customer data before any sale.
|
||||
|
||||
## 9. Initial deliverables and document map
|
||||
|
||||
| Artifact | Timing / status | Purpose |
|
||||
|---|---|---|
|
||||
| `VISION.md` | Existing | Founding thesis and principles |
|
||||
| `PORTFOLIO.md` | Existing | Investment register, priorities, windows and allocation |
|
||||
| `PROJECT-PLAN.md` | This document; proposed | Ninety-day coordination and first-week execution |
|
||||
| `PROJECT-CHARTER.md` | W0, short draft | Authority, operating rules and investment approval |
|
||||
| `canvases/EGYPT-MEDIA.md` | D0 | First video/channel/product hypothesis and constraints |
|
||||
| `canvases/OPPORTUNITY-INTELLIGENCE.md` | D0 | Internal capability scope, sources, criteria, permissions and acceptance |
|
||||
| `logs/EXPERIMENT-REGISTER.md` | D0 | Actual kickoffs, states, gates, receipts and decisions |
|
||||
| `ARCHITECTURE.md` | Initial boundaries by end of Week 2; evolve from use | Shared factory, venture separability and deployment paths |
|
||||
| `runbooks/` and per-venture repositories | As workflows become repeatable | Reproduction, recovery, rights and potential transfer |
|
||||
|
||||
Paths are **proposed**, not assertions that these files or folders have been created. Keep governing documents in Markdown and link specific execution artifacts rather than duplicating their contents across chats.
|
||||
|
||||
## 10. Blockers and next owner decisions
|
||||
|
||||
Before D0, Ken must decide or explicitly delegate: (1) actual available weekly hours and any first-week allocation variance; (2) incremental sprint cash ceiling; (3) which job/contract/FI opportunity sources and accounts the research system may access; (4) Egypt channel ownership, first topic and publishing account; (5) applicable rights and acceptable content-production tools; and (6) who may approve external actions and spend. Unknown prices, dates, buyer interest and technical access stay `TBD` until verified.
|
||||
|
||||
**First execution instruction after authorization:** create the two one-page canvases, log D0 and budget, start Opportunity Intelligence research and Egypt research in parallel, and continue live cash-acquisition follow-through. Do not wait for a complete multi-agent platform.
|
||||
|
||||
---
|
||||
|
||||
**Project rule:** Build a real offer quickly, seek an actual paid transaction, record the evidence, and make the next investment decision deliberately. Preserve reusable assets and the freedom to operate, replicate, license, sell or responsibly retire each venture.
|
||||
@@ -0,0 +1,163 @@
|
||||
# Autonomous Enterprise Portfolio
|
||||
## Vision
|
||||
|
||||
**Document:** `VISION.md`
|
||||
**Status:** Founding vision — initial version
|
||||
**Established:** September 16, 2026
|
||||
**Owner:** Ken Schaefer
|
||||
|
||||
> **Build once. Launch rapidly. Validate with a sale. Operate, replicate, or sell.**
|
||||
|
||||
## 1. The vision
|
||||
|
||||
Create a diversified portfolio of complementary, AI-enabled businesses that can be conceived, launched, commercially tested, and operated with dramatically less incremental capital and routine human labor than conventional small businesses require.
|
||||
|
||||
The portfolio will use shared infrastructure, reusable business capabilities, and independently separable ventures. The owner will remain actively involved in vision, discovery, product development, editorial judgment, relationships, and major decisions, while AI and automation take over as much repetitive operational work as they can reliably perform.
|
||||
|
||||
Every venture is an experiment with a defined validation window. Ventures that establish commercial demand may become ongoing income sources, grow into stand-alone businesses, be licensed, or be sold. Unsuccessful experiments will be closed responsibly; their reusable assets and lessons will return to the portfolio.
|
||||
|
||||
**The long-term ambition is not merely to own several businesses. It is to develop a repeatable capability for creating and testing businesses.**
|
||||
|
||||
## 2. Why we are doing this
|
||||
|
||||
The initiating challenge came from videos claiming that AI can build highly profitable businesses in extraordinarily short periods, including a claim of a $1.2 million business built in roughly 30 minutes. The revenue, profit, timing, and repeatability of those claims have **not** been established. Building a website or product quickly is not the same as earning its claimed revenue.
|
||||
|
||||
We will neither accept such claims at face value nor dismiss their underlying possibility. We will test the proposition ourselves, recording build time, time to first sale, actual collected revenue, incremental spending, human effort, and failure as carefully as success.
|
||||
|
||||
The broader hypothesis is that AI may lower the minimum viable scale of a business: one technically capable person may be able to undertake work that previously demanded a team, agencies, or extensive founder labor. At the same time, cheaper production can increase competition, making demand, distribution, trust, and differentiation no less important. The experiment must test **commercial outcomes**, not simply prove that we can generate outputs.
|
||||
|
||||
## 3. The hypotheses we will test
|
||||
|
||||
1. **Launch compression:** Can AI and existing assets shorten the time from idea to purchasable product to days or weeks?
|
||||
2. **First-sale compression:** Can a newly launched venture obtain its first genuine paying customer within a bounded validation window?
|
||||
3. **Capital efficiency:** Can we run many experiments at little *incremental* cost by reusing infrastructure and capabilities already under our control?
|
||||
4. **Operational leverage:** Can shared AI systems carry out opportunity discovery, sales support, production, administration, and routine operations without requiring proportionate increases in the owner's labor?
|
||||
5. **Commercial adjacency:** Can an audience, product, service, or discovery in one venture create customers or useful intellectual property for another?
|
||||
6. **Transferable value:** Can validated ventures be sufficiently modular to operate independently, be licensed, or be sold?
|
||||
7. **Factory repeatability:** Can a repeatable process support numerous experiments rather than requiring each business to be invented from scratch?
|
||||
|
||||
These are questions to investigate, not claims of proven capability.
|
||||
|
||||
## 4. Portfolio philosophy
|
||||
|
||||
### 4.1 Embrace uncertainty, bound exposure
|
||||
|
||||
We are deliberately willing to go out on a limb. An initial **70% allocation of available effort to speculative opportunities** is an expression of that ambition, not a promise to neglect near-term financial commitments. Actual allocation will be set and rebalanced in the portfolio plan as cash and evidence change.
|
||||
|
||||
We distinguish uncertainty about demand, timing, and outcomes from exposure to cash loss, contractual commitments, and other harm. Experiments should be bold in their hypotheses and disciplined in their commitments.
|
||||
|
||||
### 4.2 First sale is the first commercial gate
|
||||
|
||||
The initial commercial KPI for each new venture is **one genuine, arm's-length sale with collected revenue greater than $0 within its defined validation window**. A sale earns the venture consideration for further investment; it does **not** prove profitability, repeatability, or sustainability.
|
||||
|
||||
A venture that records no qualifying sale by its deadline fails its *current commercial hypothesis*: we stop investing under that hypothesis and decide whether to retire, archive, or explicitly redesign the experiment. We do not quietly extend deadlines or mistake activity for revenue.
|
||||
|
||||
Pledges, expressions of interest, waitlists, booked but unpaid orders, and promotional exchanges are evidence of different kinds—not interchangeable with collected sales. Crowdfunding proceeds, preorders, subscriptions, advertising receipts, and product purchases must be identified by type; money subject to fulfillment, refund, or other obligations is not automatically profit.
|
||||
|
||||
Existing revenue relationships are evaluated **incrementally**. Gaussian, for example, has already produced more than $8,000 in 2026; the new test concerns additional paid work, not proving the first-ever sale again.
|
||||
|
||||
### 4.3 Keep ambition separate from the acceptance test
|
||||
|
||||
Our provocative stretch outcome is to **launch a business in seven days and collect $10,000 in gross revenue during its first 30 days of operation**. It is a challenge to test, not a forecast and not a prerequisite for passing the first-sale gate.
|
||||
|
||||
We will separately record gross receipts, refunds and obligations, variable and incremental costs, profit or loss, and required human effort. A business with its first small sale may merit further investigation; a business with large gross revenue but unsustainable economics may not.
|
||||
|
||||
### 4.4 Validate before perfecting
|
||||
|
||||
A purchasable, useful initial product can precede a polished platform and a fully autonomous operation. We favor minimum viable offers, paid pilots, limited releases, and carefully scoped Early Access where suitable. The product must deliver present value, and its limitations and discontinuation terms must be candid. Early Access does not erase customer, security, privacy, platform, or legal obligations.
|
||||
|
||||
### 4.5 Complementary businesses, not unrelated bets
|
||||
|
||||
We will seek combinations in which content builds an audience for products; products create material for content; services reveal software opportunities; software and workflows become reusable intellectual property. We will still test each connection rather than assume that an audience will buy or that one revenue stream guarantees another.
|
||||
|
||||
The portfolio must also retain genuine diversification: sharing infrastructure is useful, but shared distribution or a single dependent customer can create correlated failure.
|
||||
|
||||
## 5. The business factory
|
||||
|
||||
The enterprise will have **shared services** and **separable business units**.
|
||||
|
||||
Shared capabilities may include opportunity intelligence, market research, sales development, marketing, content production, AI inference, engineering, accounting support, reporting, and deployment. They will be implemented with an appropriate combination of specialized agents, deterministic workflows, existing software, and people. We will **not** presume that every business function needs its own agent.
|
||||
|
||||
Each venture should have an identifiable offer, audience, brand or product identity where appropriate, assets and intellectual property, customer records, financial attribution, operating configuration, validation criteria, and a path to stand-alone operation.
|
||||
|
||||
**Modularity is a founding constraint:** a venture should be possible to retain, scale, license, sell, or retire without dismantling the shared factory or unnecessarily entangling other ventures. This does not require a separate LLC, bank account, cloud account, or full software stack for every early experiment. It does require deliberate boundaries, documentation, portable data, and clarity about ownership and transferability. Third-party accounts, contracts, licenses, and customer data may not be transferable without permission or additional work.
|
||||
|
||||
The factory itself—its methods, workflows, software, templates, and operating know-how—may ultimately become intellectual property or a commercial offering. That possibility must not delay the first experiments.
|
||||
|
||||
## 6. The owner's role and the purpose of autonomy
|
||||
|
||||
The objective of automation is to **remove required routine labor**, not to remove the owner from work he finds valuable. Ken intends to remain involved in opportunity selection, developing products, architecture, creative direction, major customer relationships, portfolio allocation, and consequential decisions.
|
||||
|
||||
We will focus early automation on his constraints: finding leads, qualifying opportunities, supporting sales, following up, and covering business functions for which time is scarce. His comparative advantage is in building and developing, not spending every hour prospecting or administering the portfolio.
|
||||
|
||||
An Opportunity Intelligence capability should independently discover, evaluate, and organize relevant employment, contract, and client opportunities, then present actionable findings for Ken to review and act upon. Independence in research does not imply authorization to apply, contact people, accept terms, move money, or make irreversible commitments without appropriate controls.
|
||||
|
||||
Autonomy is progressive: prove a bounded workflow, measure quality and exceptions, expand permissions where earned, and preserve human governance of consequential decisions. We want the businesses to continue their routine work when Ken turns his attention elsewhere—not a theatrical claim of zero human involvement.
|
||||
|
||||
## 7. Assets and capital strategy
|
||||
|
||||
We begin with assets already under our control:
|
||||
|
||||
- A home lab with static IP, firewall, reverse proxy, virtualization, and a Docker server for public-facing services.
|
||||
- The **Forge / Gateway / Oracle** AI infrastructure, local-model capability, and Project Thoth engineering work.
|
||||
- **Fractional Insight CIO, LLC**, its registration, EIN, business bank account, QuickBooks, and credit-card processing capability.
|
||||
- Professional experience, reputation, career documentation, existing consulting relationships, and defined service offerings.
|
||||
- **Withered Sanctum** and **Pyramid**, including existing creative work and historical publishing experience.
|
||||
|
||||
Previously committed lab and business expenditures are part of our existing cost base; the investment decision for an experiment focuses on **incremental** spending and labor. We will still account for any additional electricity, model/API usage, storage, hardware load, fees, and support attributable to a venture. Existing resources are an advantage, not a claim of zero cost or unlimited capacity.
|
||||
|
||||
**Lab first, commercial infrastructure when justified.** Each software venture's detailed plan will model the cost of a suitable Azure, DigitalOcean, or other production deployment and calculate the revenue or contribution needed to support it. Commercial hosting cost creates an economic affordability floor, not an automatic command to migrate. Capacity, security, customer-data sensitivity, recovery needs, and promises to customers may require a different environment sooner; if so, we must fund it or narrow the offer rather than make commitments the lab cannot safely support.
|
||||
|
||||
Customer-funded development is an option to examine in every relevant business canvas: paid pilots, preorders, Early Access, crowdfunding, memberships, or subscriptions. We will distinguish committed funding and collected cash from earned revenue and account for fees, refund risks, and delivery obligations.
|
||||
|
||||
## 8. Initial portfolio ecosystems
|
||||
|
||||
### A. Withered Sanctum: media, games, and publishing
|
||||
|
||||
An Ancient Egypt channel is the first speculative proof of concept. It may connect to **Pyramid** tabletop products, historical and game-related digital publications, assets, memberships, and eventually an interactive or video-game adaptation. The channel is a potential audience and distribution asset, not necessarily an advertising-only business.
|
||||
|
||||
The initial aggressive **seven-day** goal is to launch a real, original video and a repeatable production process. That establishes operational feasibility; the commercial gate is the first attributable paid transaction within the separately defined validation window. Advertising revenue remains a potential later revenue source alongside direct product sales and support.
|
||||
|
||||
Content quality, historical accuracy, rights, and audience value matter whether the work is made by AI or people. We will not confuse high-volume output with commercial demand.
|
||||
|
||||
### B. Fractional Insight: services, technology, and software
|
||||
|
||||
Existing consulting relationships and AI/service offerings provide pathways to current revenue. Opportunity Intelligence and Sales Development should support employment, short-term contracting, Gaussian expansion, new clients, and paid AI services in parallel with speculative development.
|
||||
|
||||
Customer problems discovered through these activities may lead to templates, tools, narrowly scoped paid software, or SaaS. SaaS does not need to be autonomous before it can be sold; the first paying customer is its initial commercial gate. Any associated media channel should serve a coherent product or audience rather than exist solely because we can automate video production.
|
||||
|
||||
These ecosystems are initial candidates, **not permanent limits** on new ideas. An experiment can originate elsewhere if it has a clear hypothesis and a bounded test.
|
||||
|
||||
## 9. Experimental lifecycle and evidence
|
||||
|
||||
Every proposed venture will have a short business canvas documenting its customer and problem, offer, commercial mechanism, complementary assets, uncertainty, estimated build horizon, estimated customer-acquisition horizon, maximum validation window, incremental investment ceiling, deployment economics, funding possibilities, and exit or retirement path.
|
||||
|
||||
Its lifecycle is:
|
||||
|
||||
1. **Propose:** Define a falsifiable commercial hypothesis and a bounded investment.
|
||||
2. **Build and launch:** Offer a real, usable product or service as quickly as practical.
|
||||
3. **Find the first sale:** Seek collected revenue within the venture's window.
|
||||
4. **Decide:** Continue testing, operate, expand, license, offer for sale, redesign, or retire based on evidence.
|
||||
5. **Preserve learning:** Return reusable software, content, research, and operational lessons to the shared factory.
|
||||
|
||||
Build time and customer-acquisition time are tracked separately. The world may not cooperate with our estimates; that uncertainty is part of the test. Validation clocks and resource commitments must be explicit so a starved or deferred experiment is not confused with a completed failure.
|
||||
|
||||
The **first sale is our only initial commercial pass/fail KPI**, but operational facts such as launch date, costs, effort, quality, and obligations must still be recorded to interpret it responsibly. Subsequent funding gates will examine repeat demand, contribution, customer retention, autonomy, and transferability.
|
||||
|
||||
## 10. What success looks like
|
||||
|
||||
**Near term:** A functioning opportunity-discovery capability that surfaces actionable revenue opportunities; an Ancient Egypt production proof of concept launched rapidly; and honest first-sale tests for the first ventures.
|
||||
|
||||
**Medium term:** A small set of ventures with paid demand, reusable shared services, documented unit economics, and progressively reduced routine owner workload. Some experiments will end; they are not evidence that the overall approach has failed if we learn quickly and limit exposure.
|
||||
|
||||
**Long term:** A repeatable business factory and portfolio of complementary, modular income-producing assets. Some are retained for cash flow and creative satisfaction; others may be grown, licensed, or sold. Success means that additional businesses do not require a proportional increase in Ken's operational labor.
|
||||
|
||||
We will measure the claims that inspired this project against **actual sales, actual costs, actual time, and actual independence**—not viral anecdotes or the number of agents deployed.
|
||||
|
||||
---
|
||||
|
||||
## Founding commitment
|
||||
|
||||
We will be ambitious about what AI may make possible and unsentimental about what the market proves. We will launch quickly, ask customers to pay, share what works across ventures, protect the ability to exit what does not, and keep the owner doing the work that makes the enterprise worth building.
|
||||
|
||||
**Build once. Launch rapidly. Validate with a sale. Operate, replicate, or sell.**
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,967 @@
|
||||
# W1 — Opportunity Intelligence
|
||||
## Project Plan
|
||||
|
||||
**Project:** W1 — Opportunity Intelligence
|
||||
**Portfolio:** Autonomous Enterprise Portfolio
|
||||
**Classification:** Shared Service
|
||||
**Shared Service Domain:** Sales & Marketing Operations
|
||||
**Parent Project:** AEP Shared Services
|
||||
**Initial Consumer:** Fractional Insight / owner income-acquisition activity
|
||||
**Status:** Draft for approval
|
||||
**Owner / Architecture Authority:** Ken Schaefer
|
||||
**Development Lead:** ChatGPT
|
||||
**Implementation Engineer:** Codex
|
||||
**Related documents:** `W1-REQUIREMENTS.md`, `W1-ARCHITECTURE.md`, `ENTERPRISE-MODEL.md`
|
||||
|
||||
---
|
||||
|
||||
# Project Value Gates
|
||||
|
||||
## Development Window
|
||||
|
||||
**Target:** Make the first complete, human-usable W1 capability available by the end of Sprint 0, **September 25, 2026**.
|
||||
|
||||
The project is explicitly time-boxed. The objective is not to perfect Opportunity Intelligence but to make the capability operational within the Sprint 0 window and measure whether AI-assisted development materially compresses time-to-capability.
|
||||
|
||||
If the September 25 development gate is missed, additional implementation work requires an explicit review of:
|
||||
|
||||
- what remains incomplete;
|
||||
- actual owner effort consumed;
|
||||
- whether the architecture is too broad;
|
||||
- whether features should be deferred;
|
||||
- whether the capability still justifies further investment.
|
||||
|
||||
No silent extension of the development window is permitted.
|
||||
|
||||
## Operational Validation Window
|
||||
|
||||
**Direct financial validation:** Not applicable.
|
||||
|
||||
W1 is a Shared Service and is therefore validated operationally.
|
||||
|
||||
By the end of Sprint 0, W1 must demonstrate repeatable live opportunity discovery across multiple execution cycles.
|
||||
|
||||
A successful cycle must:
|
||||
|
||||
- run from the human interface;
|
||||
- execute against configured live sources;
|
||||
- require no manual opportunity searching by the user;
|
||||
- evaluate discovered opportunities against the configured profile;
|
||||
- preserve original-source evidence;
|
||||
- identify qualification gaps and unknowns;
|
||||
- present findings through the human UI;
|
||||
- complete predictably enough for normal business use.
|
||||
|
||||
The existing implementation spike has already demonstrated feasibility. Sprint 0 acceptance requires a bounded, maintainable, human-usable implementation.
|
||||
|
||||
---
|
||||
|
||||
# 1. Purpose
|
||||
|
||||
This plan translates the approved W1 requirements and architecture into a bounded implementation effort.
|
||||
|
||||
W1 will provide a reusable Opportunity Intelligence Shared Service that:
|
||||
|
||||
1. searches configured opportunity sources;
|
||||
2. normalizes and deduplicates findings;
|
||||
3. evaluates opportunities against a configurable user profile;
|
||||
4. identifies matches, disqualifiers, and unknowns;
|
||||
5. preserves source evidence;
|
||||
6. presents results through a human-operable web interface.
|
||||
|
||||
The project is not intended to build a complete autonomous sales organization.
|
||||
|
||||
The initial release ends at decision support.
|
||||
|
||||
---
|
||||
|
||||
# 2. Project State at Plan Approval
|
||||
|
||||
W1 is not starting from zero.
|
||||
|
||||
An implementation spike already exists and has demonstrated:
|
||||
|
||||
- live public-source retrieval;
|
||||
- USAC procurement processing;
|
||||
- LRS employment/contract discovery;
|
||||
- deduplication;
|
||||
- normalized opportunity records;
|
||||
- technical qualification;
|
||||
- practical qualification;
|
||||
- owner-profile/evidence modeling;
|
||||
- deterministic replay;
|
||||
- source provenance;
|
||||
- automated tests;
|
||||
- Git/Gitea workflow.
|
||||
|
||||
This spike is treated as **feasibility evidence**, not as the production baseline.
|
||||
|
||||
Before feature work resumes, the existing implementation must be reviewed against `W1-REQUIREMENTS.md` and `W1-ARCHITECTURE.md`.
|
||||
|
||||
Each existing component will be classified as:
|
||||
|
||||
- `RETAIN`
|
||||
- `REFACTOR`
|
||||
- `MIGRATE`
|
||||
- `SUPERSEDE`
|
||||
- `REMOVE`
|
||||
|
||||
---
|
||||
|
||||
# 3. Definition of Ready
|
||||
|
||||
Implementation resumes only when all of the following are true:
|
||||
|
||||
- `W1-REQUIREMENTS.md` approved;
|
||||
- `W1-ARCHITECTURE.md` approved;
|
||||
- `W1-PROJECT-PLAN.md` approved;
|
||||
- AEP Shared Services repository location decided;
|
||||
- Gitea repository created or approved;
|
||||
- repository initialized/cloned on Forge;
|
||||
- project opened in VS Code;
|
||||
- `.project/` control structure established;
|
||||
- W1 component structure established;
|
||||
- existing spike inventory completed;
|
||||
- source control remote verified;
|
||||
- first implementation work order approved.
|
||||
|
||||
---
|
||||
|
||||
# 4. Source Project Structure
|
||||
|
||||
W1 will reside within the formal **AEP Shared Services** source project.
|
||||
|
||||
Target conceptual structure:
|
||||
|
||||
```text
|
||||
AEP-Shared-Services/
|
||||
│
|
||||
├── .project/
|
||||
│ ├── REQUIREMENTS.md
|
||||
│ ├── ARCHITECTURE.md
|
||||
│ ├── PROJECT-PLAN.md
|
||||
│ ├── STATUS.md
|
||||
│ ├── DECISIONS/
|
||||
│ └── WORK-ORDERS/
|
||||
│
|
||||
├── opportunity-intelligence/
|
||||
│ │
|
||||
│ ├── .project/
|
||||
│ │ ├── REQUIREMENTS.md
|
||||
│ │ ├── ARCHITECTURE.md
|
||||
│ │ ├── PROJECT-PLAN.md
|
||||
│ │ ├── STATUS.md
|
||||
│ │ ├── DECISIONS/
|
||||
│ │ └── WORK-ORDERS/
|
||||
│ │
|
||||
│ ├── src/
|
||||
│ ├── tests/
|
||||
│ ├── config/
|
||||
│ ├── data/
|
||||
│ ├── docs/
|
||||
│ └── README.md
|
||||
│
|
||||
└── common/
|
||||
```
|
||||
|
||||
The final folder structure may be refined during environment setup, but any change must preserve:
|
||||
|
||||
- clear W1 boundaries;
|
||||
- maintainable organization;
|
||||
- human readability;
|
||||
- separation between project-control artifacts and implementation artifacts.
|
||||
|
||||
---
|
||||
|
||||
# 5. Development Roles
|
||||
|
||||
## Ken — Senior Architect / Owner
|
||||
|
||||
Responsible for:
|
||||
|
||||
- business decisions;
|
||||
- architecture authority;
|
||||
- environment operation;
|
||||
- VS Code and Codex supervision;
|
||||
- reviewing implementation;
|
||||
- supplying Codex output and observations back to ChatGPT;
|
||||
- acceptance or rejection of completed work.
|
||||
|
||||
## ChatGPT — AppDev Manager / Technical Lead
|
||||
|
||||
Responsible for:
|
||||
|
||||
- requirements refinement;
|
||||
- architecture;
|
||||
- project planning;
|
||||
- work decomposition;
|
||||
- Codex work orders;
|
||||
- acceptance criteria;
|
||||
- implementation review;
|
||||
- project-status interpretation.
|
||||
|
||||
ChatGPT does not directly implement production source code under the established workflow.
|
||||
|
||||
## Codex — Implementation Engineer / Junior Programmer
|
||||
|
||||
Responsible for:
|
||||
|
||||
- implementing approved work orders;
|
||||
- creating and modifying source code;
|
||||
- writing tests;
|
||||
- running verification;
|
||||
- reporting changes, test results, and unresolved issues.
|
||||
|
||||
Codex does not independently redefine requirements or architecture.
|
||||
|
||||
---
|
||||
|
||||
# 6. Development Method
|
||||
|
||||
## 6.1 Preferred Development Cycle
|
||||
|
||||
TDD is the preferred implementation method.
|
||||
|
||||
For bounded behavior:
|
||||
|
||||
```text
|
||||
Requirement
|
||||
↓
|
||||
Acceptance criterion
|
||||
↓
|
||||
Failing test
|
||||
↓
|
||||
Implementation
|
||||
↓
|
||||
Passing test
|
||||
↓
|
||||
Regression suite
|
||||
↓
|
||||
Human review
|
||||
```
|
||||
|
||||
Exploratory spikes may precede formal tests when uncertainty must be resolved, but production behavior should normally become test-backed before acceptance.
|
||||
|
||||
## 6.2 Source-Code Standards
|
||||
|
||||
Generated code must prioritize maintainability.
|
||||
|
||||
Required characteristics:
|
||||
|
||||
- human-readable naming;
|
||||
- generous whitespace;
|
||||
- clear module boundaries;
|
||||
- explanatory comments for major and minor behavior where they improve understanding;
|
||||
- configuration separated from business logic;
|
||||
- short, understandable functions and modules;
|
||||
- predictable folder structure;
|
||||
- README and operating documentation kept current;
|
||||
- no clever compression solely to reduce line count.
|
||||
|
||||
Working code is not accepted solely because automated tests pass.
|
||||
|
||||
---
|
||||
|
||||
# 7. Release 1 Scope
|
||||
|
||||
Release 1 includes:
|
||||
|
||||
- manually triggered opportunity discovery;
|
||||
- multiple configured sources;
|
||||
- normalization;
|
||||
- deterministic deduplication;
|
||||
- profile-based qualification;
|
||||
- gap and unknown identification;
|
||||
- source provenance;
|
||||
- durable run records;
|
||||
- durable opportunity records;
|
||||
- human web interface;
|
||||
- opportunity list;
|
||||
- opportunity detail;
|
||||
- editable profile;
|
||||
- visible run status;
|
||||
- multiple repeatable discovery cycles.
|
||||
|
||||
Release 1 excludes:
|
||||
|
||||
- scheduled execution;
|
||||
- autonomous applications;
|
||||
- autonomous outreach;
|
||||
- proposal submission;
|
||||
- CRM replacement;
|
||||
- billing/accounting;
|
||||
- generalized multi-agent frameworks;
|
||||
- public API;
|
||||
- multi-user SaaS;
|
||||
- elaborate analytics;
|
||||
- advanced dashboarding.
|
||||
|
||||
---
|
||||
|
||||
# 8. Implementation Phases
|
||||
|
||||
## Phase 0 — Project Control and Environment Setup
|
||||
|
||||
**Purpose:** Establish the correct project boundary and working environment before further coding.
|
||||
|
||||
### Tasks
|
||||
|
||||
1. Create/confirm the **AEP Shared Services** Gitea repository.
|
||||
2. Clone or initialize the repository on Forge.
|
||||
3. Open the repository in VS Code.
|
||||
4. Establish the top-level `.project/`.
|
||||
5. Establish `opportunity-intelligence/.project/`.
|
||||
6. Add the approved:
|
||||
- `REQUIREMENTS.md`
|
||||
- `ARCHITECTURE.md`
|
||||
- `PROJECT-PLAN.md`
|
||||
7. Establish initial source/test/config/data/docs structure.
|
||||
8. Verify Git remote connectivity.
|
||||
9. Preserve the existing W1 spike before migration work begins.
|
||||
10. Record environment setup in `STATUS.md`.
|
||||
|
||||
### Exit Criteria
|
||||
|
||||
- project opens cleanly in VS Code;
|
||||
- source control works;
|
||||
- project documents are present;
|
||||
- W1 has an approved component location;
|
||||
- no implementation work is being performed outside the controlled project.
|
||||
|
||||
---
|
||||
|
||||
## Phase 1 — Spike Inventory and Migration Plan
|
||||
|
||||
**Purpose:** Prevent prototype implementation choices from becoming accidental production architecture.
|
||||
|
||||
### Tasks
|
||||
|
||||
Inventory existing W1 components, including:
|
||||
|
||||
- source collectors;
|
||||
- source-specific parsers;
|
||||
- normalizers;
|
||||
- deduplication;
|
||||
- profile model;
|
||||
- technical qualification;
|
||||
- practical qualification;
|
||||
- evidence/provenance handling;
|
||||
- deterministic replay;
|
||||
- run artifacts;
|
||||
- tests;
|
||||
- command-line entry points;
|
||||
- configuration.
|
||||
|
||||
For each component, record:
|
||||
|
||||
- current location;
|
||||
- purpose;
|
||||
- test coverage;
|
||||
- architecture fit;
|
||||
- maintainability assessment;
|
||||
- migration disposition.
|
||||
|
||||
Disposition values:
|
||||
|
||||
```text
|
||||
RETAIN
|
||||
REFACTOR
|
||||
MIGRATE
|
||||
SUPERSEDE
|
||||
REMOVE
|
||||
```
|
||||
|
||||
### Deliverable
|
||||
|
||||
`SPIKE-MIGRATION-ASSESSMENT.md`
|
||||
|
||||
or equivalent decision record under `.project/DECISIONS/`.
|
||||
|
||||
### Exit Criteria
|
||||
|
||||
The team can answer:
|
||||
|
||||
> Which existing code is becoming part of Release 1, and why?
|
||||
|
||||
No broad feature development should occur before this decision is recorded.
|
||||
|
||||
---
|
||||
|
||||
## Phase 2 — Core Domain Baseline
|
||||
|
||||
**Purpose:** Establish the stable domain model that the UI and adapters will use.
|
||||
|
||||
### Required capabilities
|
||||
|
||||
- normalized `Opportunity`;
|
||||
- `Run`;
|
||||
- structured `Profile`;
|
||||
- qualification result;
|
||||
- opportunity lifecycle state;
|
||||
- source/provenance reference.
|
||||
|
||||
### Tasks
|
||||
|
||||
1. Define domain objects and boundaries.
|
||||
2. Write tests for core states and validation.
|
||||
3. Migrate/refactor existing normalized opportunity logic.
|
||||
4. Migrate/refactor profile/evidence logic.
|
||||
5. Implement or retain deterministic state transitions.
|
||||
6. Ensure unknown values remain explicitly unknown.
|
||||
7. Confirm domain code has no dependency on the web UI.
|
||||
|
||||
### Exit Criteria
|
||||
|
||||
- core domain tests pass;
|
||||
- profile and opportunity models meet requirements;
|
||||
- qualification output has a defined structure;
|
||||
- UI development can consume the domain model without reading raw run files.
|
||||
|
||||
---
|
||||
|
||||
## Phase 3 — Persistence and Evidence
|
||||
|
||||
**Purpose:** Replace reliance on timestamped output directories as the primary application state.
|
||||
|
||||
### Architecture target
|
||||
|
||||
- SQLite for structured operational state;
|
||||
- file-based evidence storage where useful;
|
||||
- database references to evidence artifacts.
|
||||
|
||||
### Tasks
|
||||
|
||||
1. Establish database schema/migrations.
|
||||
2. Persist:
|
||||
- runs;
|
||||
- opportunities;
|
||||
- qualification results;
|
||||
- profile;
|
||||
- lifecycle state.
|
||||
3. Preserve relevant raw/saved source evidence.
|
||||
4. Preserve deterministic replay capability.
|
||||
5. Test restart persistence.
|
||||
6. Test successful run with zero opportunities.
|
||||
7. Test partial-source failure representation.
|
||||
|
||||
### Exit Criteria
|
||||
|
||||
The application can restart without losing normal operational state.
|
||||
|
||||
Historical evidence remains reviewable.
|
||||
|
||||
---
|
||||
|
||||
## Phase 4 — Source Adapter Integration
|
||||
|
||||
**Purpose:** Move proven source collection behind the approved adapter boundary.
|
||||
|
||||
### Initial candidate adapters
|
||||
|
||||
- LRS;
|
||||
- USAC.
|
||||
|
||||
The project plan does not require retaining both if implementation review shows one is unsuitable for Release 1, but multiple configured sources are required by the Requirements.
|
||||
|
||||
### Tasks
|
||||
|
||||
1. Define source adapter contract.
|
||||
2. Migrate/refactor first adapter.
|
||||
3. Add adapter contract tests.
|
||||
4. Migrate/refactor second adapter.
|
||||
5. Implement source health/error reporting.
|
||||
6. Verify normalized output.
|
||||
7. Verify original-source URLs and provenance.
|
||||
8. Verify source failures do not silently appear as zero opportunities.
|
||||
|
||||
### Exit Criteria
|
||||
|
||||
At least two configured sources can execute through the common discovery workflow.
|
||||
|
||||
---
|
||||
|
||||
## Phase 5 — Qualification Pipeline
|
||||
|
||||
**Purpose:** Produce explainable, profile-based opportunity evaluation.
|
||||
|
||||
### Stages
|
||||
|
||||
1. deterministic screening;
|
||||
2. interpretive qualification;
|
||||
3. gap analysis;
|
||||
4. human-readable explanation.
|
||||
|
||||
### Tasks
|
||||
|
||||
1. Retain/refactor existing deterministic qualification.
|
||||
2. Retain/refactor owner-evidence model.
|
||||
3. Establish intelligence-provider boundary.
|
||||
4. Ensure provider-specific behavior is isolated.
|
||||
5. Test:
|
||||
- strong match;
|
||||
- disqualification;
|
||||
- unknown qualification;
|
||||
- conflicting source data;
|
||||
- expired opportunity;
|
||||
- unresolved gap.
|
||||
6. Ensure the output explains:
|
||||
- matches;
|
||||
- mismatches;
|
||||
- unknowns;
|
||||
- required next action.
|
||||
|
||||
### Exit Criteria
|
||||
|
||||
The qualification engine produces structured and human-readable results without inventing missing qualifications.
|
||||
|
||||
---
|
||||
|
||||
## Phase 6 — First Human-Usable Vertical Slice
|
||||
|
||||
**Purpose:** Satisfy the human-first requirement before expanding features.
|
||||
|
||||
This phase is the most important Release 1 milestone.
|
||||
|
||||
The first vertical slice must allow the user to:
|
||||
|
||||
```text
|
||||
Open W1
|
||||
↓
|
||||
Run Opportunity Intelligence
|
||||
↓
|
||||
Wait for completion/status
|
||||
↓
|
||||
Review opportunities
|
||||
↓
|
||||
Open one opportunity
|
||||
↓
|
||||
Understand why it matters
|
||||
```
|
||||
|
||||
### UI pages / views
|
||||
|
||||
#### Dashboard / Run
|
||||
|
||||
Must show:
|
||||
|
||||
- Run control;
|
||||
- current status;
|
||||
- last run;
|
||||
- configured sources;
|
||||
- discovered count;
|
||||
- qualification count;
|
||||
- errors/warnings.
|
||||
|
||||
#### Opportunity List
|
||||
|
||||
Must show enough information to prioritize review.
|
||||
|
||||
#### Opportunity Detail
|
||||
|
||||
Must show:
|
||||
|
||||
- source;
|
||||
- original link;
|
||||
- opportunity summary;
|
||||
- qualification explanation;
|
||||
- matches;
|
||||
- gaps;
|
||||
- disqualifiers;
|
||||
- next actions.
|
||||
|
||||
### Exit Criteria
|
||||
|
||||
Ken can operate a complete discovery-and-review cycle without navigating internal run folders or opening raw data files.
|
||||
|
||||
---
|
||||
|
||||
## Phase 7 — Profile Management UI
|
||||
|
||||
**Purpose:** Make qualification criteria controllable by the business user.
|
||||
|
||||
### Tasks
|
||||
|
||||
1. Build human-readable profile page.
|
||||
2. Display:
|
||||
- established facts;
|
||||
- preferences;
|
||||
- requirements;
|
||||
- exclusions;
|
||||
- unknowns.
|
||||
3. Allow supported profile edits.
|
||||
4. Validate changes.
|
||||
5. Persist changes.
|
||||
6. Verify subsequent qualification uses updated profile.
|
||||
7. Protect structured evidence fields from accidental corruption where necessary.
|
||||
|
||||
### Exit Criteria
|
||||
|
||||
Normal qualification criteria can be changed without editing source code.
|
||||
|
||||
---
|
||||
|
||||
## Phase 8 — Repeatability and Operational Validation
|
||||
|
||||
**Purpose:** Demonstrate that W1 is a usable business capability rather than a successful one-time run.
|
||||
|
||||
### Required demonstration
|
||||
|
||||
At least two live discovery cycles through the approved human interface.
|
||||
|
||||
The validation should demonstrate:
|
||||
|
||||
- manual UI trigger;
|
||||
- configured live sources;
|
||||
- no manual web searching to populate results;
|
||||
- successful source retrieval;
|
||||
- deduplication;
|
||||
- qualification;
|
||||
- provenance;
|
||||
- opportunity presentation;
|
||||
- persisted run history.
|
||||
|
||||
A cycle that correctly finds zero qualifying opportunities may still be successful.
|
||||
|
||||
### Required observations
|
||||
|
||||
Record:
|
||||
|
||||
- run duration;
|
||||
- owner intervention;
|
||||
- source failures;
|
||||
- discovered opportunities;
|
||||
- qualified/potential matches;
|
||||
- false positives observed;
|
||||
- usability problems;
|
||||
- owner review effort.
|
||||
|
||||
### Exit Criteria
|
||||
|
||||
The service can be used repeatedly as a normal business process.
|
||||
|
||||
---
|
||||
|
||||
## Phase 9 — Release 1 Acceptance
|
||||
|
||||
Release 1 is accepted only when all W1 Requirements success criteria are satisfied or explicitly waived by the owner.
|
||||
|
||||
Acceptance review covers:
|
||||
|
||||
### Discovery
|
||||
|
||||
- live sources operate;
|
||||
- real opportunities can be identified;
|
||||
- provenance is preserved.
|
||||
|
||||
### Qualification
|
||||
|
||||
- profile criteria are used;
|
||||
- unsuitable opportunities can be filtered;
|
||||
- unknowns remain unknown;
|
||||
- gaps are visible.
|
||||
|
||||
### UI
|
||||
|
||||
- agent can be launched;
|
||||
- opportunities can be listed;
|
||||
- detail can be reviewed;
|
||||
- profile can be edited.
|
||||
|
||||
### Repeatability
|
||||
|
||||
- multiple cycles demonstrated;
|
||||
- no manual search required;
|
||||
- output is operationally usable.
|
||||
|
||||
### Maintainability
|
||||
|
||||
- project follows AEP SDLC;
|
||||
- source controlled in Gitea;
|
||||
- relevant tests pass;
|
||||
- structure is human-readable;
|
||||
- operating documentation is current.
|
||||
|
||||
---
|
||||
|
||||
# 9. Milestone Schedule
|
||||
|
||||
The detailed work-order durations will be refined during implementation, but the development window is fixed.
|
||||
|
||||
| Milestone | Required outcome |
|
||||
|---|---|
|
||||
| **M0 — Project Ready** | Requirements, Architecture, Project Plan, environment, and repository structure established |
|
||||
| **M1 — Spike Assessed** | Existing implementation disposition recorded |
|
||||
| **M2 — Core Domain Operational** | Opportunity/Profile/Run/qualification structures test cleanly |
|
||||
| **M3 — Discovery Pipeline Operational** | Multiple source adapters execute through approved architecture |
|
||||
| **M4 — Human Vertical Slice** | User can launch a run and review opportunity detail from web UI |
|
||||
| **M5 — Profile Editable** | User can modify qualification criteria through UI |
|
||||
| **M6 — Operational Validation** | Multiple live discovery cycles complete through UI |
|
||||
| **M7 — Release 1** | Requirements accepted by owner |
|
||||
|
||||
**Final development gate:** **September 25, 2026**.
|
||||
|
||||
---
|
||||
|
||||
# 10. Time Budget and Owner Effort
|
||||
|
||||
Owner time must be explicitly recorded beginning with approval of this plan.
|
||||
|
||||
Track separately:
|
||||
|
||||
- architecture/project-management time;
|
||||
- environment setup;
|
||||
- Codex supervision;
|
||||
- code review;
|
||||
- testing;
|
||||
- UI review;
|
||||
- live operational validation;
|
||||
- opportunity review.
|
||||
|
||||
Machine execution time should not be counted as owner effort.
|
||||
|
||||
At the end of Sprint 0, report:
|
||||
|
||||
- total human hours;
|
||||
- implementation elapsed time;
|
||||
- major rework;
|
||||
- incremental spending;
|
||||
- usable capability delivered;
|
||||
- comparison against the development-window target.
|
||||
|
||||
This measurement is part of the Autonomous Enterprise experiment.
|
||||
|
||||
---
|
||||
|
||||
# 11. Incremental Spending
|
||||
|
||||
W1 shares the portfolio's approved Sprint 0 incremental spending ceiling.
|
||||
|
||||
Current W1 incremental spend: **$0** based on existing status reporting.
|
||||
|
||||
The architecture assumes existing:
|
||||
|
||||
- Forge;
|
||||
- Gitea;
|
||||
- VS Code;
|
||||
- Codex;
|
||||
- local infrastructure;
|
||||
- existing model/tool access.
|
||||
|
||||
No paid service should be introduced without explicit approval.
|
||||
|
||||
---
|
||||
|
||||
# 12. Work-Order Strategy
|
||||
|
||||
After plan approval, implementation proceeds through bounded work orders.
|
||||
|
||||
Each work order should contain:
|
||||
|
||||
- objective;
|
||||
- architectural context;
|
||||
- exact scope;
|
||||
- files/components expected to change;
|
||||
- tests required;
|
||||
- acceptance criteria;
|
||||
- exclusions;
|
||||
- reporting requirements.
|
||||
|
||||
Work orders should be small enough that:
|
||||
|
||||
- Codex can complete them without redefining architecture;
|
||||
- Ken can review the result;
|
||||
- ChatGPT can verify progress against the plan;
|
||||
- failure does not invalidate a large body of unrelated work.
|
||||
|
||||
---
|
||||
|
||||
# 13. Initial Work-Order Sequence
|
||||
|
||||
## W1-WO-001 — AEP Shared Services Environment Setup
|
||||
|
||||
Create/establish:
|
||||
|
||||
- Gitea repository;
|
||||
- Forge working copy;
|
||||
- VS Code project;
|
||||
- `.project/`;
|
||||
- W1 component project structure;
|
||||
- version-control verification.
|
||||
|
||||
No product feature work.
|
||||
|
||||
## W1-WO-002 — Spike Inventory and Migration Assessment
|
||||
|
||||
Inventory existing code and classify each component:
|
||||
|
||||
- retain;
|
||||
- refactor;
|
||||
- migrate;
|
||||
- supersede;
|
||||
- remove.
|
||||
|
||||
Produce migration decision artifact.
|
||||
|
||||
No new functional scope.
|
||||
|
||||
## W1-WO-003 — Core Domain and Persistence Baseline
|
||||
|
||||
Establish the approved:
|
||||
|
||||
- Opportunity;
|
||||
- Run;
|
||||
- Profile;
|
||||
- qualification structures;
|
||||
- SQLite persistence;
|
||||
- tests.
|
||||
|
||||
Reuse spike assets where appropriate.
|
||||
|
||||
## W1-WO-004 — Source Adapter Migration
|
||||
|
||||
Migrate/refactor initial source adapters and contract tests.
|
||||
|
||||
## W1-WO-005 — Qualification Pipeline Migration
|
||||
|
||||
Migrate/refactor deterministic and interpretive qualification under the approved architecture.
|
||||
|
||||
## W1-WO-006 — Human Vertical Slice
|
||||
|
||||
Implement the minimum web UI needed to:
|
||||
|
||||
- run W1;
|
||||
- see run state;
|
||||
- review opportunities;
|
||||
- open opportunity detail.
|
||||
|
||||
This work order should produce the first truly usable application milestone.
|
||||
|
||||
## W1-WO-007 — Profile Management
|
||||
|
||||
Implement profile viewing and editing.
|
||||
|
||||
## W1-WO-008 — Operational Validation
|
||||
|
||||
Run and document multiple live discovery cycles.
|
||||
|
||||
Fix only defects required for Release 1 acceptance.
|
||||
|
||||
## W1-WO-009 — Release Review
|
||||
|
||||
Verify:
|
||||
|
||||
- requirements;
|
||||
- tests;
|
||||
- documentation;
|
||||
- usability;
|
||||
- time;
|
||||
- spending;
|
||||
- operational-validation evidence.
|
||||
|
||||
Record Release 1 decision.
|
||||
|
||||
---
|
||||
|
||||
# 14. Progress Reporting
|
||||
|
||||
`opportunity-intelligence/.project/STATUS.md` should make current state understandable without reconstructing chat history.
|
||||
|
||||
Minimum fields:
|
||||
|
||||
```text
|
||||
Current phase:
|
||||
Current milestone:
|
||||
Development deadline:
|
||||
Operational validation state:
|
||||
Owner hours consumed:
|
||||
Incremental spend:
|
||||
Completed:
|
||||
In progress:
|
||||
Blocked:
|
||||
Next authorized work:
|
||||
Latest evidence:
|
||||
```
|
||||
|
||||
The PMO status report should summarize this state rather than replace the project-local record.
|
||||
|
||||
---
|
||||
|
||||
# 15. Definition of Done
|
||||
|
||||
W1 Release 1 is done when:
|
||||
|
||||
1. the capability is available through a human-usable web interface;
|
||||
2. the user can manually trigger discovery;
|
||||
3. multiple configured live sources are supported;
|
||||
4. opportunity results are normalized and deduplicated;
|
||||
5. opportunities are evaluated against the profile;
|
||||
6. unknowns and qualification gaps remain explicit;
|
||||
7. opportunity detail explains what the user must do next;
|
||||
8. original-source provenance is retained;
|
||||
9. the profile can be modified through the UI;
|
||||
10. multiple live discovery cycles have been demonstrated;
|
||||
11. no manual opportunity searching is required to populate those cycles;
|
||||
12. source is in the approved Gitea project;
|
||||
13. relevant tests pass;
|
||||
14. documentation is current;
|
||||
15. actual owner effort and incremental spending are recorded;
|
||||
16. Ken accepts the Release 1 result.
|
||||
|
||||
---
|
||||
|
||||
# 16. Stop / Review Conditions
|
||||
|
||||
Stop implementation and return to project review if:
|
||||
|
||||
- September 25 cannot reasonably be met;
|
||||
- the solution requires substantial infrastructure outside the approved architecture;
|
||||
- W1 begins expanding into CRM, outreach, proposal generation, or other adjacent services;
|
||||
- a technology decision creates significant vendor lock-in not previously approved;
|
||||
- a new paid service is required;
|
||||
- maintainability degrades to preserve prototype shortcuts;
|
||||
- UI work begins requiring a separate frontend platform without demonstrated necessity;
|
||||
- existing implementation proves fundamentally incompatible with the approved architecture.
|
||||
|
||||
---
|
||||
|
||||
# 17. Post-Release Backlog
|
||||
|
||||
The following are explicitly deferred until after Release 1:
|
||||
|
||||
- scheduled execution;
|
||||
- unattended recurring runs;
|
||||
- additional source adapters beyond those required for validation;
|
||||
- opportunity alerts;
|
||||
- sales-development integration;
|
||||
- resume/application drafting;
|
||||
- proposal generation;
|
||||
- pipeline-management integration;
|
||||
- Project Thoth integration;
|
||||
- API exposure;
|
||||
- multi-user operation;
|
||||
- external commercialization;
|
||||
- autonomous external actions.
|
||||
|
||||
Backlog items require separate prioritization and must not silently enter Sprint 0.
|
||||
|
||||
---
|
||||
|
||||
# 18. Release 1 Decision
|
||||
|
||||
At the development gate, the owner records one of:
|
||||
|
||||
- `ACCEPT`
|
||||
- `ACCEPT WITH DEFERRED ITEMS`
|
||||
- `REWORK WITHIN APPROVED WINDOW`
|
||||
- `EXTEND AFTER REVIEW`
|
||||
- `STOP / REDESIGN`
|
||||
|
||||
Release acceptance does not require every future feature.
|
||||
|
||||
It requires the requirements-defined capability to be usable, maintainable, repeatable, and measurable.
|
||||
|
||||
---
|
||||
|
||||
# 19. Project Principle
|
||||
|
||||
> **Build the smallest complete Opportunity Intelligence service that a human can actually use, prove that it repeatedly performs the business function, measure how long it took, and stop adding machinery until the result demonstrates value.**
|
||||
@@ -0,0 +1,714 @@
|
||||
# W1 — Opportunity Intelligence
|
||||
|
||||
## Requirements
|
||||
|
||||
**Project:** W1 — Opportunity Intelligence
|
||||
**Portfolio:** Autonomous Enterprise Portfolio
|
||||
**Classification:** Shared Service
|
||||
**Shared Service Domain:** Sales & Marketing Operations
|
||||
**Parent Project:** AEP Shared Services
|
||||
**Initial Consumer:** Fractional Insight / owner income-acquisition activity
|
||||
**Status:** Draft for approval
|
||||
**Owner:** Ken Schaefer
|
||||
**Initial implementation window:** Sprint 0 — September 17–25, 2026
|
||||
**Related portfolio documents:** `VISION.md`, `PORTFOLIO.md`, `PROJECT-PLAN.md`, `PROJECT-CHARTER.md`, `ARCHITECTURE.md`, `ENTERPRISE-MODEL.md`
|
||||
|
||||
---
|
||||
|
||||
## Project Value Gates
|
||||
|
||||
### Development Window
|
||||
|
||||
**Target:** Make the first complete, human-usable W1 capability available by the end of Sprint 0, **September 25, 2026**.
|
||||
|
||||
The detailed project plan will define:
|
||||
|
||||
* the implementation sequence;
|
||||
* estimated human effort;
|
||||
* milestone dates;
|
||||
* environment setup;
|
||||
* testing;
|
||||
* release criteria.
|
||||
|
||||
The development window measures whether AI-assisted software development materially compresses the time required to create a usable business capability.
|
||||
|
||||
If the capability cannot be made available within the authorized development window, the project must be reviewed before additional development effort is authorized.
|
||||
|
||||
### Operational Validation Window
|
||||
|
||||
**Direct financial validation:** Not applicable.
|
||||
|
||||
W1 is a shared internal business service. It is not presently intended to be sold independently.
|
||||
|
||||
Its value is measured by whether it reliably supports the businesses that consume it.
|
||||
|
||||
**Initial operational validation target:** By the end of Sprint 0, W1 must demonstrate repeatable live opportunity discovery across multiple execution cycles.
|
||||
|
||||
A successful discovery cycle must:
|
||||
|
||||
* execute against configured live sources;
|
||||
* locate available opportunities or explicitly report that none qualify;
|
||||
* evaluate discovered opportunities against the user's profile;
|
||||
* preserve original-source evidence;
|
||||
* identify gaps or uncertainties;
|
||||
* present results through the human interface;
|
||||
* require no manual searching by the user.
|
||||
|
||||
The existing implementation spike has already demonstrated that the concept can locate potentially valuable opportunities. That result is **feasibility evidence**, not final project acceptance.
|
||||
|
||||
### Downstream Business Value
|
||||
|
||||
Longer-term W1 value should be measured by outcomes enabled for consuming businesses, such as:
|
||||
|
||||
* qualified opportunities discovered;
|
||||
* opportunities pursued;
|
||||
* proposals or applications created;
|
||||
* interviews or sales conversations;
|
||||
* contracts;
|
||||
* consulting engagements;
|
||||
* new customers;
|
||||
* employment;
|
||||
* collected revenue attributable to W1-discovered opportunities.
|
||||
|
||||
These are downstream business outcomes, not a separate first-sale KPI for W1 itself.
|
||||
|
||||
---
|
||||
|
||||
# 1. Business Problem
|
||||
|
||||
Business development for consultants and freelancers is time consuming and inconsistent.
|
||||
|
||||
Typical activities include:
|
||||
|
||||
* networking;
|
||||
* cold calling;
|
||||
* advertising;
|
||||
* browsing job and contract sites;
|
||||
* monitoring procurement systems;
|
||||
* checking professional networks;
|
||||
* searching for potential clients.
|
||||
|
||||
These activities require substantial human attention and are vulnerable to missed opportunities.
|
||||
|
||||
A relevant opportunity may:
|
||||
|
||||
* appear on a source the consultant is not currently monitoring;
|
||||
* remain available only briefly;
|
||||
* require a response before the consultant notices it;
|
||||
* be overlooked while the consultant is occupied with billable work;
|
||||
* appear during a period when the consultant is not actively conducting business development.
|
||||
|
||||
This creates a recurring **feast-or-famine business-development cycle**.
|
||||
|
||||
When consultants have active work, business development is often neglected.
|
||||
|
||||
When work ends, business development suddenly becomes urgent.
|
||||
|
||||
This produces several undesirable effects:
|
||||
|
||||
* pipeline development occurs too late;
|
||||
* consultants may accept less desirable work because cash is urgently needed;
|
||||
* ideal opportunities may be missed while the consultant is occupied;
|
||||
* business development becomes reactive rather than continuous;
|
||||
* the consultant repeatedly diverts time from productive work to administrative search activity.
|
||||
|
||||
W1 exists to reduce this administrative burden and maintain continuous awareness of potentially valuable opportunities.
|
||||
|
||||
---
|
||||
|
||||
# 2. Shared-Service Purpose
|
||||
|
||||
W1 is not itself the consulting business.
|
||||
|
||||
W1 is a reusable internal business capability that supports businesses requiring ongoing opportunity discovery.
|
||||
|
||||
Its initial consumer is:
|
||||
|
||||
**Fractional Insight / owner income-acquisition activity**
|
||||
|
||||
Future consumers may include other portfolio businesses that need to monitor external opportunities, including:
|
||||
|
||||
* procurement;
|
||||
* partnerships;
|
||||
* licensing;
|
||||
* sponsorship;
|
||||
* distribution;
|
||||
* sales leads;
|
||||
* contract opportunities;
|
||||
* other market opportunities.
|
||||
|
||||
The service should therefore be designed for reuse without becoming prematurely generalized.
|
||||
|
||||
---
|
||||
|
||||
# 3. Intended Users
|
||||
|
||||
The initial user is the owner/operator of a consulting or freelance business.
|
||||
|
||||
The broader intended user category includes:
|
||||
|
||||
* independent consultants;
|
||||
* freelancers;
|
||||
* small professional-services business owners;
|
||||
* other professionals whose income depends on repeatedly finding new engagements.
|
||||
|
||||
The typical user is capable of evaluating and performing professional work but either:
|
||||
|
||||
* dislikes business-development administration;
|
||||
* does not have enough time to perform it consistently;
|
||||
* becomes occupied with existing client work;
|
||||
* lacks visibility into all possible opportunity sources;
|
||||
* performs opportunity searching only when income becomes urgent.
|
||||
|
||||
W1 should allow the user to concentrate on professional judgment and relationship decisions while delegating repetitive discovery and initial qualification work to the system.
|
||||
|
||||
---
|
||||
|
||||
# 4. Product Objective
|
||||
|
||||
W1 will provide a human-operated Opportunity Intelligence capability consisting initially of two major components:
|
||||
|
||||
1. **Opportunity Intelligence Agent**
|
||||
2. **Human User Interface**
|
||||
|
||||
The agent discovers and evaluates opportunities.
|
||||
|
||||
The interface allows the human user to operate the capability, review findings, and control the criteria used by the agent.
|
||||
|
||||
The system supports human decision-making.
|
||||
|
||||
It does not initially replace the human in consequential external actions.
|
||||
|
||||
---
|
||||
|
||||
# 5. Opportunity Intelligence Agent
|
||||
|
||||
## 5.1 Discovery
|
||||
|
||||
The agent must be capable of searching configured sources for opportunities that may be relevant to the user.
|
||||
|
||||
Potential opportunity types include:
|
||||
|
||||
* full-time employment;
|
||||
* part-time employment;
|
||||
* contract engagements;
|
||||
* consulting engagements;
|
||||
* freelance projects;
|
||||
* public procurement opportunities;
|
||||
* potential client opportunities where appropriate.
|
||||
|
||||
The specific sources supported in the first release will be determined during architecture and project planning.
|
||||
|
||||
The service should support additional sources without requiring redesign of the entire application.
|
||||
|
||||
---
|
||||
|
||||
## 5.2 Manual Execution
|
||||
|
||||
For the initial W1 release, the agent will run only when manually triggered by the user.
|
||||
|
||||
Scheduled or continuous execution is a future capability and is not required for initial acceptance.
|
||||
|
||||
The user must be able to initiate a discovery run from the human interface.
|
||||
|
||||
---
|
||||
|
||||
## 5.3 Qualification
|
||||
|
||||
The agent must evaluate discovered opportunities against a configurable user profile.
|
||||
|
||||
Evaluation may consider criteria such as:
|
||||
|
||||
* professional experience;
|
||||
* technical skills;
|
||||
* industry experience;
|
||||
* role preferences;
|
||||
* engagement type;
|
||||
* location;
|
||||
* remote-work requirements;
|
||||
* compensation;
|
||||
* citizenship or work-authorization requirements;
|
||||
* certifications;
|
||||
* travel requirements;
|
||||
* clearance requirements;
|
||||
* contract requirements;
|
||||
* bidder prerequisites;
|
||||
* other user-defined constraints.
|
||||
|
||||
The agent must distinguish among:
|
||||
|
||||
* confirmed matching evidence;
|
||||
* confirmed disqualifying evidence;
|
||||
* unknown information;
|
||||
* information requiring user clarification.
|
||||
|
||||
The system must not infer that an unknown qualification exists merely because it would improve the apparent match.
|
||||
|
||||
---
|
||||
|
||||
## 5.4 Opportunity Filtering
|
||||
|
||||
The system must use profile criteria to reduce the raw discovery set to opportunities that warrant human review.
|
||||
|
||||
Filtering must not silently discard potentially useful opportunities without preserving enough information to understand why the opportunity was excluded.
|
||||
|
||||
The application should distinguish among:
|
||||
|
||||
* qualified opportunities;
|
||||
* potentially qualified opportunities with unresolved gaps;
|
||||
* clearly unsuitable opportunities;
|
||||
* expired or otherwise unavailable opportunities.
|
||||
|
||||
---
|
||||
|
||||
# 6. Opportunity Detail
|
||||
|
||||
Each valid or potentially valid opportunity must have a detailed human-readable record.
|
||||
|
||||
At minimum, the detail view must show:
|
||||
|
||||
* opportunity title;
|
||||
* organization or customer;
|
||||
* opportunity type;
|
||||
* source;
|
||||
* original-source link;
|
||||
* date discovered;
|
||||
* posting date where available;
|
||||
* closing or application deadline where available;
|
||||
* location or remote status where available;
|
||||
* compensation or contract value where available;
|
||||
* summary of the opportunity;
|
||||
* why the opportunity appears relevant;
|
||||
* profile criteria that match;
|
||||
* criteria that do not match;
|
||||
* criteria that remain unknown;
|
||||
* gaps that must be resolved;
|
||||
* prerequisites;
|
||||
* what the user must do to pursue the opportunity;
|
||||
* current opportunity status.
|
||||
|
||||
The user should not need to inspect raw source files or internal execution logs to understand what action is required.
|
||||
|
||||
---
|
||||
|
||||
# 7. Human User Interface
|
||||
|
||||
The first usable release must provide a human-oriented interface.
|
||||
|
||||
Raw JSON, Markdown files, database rows, logs, or run directories may support auditing and troubleshooting but do not constitute the primary user interface.
|
||||
|
||||
The UI must provide the following capabilities.
|
||||
|
||||
## 7.1 Launch Agent
|
||||
|
||||
The user must be able to manually initiate an Opportunity Intelligence discovery run.
|
||||
|
||||
The interface must communicate:
|
||||
|
||||
* that a run has started;
|
||||
* whether it completed successfully;
|
||||
* whether errors occurred;
|
||||
* when the most recent run occurred.
|
||||
|
||||
---
|
||||
|
||||
## 7.2 Opportunity Listing
|
||||
|
||||
The interface must provide a consolidated listing of opportunities discovered by the system.
|
||||
|
||||
The list should make it possible to quickly identify opportunities that warrant attention.
|
||||
|
||||
The exact presentation and filtering controls will be determined during architecture and implementation design.
|
||||
|
||||
---
|
||||
|
||||
## 7.3 Opportunity Detail View
|
||||
|
||||
The user must be able to open an individual opportunity and review its detailed evaluation.
|
||||
|
||||
The detail view must clearly communicate:
|
||||
|
||||
* why the opportunity was surfaced;
|
||||
* unresolved questions;
|
||||
* significant disqualifiers;
|
||||
* source evidence;
|
||||
* what the user must do next.
|
||||
|
||||
---
|
||||
|
||||
## 7.4 Configurable User Profile
|
||||
|
||||
The user must have a human-readable way to review and modify the profile used for qualification.
|
||||
|
||||
The profile must distinguish between:
|
||||
|
||||
* established facts;
|
||||
* preferences;
|
||||
* requirements;
|
||||
* exclusions;
|
||||
* unknown information.
|
||||
|
||||
Profile changes must affect subsequent opportunity evaluations.
|
||||
|
||||
The user must not be required to edit source code to change normal qualification criteria.
|
||||
|
||||
---
|
||||
|
||||
# 8. Provenance and Evidence Requirements
|
||||
|
||||
Opportunity Intelligence must preserve enough evidence for the user to independently verify important conclusions.
|
||||
|
||||
For each discovered opportunity, the system must retain:
|
||||
|
||||
* original source;
|
||||
* original-source URL where available;
|
||||
* discovery timestamp;
|
||||
* source-specific identifier where available;
|
||||
* relevant retrieved source information;
|
||||
* qualification result.
|
||||
|
||||
Generated summaries must not replace access to the original opportunity.
|
||||
|
||||
Where source information conflicts, the system should preserve the conflict rather than silently selecting whichever value is most convenient.
|
||||
|
||||
---
|
||||
|
||||
# 9. Human Authority
|
||||
|
||||
W1 is initially an intelligence and decision-support service.
|
||||
|
||||
The first release is not authorized to independently:
|
||||
|
||||
* submit job applications;
|
||||
* send client outreach;
|
||||
* submit proposals;
|
||||
* bid on procurements;
|
||||
* accept contracts;
|
||||
* negotiate terms;
|
||||
* commit funds;
|
||||
* agree to customer obligations;
|
||||
* make other consequential external commitments.
|
||||
|
||||
The system may identify and explain the actions required to pursue an opportunity.
|
||||
|
||||
The human user decides whether those actions occur.
|
||||
|
||||
Future delegated actions require separate requirements, architecture, authorization, and controls.
|
||||
|
||||
---
|
||||
|
||||
# 10. Usability Requirements
|
||||
|
||||
A user should be able to operate W1 without understanding its internal file structure or source code.
|
||||
|
||||
The normal workflow should be:
|
||||
|
||||
1. Open the W1 interface.
|
||||
2. Review or update the qualification profile if necessary.
|
||||
3. Run Opportunity Intelligence.
|
||||
4. Review the resulting opportunities.
|
||||
5. Open promising opportunities.
|
||||
6. Understand why each opportunity was surfaced.
|
||||
7. Understand what must be done to pursue it.
|
||||
|
||||
The system should minimize administrative effort rather than merely relocating administrative effort from external websites into internal files.
|
||||
|
||||
---
|
||||
|
||||
# 11. Maintainability Requirements
|
||||
|
||||
The implementation must be designed for ongoing modification.
|
||||
|
||||
Source code must be:
|
||||
|
||||
* human readable;
|
||||
* logically organized;
|
||||
* maintainable by another developer;
|
||||
* generously formatted;
|
||||
* meaningfully commented where behavior or intent is not immediately obvious;
|
||||
* divided into understandable components;
|
||||
* supported by automated tests where appropriate.
|
||||
|
||||
Test-driven development is the preferred implementation approach.
|
||||
|
||||
Application structure, naming, configuration, and documentation should follow established AEP software-development practices.
|
||||
|
||||
Detailed SDLC workflow belongs in `W1-PROJECT-PLAN.md`.
|
||||
|
||||
---
|
||||
|
||||
# 12. Initial Scope
|
||||
|
||||
The first W1 release includes:
|
||||
|
||||
* manually triggered opportunity discovery;
|
||||
* multiple configured opportunity sources;
|
||||
* profile-based qualification;
|
||||
* opportunity filtering;
|
||||
* gap identification;
|
||||
* source provenance;
|
||||
* opportunity listing;
|
||||
* opportunity detail view;
|
||||
* profile configuration;
|
||||
* human-readable run status.
|
||||
|
||||
---
|
||||
|
||||
# 13. Explicitly Out of Scope for Initial Release
|
||||
|
||||
The initial project does not require:
|
||||
|
||||
* scheduled execution;
|
||||
* continuous monitoring;
|
||||
* autonomous applications;
|
||||
* autonomous client outreach;
|
||||
* autonomous procurement bidding;
|
||||
* automated contract acceptance;
|
||||
* CRM replacement;
|
||||
* automated invoicing;
|
||||
* financial transactions;
|
||||
* generalized multi-agent infrastructure;
|
||||
* mobile application;
|
||||
* advanced analytics;
|
||||
* elaborate dashboarding;
|
||||
* commercial multi-user SaaS capability.
|
||||
|
||||
These capabilities may become future requirements only after the initial project demonstrates value.
|
||||
|
||||
---
|
||||
|
||||
# 14. Success Criteria
|
||||
|
||||
W1 succeeds as an initial development project when all of the following are demonstrated.
|
||||
|
||||
## Discovery
|
||||
|
||||
* The agent successfully searches configured live sources.
|
||||
* The agent identifies real opportunities.
|
||||
* Original-source information is preserved.
|
||||
|
||||
## Qualification
|
||||
|
||||
* Opportunities are evaluated against the configured user profile.
|
||||
* Clearly unsuitable opportunities can be filtered appropriately.
|
||||
* Missing or unknown qualifications are explicitly identified.
|
||||
* Unknown information is not silently converted into assumed qualifications.
|
||||
|
||||
## Opportunity Intelligence
|
||||
|
||||
* Each valid or potentially valid opportunity receives a detailed evaluation.
|
||||
* The evaluation explains why the opportunity was surfaced.
|
||||
* The evaluation identifies material gaps or unresolved questions.
|
||||
* The evaluation explains what the user must do to pursue the opportunity.
|
||||
|
||||
## User Interface
|
||||
|
||||
* The human user can launch an agent run through the interface.
|
||||
* The human user can review a consolidated opportunity list.
|
||||
* The human user can open and review individual opportunity details.
|
||||
* The human user can view and modify the qualification profile without modifying source code.
|
||||
|
||||
## Repeatability
|
||||
|
||||
* The capability successfully completes multiple live discovery cycles.
|
||||
* Running the capability does not require the user to manually perform the underlying opportunity search.
|
||||
* Results are presented consistently enough for normal human operation.
|
||||
|
||||
## Maintainability
|
||||
|
||||
* The project follows the approved AEP SDLC.
|
||||
* Source is under version control.
|
||||
* Automated tests cover appropriate behavior.
|
||||
* The implementation is understandable and maintainable.
|
||||
* Operating instructions are documented.
|
||||
|
||||
---
|
||||
|
||||
# 15. Operational Value Criteria
|
||||
|
||||
Because W1 is a Shared Service, its initial value is measured operationally rather than through a direct sale.
|
||||
|
||||
Initial value will be assessed using:
|
||||
|
||||
1. **Discovery effectiveness** — does it find opportunities the user should know about?
|
||||
2. **Qualification effectiveness** — does it reduce irrelevant opportunities while retaining plausible ones?
|
||||
3. **Repeatability** — does it continue performing useful discovery across multiple runs?
|
||||
4. **Administrative leverage** — does it reduce the amount of human searching and initial evaluation required?
|
||||
5. **Actionability** — can the user understand and pursue a surfaced opportunity without reconstructing the research himself?
|
||||
|
||||
The existing implementation spike has already produced at least one opportunity considered useful enough to demonstrate feasibility.
|
||||
|
||||
That result should be retained as evidence, but the completed project must demonstrate repeatable value through the approved user experience.
|
||||
|
||||
---
|
||||
|
||||
# 16. Downstream Business Metrics
|
||||
|
||||
W1 should eventually support measurement of its contribution to the businesses that consume it.
|
||||
|
||||
Possible downstream metrics include:
|
||||
|
||||
* number of opportunities discovered;
|
||||
* number of qualified opportunities;
|
||||
* number reviewed by the user;
|
||||
* number pursued;
|
||||
* applications submitted;
|
||||
* proposals submitted;
|
||||
* sales conversations;
|
||||
* interviews;
|
||||
* contracts awarded;
|
||||
* engagements started;
|
||||
* collected revenue;
|
||||
* owner time spent per discovery cycle;
|
||||
* owner time saved compared with manual discovery.
|
||||
|
||||
These measurements belong to business performance reporting and should not be confused with W1's development acceptance criteria.
|
||||
|
||||
---
|
||||
|
||||
# 17. Enterprise Placement
|
||||
|
||||
W1 is classified under the AEP Enterprise Model as:
|
||||
|
||||
```text
|
||||
Autonomous Enterprise Portfolio
|
||||
└── Shared Services
|
||||
└── Sales & Marketing Operations
|
||||
└── Opportunity Intelligence
|
||||
```
|
||||
|
||||
The initial consumer is:
|
||||
|
||||
```text
|
||||
Fractional Insight / owner income acquisition
|
||||
```
|
||||
|
||||
W1 should therefore be designed as a reusable business capability rather than as functionality permanently embedded inside Fractional Insight.
|
||||
|
||||
---
|
||||
|
||||
# 18. Source Project Placement
|
||||
|
||||
W1 is expected to reside within the formal:
|
||||
|
||||
**AEP Shared Services**
|
||||
|
||||
source project.
|
||||
|
||||
Conceptually:
|
||||
|
||||
```text
|
||||
AEP-Shared-Services/
|
||||
│
|
||||
├── .project/
|
||||
│
|
||||
├── opportunity-intelligence/
|
||||
│ ├── .project/
|
||||
│ └── ...
|
||||
│
|
||||
└── ...
|
||||
```
|
||||
|
||||
The exact internal organization will be finalized in `W1-ARCHITECTURE.md`.
|
||||
|
||||
W1 should maintain its own project-control artifacts even though it resides within the larger shared-services repository.
|
||||
|
||||
---
|
||||
|
||||
# 19. Relationship to Project Thoth
|
||||
|
||||
W1 is not currently classified as a Project Thoth application.
|
||||
|
||||
Project Thoth may provide supporting capabilities where appropriate, including:
|
||||
|
||||
* knowledge retrieval;
|
||||
* source management;
|
||||
* provenance;
|
||||
* owner-context retrieval;
|
||||
* document analysis.
|
||||
|
||||
Those capabilities should be treated as dependencies or interfaces where justified.
|
||||
|
||||
Opportunity Intelligence remains fundamentally a **business operations capability**, not a knowledge-management product.
|
||||
|
||||
This boundary may be revisited if future requirements materially change.
|
||||
|
||||
---
|
||||
|
||||
# 20. Existing Implementation Work
|
||||
|
||||
Work completed before approval of these requirements is classified as an **implementation spike / feasibility prototype**.
|
||||
|
||||
Its artifacts may provide useful evidence concerning:
|
||||
|
||||
* available sources;
|
||||
* source ingestion;
|
||||
* opportunity records;
|
||||
* qualification logic;
|
||||
* owner-profile modeling;
|
||||
* provenance;
|
||||
* deterministic replay;
|
||||
* testing;
|
||||
* practical feasibility.
|
||||
|
||||
The spike does not define the approved product architecture.
|
||||
|
||||
Existing code may be:
|
||||
|
||||
* retained;
|
||||
* refactored;
|
||||
* migrated;
|
||||
* incorporated into the AEP Shared Services project;
|
||||
* partially reused;
|
||||
* or superseded
|
||||
|
||||
based on the approved architecture and project plan.
|
||||
|
||||
No prior implementation choice is automatically grandfathered into the production architecture.
|
||||
|
||||
---
|
||||
|
||||
# 21. Project Management and Measurement
|
||||
|
||||
At all times, the project should make it possible to answer:
|
||||
|
||||
* What phase are we in?
|
||||
* What has been completed?
|
||||
* What remains?
|
||||
* What is blocking progress?
|
||||
* How much owner effort has been consumed?
|
||||
* Are we still inside the development window?
|
||||
* Has the service demonstrated operational value?
|
||||
* Is the service reducing business-development effort?
|
||||
* What downstream business outcomes has it enabled?
|
||||
|
||||
The project should preserve sufficient evidence to answer these questions without reconstructing history from chat transcripts.
|
||||
|
||||
---
|
||||
|
||||
# 22. Next Project Gate
|
||||
|
||||
Upon approval of this document, the next required artifact is:
|
||||
|
||||
**`W1-ARCHITECTURE.md`**
|
||||
|
||||
The architecture must define:
|
||||
|
||||
* W1's boundary within AEP Shared Services;
|
||||
* major components;
|
||||
* user-interface architecture;
|
||||
* agent/runtime architecture;
|
||||
* source-adapter model;
|
||||
* profile model;
|
||||
* opportunity-information model;
|
||||
* persistence;
|
||||
* provenance;
|
||||
* interfaces;
|
||||
* deployment;
|
||||
* security;
|
||||
* Project Thoth dependencies, if any;
|
||||
* migration of useful implementation-spike assets;
|
||||
* testing architecture;
|
||||
* replaceability and future extension points.
|
||||
|
||||
No additional W1 feature-development work orders should be issued until `W1-ARCHITECTURE.md` and `W1-PROJECT-PLAN.md` have been approved.
|
||||
Reference in New Issue
Block a user