Planned capability directions for shaped intelligence
This public planning page explains what three planned shaped-intelligence capabilities would carry, why the investment direction is deliberately two-step and why code development remains a distinct transfer-evaluation direction despite intertwined development origins. All remain planning context outside current evidence.
Planning context
Shared claim status, distinct functions and relationships
Stock-evaluating shaped intelligence, portfolio-managing shaped intelligence and code-developing shaped intelligence share the same public claim status: planning context outside the current public capability-evidence package. Their work objects, functions, dependencies and evaluation relationships differ, and naming or illustrating a direction does not create evidence or rank maturity.
The intended practical direction is the same: move from repeatedly rebuilding the work manually to directing shaped intelligence that can carry more of the recurring domain burden. That remains an evaluation objective, not a current capability result.
Planned directions at a glance
Planned directions at a glance
Planned capability direction
Development and dependency
Primary work object and function
Public evaluation and limit
Stock-evaluating shaped intelligence
Prospective cross-domain transfer evaluation and intended first bounded stock-domain capability.
One listed stock. It would preserve source basis, evidence, assumptions, valuation and decision context, unresolved questions, review state and next action for repeated evaluation; it is deliberately not portfolio-aware.
Can shaped intelligence carry more recurring listed-stock evaluation burden while decisions and real-world action remain human-owned? No financial advice, autonomous trading, guaranteed performance or authority to act.
Portfolio-managing shaped intelligence
Possible later superset extension, dependent on first materialising and evaluating stock-evaluating shaped intelligence.
The portfolio as an interacting whole. It would add holdings and transaction state, sizing, concentration, combined exposures, allocation, cash constraints, aggregate risk, rebalancing, outcomes, portfolio history, review state and continuation across decisions and review cycles.
Can shaped intelligence carry more recurring portfolio-management burden while portfolio decisions and real-world action remain human-owned? No portfolio-management assurance or financial advice.
Code-developing shaped intelligence
Distinct prospective cross-domain transfer evaluation.
An evolving code-development workstream. It would carry research, specification, architectural decision context and rationale, implementation state, testing, defects, unresolved matters and resumption across development cycles.
Can shaped intelligence carry more recurring code-development burden while architectural judgement and decisions, review, approval and deployment action remain human-owned? No implementation guidance or software assurance.
Investment direction
Why investment evaluation comes before portfolio management
The investment-analysis approach has earlier roots in postgraduate financial-management and MBA study and subsequent investment work. From July 2022, it was substantially developed alongside structured information and workflow support for investment analysis and portfolio review. The analytical work defined the evidence, decision-context and review needs; software development made the process operational.
For planned AI-shaping evaluation, that broader problem is separated into two bounded work objects. Stock-evaluating shaped intelligence would first carry the recurring work needed to form and review an evidence and decision basis for one listed stock, deliberately without portfolio state. Portfolio-managing shaped intelligence would be a later, broader capability carrying portfolio state and relationships among holdings, transactions, constraints, exposures, outcomes and future decisions. Portfolio management is therefore not merely investment evaluation repeated more often.
The sequence uses the same bounded-then-broader structural hypothesis as the demonstrated vendor-evaluating-to-project-managing progression: first establish a bounded evaluating capability, then assess whether it can extend into the broader managing capability. That similarity is planning rationale only; it does not establish that the investment-domain materialisation will succeed. The public development chronology appears on About.
Code-development direction
Why code development is a distinct transfer evaluation
The software-development work developed alongside investment-analysis and portfolio-review work because the supporting information system was necessary to make the analytical and review work operational, while the domain work drove requirements, evidence handling, data structures, workflow logic and testing. Conversational AI was used progressively across both the analytical and technical work.
The planned question is not whether AI can generate code. It is whether AI-shaping intelligence can use its shaping pattern to develop code-developing shaped intelligence through a distinct transfer evaluation, and whether that domain-facing capability can then carry more of the recurring burden across changing requirements, architectural decision context and rationale, implementation, testing, defect handling, review and resumption.
For uncertain or evolving code-development work, this site treats iterative AI work as the stronger default while recognising that iteration alone can leave continuity, review-state and resumption burden with the person. The bounded development position is explained on Specification-led AI work vs Iterative AI work. The private application stack and implementation mechanics remain outside the public plan.
How the development relationships differ
Their development origins are intertwined, but stock-evaluating and code-developing shaped intelligence remain distinct prospective cross-domain transfer-evaluation directions. Portfolio-managing shaped intelligence is a possible later superset extension whose evaluation depends on first materialising and evaluating the deliberately non-portfolio-aware stock capability. All three remain planning context; development logic and dependency do not create current capability evidence.
What changes a direction's status
A planned direction should not become a public capability claim until the work domain is bounded, the shaping approach is established, shaped intelligence is materially developed, repeated work-burden shift is evaluated and a public-safe evidence object supports the claim.
Public planning boundary
Planning context only: these directions are not current capability evidence, implementation commitments, product announcements or authority to rely on a capability. Stock- and portfolio-related directions do not provide financial advice, autonomous trading, guaranteed performance or authority to act; the code-development direction does not provide implementation guidance or software assurance.