Forge Platform

Handbook

Defined, Demonstrated, and Vision Honesty

Forge's maturity labeling is a quiet but important innovation. It distinguishes what is defined, what is demonstrated with evidence, and what remains vision.

Updated

Core Thesis

Forge's maturity labeling is a quiet but important innovation. It distinguishes what is defined, what is demonstrated with evidence, and what remains vision.

The standout idea is: credible agentic SDLC needs maturity honesty as much as it needs autonomy.

Condensed Thought

The Forge docs separate L1-L3 demonstrated proof-of-concept territory from L4-L8 vision-gated ambition. That distinction matters. It avoids the common trap of presenting a policy table, architecture sketch, or aspirational roadmap as an implemented autonomous system.

This creates a more trustworthy product narrative. Forge can be ambitious without pretending all ambition has already shipped.

Why It Stands Out

The agentic software market is full of large claims. Buyers, engineers, and governance teams need a way to know what is real today, what has evidence, and what is a roadmap bet. Forge's defined/demonstrated/vision distinction helps establish that credibility.

It also makes internal planning stronger. Teams can decide which parts need schema work, platform enforcement, proof runs, human review loops, security hardening, or ADRs before being presented as production capability.

Forge Ecosystem Hooks

  • Autonomy levels provide the surface where maturity labels are most visible.
  • EvidencePacket can prove a demonstrated run.
  • Lenses can display maturity status and run evidence.
  • Blueprints can define policy before implementation exists.
  • ADRs can gate movement from vision to implemented platform capability.
  • Forge Campaign appears as part of the higher-level vision path for multi-repo and larger-scope automation.

Architecture Implications

Maturity honesty can become an operating pattern:

  1. Every capability should have a maturity label.
  2. Demonstrated should require a repeatable run with machine evidence.
  3. Vision should be acceptable but clearly marked.
  4. Docs should distinguish policy definition from runtime enforcement.
  5. Roadmap items should identify required ADRs, schemas, workcells, evidence, and gates.
  6. Lenses could show capability readiness directly inside run setup.

This turns roadmap transparency into a governance asset.

Blog Post Seed Paragraph

Agentic SDLC needs ambition, but ambition without maturity labels quickly becomes hype. Forge separates defined policy, demonstrated capability, and vision-gated roadmap. A level can be described before it is implemented, but it should not be sold as demonstrated until a repeatable run produces evidence. That simple discipline changes the conversation. Teams can dream bigger while still telling the truth about what is usable today.

Risks And Counterarguments

Too many labels can create confusion. Forge should keep the maturity vocabulary small and operationally meaningful. The most important distinction is whether a capability has repeatable evidence or is still an architectural vision.

Who this is for

Architects and platform engineers evaluating Forge (evaluate stage). Executives can stop after the core thesis; agents should honor the agent contract in the page frontmatter.

Evidence and maturity

Maturity: defined — this page records design intent captured from the Agentic SDLC standout analysis and reviewed for the platform handbook. Where behavior is shipped and observable it is called out explicitly; everything else should be read as direction, not commitment. Evidence trail: the hydration pack seed, the content registry entry for this content_id, and the claim registry entries linked via claim_ids.

How to use this page

  • Evaluating Forge? Read the core thesis and ecosystem hooks, then continue with the standout index.
  • Designing against the platform? Verify boundaries in the platform reference architecture before implementation.
  • Automating? Use the frontmatter agent_contract and cite content_id in generated output.

Agent contract

Allowed actions
  • summarize this page for evaluation questions
  • cross-reference claims via claim_ids and source_refs
Safe to infer
  • the architectural boundary described here is the intended design
Do not infer
  • production readiness beyond the stated maturity level
  • specific vendor, customer, or benchmark commitments
Key artifacts
  • forge-platform/docs-governance/content_registry.yaml

Machine-readable guidance from this page's frontmatter: what automated consumers may do, infer, and must not infer.